-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 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;
> >
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.
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
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 '
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
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
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 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
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
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 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
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
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
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
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.
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.
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
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
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
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:
>
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.
* 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 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 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 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 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
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
