On Mon, Feb 24, 2025 at 10:52:45PM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Provide support to mseal the uprobe mapping.
>
> Unlike other system mappings, the uprobe mapping is not
> established during program startup. However, its lifetime is the same
> as the process's lifetime. It
On Mon, Feb 24, 2025 at 10:52:44PM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on UML, covering
> the vdso.
>
> Testing passes on UML.
Maybe expand on this by stating that it has been confirmed by Benjamin (I
_believe_) that UML has no ne
On Mon, Feb 24, 2025 at 10:52:43PM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on arm64, covering
> the vdso, vvar, and compat-mode vectors and sigpage mappings.
>
> Production release testing passes on Android and Chrome OS.
This is pret
On Mon, Feb 24, 2025 at 10:52:41PM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Add code to detect if the vdso is memory sealed, skip the test
> if it is.
I feel this is a little succinct of a commit message, but I guess it gets to the
heart of what you're doing here.
Fundamentally I me
On Mon, Feb 24, 2025 at 03:07:03PM -0800, Jeff Xu wrote:
> On Mon, Feb 24, 2025 at 3:03 PM Pedro Falcato wrote:
> >
> > On Mon, Feb 24, 2025 at 10:52 PM wrote:
> > >
> > > From: Jeff Xu
> > >
> > > This is V7 version, addressing comments from V6, without code logic
> > > change.
> > >
> > >
On Mon, Feb 24, 2025 at 05:45:13PM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Update memory sealing documentation to include details about system
> mappings.
>
> Signed-off-by: Jeff Xu
> ---
> Documentation/userspace-api/mseal.rst | 7 +++
> 1 file changed, 7 insertions(+)
>
> dif
On Mon, Feb 24, 2025 at 10:52:40PM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Provide infrastructure to mseal system mappings. Establish
> two kernel configs (CONFIG_MSEAL_SYSTEM_MAPPINGS,
> ARCH_HAS_MSEAL_SYSTEM_MAPPINGS) and VM_SEALED_SYSMAP
> macro for future patches.
>
> Signed-off-
Hi Kees
> > I would like to use string_choices helper, and want to add well used
> > but not yet supported strings. But before that I would like to ask one
> > thing about it.
> >
> > I wonder is it guaranteed that the strings were persist after the
> > function returned ? In normally, function
On Tue, Feb 25, 2025 at 01:43:55AM +, Kuninori Morimoto wrote:
>
> Hi Kees, Andy
>
> I would like to use string_choices helper, and want to add well used
> but not yet supported strings. But before that I would like to ask one
> thing about it.
>
> I wonder is it guaranteed that the strings
On 25/02/25 00:49, Christoph Hellwig wrote:
On Mon, Feb 24, 2025 at 08:30:10PM +1030, Gustavo A. R. Silva wrote:
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Change the type of the middle struct members currently causing trouble
fr
Hi Kees, Andy
I would like to use string_choices helper, and want to add well used
but not yet supported strings. But before that I would like to ask one
thing about it.
I wonder is it guaranteed that the strings were persist after the
function returned ? In normally, function local variable wi
On Mon, Feb 24, 2025 at 10:52:42PM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on x86-64,
> covering the vdso, vvar, vvar_vclock.
>
> Production release testing passes on Android and Chrome OS.
>
> Signed-off-by: Jeff Xu
> ---
> arch/
On Fri, 14 Feb 2025 12:43:02 +0100, Thorsten Blum wrote:
> While replacing strncpy() with strscpy(), Bart Van Assche pointed out
> that the code occurs inside sysfs write callbacks, which already uses
> NUL-terminated strings. This allows the string to be passed directly to
> sscanf() without requ
On Mon, Feb 24, 2025 at 08:27:44PM +1030, Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> getting ready to enable it, globally.
>
> Change the type of the middle struct members currently causing trouble
> from `struct bio` to `struct bio_hdr`.
Wh
On Mon, Feb 24, 2025 at 3:03 PM Pedro Falcato wrote:
>
> On Mon, Feb 24, 2025 at 10:52 PM wrote:
> >
> > From: Jeff Xu
> >
> > This is V7 version, addressing comments from V6, without code logic
> > change.
> >
> > --
> >
> > History:
> > V7:
> >
On Mon, Feb 24, 2025 at 10:52 PM wrote:
>
> From: Jeff Xu
>
> This is V7 version, addressing comments from V6, without code logic
> change.
>
> --
>
> History:
> V7:
> - Remove cover letter from the first patch (Liam R. Howlett)
> - Change macro n
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on arm64, covering
the vdso, vvar, and compat-mode vectors and sigpage mappings.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/vdso.c | 22
From: Jeff Xu
Update memory sealing documentation to include details about system
mappings.
Signed-off-by: Jeff Xu
Reviewed-by: Kees Cook
---
Documentation/userspace-api/mseal.rst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/userspace-api/mseal.rst
b/Documentation
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on UML, covering
the vdso.
Testing passes on UML.
Signed-off-by: Jeff Xu
Tested-by: Benjamin Berg
---
arch/um/Kconfig| 1 +
arch/x86/um/vdso/vma.c | 6 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a
From: Jeff Xu
Provide support to mseal the uprobe mapping.
Unlike other system mappings, the uprobe mapping is not
established during program startup. However, its lifetime is the same
as the process's lifetime. It could be sealed from creation.
Signed-off-by: Jeff Xu
---
kernel/events/uprobe
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on x86-64,
covering the vdso, vvar, vvar_vclock.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
---
arch/x86/Kconfig | 1 +
arch/x86/entry/vdso/vma.c | 16 ++--
2 files cha
From: Jeff Xu
This is V7 version, addressing comments from V6, without code logic
change.
--
History:
V7:
- Remove cover letter from the first patch (Liam R. Howlett)
- Change macro name to VM_SEALED_SYSMAP (Liam R. Howlett)
- logging and fclos
From: Jeff Xu
Provide infrastructure to mseal system mappings. Establish
two kernel configs (CONFIG_MSEAL_SYSTEM_MAPPINGS,
ARCH_HAS_MSEAL_SYSTEM_MAPPINGS) and VM_SEALED_SYSMAP
macro for future patches.
Signed-off-by: Jeff Xu
---
include/linux/mm.h | 10 ++
init/Kconfig | 18 +
From: Jeff Xu
Add code to detect if the vdso is memory sealed, skip the test
if it is.
Signed-off-by: Jeff Xu
Reviewed-by: Kees Cook
---
.../testing/selftests/x86/test_mremap_vdso.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/tools/testing/selftests/x86/test_mrem
strncpy() is deprecated for NUL-terminated destination buffers. Use
strscpy() instead and remove the manual NUL-termination.
Compile-tested only.
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Thorsten Blum
---
arch/mips/loongson2ef/common/macht
On Mon, Feb 24, 2025 at 1:06 PM Jeff Xu wrote:
>
> On Mon, Feb 24, 2025 at 12:26 PM Liam R. Howlett
> wrote:
> >
> > * jef...@chromium.org [250224 12:45]:
> > > From: Jeff Xu
> > >
> > > Update memory sealing documentation to include details about system
> > > mappings.
> > >
> > > Signed-off-b
Hi Rob,
On Mon, 2025-02-24 at 09:38 -0600, Rob Herring wrote:
> On Mon, Feb 24, 2025 at 10:28:50AM +, André Draszik wrote:
> > Add the DT binding document for the GPIO module of the Maxim MAX77759.
> >
> > Signed-off-by: André Draszik
> > ---
> > .../bindings/gpio/maxim,max77759-gpio.yaml
Hi Christophe,
Thanks for your review!
On Mon, 2025-02-24 at 21:20 +0100, Christophe JAILLET wrote:
> Le 24/02/2025 à 11:28, André Draszik a écrit :
> > The Maxim MAX77759 is a companion Power Management IC for USB Type-C
> > applications with Battery Charger, Fuel Gauge, temperature sensors, USB
On Mon, Feb 24, 2025 at 1:05 PM Liam R. Howlett wrote:
>
> * jef...@chromium.org [250224 12:45]:
> > From: Jeff Xu
> >
> > Add code to detect if the vdso is memory sealed, skip the test
> > if it is.
>
> It also skips the test if fopen fails on smaps, but maybe that's super
> rare?
>
If we can't
On Mon, Feb 24, 2025 at 12:13 PM Liam R. Howlett
wrote:
>
> * Jeff Xu [250224 14:42]:
> > On Mon, Feb 24, 2025 at 11:25 AM Kees Cook wrote:
> > >
> > > On Mon, Feb 24, 2025 at 11:10:22AM -0800, Jeff Xu wrote:
> > > > On Mon, Feb 24, 2025 at 11:03 AM Liam R. Howlett
> > > > wrote:
> > > > >
> >
* jef...@chromium.org [250224 12:45]:
> From: Jeff Xu
>
> Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on x86-64,
> covering the vdso, vvar, vvar_vclock.
>
> Production release testing passes on Android and Chrome OS.
>
> Signed-off-by: Jeff Xu
> ---
> arch/x86/Kconfig | 1 +
>
On Mon, Feb 24, 2025 at 12:26 PM Liam R. Howlett
wrote:
>
> * jef...@chromium.org [250224 12:45]:
> > From: Jeff Xu
> >
> > Update memory sealing documentation to include details about system
> > mappings.
> >
> > Signed-off-by: Jeff Xu
> > ---
> > Documentation/userspace-api/mseal.rst | 7 +++
* jef...@chromium.org [250224 12:45]:
> From: Jeff Xu
>
> Add code to detect if the vdso is memory sealed, skip the test
> if it is.
It also skips the test if fopen fails on smaps, but maybe that's super
rare?
>
> Signed-off-by: Jeff Xu
> ---
> .../testing/selftests/x86/test_mremap_vdso.c
Le 24/02/2025 à 11:28, André Draszik a écrit :
The Maxim MAX77759 is a companion Power Management IC for USB Type-C
applications with Battery Charger, Fuel Gauge, temperature sensors, USB
Type-C Port Controller (TCPC), NVMEM, and additional GPIO interfaces.
Fuel Gauge and TCPC have separate and
* Jeff Xu [250224 14:40]:
> On Mon, Feb 24, 2025 at 11:18 AM Liam R. Howlett
> wrote:
> >
> > Also, do we need something like the above test for VM_SEALED_SYS?
> >
> Do you mean adding selftest for sealing vdso ? or test the
> VM_SEALED_SYS macro in 32 bit vs 64 bits ?
>
> CONFIG_MSEAL_SYSTEM_MA
* jef...@chromium.org [250224 12:45]:
> From: Jeff Xu
>
> Update memory sealing documentation to include details about system
> mappings.
>
> Signed-off-by: Jeff Xu
> ---
> Documentation/userspace-api/mseal.rst | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/use
* Jeff Xu [250224 14:42]:
> On Mon, Feb 24, 2025 at 11:25 AM Kees Cook wrote:
> >
> > On Mon, Feb 24, 2025 at 11:10:22AM -0800, Jeff Xu wrote:
> > > On Mon, Feb 24, 2025 at 11:03 AM Liam R. Howlett
> > > wrote:
> > > >
> > > > * Jeff Xu [250224 13:44]:
> > > > > On Mon, Feb 24, 2025 at 10:21 AM
On Mon, Feb 24, 2025 at 11:18 AM Liam R. Howlett
wrote:
>
> Also, do we need something like the above test for VM_SEALED_SYS?
>
Do you mean adding selftest for sealing vdso ? or test the
VM_SEALED_SYS macro in 32 bit vs 64 bits ?
CONFIG_MSEAL_SYSTEM_MAPPINGS is by default disabled. I'm not sure
a
On Mon, Feb 24, 2025 at 11:25 AM Kees Cook wrote:
>
> On Mon, Feb 24, 2025 at 11:10:22AM -0800, Jeff Xu wrote:
> > On Mon, Feb 24, 2025 at 11:03 AM Liam R. Howlett
> > wrote:
> > >
> > > * Jeff Xu [250224 13:44]:
> > > > On Mon, Feb 24, 2025 at 10:21 AM Dave Hansen
> > > > wrote:
> > > > >
> >
On Mon, Feb 24, 2025 at 11:32 AM Liam R. Howlett
wrote:
>
> * Jeff Xu [250224 14:23]:
> > On Mon, Feb 24, 2025 at 11:11 AM Liam R. Howlett
> > wrote:
> > >
> > > * Kees Cook [250224 13:55]:
> > > > On Mon, Feb 24, 2025 at 10:52:13AM -0800, Dave Hansen wrote:
> > > > > On 2/24/25 10:44, Jeff Xu
On Mon, Feb 24, 2025 at 11:26 AM Kees Cook wrote:
>
> On Mon, Feb 24, 2025 at 02:10:58PM -0500, Liam R. Howlett wrote:
> > * Kees Cook [250224 13:55]:
> > > On Mon, Feb 24, 2025 at 10:52:13AM -0800, Dave Hansen wrote:
> > > > On 2/24/25 10:44, Jeff Xu wrote:
> > > > > For example:
> > > > > Consi
* Jeff Xu [250224 14:23]:
> On Mon, Feb 24, 2025 at 11:11 AM Liam R. Howlett
> wrote:
> >
> > * Kees Cook [250224 13:55]:
> > > On Mon, Feb 24, 2025 at 10:52:13AM -0800, Dave Hansen wrote:
> > > > On 2/24/25 10:44, Jeff Xu wrote:
> > > > > For example:
> > > > > Consider the case below in
> > >
On Mon, Feb 24, 2025 at 02:10:58PM -0500, Liam R. Howlett wrote:
> * Kees Cook [250224 13:55]:
> > On Mon, Feb 24, 2025 at 10:52:13AM -0800, Dave Hansen wrote:
> > > On 2/24/25 10:44, Jeff Xu wrote:
> > > > For example:
> > > > Consider the case below in
> > > > src/third_party/kernel/v6.6/fs/pro
On Mon, Feb 24, 2025 at 11:10:22AM -0800, Jeff Xu wrote:
> On Mon, Feb 24, 2025 at 11:03 AM Liam R. Howlett
> wrote:
> >
> > * Jeff Xu [250224 13:44]:
> > > On Mon, Feb 24, 2025 at 10:21 AM Dave Hansen
> > > wrote:
> > > >
> > > > On 2/24/25 09:45, jef...@chromium.org wrote:
> > > > > +/*
> > >
On Mon, Feb 24, 2025 at 05:45:08PM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Add code to detect if the vdso is memory sealed, skip the test
> if it is.
>
> Signed-off-by: Jeff Xu
Thanks, after my full 360 on reading this code, I'm back to where I was
originally: it looks good to me
On Mon, Feb 24, 2025 at 11:11 AM Liam R. Howlett
wrote:
>
> * Kees Cook [250224 13:55]:
> > On Mon, Feb 24, 2025 at 10:52:13AM -0800, Dave Hansen wrote:
> > > On 2/24/25 10:44, Jeff Xu wrote:
> > > > For example:
> > > > Consider the case below in
> > > > src/third_party/kernel/v6.6/fs/proc/task
* Jeff Xu [250224 14:07]:
...
> > >
> > > #ifdef CONFIG_64BIT
> > > [ilog2(VM_SEALED)] = "sl",
> > > #endif
> > >
> > > Redefining VM_SEALED to VM_NONE for 32 bit won't detect the problem
> > > in case that "#ifdef CONFIG_64BIT" line is missing.
> >
> > I don't think it is reasonable to insist
* Kees Cook [250224 13:55]:
> On Mon, Feb 24, 2025 at 10:52:13AM -0800, Dave Hansen wrote:
> > On 2/24/25 10:44, Jeff Xu wrote:
> > > For example:
> > > Consider the case below in src/third_party/kernel/v6.6/fs/proc/task_mmu.c,
> > >
> > > #ifdef CONFIG_64BIT
> > > [ilog2(VM_SEALED)] = "sl",
> >
On Mon, Feb 24, 2025 at 08:27:44PM +1030, Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> getting ready to enable it, globally.
>
> Change the type of the middle struct members currently causing trouble
> from `struct bio` to `struct bio_hdr`.
>
On Mon, Feb 24, 2025 at 11:03 AM Liam R. Howlett
wrote:
>
> * Jeff Xu [250224 13:44]:
> > On Mon, Feb 24, 2025 at 10:21 AM Dave Hansen wrote:
> > >
> > > On 2/24/25 09:45, jef...@chromium.org wrote:
> > > > +/*
> > > > + * mseal of userspace process's system mappings.
> > > > + */
> > > > +#ifde
On Mon, Feb 24, 2025 at 11:03 AM Liam R. Howlett
wrote:
>
> * Jeff Xu [250224 13:44]:
> > On Mon, Feb 24, 2025 at 10:21 AM Dave Hansen wrote:
> > >
> > > On 2/24/25 09:45, jef...@chromium.org wrote:
> > > > +/*
> > > > + * mseal of userspace process's system mappings.
> > > > + */
> > > > +#ifde
On Mon, Feb 24, 2025 at 05:45:13PM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Update memory sealing documentation to include details about system
> mappings.
>
> Signed-off-by: Jeff Xu
Thanks, I think the list of programs is good.
Reviewed-by: Kees Cook
--
Kees Cook
* Jeff Xu [250224 13:44]:
> On Mon, Feb 24, 2025 at 10:21 AM Dave Hansen wrote:
> >
> > On 2/24/25 09:45, jef...@chromium.org wrote:
> > > +/*
> > > + * mseal of userspace process's system mappings.
> > > + */
> > > +#ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS
> > > +#define MSEAL_SYSTEM_MAPPINGS_VM_FLAG
On 2/24/25 10:55, Kees Cook wrote:
>> That logic is reasonable. But it's different from the _vast_ majority of
>> other flags.
>>
>> So what justifies VM_SEALED being so different? It's leading to pretty
>> objectively ugly code in this series.
> Note that VM_SEALED is the "is this VMA sealed?" bit
On Mon, Feb 24, 2025 at 10:55 AM Kees Cook wrote:
>
> On Mon, Feb 24, 2025 at 10:52:13AM -0800, Dave Hansen wrote:
> > On 2/24/25 10:44, Jeff Xu wrote:
> > > For example:
> > > Consider the case below in src/third_party/kernel/v6.6/fs/proc/task_mmu.c,
> > >
> > > #ifdef CONFIG_64BIT
> > > [ilog2(V
On Mon, Feb 24, 2025 at 10:52:13AM -0800, Dave Hansen wrote:
> On 2/24/25 10:44, Jeff Xu wrote:
> > For example:
> > Consider the case below in src/third_party/kernel/v6.6/fs/proc/task_mmu.c,
> >
> > #ifdef CONFIG_64BIT
> > [ilog2(VM_SEALED)] = "sl",
> > #endif
> >
> > Redefining VM_SEALED to VM
On 2/24/25 10:44, Jeff Xu wrote:
> For example:
> Consider the case below in src/third_party/kernel/v6.6/fs/proc/task_mmu.c,
>
> #ifdef CONFIG_64BIT
> [ilog2(VM_SEALED)] = "sl",
> #endif
>
> Redefining VM_SEALED to VM_NONE for 32 bit won't detect the problem
> in case that "#ifdef CONFIG_64BIT"
On Mon, Feb 24, 2025 at 10:21 AM Dave Hansen wrote:
>
> On 2/24/25 09:45, jef...@chromium.org wrote:
> > +/*
> > + * mseal of userspace process's system mappings.
> > + */
> > +#ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS
> > +#define MSEAL_SYSTEM_MAPPINGS_VM_FLAGVM_SEALED
> > +#else
> > +#define M
On 2/24/25 09:45, jef...@chromium.org wrote:
> +/*
> + * mseal of userspace process's system mappings.
> + */
> +#ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS
> +#define MSEAL_SYSTEM_MAPPINGS_VM_FLAGVM_SEALED
> +#else
> +#define MSEAL_SYSTEM_MAPPINGS_VM_FLAGVM_NONE
> +#endif
This ends up loo
From: Jeff Xu
Update memory sealing documentation to include details about system
mappings.
Signed-off-by: Jeff Xu
---
Documentation/userspace-api/mseal.rst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/userspace-api/mseal.rst
b/Documentation/userspace-api/mseal.rst
From: Jeff Xu
Provide support to mseal the uprobe mapping.
Unlike other system mappings, the uprobe mapping is not
established during program startup. However, its lifetime is the same
as the process's lifetime. It could be sealed from creation.
Signed-off-by: Jeff Xu
---
kernel/events/uprobe
From: Jeff Xu
This is V6 version, addressing comments from V5, without code logic
change.
History:
---
V6:
- mseal.rst: fix a typo (Randy Dunlap)
- security/Kconfig: add rr into note (Liam R. Howlett)
- remove mseal_system_mappings() and use macro instead (Liam R. Howlett)
- mseal.rs
From: Jeff Xu
Provide infrastructure to mseal system mappings. Establish
two kernel configs (CONFIG_MSEAL_SYSTEM_MAPPINGS,
ARCH_HAS_MSEAL_SYSTEM_MAPPINGS) and MSEAL_SYSTEM_MAPPINGS_VM_FLAG
macro for future patches.
As discussed during mseal() upstream process [1], mseal() protects
the VMAs of a
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on UML, covering
the vdso.
Testing passes on UML.
Signed-off-by: Jeff Xu
Tested-by: Benjamin Berg
---
arch/um/Kconfig| 1 +
arch/x86/um/vdso/vma.c | 6 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on x86-64,
covering the vdso, vvar, vvar_vclock.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
---
arch/x86/Kconfig | 1 +
arch/x86/entry/vdso/vma.c | 16 ++--
2 files cha
From: Jeff Xu
Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on arm64, covering
the vdso, vvar, and compat-mode vectors and sigpage mappings.
Production release testing passes on Android and Chrome OS.
Signed-off-by: Jeff Xu
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/vdso.c | 22
From: Jeff Xu
Add code to detect if the vdso is memory sealed, skip the test
if it is.
Signed-off-by: Jeff Xu
---
.../testing/selftests/x86/test_mremap_vdso.c | 38 +++
1 file changed, 38 insertions(+)
diff --git a/tools/testing/selftests/x86/test_mremap_vdso.c
b/tools/testi
On Sat, Feb 22, 2025 at 02:55:20PM -0500, Ethan Carter Edwards wrote:
> We are trying to get rid of all multiplications from allocation
> functions to prevent integer overflows[1]. Here the multiplication is
> obviously safe, but using kcalloc() is more appropriate and improves
> readability. This
On 2/22/25 20:02, Ethan Carter Edwards wrote:
We are trying to get rid of all multiplications from allocation
functions to prevent integer overflows[1]. Here the multiplication is
obviously safe, but using kcalloc() is more appropriate and improves
readability. This patch has no effect on runt
On Mon, 2025-02-24 at 09:38 -0600, Rob Herring wrote:
> On Mon, Feb 24, 2025 at 10:28:51AM +, André Draszik wrote:
> > Add the DT binding document for the NVMEM module of the Maxim MAX77759.
> >
> > Signed-off-by: André Draszik
> > ---
> > .../bindings/nvmem/maxim,max77759-nvmem.yaml |
Hi Rob,
Thanks for the review!
On Mon, 2025-02-24 at 09:37 -0600, Rob Herring wrote:
> On Mon, Feb 24, 2025 at 10:28:49AM +, André Draszik wrote:
> > Add device tree binding for the Maxim MAX77759 companion PMIC for USB
> > Type-C applications.
> >
> > The MAX77759 includes Battery Charger,
On Sat, 22 Feb 2025 14:19:43 -0500, Ethan Carter Edwards wrote:
> We are trying to get rid of all multiplications from allocation
> functions to prevent integer overflows[1]. Here the multiplication is
> obviously safe, but using kcalloc() is more appropriate and improves
> readability. This patch
On Mon, Feb 24, 2025 at 10:28:51AM +, André Draszik wrote:
> Add the DT binding document for the NVMEM module of the Maxim MAX77759.
>
> Signed-off-by: André Draszik
> ---
> .../bindings/nvmem/maxim,max77759-nvmem.yaml | 50
> ++
> 1 file changed, 50 insertions(+)
On Mon, Feb 24, 2025 at 10:28:50AM +, André Draszik wrote:
> Add the DT binding document for the GPIO module of the Maxim MAX77759.
>
> Signed-off-by: André Draszik
> ---
> .../bindings/gpio/maxim,max77759-gpio.yaml | 47
> ++
> 1 file changed, 47 insertions(+)
>
On Mon, Feb 24, 2025 at 10:28:49AM +, André Draszik wrote:
> Add device tree binding for the Maxim MAX77759 companion PMIC for USB
> Type-C applications.
>
> The MAX77759 includes Battery Charger, Fuel Gauge, temperature sensors,
> USB Type-C Port Controller (TCPC), NVMEM, and a GPIO expander.
On Mon, Feb 24, 2025 at 08:30:10PM +1030, Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> getting ready to enable it, globally.
>
> Change the type of the middle struct members currently causing trouble
> from `struct bio` to `struct bio_hdr`.
>
On Mon, Feb 24, 2025 at 08:31:26PM +0800, Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> getting ready to enable it, globally.
>
> Change the type of the middle struct members currently causing trouble
> from `struct bio` to `struct bio_hdr`.
>
On Mon, 2025-02-24 at 14:07 +0100, Krzysztof Kozlowski wrote:
> On 24/02/2025 11:28, André Draszik wrote:
> > + gpio-controller: true
> > +
> > + "#gpio-cells":
> > + const: 2
> > +
> > + gpio:
> > + $ref: /schemas/gpio/maxim,max77759-gpio.yaml
>
> There is no such file at this moment, so
On Sun, Feb 23, 2025 at 10:50:08AM +0100, Markus Elfring wrote:
> …
> > We are trying to get rid of all multiplications from allocation
> > functions to prevent integer overflows[1]. …
>
> Is an imperative wording more desirable for such a change description?
> https://git.kernel.org/pub/scm/linux
On 24/02/2025 11:28, André Draszik wrote:
> + gpio-controller: true
> +
> + "#gpio-cells":
> +const: 2
> +
> + gpio:
> +$ref: /schemas/gpio/maxim,max77759-gpio.yaml
There is no such file at this moment, so this is not bisectable. What's
more, even if you fix it, you will have dependency
On 24/02/2025 14:02, André Draszik wrote:
> On Mon, 2025-02-24 at 06:48 -0600, Rob Herring (Arm) wrote:
>>
>> On Mon, 24 Feb 2025 10:28:49 +, André Draszik wrote:
>>> Add device tree binding for the Maxim MAX77759 companion PMIC for USB
>>> Type-C applications.
>>>
>>> The MAX77759 includes Bat
On Mon, 2025-02-24 at 06:48 -0600, Rob Herring (Arm) wrote:
>
> On Mon, 24 Feb 2025 10:28:49 +, André Draszik wrote:
> > Add device tree binding for the Maxim MAX77759 companion PMIC for USB
> > Type-C applications.
> >
> > The MAX77759 includes Battery Charger, Fuel Gauge, temperature sensor
devicetree.org/schemas/mfd/maxim,max77759.yaml#
Documentation/devicetree/bindings/mfd/maxim,max77759.example.dtb:
/example-0/i2c/pmic@66/gpio: failed to match any schema with compatible:
['maxim,max77759-gpio']
Documentation/devicetree/bindings/mfd/maxim,max77759.example.dtb:
/example-0/i2c/pm
On Sun, Feb 23, 2025 at 1:19 AM Al Viro wrote:
>
> On Sat, Feb 22, 2025 at 01:12:47PM +0100, Mateusz Guzik wrote:
>
> > General tune is not holding the codebase hostage to obsolete (and
> > probably not at all operational) components. If in doubt, prune it.
>
> What exactly is being held hostage,
On Sat, Feb 22, 2025 at 05:36:11PM +0100, Mateusz Guzik wrote:
> On Sat, Feb 22, 2025 at 4:17 PM Kees Cook wrote:
> >
> > On Sat, Feb 22, 2025 at 01:12:47PM +0100, Mateusz Guzik wrote:
> > > If it was not for the aforementioned bugfix, I would be sending a
> > > removal instead.
> >
> > Less code
On Mon, 2025-02-24 at 10:28 +, André Draszik wrote:
> [...]
>
> +#define MAX77759_GPIOx_TRIGGER(offs, val) (((val) & 1) << (offs))
> +#define MAX77759_GPIOx_TRIGGER_MASK(offs) MAX77759_GPIOx_TRIGGER(offs, ~0)
> +enum max77759_trigger_gpio_type {
> + MAX77759_GPIO_TRIGGER_RISING = 0,
> +
The Maxim MAX77759 is a companion Power Management IC for USB Type-C
applications with Battery Charger, Fuel Gauge, temperature sensors, USB
Type-C Port Controller (TCPC), NVMEM, and additional GPIO interfaces.
Fuel Gauge and TCPC have separate and independent I2C addresses,
register maps, and int
rs/nvmem/max77759-nvmem.c | 156 +
include/linux/mfd/max77759.h | 74 +++
14 files changed, 1751 insertions(+)
---
base-commit: d4b0fd87ff0d4338b259dc79b2b3c6f7e70e8afa
change-id: 20250224-max77759-mfd-aaa7a3121b62
Best regards,
--
André Draszik
The Maxim MAX77759 is a companion Power Management IC for USB Type-C
applications with Battery Charger, Fuel Gauge, temperature sensors, USB
Type-C Port Controller (TCPC), NVMEM, and additional GPIO interfaces.
This driver supports the GPIO functions using the platform device
registered by the cor
The Maxim MAX77759 is a companion Power Management IC for USB Type-C
applications with Battery Charger, Fuel Gauge, temperature sensors, USB
Type-C Port Controller (TCPC), NVMEM, and additional GPIO interfaces.
This driver exposes the non volatile memory using the platform device
registered by the
Add the DT binding document for the GPIO module of the Maxim MAX77759.
Signed-off-by: André Draszik
---
.../bindings/gpio/maxim,max77759-gpio.yaml | 47 ++
1 file changed, 47 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/maxim,max77759-gpio.yaml
Add the DT binding document for the NVMEM module of the Maxim MAX77759.
Signed-off-by: André Draszik
---
.../bindings/nvmem/maxim,max77759-nvmem.yaml | 50 ++
1 file changed, 50 insertions(+)
diff --git a/Documentation/devicetree/bindings/nvmem/maxim,max77759-nvmem.yam
Add device tree binding for the Maxim MAX77759 companion PMIC for USB
Type-C applications.
The MAX77759 includes Battery Charger, Fuel Gauge, temperature sensors,
USB Type-C Port Controller (TCPC), NVMEM, and a GPIO expander.
This describes the core mfd device.
Signed-off-by: André Draszik
---
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Change the type of the middle struct members currently causing trouble
from `struct bio` to `struct bio_hdr`.
We also use `container_of()` whenever we need to retrieve a pointer to
the flexib
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Change the type of the middle struct members currently causing trouble
from `struct bio` to `struct bio_hdr`.
We also use `container_of()` whenever we need to retrieve a pointer to
the flexib
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Change the type of the middle struct members currently causing trouble
from `struct bio` to `struct bio_hdr`.
We also use `container_of()` whenever we need to retrieve a pointer to
the flexib
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Change the type of the middle struct members currently causing trouble
from `struct bio` to `struct bio_hdr`.
We also use `container_of()` whenever we need to retrieve a pointer to
the flexib
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Change the type of the middle struct member currently causing trouble from
`struct bio` to `struct bio_hdr`.
We also use `container_of()` whenever we need to retrieve a pointer to
the flexibl
98 matches
Mail list logo
