* [GIT PULL 4/4] i.MX drivers/soc changes for v7.1
From: Frank Li @ 2026-03-30 14:14 UTC (permalink / raw)
To: soc, arm
Cc: Frank.Li, Shawn Guo, Fabio Estevam, kernel, imx, linux-arm-kernel
In-Reply-To: <20260330141444.3789193-1-Frank.Li@nxp.com>
From: Frank.Li@nxp.com
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-soc-7.1
for you to fetch changes up to 1b7c834dedf9933447c424bfa01348f9dc3db4d1:
MAINTAINERS: Add i.MX team to all arm NXP platforms (2026-03-13 11:00:45 -0400)
----------------------------------------------------------------
i.MX SoC update for 7.1:
- Updates MAINTAINERS file to include i.MX team coverage for ARM NXP platforms
- Sets default values for OPACR (Off-Platform Peripheral Access Control
Register) in the i.MX AIPSTZ bus driver
----------------------------------------------------------------
Alexander Stein (1):
MAINTAINERS: Add i.MX team to all arm NXP platforms
Shengjiu Wang (1):
bus: imx-aipstz: set default value for opacr registers
MAINTAINERS | 3 +--
drivers/bus/imx-aipstz.c | 15 +++++++++++++++
2 files changed, 16 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH] usb: phy: mxs: manually reset phy regs after a warm reset
From: Greg KH @ 2026-03-30 14:19 UTC (permalink / raw)
To: Xu Yang
Cc: Frank.Li, s.hauer, kernel, festevam, linux-usb, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260330093133.973785-1-xu.yang_2@nxp.com>
On Mon, Mar 30, 2026 at 05:31:33PM +0800, Xu Yang wrote:
> The usb phy registers are not fully reset on warm reset under stress
> conditions. We need to manually reset those (CTRL, PWD, DEBUG, PLL_SIC)
> regs after a warm reset. This will reset DEBUG and PLL_SIC registers.
> CTRL and PWD register are handled by "SFT" bit in stmp_reset_block().
>
> ERR051269: USB PHY registers not fully resetting on warm reset under
> stress conditions
>
> The following USB PHY registers must be written by SW to restore the reset
> value after a warm reset:
>
> Reg: ctrl Addr: 0x29910030 Data: 0xc000_0000
> Reg: pwd Addr: 0x29910000 Data: 0x001e_1c00
> Reg: debug0 Addr: 0x29910050 Data: 0x7f18_0000
> Reg: pll_sic Addr: 0x299100a0 Data: 0x00d1_2000
>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> ---
> drivers/usb/phy/phy-mxs-usb.c | 32 +++++++++++++++++++++++++++++---
> 1 file changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> index 7069dd3f4d0d..dd42db8a0829 100644
> --- a/drivers/usb/phy/phy-mxs-usb.c
> +++ b/drivers/usb/phy/phy-mxs-usb.c
> @@ -209,6 +209,9 @@ static const struct mxs_phy_data imx6ul_phy_data = {
> static const struct mxs_phy_data imx7ulp_phy_data = {
> };
>
> +static const struct mxs_phy_data imx8ulp_phy_data = {
> +};
> +
> static const struct of_device_id mxs_phy_dt_ids[] = {
> { .compatible = "fsl,imx6sx-usbphy", .data = &imx6sx_phy_data, },
> { .compatible = "fsl,imx6sl-usbphy", .data = &imx6sl_phy_data, },
> @@ -217,6 +220,7 @@ static const struct of_device_id mxs_phy_dt_ids[] = {
> { .compatible = "fsl,vf610-usbphy", .data = &vf610_phy_data, },
> { .compatible = "fsl,imx6ul-usbphy", .data = &imx6ul_phy_data, },
> { .compatible = "fsl,imx7ulp-usbphy", .data = &imx7ulp_phy_data, },
> + { .compatible = "fsl,imx8ulp-usbphy", .data = &imx8ulp_phy_data, },
Why can't you use &imx7ulp_phy_data here as it's all just empty?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 1/3] kernel: ksysfs: initialize kernel_kobj earlier
From: Bartosz Golaszewski @ 2026-03-30 14:19 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann, driver-core,
linux-kernel, linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <DHG5WQI26R5U.WTZW61VKJHF5@kernel.org>
On Mon, Mar 30, 2026 at 3:47 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
> > diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> > index c8219505a79f98bc370e52997efc8af51833cfda..71b9086621c35b7e4ef99b9d3b6707db23faf58c 100644
> > --- a/include/linux/kobject.h
> > +++ b/include/linux/kobject.h
> > @@ -219,4 +219,6 @@ int kobject_synth_uevent(struct kobject *kobj, const char *buf, size_t count);
> > __printf(2, 3)
> > int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...);
> >
> > +void ksysfs_init(void);
>
> NIT: I'm aware there's also all the core kobjects in include/linux/kobject.h,
> but maybe a separate header would be a better fit.
Do you mean moving all the top-level kobject declarations
(kernel_kobj, firmware_kobj, etc.) out of kobject.h into this new
header (ksysfs.h?) along with their init functions?
Bart
^ permalink raw reply
* Re: [PATCH 1/4] media: rkvdec: Introduce a global bitwriter helper
From: Nicolas Dufresne @ 2026-03-30 14:17 UTC (permalink / raw)
To: Detlev Casanova, Ezequiel Garcia, Mauro Carvalho Chehab,
Heiko Stuebner, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, Jonas Karlman
Cc: linux-kernel, linux-media, linux-rockchip, linux-arm-kernel, llvm,
kernel
In-Reply-To: <20260327-rkvdec-use-bitwriter-v1-1-982cf872b590@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 3843 bytes --]
Le vendredi 27 mars 2026 à 11:16 -0400, Detlev Casanova a écrit :
> The use of structures with bitfields is good when the values are
> somewhat aligned.
> More mis-alignement means that compilers need to do more gymanstics
> to edit the fields values.
>
> Some cases have been reported with CLang on specific architectures
> like armhf and hexagon, where the compiler would allocate a bigger
> local stack than needed or even completely freeze during compilation.
>
> Some fixes have been provided to ease the issues, but the real fix
> here is to use a bitwriter instead of heavily unaligned bitfields.
>
> This is a preparation commit to provide a global bitwriter interface
> for the whole driver.
>
> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
> ---
> drivers/media/platform/rockchip/rkvdec/Makefile | 1 +
> .../platform/rockchip/rkvdec/rkvdec-bitwriter.c | 30 ++++++++++++++++++++++
> .../platform/rockchip/rkvdec/rkvdec-bitwriter.h | 25 ++++++++++++++++++
> 3 files changed, 56 insertions(+)
>
> diff --git a/drivers/media/platform/rockchip/rkvdec/Makefile b/drivers/media/platform/rockchip/rkvdec/Makefile
> index e629d571e4d8..11e2122bcbbf 100644
> --- a/drivers/media/platform/rockchip/rkvdec/Makefile
> +++ b/drivers/media/platform/rockchip/rkvdec/Makefile
> @@ -2,6 +2,7 @@ obj-$(CONFIG_VIDEO_ROCKCHIP_VDEC) += rockchip-vdec.o
>
> rockchip-vdec-y += \
> rkvdec.o \
> + rkvdec-bitwriter.o \
Its just one function, with 10 lines of code, can we inline it in the header and
drop the object ?
> rkvdec-cabac.o \
> rkvdec-h264.o \
> rkvdec-h264-common.o \
> diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec-bitwriter.c b/drivers/media/platform/rockchip/rkvdec/rkvdec-bitwriter.c
> new file mode 100644
> index 000000000000..673ebb89002b
> --- /dev/null
> +++ b/drivers/media/platform/rockchip/rkvdec/rkvdec-bitwriter.c
> @@ -0,0 +1,30 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Rockchip Video Decoder bit writer
> + *
> + * Copyright (C) 2026 Collabora, Ltd.
> + * Detlev Casanova <detlev.casanova@collabora.com>
> + * Copyright (C) 2019 Collabora, Ltd.
> + * Boris Brezillon <boris.brezillon@collabora.com>
> + */
> +
> +#include <linux/types.h>
> +#include <linux/bits.h>
> +
> +#include "rkvdec-bitwriter.h"
> +
> +void rkvdec_set_bw_field(u32 *buf, struct rkvdec_bw_field field, u32 value)
> +{
> + u8 bit = field.offset % 32;
> + u16 word = field.offset / 32;
> + u64 mask = GENMASK_ULL(bit + field.len - 1, bit);
> + u64 val = ((u64)value << bit) & mask;
> +
> + buf[word] &= ~mask;
> + buf[word] |= val;
> + if (bit + field.len > 32) {
> + buf[word + 1] &= ~(mask >> 32);
> + buf[word + 1] |= val >> 32;
> + }
> +}
> +
> diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec-bitwriter.h b/drivers/media/platform/rockchip/rkvdec/rkvdec-bitwriter.h
> new file mode 100644
> index 000000000000..44154f1ebc65
> --- /dev/null
> +++ b/drivers/media/platform/rockchip/rkvdec/rkvdec-bitwriter.h
> @@ -0,0 +1,25 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Rockchip Video Decoder bit writer
> + *
> + * Copyright (C) 2026 Collabora, Ltd.
> + * Detlev Casanova <detlev.casanova@collabora.com>
> + * Copyright (C) 2019 Collabora, Ltd.
> + * Boris Brezillon <boris.brezillon@collabora.com>
> + */
> +
> +#ifndef RKVDEC_BIT_WRITER_H_
> +#define RKVDEC_BIT_WRITER_H_
> +
> +#include <linux/types.h>
> +
> +struct rkvdec_bw_field {
> + u16 offset;
> + u8 len;
> +};
> +
> +#define BW_FIELD(_offset, _len) ((struct rkvdec_bw_field){ _offset, _len })
> +
> +void rkvdec_set_bw_field(u32 *buf, struct rkvdec_bw_field field, u32 value);
> +
> +#endif /* RKVDEC_BIT_WRITER_H_ */
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-03-30 14:08 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann, driver-core,
linux-kernel, linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <CAMRc=MfG1ZF=4T2WAw71Zb+4BFD2_4VSNRQZQsoGLE8gZxWcHg@mail.gmail.com>
On Mon, Mar 30, 2026 at 3:52 PM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Mon, Mar 30, 2026 at 3:37 PM Danilo Krummrich <dakr@kernel.org> wrote:
> >
> > On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
> > > Bartosz Golaszewski (3):
> > > kernel: ksysfs: initialize kernel_kobj earlier
> > > driver core: make software nodes available earlier
> > > ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
> >
> > Looks good to me overall (one minor nit in the first patch); which tree should
> > this go through?
>
> If the first two patches can make v7.1 then I'm fine with postponing
> patch 3 until v7.2. Maybe Dmitry's changes allowing passing
> unregistered software nodes to new platform devices (where are we with
> this?) would also make it in and patch 3/3 could be smaller as a
> result.
>
In other words: patches 1 and 2 can go though the driver core tree
into v7.1 and patch 3/3 will be respun next cycle.
Bart
^ permalink raw reply
* Re: [PATCH v2 3/4] elf: align ET_DYN base to max folio size for PTE coalescing
From: Usama Arif @ 2026-03-30 14:00 UTC (permalink / raw)
To: Matthew Wilcox, WANG Rui
Cc: Liam.Howlett, ajd, akpm, apopple, baohua, baolin.wang, brauner,
catalin.marinas, david, dev.jain, jack, kees, kevin.brodsky,
lance.yang, linux-arm-kernel, linux-fsdevel, linux-kernel,
linux-mm, lorenzo.stoakes, mhocko, npache, pasha.tatashin,
rmclure, rppt, ryan.roberts, surenb, vbabka, viro
In-Reply-To: <acpy6DLjPVXXzwJX@casper.infradead.org>
On 30/03/2026 15:56, Matthew Wilcox wrote:
> On Sun, Mar 29, 2026 at 12:37:00PM +0800, WANG Rui wrote:
>>> mapping_max_folio_size() reflects what the page cache will actually
>>> allocate for a given filesystem, since readahead caps folio allocation
>>> at mapping_max_folio_order() (in page_cache_ra_order()). If btrfs
>>> reports PAGE_SIZE, readahead won't allocate large folios for it, so
>>> there are no large folios to coalesce PTEs for, aligning the binary
>>> beyond that would only reduce ASLR entropy for no benefit.
>>>
>>> I don't think we should over-align binaries on filesystems that can't
>>> take advantage of it.
>>
>> Ah, it looks like this might be overlooking another path that can create
>> huge page mappings for read-only code segments: even when the filesystem
>> (e.g. btrfs without experimental) didn't support large folios,
>> READ_ONLY_THP_FOR_FS still allowed read-only file-backed code segments
>> to be collapsed into huge page mappings via khugepaged.
ah yes, Thank you for pointing this out!
Maybe we should rename mapping_max_folio_size() to mapping_fault_max_folio_size().
>>
>> As Wilcox pointed out, it may take quite some time for many filesystems
>> to gain full large folio support? So what I'm trying to clarify is that
>> using mapping_max_folio_size() on this path is not favorable for
>> khugepaged-based optimizations.
ack
I am worried that 32M is too large and we lose out on a lot of ASLR bits.
Instead of PMD_ORDER, should we do max(SZ_2M, PMD_ORDER)?
> Nono, that's not what I'm pointing out! btrfs is simply not putting
> in the effort to support large folios, and that needs to change.
> READ_ONLY_THP_FOR_FS unnecessaily burdens the rest of the kernel.
> It was a great hack for its time and paved the path for a lot of what
> we have today, but it's time to remove it.
^ permalink raw reply
* Re: [PATCH v4 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-03-30 13:52 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann, driver-core,
linux-kernel, linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <DHG5OX85I4LL.39U0RRBS0JXFP@kernel.org>
On Mon, Mar 30, 2026 at 3:37 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
> > Bartosz Golaszewski (3):
> > kernel: ksysfs: initialize kernel_kobj earlier
> > driver core: make software nodes available earlier
> > ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
>
> Looks good to me overall (one minor nit in the first patch); which tree should
> this go through?
If the first two patches can make v7.1 then I'm fine with postponing
patch 3 until v7.2. Maybe Dmitry's changes allowing passing
unregistered software nodes to new platform devices (where are we with
this?) would also make it in and patch 3/3 could be smaller as a
result.
Bart
^ permalink raw reply
* Re: [PATCH v4 1/3] kernel: ksysfs: initialize kernel_kobj earlier
From: Danilo Krummrich @ 2026-03-30 13:47 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Aaro Koskinen,
Janusz Krzysztofik, Tony Lindgren, Russell King, Dmitry Torokhov,
Kevin Hilman, Arnd Bergmann, brgl, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <20260330-nokia770-gpio-swnodes-v4-1-b68592e977d0@oss.qualcomm.com>
On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
> diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> index c8219505a79f98bc370e52997efc8af51833cfda..71b9086621c35b7e4ef99b9d3b6707db23faf58c 100644
> --- a/include/linux/kobject.h
> +++ b/include/linux/kobject.h
> @@ -219,4 +219,6 @@ int kobject_synth_uevent(struct kobject *kobj, const char *buf, size_t count);
> __printf(2, 3)
> int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...);
>
> +void ksysfs_init(void);
NIT: I'm aware there's also all the core kobjects in include/linux/kobject.h,
but maybe a separate header would be a better fit.
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Krzysztof Kozlowski @ 2026-03-30 13:38 UTC (permalink / raw)
To: Ulf Hansson
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <CAPDyKFomzokuF+UL8d0+Syk1FCG3jnUfy7rVr+3iC1GPZmH1UQ@mail.gmail.com>
On 30/03/2026 15:30, Ulf Hansson wrote:
>
> Usually we want bindings to go along with their respective drivers on
> a subsystem basis.
>
> Both patch2 and patch4 updates DT bindings for the power-domain providers.
Patch 2 yes. Patch 4 not. That's why I did not take patch 2.
>
> Why shouldn't the bindings go along with the driver changes here?
Patch #2 is pmdomain, so with pmdomain drivers thus your tree. Patch #4
is not pmdomain, so not with pmdomain drivers, so not your tree... At
least I do not see any pmdomain parts in that patch #4. It's a Samsung
SoC PMU driver and none of further driver patches touch that PMU driver.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Danilo Krummrich @ 2026-03-30 13:37 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Aaro Koskinen,
Janusz Krzysztofik, Tony Lindgren, Russell King, Dmitry Torokhov,
Kevin Hilman, Arnd Bergmann, brgl, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <20260330-nokia770-gpio-swnodes-v4-0-b68592e977d0@oss.qualcomm.com>
On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
> Bartosz Golaszewski (3):
> kernel: ksysfs: initialize kernel_kobj earlier
> driver core: make software nodes available earlier
> ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
Looks good to me overall (one minor nit in the first patch); which tree should
this go through?
^ permalink raw reply
* Re: [PATCH] coresight: platform: check the availability of the endpoint before parse
From: Jie Gan @ 2026-03-30 13:31 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel
In-Reply-To: <20260320092337.GP8048@e132581.arm.com>
On 3/20/2026 5:23 PM, Leo Yan wrote:
> Hi Jie,
>
> On Fri, Mar 20, 2026 at 04:44:54PM +0800, Jie Gan wrote:
>
> [...]
>
>> It's about the coresight_find_device_by_fwnode() returns NULL, resulting in
>> -EPROBE_DEFER. So the probe process will re-start after several seconds, but
>> always failed because we have a "disabled" device node in DT(we can see this
>> device in DT, but it never becomes available). It's ok if the device only
>> has one remote device, but has issue with more than one remote devices.
>>
>> Consider below situation:
>>
>> device0
>> | |
>> device1 device2(status = "disabled")
>>
>> The probe of device0 succeeds only when device1 and device2 are available at
>> probe time. But I think it's ok to probe the device0 only with device1
>> available.
>
> Thanks a lot for details. We might need to report warning or error if
> all remote endpoints fail (e.g., device1/device2 both are disabled),
> this is a rare case so would be low priority.
>
> For this patch:
>
> Reviewed-by: Leo Yan <leo.yan@arm.com>
Gentle ping.
Thanks,
Jie
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Ulf Hansson @ 2026-03-30 13:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <a417e45b-1632-4b14-9e3c-f7110db53190@kernel.org>
On Mon, 30 Mar 2026 at 13:24, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 30/03/2026 13:12, Ulf Hansson wrote:
> >
> >>
> >>>
> >>> Although, as I said, if you think it's best to funnel them through
> >>> your tree, please do and then share them via an immutable branch, so I
> >>> can apply the pmdomain driver changes.
> >>
> >> soc must go via my tree, but there is no reason to take the pmdomain
> >> binding patch. So I did not take.
> >
> > Yes, they belong to soc/platform, which is common for most
> > power-domain providers.
>
> What does belong to soc/platform? pmdomain changes? No, they do not...
I think you may have misunderstood me here. I was referring to the DT
bindings that describe power domain providers.
Generally speaking, these are often provided via some
SOC/platform-specific hardware (like a PMU for example).
>
> >
> > To allow us to merge/maintain power-domain provider *driver* changes
> > separately, we needed a way to manage the corresponding DT bindings.
>
> Nothing stops that, there is no dependency. For a week I am saying there
> are no dependencies. If there are, please provide any sort of
> argument/proof, otherwise there is nothing to do here.
>
> > That's why I am hosting the immutable "dt" branch for these, which
> > soc/platform maintainers can pull-in when they need it.
> >
> > Of course, doing it the other way around is also possible. Just let me
> > know what you prefer.
>
> Nothing like that is necessary.
Usually we want bindings to go along with their respective drivers on
a subsystem basis.
Both patch2 and patch4 updates DT bindings for the power-domain providers.
Why shouldn't the bindings go along with the driver changes here?
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH 5/5] cpufreq: ti: Add device link to k3-socinfo
From: Krzysztof Kozlowski @ 2026-03-30 13:22 UTC (permalink / raw)
To: Akashdeep Kaur, praneeth, nm, vigneshr, kristo, robh, krzk+dt,
conor+dt, rafael, viresh.kumar, linux-arm-kernel, devicetree,
linux-kernel, linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis
In-Reply-To: <20260330120105.2985200-6-a-kaur@ti.com>
On 30/03/2026 14:01, Akashdeep Kaur wrote:
> opp_data->cpu_dev = get_cpu_device(0);
> if (!opp_data->cpu_dev) {
> @@ -560,6 +563,42 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
> if (ret)
> goto fail_put_node;
>
> + /* Create device link to k3-socinfo if specified in DT */
> + if (opp_data->soc_data == &am625_soc_data ||
> + opp_data->soc_data == &am62a7_soc_data ||
> + opp_data->soc_data == &am62l3_soc_data ||
> + opp_data->soc_data == &am62p5_soc_data) {
> + struct device_node *socinfo_np;
> +
> + socinfo_np = of_parse_phandle(opp_data->opp_node, "ti,soc-info", 0);
Undocumented ABI.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RFC net-next] net: stmmac: qcom-ethqos: set clk_csr
From: Russell King (Oracle) @ 2026-03-30 13:21 UTC (permalink / raw)
To: Andrew Lunn
Cc: Konrad Dybcio, Mohd Ayaan Anwar, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-arm-msm, linux-stm32, netdev, Paolo Abeni
In-Reply-To: <0d650de4-eb45-481b-8c39-1bf455b948c9@lunn.ch>
On Mon, Mar 30, 2026 at 02:35:39PM +0200, Andrew Lunn wrote:
> On Mon, Mar 30, 2026 at 01:20:18PM +0100, Russell King (Oracle) wrote:
> > On Mon, Mar 30, 2026 at 01:18:56PM +0200, Konrad Dybcio wrote:
> > > On 3/27/26 6:02 PM, Russell King (Oracle) wrote:
> > > > The clocks for qcom-ethqos return a rate of zero as firmware manages
> > > > their rate. According to hardware documentation, the clock which is
> > > > fed to the slave AHB interface can crange between 50 and 100MHz.
> > >
> > > FWIW this __may__ possibly differ between platforms, but I'm not sure
> > > to what degree. Will there be visible impact if we e.g. have a 200 or
> > > 300 MHz clock somewhere?
> >
> > When you add other platforms, you're going to have to deal with their
> > differences.
> >
> > IEEE 802.3 states that the maximum clock rate for the MDIO bus is
> > 2.5MHz. You need to ensure that is the case.
> >
> > Current qcom-ethqos code doesn't set clk_csr, and returns zero for
> > clk_get_rate() on the stmmac clocks because they are managed entirely
> > in firmware.
>
> Could a fixed clock be used in DT to represent clk_csr? Different
> platforms then set it to different frequencies, to represent whatever
> the firmware is doing.
Unfortunately, at hardware level, clk_csr isn't a separate clock input
as such. It can be one of many, depending on the synthesis options
chosen by the designer. It may be hclk (AHB clock), aclk (AXI clock)
clk_app (application clock) or a specific clk_csr input.
Nothing is simple with dwmac. :/
The problem with adding a ficticious clock to solve this is that it
adds to implementers confusion for what is already a very complicated
problem.
We've already seen that the stmmac clocks are a total trainwreck
because no one seems to really understnad what is what, and that goes
back to the days when that "apb" clock was added - and that made the
situation worse not better.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH 3/5] arm64: dts: ti: k3-am62a7: Add ti,soc-info to OPP table
From: Krzysztof Kozlowski @ 2026-03-30 13:21 UTC (permalink / raw)
To: Akashdeep Kaur, praneeth, nm, vigneshr, kristo, robh, krzk+dt,
conor+dt, rafael, viresh.kumar, linux-arm-kernel, devicetree,
linux-kernel, linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis
In-Reply-To: <20260330120105.2985200-4-a-kaur@ti.com>
On 30/03/2026 14:01, Akashdeep Kaur wrote:
> Link CPU OPP table to k3-socinfo driver for dependency tracking.
>
> Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-am62a7.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
> index b6e5eee99370..6d1459e9ea71 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
> @@ -109,6 +109,7 @@ a53_opp_table: opp-table {
> compatible = "operating-points-v2-ti-cpu";
> opp-shared;
> syscon = <&opp_efuse_table>;
> + ti,soc-info = <&chipid>;
You should have tested this before sending. It obviously fails checks.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 phy-next 03/28] usb: add missing headers transitively included by <linux/phy/phy.h>
From: Greg Kroah-Hartman @ 2026-03-30 13:19 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, Thinh Nguyen, Peter Chen, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <20260327184706.1600329-4-vladimir.oltean@nxp.com>
On Fri, Mar 27, 2026 at 08:46:41PM +0200, Vladimir Oltean wrote:
> The chipidea ci_hdrc_imx driver uses regulator consumer API like
> regulator_enable() but does not include <linux/regulator/consumer.h>.
>
> The core USB HCD driver calls invalidate_kernel_vmap_range() and
> flush_kernel_vmap_range(), but does not include <linux/highmem.h>.
>
> The DWC3 gadget driver calls:
> - device_property_present()
> - device_property_count_u8()
> - device_property_read_u8_array()
> but does not include <linux/property.h>
>
> The dwc3-generic-plat driver uses of_device_get_match_data() but does
> not include <linux/of.h>.
>
> In all these cases, the necessary includes were still provided somehow,
> directly or indirectly, through <linux/phy/phy.h>. The latter header
> wants to drop those includes, so fill in the required headers to avoid
> any breakage.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> # dwc3
> ---
> Cc: Peter Chen <peter.chen@kernel.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Frank Li <Frank.Li@nxp.com>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
>
> v2->v6: none
> v1->v2: collect tag
> ---
> drivers/usb/chipidea/ci_hdrc_imx.c | 1 +
> drivers/usb/core/hcd.c | 1 +
> drivers/usb/dwc3/dwc3-generic-plat.c | 1 +
> drivers/usb/dwc3/gadget.c | 1 +
> 4 files changed, 4 insertions(+)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH] clk: kirkwood: use kzalloc_flex
From: Brian Masney @ 2026-03-30 13:13 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Michael Turquette, Stephen Boyd, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260326045555.240730-1-rosenp@gmail.com>
On Wed, Mar 25, 2026 at 09:55:55PM -0700, Rosen Penev wrote:
> Simplify allocation by using a flexible array member and kzalloc_flex to
> combine allocations.
>
> Add __counted_by for extra runtime analysis. Move counting variable
> assignment to right after allocation as required by __counted_by.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/clk/mvebu/kirkwood.c | 19 ++++++++-----------
> 1 file changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/clk/mvebu/kirkwood.c b/drivers/clk/mvebu/kirkwood.c
> index ed061d82fb65..fc2972538008 100644
> --- a/drivers/clk/mvebu/kirkwood.c
> +++ b/drivers/clk/mvebu/kirkwood.c
> @@ -253,8 +253,8 @@ struct clk_muxing_soc_desc {
>
> struct clk_muxing_ctrl {
> spinlock_t *lock;
> - struct clk **muxes;
> int num_muxes;
> + struct clk *muxes[] __counted_by(num_muxes);
> };
>
> static const char *powersave_parents[] = {
> @@ -297,21 +297,18 @@ static void __init kirkwood_clk_muxing_setup(struct device_node *np,
> if (WARN_ON(!base))
> return;
>
> - ctrl = kzalloc_obj(*ctrl);
> - if (WARN_ON(!ctrl))
> - goto ctrl_out;
> -
> - /* lock must already be initialized */
> - ctrl->lock = &ctrl_gating_lock;
> -
> /* Count, allocate, and register clock muxes */
> for (n = 0; desc[n].name;)
> n++;
>
> + ctrl = kzalloc_flex(*ctrl, muxes, n);
> + if (WARN_ON(!ctrl))
> + goto ctrl_out;
> +
> ctrl->num_muxes = n;
> - ctrl->muxes = kzalloc_objs(struct clk *, ctrl->num_muxes);
> - if (WARN_ON(!ctrl->muxes))
> - goto muxes_out;
Question from Sashiko:
https://sashiko.dev/#/patchset/20260326045555.240730-1-rosenp%40gmail.com
This isn't a bug, but since the goto muxes_out error path was removed here,
should the muxes_out label and its kfree(ctrl) be removed at the end of the
function?
They appear to be dead code now and might cause an unused label warning:
return;
muxes_out:
kfree(ctrl);
ctrl_out:
iounmap(base);
}
Brian
> +
> + /* lock must already be initialized */
> + ctrl->lock = &ctrl_gating_lock;
>
> for (n = 0; n < ctrl->num_muxes; n++) {
> ctrl->muxes[n] = clk_register_mux(NULL, desc[n].name,
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH] clk: bcm: iproc-asiu: simplify allocation
From: Brian Masney @ 2026-03-30 13:10 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Michael Turquette, Stephen Boyd, Ray Jui,
Scott Branden, Broadcom internal kernel review list,
moderated list:BROADCOM IPROC ARM ARCHITECTURE, open list
In-Reply-To: <20260326045324.240150-1-rosenp@gmail.com>
On Wed, Mar 25, 2026 at 09:53:24PM -0700, Rosen Penev wrote:
> Use kzalloc_flex and a flexible array member to combine allocations
>
> While at it, take clk_data out of the struct and move it into probe.
> It's not used anywhere else.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH v14 12/12] crypto: qce - Communicate the base physical address to the dmaengine
From: Manivannan Sadhasivam @ 2026-03-30 13:08 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Stephan Gerhold, Bjorn Andersson, Peter Ujfalusi, Michal Simek,
Frank Li, dmaengine, linux-doc, linux-kernel, linux-arm-msm,
linux-crypto, linux-arm-kernel, brgl, Bartosz Golaszewski
In-Reply-To: <20260323-qcom-qce-cmd-descr-v14-12-f323af411274@oss.qualcomm.com>
On Mon, Mar 23, 2026 at 04:17:18PM +0100, Bartosz Golaszewski wrote:
> In order to communicate to the BAM DMA engine which address should be
> used as a scratchpad for dummy writes related to BAM pipe locking,
> fill out and attach the provided metadata struct to the descriptor as
> well as mark the RX channel as such using the slave config struct.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> drivers/crypto/qce/dma.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/crypto/qce/dma.c b/drivers/crypto/qce/dma.c
> index 5c42fc7ddf01e11a6562d272ba7c90c906e0e312..635208947668667765e6accf9ef02100746c0f9a 100644
> --- a/drivers/crypto/qce/dma.c
> +++ b/drivers/crypto/qce/dma.c
> @@ -11,6 +11,7 @@
>
> #include "core.h"
> #include "dma.h"
> +#include "regs-v5.h"
>
> #define QCE_IGNORE_BUF_SZ (2 * QCE_BAM_BURST_SIZE)
> #define QCE_BAM_CMD_SGL_SIZE 128
> @@ -43,6 +44,7 @@ void qce_clear_bam_transaction(struct qce_device *qce)
>
> int qce_submit_cmd_desc(struct qce_device *qce)
> {
> + struct bam_desc_metadata meta = { .scratchpad_addr = qce->base_phys + REG_VERSION };
> struct qce_desc_info *qce_desc = qce->dma.bam_txn->desc;
> struct qce_bam_transaction *bam_txn = qce->dma.bam_txn;
> struct dma_async_tx_descriptor *dma_desc;
> @@ -64,6 +66,12 @@ int qce_submit_cmd_desc(struct qce_device *qce)
> return -ENOMEM;
> }
>
> + ret = dmaengine_desc_attach_metadata(dma_desc, &meta, 0);
> + if (ret) {
> + dma_unmap_sg(qce->dev, bam_txn->wr_sgl, bam_txn->wr_sgl_cnt, DMA_TO_DEVICE);
> + return ret;
> + }
> +
> qce_desc->dma_desc = dma_desc;
> cookie = dmaengine_submit(qce_desc->dma_desc);
>
> @@ -107,7 +115,9 @@ void qce_write_dma(struct qce_device *qce, unsigned int offset, u32 val)
> int devm_qce_dma_request(struct qce_device *qce)
> {
> struct qce_dma_data *dma = &qce->dma;
> + struct dma_slave_config cfg = { };
> struct device *dev = qce->dev;
> + int ret;
>
> dma->txchan = devm_dma_request_chan(dev, "tx");
> if (IS_ERR(dma->txchan))
> @@ -119,6 +129,11 @@ int devm_qce_dma_request(struct qce_device *qce)
> return dev_err_probe(dev, PTR_ERR(dma->rxchan),
> "Failed to get RX DMA channel\n");
>
> + cfg.direction = DMA_MEM_TO_DEV;
> + ret = dmaengine_slave_config(dma->rxchan, &cfg);
> + if (ret)
> + return ret;
> +
I don't think this part is necessary. You are already passing the metadata above
and that should be sufficient for the BAM DMA driver to get the scratchpad
address. If any client drivers call dmaengine_slave_config() without
dmaengine_desc_attach_metadata(), and if the BAM DMA supports locking, then the
BAM driver should fail. Otherwise, continuing so would cause race conditions
among the BAM clients, which we are seeing right now on Qcom SDX targets with
both NAND driver in Linux and Modem trying to access NAND memory over BAM.
So please drop this and just use dmaengine_desc_attach_metadata().
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] clk: visconti: pll: use kzalloc_flex
From: Brian Masney @ 2026-03-30 13:07 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Michael Turquette, Stephen Boyd, Nobuhiro Iwamatsu,
Kees Cook, Gustavo A. R. Silva,
moderated list:ARM/TOSHIBA VISCONTI ARCHITECTURE, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260326042317.122536-1-rosenp@gmail.com>
On Wed, Mar 25, 2026 at 09:23:17PM -0700, Rosen Penev wrote:
> Simplify allocation by using a flexible array member and kzalloc_flex.
>
> Add __counted_by for extra runtime analysis. Assign after allocation as
> required by __counted_by.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Note: Sashiko reported a separate issue related to the struct clk_init_data
not fully initialized to zero, and parent_data and parent_hws fields are
left containing stack garbage.
https://sashiko.dev/#/patchset/20260326042317.122536-1-rosenp%40gmail.com
I'll post a fix for this.
Brian
^ permalink raw reply
* Re: [PATCH v3 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
From: Jason Gunthorpe @ 2026-03-30 12:48 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, bhelgaas, joro, praan, baolu.lu, kevin.tian,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, linux-pci,
dan.j.williams, jonathan.cameron, vsethi, linux-cxl
In-Reply-To: <a0dd3e4cc5260f55bbec5b3ed6791def33028735.1772833963.git.nicolinc@nvidia.com>
On Fri, Mar 06, 2026 at 03:41:15PM -0800, Nicolin Chen wrote:
> Controlled by the IOMMU driver, ATS is usually enabled "on demand" when a
> device requests a translation service from its associated IOMMU HW running
> on the channel of a given PASID. This is working even when a device has no
> translation on its RID (i.e., the RID is IOMMU bypassed).
>
> However, certain PCIe devices require non-PASID ATS on their RID even when
> the RID is IOMMU bypassed. Call this "always on".
>
> For instance, the CXL spec notes in "3.2.5.13 Memory Type on CXL.cache":
> "To source requests on CXL.cache, devices need to get the Host Physical
> Address (HPA) from the Host by means of an ATS request on CXL.io."
>
> In other words, the CXL.cache capability requires ATS; otherwise, it can't
> access host physical memory.
>
> Introduce a new pci_ats_always_on() helper for the IOMMU driver to scan a
> PCI device and shift ATS policies between "on demand" and "always on".
>
> Add the support for CXL.cache devices first. Pre-CXL devices will be added
> in quirks.c file.
>
> Note that pci_ats_always_on() validates against pci_ats_supported(), so we
> ensure that untrusted devices (e.g. external ports) will not be always on.
> This maintains the existing ATS security policy regarding potential side-
> channel attacks via ATS.
>
> Cc: linux-cxl@vger.kernel.org
> Suggested-by: Vikram Sethi <vsethi@nvidia.com>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> include/linux/pci-ats.h | 3 +++
> include/uapi/linux/pci_regs.h | 1 +
> drivers/pci/ats.c | 42 +++++++++++++++++++++++++++++++++++
> 3 files changed, 46 insertions(+)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH 4/5] xor/arm64: Use shared NEON intrinsics implementation from 32-bit ARM
From: Christoph Hellwig @ 2026-03-30 13:02 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Christoph Hellwig, Ard Biesheuvel, linux-raid, linux-arm-kernel,
linux-crypto, Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <6bedf98e-a424-4baa-890c-806345c067c1@app.fastmail.com>
On Mon, Mar 30, 2026 at 11:38:15AM +0200, Ard Biesheuvel wrote:
> > This avoid the including of .c files which is always a bit ugly.
> > But if there is a strong argument to prefer including of the .c file I
> > can live with that as well.
> >
>
> I've respun it without the include. Instead, I've added this to arm/xor-neon.c
>
> +#ifdef CONFIG_ARM64
> +extern typeof(__xor_neon_2) __xor_eor3_2 __alias(__xor_neon_2);
> +#endif
>
> so that __xor_eor3_2() exists in the arm64 build as an alias. That way, the arm64-only EOR3 implementation can just remain a separate compilation unit.
Ok.
^ permalink raw reply
* Re: [PATCH v2 3/4] elf: align ET_DYN base to max folio size for PTE coalescing
From: Matthew Wilcox @ 2026-03-30 12:56 UTC (permalink / raw)
To: WANG Rui
Cc: usama.arif, Liam.Howlett, ajd, akpm, apopple, baohua, baolin.wang,
brauner, catalin.marinas, david, dev.jain, jack, kees,
kevin.brodsky, lance.yang, linux-arm-kernel, linux-fsdevel,
linux-kernel, linux-mm, lorenzo.stoakes, mhocko, npache,
pasha.tatashin, rmclure, rppt, ryan.roberts, surenb, vbabka, viro
In-Reply-To: <20260329043700.19355-1-r@hev.cc>
On Sun, Mar 29, 2026 at 12:37:00PM +0800, WANG Rui wrote:
> > mapping_max_folio_size() reflects what the page cache will actually
> > allocate for a given filesystem, since readahead caps folio allocation
> > at mapping_max_folio_order() (in page_cache_ra_order()). If btrfs
> > reports PAGE_SIZE, readahead won't allocate large folios for it, so
> > there are no large folios to coalesce PTEs for, aligning the binary
> > beyond that would only reduce ASLR entropy for no benefit.
> >
> > I don't think we should over-align binaries on filesystems that can't
> > take advantage of it.
>
> Ah, it looks like this might be overlooking another path that can create
> huge page mappings for read-only code segments: even when the filesystem
> (e.g. btrfs without experimental) didn't support large folios,
> READ_ONLY_THP_FOR_FS still allowed read-only file-backed code segments
> to be collapsed into huge page mappings via khugepaged.
>
> As Wilcox pointed out, it may take quite some time for many filesystems
> to gain full large folio support? So what I'm trying to clarify is that
> using mapping_max_folio_size() on this path is not favorable for
> khugepaged-based optimizations.
Nono, that's not what I'm pointing out! btrfs is simply not putting
in the effort to support large folios, and that needs to change.
READ_ONLY_THP_FOR_FS unnecessaily burdens the rest of the kernel.
It was a great hack for its time and paved the path for a lot of what
we have today, but it's time to remove it.
^ permalink raw reply
* Re: [PATCH v14 05/12] dmaengine: qcom: bam_dma: add support for BAM locking
From: Manivannan Sadhasivam @ 2026-03-30 12:54 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Stephan Gerhold, Bjorn Andersson, Peter Ujfalusi, Michal Simek,
Frank Li, dmaengine, linux-doc, linux-kernel, linux-arm-msm,
linux-crypto, linux-arm-kernel, brgl, Bartosz Golaszewski
In-Reply-To: <20260323-qcom-qce-cmd-descr-v14-5-f323af411274@oss.qualcomm.com>
On Mon, Mar 23, 2026 at 04:17:11PM +0100, Bartosz Golaszewski wrote:
> Add support for BAM pipe locking. To that end: when starting DMA on an RX
> channel - prepend the existing queue of issued descriptors with an
> additional "dummy" command descriptor with the LOCK bit set. Once the
> transaction is done (no more issued descriptors), issue one more dummy
> descriptor with the UNLOCK bit.
>
> We *must* wait until the transaction is signalled as done because we
> must not perform any writes into config registers while the engine is
> busy.
>
> The dummy writes must be issued into a scratchpad register of the client
> so provide a mechanism to communicate the right address via descriptor
> metadata.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> drivers/dma/qcom/bam_dma.c | 165 ++++++++++++++++++++++++++++++++++++++-
> include/linux/dma/qcom_bam_dma.h | 10 +++
> 2 files changed, 171 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index 83491e7c2f17d8c9d12a1a055baea7e3a0a75a53..309681e798d2e44992e3d20679c3a7564ad8f29e 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -28,11 +28,13 @@
> #include <linux/clk.h>
> #include <linux/device.h>
> #include <linux/dma-mapping.h>
> +#include <linux/dma/qcom_bam_dma.h>
> #include <linux/dmaengine.h>
> #include <linux/init.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> #include <linux/kernel.h>
> +#include <linux/lockdep.h>
> #include <linux/module.h>
> #include <linux/of_address.h>
> #include <linux/of_dma.h>
> @@ -60,6 +62,8 @@ struct bam_desc_hw {
> #define DESC_FLAG_EOB BIT(13)
> #define DESC_FLAG_NWD BIT(12)
> #define DESC_FLAG_CMD BIT(11)
> +#define DESC_FLAG_LOCK BIT(10)
> +#define DESC_FLAG_UNLOCK BIT(9)
>
> struct bam_async_desc {
> struct virt_dma_desc vd;
> @@ -391,6 +395,13 @@ struct bam_chan {
> struct list_head desc_list;
>
> struct list_head node;
> +
> + /* BAM locking infrastructure */
> + phys_addr_t scratchpad_addr;
> + struct scatterlist lock_sg;
> + struct scatterlist unlock_sg;
> + struct bam_cmd_element lock_ce;
> + struct bam_cmd_element unlock_ce;
> };
>
> static inline struct bam_chan *to_bam_chan(struct dma_chan *common)
> @@ -652,6 +663,32 @@ static int bam_slave_config(struct dma_chan *chan,
> return 0;
> }
>
> +static int bam_metadata_attach(struct dma_async_tx_descriptor *desc, void *data, size_t len)
> +{
> + struct bam_chan *bchan = to_bam_chan(desc->chan);
> + const struct bam_device_data *bdata = bchan->bdev->dev_data;
> + struct bam_desc_metadata *metadata = data;
> +
> + if (!data)
> + return -EINVAL;
> +
> + if (!bdata->pipe_lock_supported)
> + /*
> + * The client wants to use locking but this BAM version doesn't
> + * support it. Don't return an error here as this will stop the
> + * client from using DMA at all for no reason.
> + */
> + return 0;
> +
> + bchan->scratchpad_addr = metadata->scratchpad_addr;
> +
> + return 0;
> +}
> +
> +static const struct dma_descriptor_metadata_ops bam_metadata_ops = {
> + .attach = bam_metadata_attach,
> +};
> +
> /**
> * bam_prep_slave_sg - Prep slave sg transaction
> *
> @@ -668,6 +705,7 @@ static struct dma_async_tx_descriptor *bam_prep_slave_sg(struct dma_chan *chan,
> void *context)
> {
> struct bam_chan *bchan = to_bam_chan(chan);
> + struct dma_async_tx_descriptor *tx_desc;
> struct bam_device *bdev = bchan->bdev;
> struct bam_async_desc *async_desc;
> struct scatterlist *sg;
> @@ -723,7 +761,12 @@ static struct dma_async_tx_descriptor *bam_prep_slave_sg(struct dma_chan *chan,
> } while (remainder > 0);
> }
>
> - return vchan_tx_prep(&bchan->vc, &async_desc->vd, flags);
> + tx_desc = vchan_tx_prep(&bchan->vc, &async_desc->vd, flags);
> + if (!tx_desc)
> + return NULL;
> +
> + tx_desc->metadata_ops = &bam_metadata_ops;
> + return tx_desc;
> }
>
> /**
> @@ -1012,13 +1055,116 @@ static void bam_apply_new_config(struct bam_chan *bchan,
> bchan->reconfigure = 0;
> }
>
> +static struct bam_async_desc *
> +bam_make_lock_desc(struct bam_chan *bchan, struct scatterlist *sg,
> + struct bam_cmd_element *ce, unsigned long flag)
> +{
> + struct dma_chan *chan = &bchan->vc.chan;
> + struct bam_async_desc *async_desc;
> + struct bam_desc_hw *desc;
> + struct virt_dma_desc *vd;
> + struct virt_dma_chan *vc;
> + unsigned int mapped;
> + dma_cookie_t cookie;
> + int ret;
> +
> + sg_init_table(sg, 1);
> +
> + async_desc = kzalloc_flex(*async_desc, desc, 1, GFP_NOWAIT);
> + if (!async_desc) {
> + dev_err(bchan->bdev->dev, "failed to allocate the BAM lock descriptor\n");
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + async_desc->num_desc = 1;
> + async_desc->curr_desc = async_desc->desc;
> + async_desc->dir = DMA_MEM_TO_DEV;
> +
> + desc = async_desc->desc;
> +
> + bam_prep_ce_le32(ce, bchan->scratchpad_addr, BAM_WRITE_COMMAND, 0);
> + sg_set_buf(sg, ce, sizeof(*ce));
> +
> + mapped = dma_map_sg_attrs(chan->slave, sg, 1, DMA_TO_DEVICE, DMA_PREP_CMD);
> + if (!mapped) {
> + kfree(async_desc);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + desc->flags |= cpu_to_le16(DESC_FLAG_CMD | flag);
> + desc->addr = sg_dma_address(sg);
> + desc->size = sizeof(struct bam_cmd_element);
> +
> + vc = &bchan->vc;
> + vd = &async_desc->vd;
> +
> + dma_async_tx_descriptor_init(&vd->tx, &vc->chan);
> + vd->tx.flags = DMA_PREP_CMD;
> + vd->tx.desc_free = vchan_tx_desc_free;
> + vd->tx_result.result = DMA_TRANS_NOERROR;
> + vd->tx_result.residue = 0;
> +
> + cookie = dma_cookie_assign(&vd->tx);
> + ret = dma_submit_error(cookie);
> + if (ret) {
> + dma_unmap_sg(chan->slave, sg, 1, DMA_TO_DEVICE);
> + kfree(async_desc);
> + return ERR_PTR(ret);
> + }
> +
> + return async_desc;
> +}
> +
> +static int bam_do_setup_pipe_lock(struct bam_chan *bchan, bool lock)
> +{
> + struct bam_device *bdev = bchan->bdev;
> + const struct bam_device_data *bdata = bdev->dev_data;
> + struct bam_async_desc *lock_desc;
> + struct bam_cmd_element *ce;
> + struct scatterlist *sgl;
> + unsigned long flag;
> +
> + lockdep_assert_held(&bchan->vc.lock);
> +
> + if (!bdata->pipe_lock_supported || !bchan->scratchpad_addr ||
> + bchan->slave.direction != DMA_MEM_TO_DEV)
> + return 0;
> +
> + if (lock) {
> + sgl = &bchan->lock_sg;
> + ce = &bchan->lock_ce;
> + flag = DESC_FLAG_LOCK;
> + } else {
> + sgl = &bchan->unlock_sg;
> + ce = &bchan->unlock_ce;
> + flag = DESC_FLAG_UNLOCK;
> + }
> +
> + lock_desc = bam_make_lock_desc(bchan, sgl, ce, flag);
> + if (IS_ERR(lock_desc))
> + return PTR_ERR(lock_desc);
> +
> + if (lock)
> + list_add(&lock_desc->vd.node, &bchan->vc.desc_issued);
> + else
> + list_add_tail(&lock_desc->vd.node, &bchan->vc.desc_issued);
> +
> + return 0;
> +}
> +
> +static void bam_setup_pipe_lock(struct bam_chan *bchan)
> +{
> + if (bam_do_setup_pipe_lock(bchan, true) || bam_do_setup_pipe_lock(bchan, false))
> + dev_err(bchan->vc.chan.slave, "Failed to setup BAM pipe lock descriptors");
> +}
> +
> /**
> * bam_start_dma - start next transaction
> * @bchan: bam dma channel
> */
> static void bam_start_dma(struct bam_chan *bchan)
> {
> - struct virt_dma_desc *vd = vchan_next_desc(&bchan->vc);
> + struct virt_dma_desc *vd;
> struct bam_device *bdev = bchan->bdev;
> struct bam_async_desc *async_desc = NULL;
> struct bam_desc_hw *desc;
> @@ -1030,6 +1176,9 @@ static void bam_start_dma(struct bam_chan *bchan)
>
> lockdep_assert_held(&bchan->vc.lock);
>
> + bam_setup_pipe_lock(bchan);
> +
> + vd = vchan_next_desc(&bchan->vc);
> if (!vd)
> return;
>
> @@ -1157,8 +1306,15 @@ static void bam_issue_pending(struct dma_chan *chan)
> */
> static void bam_dma_free_desc(struct virt_dma_desc *vd)
> {
> - struct bam_async_desc *async_desc = container_of(vd,
> - struct bam_async_desc, vd);
> + struct bam_async_desc *async_desc = container_of(vd, struct bam_async_desc, vd);
> + struct bam_desc_hw *desc = async_desc->desc;
> + struct dma_chan *chan = vd->tx.chan;
> + struct bam_chan *bchan = to_bam_chan(chan);
> +
> + if (le16_to_cpu(desc->flags) & DESC_FLAG_LOCK)
> + dma_unmap_sg(chan->slave, &bchan->lock_sg, 1, DMA_TO_DEVICE);
> + else if (le16_to_cpu(desc->flags) & DESC_FLAG_UNLOCK)
> + dma_unmap_sg(chan->slave, &bchan->unlock_sg, 1, DMA_TO_DEVICE);
>
> kfree(async_desc);
> }
> @@ -1350,6 +1506,7 @@ static int bam_dma_probe(struct platform_device *pdev)
> bdev->common.device_terminate_all = bam_dma_terminate_all;
> bdev->common.device_issue_pending = bam_issue_pending;
> bdev->common.device_tx_status = bam_tx_status;
> + bdev->common.desc_metadata_modes = DESC_METADATA_CLIENT;
> bdev->common.dev = bdev->dev;
>
> ret = dma_async_device_register(&bdev->common);
> diff --git a/include/linux/dma/qcom_bam_dma.h b/include/linux/dma/qcom_bam_dma.h
> index 68fc0e643b1b97fe4520d5878daa322b81f4f559..5f0d2a27face8223ecb77da33d9e050c1ff2622f 100644
> --- a/include/linux/dma/qcom_bam_dma.h
> +++ b/include/linux/dma/qcom_bam_dma.h
> @@ -34,6 +34,16 @@ enum bam_command_type {
> BAM_READ_COMMAND,
> };
>
> +/**
> + * struct bam_desc_metadata - DMA descriptor metadata specific to the BAM driver.
> + *
> + * @scratchpad_addr: Physical address to use for dummy write operations when
> + * queuing command descriptors with LOCK/UNLOCK bits set.
> + */
> +struct bam_desc_metadata {
> + phys_addr_t scratchpad_addr;
> +};
> +
> /*
> * prep_bam_ce_le32 - Wrapper function to prepare a single BAM command
> * element with the data already in le32 format.
>
> --
> 2.47.3
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v3 3/3] iommu/arm-smmu-v3: Allow ATS to be always on
From: Jason Gunthorpe @ 2026-03-30 12:51 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, bhelgaas, joro, praan, baolu.lu, kevin.tian,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, linux-pci,
dan.j.williams, jonathan.cameron, vsethi, linux-cxl
In-Reply-To: <0e8d1ee1557c54943dd15ff836576de4c3aa58b6.1772833963.git.nicolinc@nvidia.com>
On Fri, Mar 06, 2026 at 03:41:17PM -0800, Nicolin Chen wrote:
> When a device's default substream attaches to an identity domain, the SMMU
> driver currently sets the device's STE between two modes:
>
> Mode 1: Cfg=Translate, S1DSS=Bypass, EATS=1
> Mode 2: Cfg=bypass (EATS is ignored by HW)
>
> When there is an active PASID (non-default substream), mode 1 is used. And
> when there is no PASID support or no active PASID, mode 2 is used.
>
> The driver will also downgrade an STE from mode 1 to mode 2, when the last
> active substream becomes inactive.
>
> However, there are PCIe devices that demand ATS to be always on. For these
> devices, their STEs have to use the mode 1 as HW ignores EATS with mode 2.
>
> Change the driver accordingly:
> - always use the mode 1
> - never downgrade to mode 2
> - allocate and retain a CD table (see note below)
>
> Note that these devices might not support PASID, i.e. doing non-PASID ATS.
> In such a case, the ssid_bits is set to 0. However, s1cdmax must be set to
> a !0 value in order to keep the S1DSS field effective. Thus, when a master
> requires ats_always_on, set its s1cdmax to minimal 1, meaning the CD table
> will have a dummy entry (SSID=1) that will be never used.
>
> Now, for these device, arm_smmu_cdtab_allocated() will always return true,
> v.s. false prior to this change. When its default substream is attached to
> an IDENTITY domain, its first CD is NULL in the table, which is a totally
> valid case. Thus, add "!master->ats_always_on" to the condition.
>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 72 ++++++++++++++++++---
> 2 files changed, 65 insertions(+), 8 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox