On 20/02/25 09:38, Dave Hansen wrote:
> On 2/20/25 09:10, Valentin Schneider wrote:
>>> The LDT and maybe the PEBS buffers are the only implicit supervisor
>>> accesses to vmalloc()'d memory that I can think of. But those are both
>>> handled specially and shouldn't ever get zapped while in use. Th
On Wed, Feb 26, 2025 at 05:26:04PM +0100, Oleg Nesterov wrote:
> On 02/24, jef...@chromium.org wrote:
> >
> > 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 crea
On Wed, Feb 26, 2025 at 09:17:10AM -0800, Jeff Xu wrote:
> On Wed, Feb 26, 2025 at 9:12 AM Liam R. Howlett
> wrote:
> >
> > * Lorenzo Stoakes [250226 00:26]:
> > > On Tue, Feb 25, 2025 at 02:26:50PM -0800, Jeff Xu wrote:
> > > > On Mon, Feb 24, 2025 at 10:20 PM Lorenzo Stoakes
> > > > wrote:
>
The Maxim MAX77759 is a companion PMIC for USB Type-C applications and
includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C
Port Controller (TCPC), NVMEM, and a GPIO expander.
This driver supports the GPIO functions using the platform device
registered by the core MFD driver.
Sig
The Maxim MAX77759 is a companion PMIC for USB Type-C applications and
includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C
Port Controller (TCPC), NVMEM, and a GPIO expander.
This driver exposes the non volatile memory using the platform device
registered by the core MFD driver.
Hi,
This series improves support for the Maxim Integrated MAX77759
companion PMIC for USB Type-C applications using the MFD framework.
This series must be applied in-order, due to interdependencies of some
of the patches:
* to avoid use of undocumented compatibles by the newly added drivers,
th
The Maxim MAX77759 is a companion PMIC for USB Type-C applications and
includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C
Port Controller (TCPC), NVMEM, and a GPIO expander.
This describes the top-level device.
Signed-off-by: André Draszik
---
v2:
* rename expected nvmem subd
The Maxim MAX77759 is a companion PMIC for USB Type-C applications and
includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C
Port Controller (TCPC), NVMEM, and a GPIO expander.
This describes its GPIO module.
Signed-off-by: André Draszik
---
v2:
* drop 'interrupts' property and
I had just 'nvmem' initially,
> but that doesn't work:
>
> .../maxim,max77759.example.dtb: pmic@66: nvmem: {'compatible':
> ['maxim,max77759-nvmem'], 'nvmem-layout': {'compatible': ['fixed-
> layout'], '#address-cells': 1, '#size-cells': 1, 'reboot-mode@0': {'reg':
> [[0, 4]]}, 'boot-reason@4': {'reg': [[4, 4]]},
> 'shutdown-user-flag@8': {'reg': [[8, 1]]}, 'rsoc@10': {'reg': [[10, 2]]}}} is
> not of type 'array'
> from schema $id:
> http://devicetree.org/schemas/nvmem/nvmem-consumer.yaml#
>
> I don't know if this can be made to work, i.e. can you have both
> in yaml? Can a type be declared as a oneOf or something like that?
I wasn't able to get this to work with a node name of just
'nvmem'.
If anybody has any suggestions, I'll gladly try them.
I've renamed the node from pmic-nvmem to nvmem-0 in v2, though.
https://lore.kernel.org/all/20250226-max77759-mfd-v2-3-a65ebe2bc...@linaro.org/
Cheers,
Andre
The Maxim MAX77759 is a companion PMIC for USB Type-C applications and
includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C
Port Controller (TCPC), NVMEM, and a GPIO expander.
Fuel Gauge and TCPC have separate and independent I2C addresses,
register maps, and interrupt lines and a
The Maxim MAX77759 is a companion PMIC for USB Type-C applications and
includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C
Port Controller (TCPC), NVMEM, and a GPIO expander.
This describes its storage module (NVMEM).
Signed-off-by: André Draszik
---
v2:
* drop example as the
On Wed, Feb 26, 2025 at 07:01:36PM +0100, Oleg Nesterov wrote:
> On 02/26, Lorenzo Stoakes wrote:
> >
> > On Wed, Feb 26, 2025 at 05:26:04PM +0100, Oleg Nesterov wrote:
> > > On 02/24, jef...@chromium.org wrote:
> > > >
> > > > Unlike other system mappings, the uprobe mapping is not
> > > > establi
strncpy() is deprecated for NUL-terminated destination buffers; use
strscpy() instead.
Compile-tested only.
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Thorsten Blum
---
drivers/scsi/elx/libefc_sli/sli4.c | 6 +++---
1 file changed, 3 inserti
On 26 Feb 13:47, 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.
So, in this particular case, we create a new `struct mlx5e_umr_wqe_hdr`
to enclose the header part of flexible structure `struct mlx5e_umr_wqe`.
T
On Sat, Feb 22, 2025 at 9:02 PM 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 h
On 26/02/2025 10:48 pm, Rudolf Marek wrote:
> Hi Andrew,
>
> Dne 25. 02. 25 v 22:14 Andrew Cooper napsal(a):
>> As stand-in for "the reader", I'll point out that you need to add #DB to
>> that list or you're in for a rude surprise when running the x86
>> selftests.
>
> Thanks for pointing this out.
On Wed, 26 Feb 2025 10:49:35 -0800 Saeed Mahameed wrote:
> On 26 Feb 13:47, Gustavo A. R. Silva wrote:
> >-struct mlx5e_umr_wqe {
> >+struct mlx5e_umr_wqe_hdr {
> > struct mlx5_wqe_ctrl_seg ctrl;
> > struct mlx5_wqe_umr_ctrl_seg uctrl;
> > struct mlx5_mkey_seg mkc;
> >
-struct mlx5e_umr_wqe {
+struct mlx5e_umr_wqe_hdr {
struct mlx5_wqe_ctrl_seg ctrl;
struct mlx5_wqe_umr_ctrl_seg uctrl;
struct mlx5_mkey_seg mkc;
+};
+
+struct mlx5e_umr_wqe {
+ struct mlx5e_umr_wqe_hdr hdr;
You missed or ignored my comment on v0, anyway:
Can
On 02/26, Oleg Nesterov wrote:
>
> On 02/24, jef...@chromium.org wrote:
> >
> > 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.
>
> Agreed, VM_SEALED sh
On Wed, Feb 26, 2025 at 9:12 AM Liam R. Howlett wrote:
>
> * Lorenzo Stoakes [250226 00:26]:
> > On Tue, Feb 25, 2025 at 02:26:50PM -0800, Jeff Xu wrote:
> > > On Mon, Feb 24, 2025 at 10:20 PM Lorenzo Stoakes
> > > wrote:
> > > >
> > > > On Mon, Feb 24, 2025 at 10:52:43PM +, jef...@chromium.
On 02/26, Lorenzo Stoakes wrote:
>
> On Wed, Feb 26, 2025 at 05:26:04PM +0100, Oleg Nesterov wrote:
> > On 02/24, jef...@chromium.org wrote:
> > >
> > > Unlike other system mappings, the uprobe mapping is not
> > > established during program startup. However, its lifetime is the same
> > > as the p
On Wed, Feb 26, 2025 at 05:43:22PM +, Lorenzo Stoakes wrote:
> On Wed, Feb 26, 2025 at 09:17:10AM -0800, Jeff Xu wrote:
> > On Wed, Feb 26, 2025 at 9:12 AM Liam R. Howlett
> > wrote:
> > >
> > > * Lorenzo Stoakes [250226 00:26]:
> > > > On Tue, Feb 25, 2025 at 02:26:50PM -0800, Jeff Xu wrote
On 02/26, Lorenzo Stoakes wrote:
>
> Like I said, Jeff opposes the change. I disagree with him, and agree with you,
> because this is very silly.
>
> But I don't want to hold up this series with that discussion (this is for his
> sake...)
Neither me, so lets go with VM_SEALED_SYSMAP.
My only obje
* Lorenzo Stoakes [250226 13:06]:
> On Wed, Feb 26, 2025 at 07:01:36PM +0100, Oleg Nesterov wrote:
> > On 02/26, Lorenzo Stoakes wrote:
> > >
> > > On Wed, Feb 26, 2025 at 05:26:04PM +0100, Oleg Nesterov wrote:
> > > > On 02/24, jef...@chromium.org wrote:
> > > > >
> > > > > Unlike other system ma
* Lorenzo Stoakes [250226 00:26]:
> On Tue, Feb 25, 2025 at 02:26:50PM -0800, Jeff Xu wrote:
> > On Mon, Feb 24, 2025 at 10:20 PM Lorenzo Stoakes
> > wrote:
> > >
> > > On Mon, Feb 24, 2025 at 10:52:43PM +, jef...@chromium.org wrote:
> > > > From: Jeff Xu
> > > >
> > > > Provide support for
On 02/24, jef...@chromium.org wrote:
>
> 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.
Agreed, VM_SEALED should be always for the "[uprobes]" vma, regard
On Wed, Feb 26, 2025 at 07:20:50PM +0100, Oleg Nesterov wrote:
> On 02/26, Lorenzo Stoakes wrote:
> >
> > Like I said, Jeff opposes the change. I disagree with him, and agree with
> > you,
> > because this is very silly.
> >
> > But I don't want to hold up this series with that discussion (this is
ngs/gpio/maxim,max77759-gpio.yaml
references a file that doesn't exist:
Documentation/devicetree/bindings/mfd/maxim,max77759.yaml
Documentation/devicetree/bindings/gpio/maxim,max77759-gpio.yaml:
Documentation/devicetree/bindings/mfd/maxim,max77759.yaml
See
https://patchwork.ozlabs.org/project/devic
evicetree/bindings/mfd/maxim,max77759.yaml
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250226-max77759-mfd-v2-2-a65ebe2bc...@linaro.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran '
Hi Andrew,
Dne 25. 02. 25 v 22:14 Andrew Cooper napsal(a):
As stand-in for "the reader", I'll point out that you need to add #DB to
that list or you're in for a rude surprise when running the x86 selftests.
Thanks for pointing this out. I forgot about the interrupt shadow on SYSCALL
and possib
Since strncpy() is deprecated for NUL-terminated destination buffers,
use strscpy() instead.
Compile-tested only.
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Thorsten Blum
---
drivers/target/target_core_configfs.c | 2 +-
1 file changed, 1 in
31 matches
Mail list logo
