* Re: (subset) [PATCH 00/12] treewide: Convert buses to use generic driver_override
From: Danilo Krummrich @ 2026-04-04 17:04 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki,
Ioana Ciornei, Nipun Gupta, Nikhil Agarwal, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Bjorn Helgaas,
Armin Wolf, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Harald Freudenberger, Holger Dengler, Mark Brown,
Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Alex Williamson, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, linux-kernel, driver-core, linuxppc-dev,
linux-hyperv, linux-pci, platform-driver-x86, linux-arm-msm,
linux-remoteproc, linux-s390, linux-spi, virtualization, kvm,
xen-devel, linux-arm-kernel
In-Reply-To: <76355cb5-0b5d-4a29-9702-8d020a79f4c0@kernel.org>
On Sat Apr 4, 2026 at 6:58 PM CEST, Christophe Leroy (CS GROUP) wrote:
>
>
> Le 04/04/2026 à 17:07, Danilo Krummrich a écrit :
>> On Tue Mar 24, 2026 at 1:59 AM CET, Danilo Krummrich wrote:
>>> Danilo Krummrich (12):
>>> PCI: use generic driver_override infrastructure
>>> platform/wmi: use generic driver_override infrastructure
>>> vdpa: use generic driver_override infrastructure
>>> s390/cio: use generic driver_override infrastructure
>>> s390/ap: use generic driver_override infrastructure
>>
>> Applied to driver-core-testing, thanks!
>>
>>> amba: use generic driver_override infrastructure
>>> cdx: use generic driver_override infrastructure
>>> hv: vmbus: use generic driver_override infrastructure
>>> rpmsg: use generic driver_override infrastructure
>>
>> I have not picked these up, as they have not received ACKs from the
>> corresponding subsystem maintainers so far.
>>
>>> bus: fsl-mc: use generic driver_override infrastructure
>
> I droped it from soc_fsl tree, some dependency must be missing.
>
> Feal free to take it if you can, it is acked-by Ioana.
It is based on v7.0-rc5; if you want I can pick it up.
>>> spi: use generic driver_override infrastructure
>>
>> These have already been picked up via the respective subsystem trees -- thanks!
>>
>> Thanks,
>> Danilo
^ permalink raw reply
* Re: [PATCH v1] PCI: imx6: Fix reference clock source selection
From: Manivannan Sadhasivam @ 2026-04-04 17:00 UTC (permalink / raw)
To: Richard Zhu, Lucas Stach, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Franz Schnyder
Cc: Franz Schnyder, linux-pci, linux-arm-kernel, imx, linux-kernel,
Francesco Dolcini, stable
In-Reply-To: <20260325093118.684142-1-fra.schnyder@gmail.com>
On Wed, 25 Mar 2026 10:31:16 +0100, Franz Schnyder wrote:
> In the PCIe PHY init for the iMX95, the reference clock source selection
> uses a conditional instead of always passing the mask. This currently
> breaks functionality if the internal refclk is used.
>
> Pass always IMX95_PCIE_REF_USE_PAD as the mask and clear the bit if
> external refclk is not used.
>
> [...]
Applied, thanks!
[1/1] PCI: imx6: Fix reference clock source selection
commit: 575d7268ca07fcb1d1a50399e1399ba60df3cb27
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH 00/12] treewide: Convert buses to use generic driver_override
From: Christophe Leroy (CS GROUP) @ 2026-04-04 16:58 UTC (permalink / raw)
To: Danilo Krummrich, Russell King, Greg Kroah-Hartman,
Rafael J. Wysocki, Ioana Ciornei, Nipun Gupta, Nikhil Agarwal,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Bjorn Helgaas, Armin Wolf, Bjorn Andersson, Mathieu Poirier,
Vineeth Vijayan, Peter Oberparleiter, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Harald Freudenberger, Holger Dengler, Mark Brown,
Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Alex Williamson, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, Christophe Leroy (CS GROUP)
Cc: linux-kernel, driver-core, linuxppc-dev, linux-hyperv, linux-pci,
platform-driver-x86, linux-arm-msm, linux-remoteproc, linux-s390,
linux-spi, virtualization, kvm, xen-devel, linux-arm-kernel
In-Reply-To: <DHKGQN6D0ANO.2QYY3JTM5435O@kernel.org>
Le 04/04/2026 à 17:07, Danilo Krummrich a écrit :
> On Tue Mar 24, 2026 at 1:59 AM CET, Danilo Krummrich wrote:
>> Danilo Krummrich (12):
>> PCI: use generic driver_override infrastructure
>> platform/wmi: use generic driver_override infrastructure
>> vdpa: use generic driver_override infrastructure
>> s390/cio: use generic driver_override infrastructure
>> s390/ap: use generic driver_override infrastructure
>
> Applied to driver-core-testing, thanks!
>
>> amba: use generic driver_override infrastructure
>> cdx: use generic driver_override infrastructure
>> hv: vmbus: use generic driver_override infrastructure
>> rpmsg: use generic driver_override infrastructure
>
> I have not picked these up, as they have not received ACKs from the
> corresponding subsystem maintainers so far.
>
>> bus: fsl-mc: use generic driver_override infrastructure
I droped it from soc_fsl tree, some dependency must be missing.
Feal free to take it if you can, it is acked-by Ioana.
>> spi: use generic driver_override infrastructure
>
> These have already been picked up via the respective subsystem trees -- thanks!
>
> Thanks,
> Danilo
^ permalink raw reply
* Re: [PATCH 02/12] bus: fsl-mc: use generic driver_override infrastructure
From: Christophe Leroy (CS GROUP) @ 2026-04-04 16:56 UTC (permalink / raw)
To: Ioana Ciornei, Danilo Krummrich
Cc: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki, Nipun Gupta,
Nikhil Agarwal, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Bjorn Helgaas, Armin Wolf, Bjorn Andersson,
Mathieu Poirier, Vineeth Vijayan, Peter Oberparleiter,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Harald Freudenberger,
Holger Dengler, Mark Brown, Michael S. Tsirkin, Jason Wang,
Xuan Zhuo, Eugenio PĂ©rez, Alex Williamson,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
linux-kernel, driver-core, linuxppc-dev, linux-hyperv, linux-pci,
platform-driver-x86, linux-arm-msm, linux-remoteproc, linux-s390,
linux-spi, virtualization, kvm, xen-devel, linux-arm-kernel,
Gui-Dong Han
In-Reply-To: <4c5e9bad-82f0-4714-99c2-8ccd79a45043@kernel.org>
Le 28/03/2026 à 13:10, Christophe Leroy (CS GROUP) a écrit :
>
>
> Le 25/03/2026 à 13:01, Ioana Ciornei a écrit :
>> On Tue, Mar 24, 2026 at 01:59:06AM +0100, Danilo Krummrich wrote:
>>> When a driver is probed through __driver_attach(), the bus' match()
>>> callback is called without the device lock held, thus accessing the
>>> driver_override field without a lock, which can cause a UAF.
>>>
>>> Fix this by using the driver-core driver_override infrastructure taking
>>> care of proper locking internally.
>>>
>>> Note that calling match() from __driver_attach() without the device lock
>>> held is intentional. [1]
>>>
>>> Link: https://eur01.safelinks.protection.outlook.com/?
>>> url=https%3A%2F%2Flore.kernel.org%2Fdriver-
>>> core%2FDGRGTIRHA62X.3RY09D9SOK77P%40kernel.org%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C4b9262ddecdd4ce29f9808de8a66485e%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639100369055903282%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BRfjlUkq7oWV%2F0v2S2B%2BEuxCY%2FLRQv6qHiEWiupd6kc%3D&reserved=0 [1]
>>> Reported-by: Gui-Dong Han <hanguidong02@gmail.com>
>>> Closes: https://eur01.safelinks.protection.outlook.com/?
>>> url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D220789&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C4b9262ddecdd4ce29f9808de8a66485e%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639100369055936232%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XL1K1ICiygOZnlvDUbQFe192KnLsBQms0HFNGCuyz%2Fw%3D&reserved=0
>>> Fixes: 1f86a00c1159 ("bus/fsl-mc: add support for 'driver_override'
>>> in the mc-bus")
>>> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
>>
>> Tested-by: Ioana Ciornei <ioana.ciornei@nxp.com>
>> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
>>
>
>
> Applied, thanks
Have to drop it for now, build fails:
CALL scripts/checksyscalls.sh
CC drivers/bus/fsl-mc/fsl-mc-bus.o
drivers/bus/fsl-mc/fsl-mc-bus.c: In function 'fsl_mc_bus_match':
drivers/bus/fsl-mc/fsl-mc-bus.c:92:15: error: implicit declaration of
function 'device_match_driver_override'
[-Werror=implicit-function-declaration]
92 | ret = device_match_driver_override(dev, drv);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/bus/fsl-mc/fsl-mc-bus.c: At top level:
drivers/bus/fsl-mc/fsl-mc-bus.c:321:10: error: 'const struct bus_type'
has no member named 'driver_override'
321 | .driver_override = true,
| ^~~~~~~~~~~~~~~
drivers/bus/fsl-mc/fsl-mc-bus.c:321:28: warning: initialization of
'const char *' from 'int' makes pointer from integer without a cast
[-Wint-conversion]
321 | .driver_override = true,
| ^~~~
drivers/bus/fsl-mc/fsl-mc-bus.c:321:28: note: (near initialization for
'fsl_mc_bus_type.dev_name')
cc1: some warnings being treated as errors
make[5]: *** [scripts/Makefile.build:289:
drivers/bus/fsl-mc/fsl-mc-bus.o] Error 1
make[4]: *** [scripts/Makefile.build:546: drivers/bus/fsl-mc] Error 2
make[3]: *** [scripts/Makefile.build:546: drivers/bus] Error 2
make[2]: *** [scripts/Makefile.build:546: drivers] Error 2
make[1]: *** [/home/chleroy/linux-powerpc/Makefile:2101: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2
Christophe
^ permalink raw reply
* Re: [GIT PULL] Microchip ARM64 SoC updates for v7.1
From: Krzysztof Kozlowski @ 2026-04-04 15:35 UTC (permalink / raw)
To: Claudiu Beznea; +Cc: soc, arm, conor, nicolas.ferre, linux-arm-kernel
In-Reply-To: <20260403070658.2554567-1-claudiu.beznea@tuxon.dev>
On Fri, Apr 03, 2026 at 10:06:58AM +0300, Claudiu Beznea wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/microchip-soc-7.1
>
> for you to fetch changes up to e4ffa98a02f4d16eda9a5faec6792493b41dab35:
>
> arm64: Kconfig: provide a top-level switch for Microchip platforms (2026-03-18 10:55:49 +0200)
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] Microchip ARM64 device tree updates for v7.1
From: Krzysztof Kozlowski @ 2026-04-04 15:33 UTC (permalink / raw)
To: Claudiu Beznea; +Cc: soc, arm, conor, nicolas.ferre, linux-arm-kernel
In-Reply-To: <20260403070637.2554408-1-claudiu.beznea@tuxon.dev>
On Fri, Apr 03, 2026 at 10:06:37AM +0300, Claudiu Beznea wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/microchip-dt64-7.1
>
> for you to fetch changes up to 711cca0f1cfef57018654b969da4041c2bab68d3:
>
> arm64: dts: microchip: add EV23X71A board (2026-03-20 10:56:22 +0200)
>
> ----------------------------------------------------------------
> Microchip ARM64 device tree updates for v7.1
>
> This update includes:
> - device tree files for the Microchip LAN9691 SoC and its evaluation
> board (Microchip EV23X71A)
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] Microchip AT91 SoC updates for v7.1
From: Krzysztof Kozlowski @ 2026-04-04 15:31 UTC (permalink / raw)
To: Claudiu Beznea
Cc: soc, arm, nicolas.ferre, alexandre.belloni, linux-arm-kernel
In-Reply-To: <20260403070344.2553018-1-claudiu.beznea@tuxon.dev>
On Fri, Apr 03, 2026 at 10:03:44AM +0300, Claudiu Beznea wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-soc-7.1
>
> for you to fetch changes up to f3ae0049ff8a3d2cbd8c05857705744435629d0c:
>
> dt-bindings: arm: atmel,at91rm9200-sdramc: convert to DT schema (2026-03-07 16:41:03 +0200)
>
> ----------------------------------------------------------------
> Microchip AT91 SoC updates for v7.1
>
> This update includes:
> - device tree bindings conversion to DT schema for CHIPID, RAM
> controller and PIT, PIT64b, ST timers
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] Microchip AT91 device tree updates for v7.1
From: Krzysztof Kozlowski @ 2026-04-04 15:28 UTC (permalink / raw)
To: Claudiu Beznea
Cc: soc, arm, nicolas.ferre, alexandre.belloni, linux-arm-kernel
In-Reply-To: <20260403070327.2552867-1-claudiu.beznea@tuxon.dev>
On Fri, Apr 03, 2026 at 10:03:27AM +0300, Claudiu Beznea wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-dt-7.1
>
> for you to fetch changes up to 7d7a9fc1310a0ade8ea61c5eb4d8b29456f8d604:
>
> ARM: dts: microchip: sama7d65: add Cortex-A7 PMU node (2026-03-24 15:35:37 +0200)
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] Microchip AT91 defconfig updates for v7.1
From: Krzysztof Kozlowski @ 2026-04-04 15:25 UTC (permalink / raw)
To: Claudiu Beznea
Cc: soc, arm, nicolas.ferre, alexandre.belloni, linux-arm-kernel
In-Reply-To: <20260403070259.2552626-1-claudiu.beznea@tuxon.dev>
On Fri, Apr 03, 2026 at 10:02:59AM +0300, Claudiu Beznea wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-defconfig-7.1
>
> for you to fetch changes up to 1f17fce8bf19a48e5e5610c6da8f806eab81878a:
>
> ARM: configs: at91: sama7: enable LVDS serializer support (2026-02-28 16:04:03 +0200)
>
> ----------------------------------------------------------------
> Microchip AT91 defconfig updates for v7.1
>
> This update includes:
> - LCD controller, LVDS controller, backlight, simple pannel, touchscreen
> configuration flags required by SAMA7D65 SoC
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] Microchip AT91 fixes for v7.0
From: Krzysztof Kozlowski @ 2026-04-04 15:22 UTC (permalink / raw)
To: Claudiu Beznea
Cc: soc, arm, nicolas.ferre, alexandre.belloni, linux-arm-kernel
In-Reply-To: <20260403070239.2552455-1-claudiu.beznea@tuxon.dev>
On Fri, Apr 03, 2026 at 10:02:39AM +0300, Claudiu Beznea wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-fixes-7.0
>
> for you to fetch changes up to 907150bbe566e23714a25d7bcb910f236c3c44c0:
>
> ARM: dts: microchip: sam9x7: fix gpio-lines count for pioB (2026-03-23 12:54:24 +0200)
>
> ----------------------------------------------------------------
> Microchip AT91 fixes for v7.0
>
> This update includes:
> - fix gpio-lines for SAM9X7 PIOB GPIO controller
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH 00/12] treewide: Convert buses to use generic driver_override
From: Danilo Krummrich @ 2026-04-04 15:07 UTC (permalink / raw)
To: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki,
Ioana Ciornei, Nipun Gupta, Nikhil Agarwal, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Bjorn Helgaas,
Armin Wolf, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Harald Freudenberger, Holger Dengler, Mark Brown,
Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Alex Williamson, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, Christophe Leroy (CS GROUP)
Cc: linux-kernel, driver-core, linuxppc-dev, linux-hyperv, linux-pci,
platform-driver-x86, linux-arm-msm, linux-remoteproc, linux-s390,
linux-spi, virtualization, kvm, xen-devel, linux-arm-kernel,
Danilo Krummrich
In-Reply-To: <20260324005919.2408620-1-dakr@kernel.org>
On Tue Mar 24, 2026 at 1:59 AM CET, Danilo Krummrich wrote:
> Danilo Krummrich (12):
> PCI: use generic driver_override infrastructure
> platform/wmi: use generic driver_override infrastructure
> vdpa: use generic driver_override infrastructure
> s390/cio: use generic driver_override infrastructure
> s390/ap: use generic driver_override infrastructure
Applied to driver-core-testing, thanks!
> amba: use generic driver_override infrastructure
> cdx: use generic driver_override infrastructure
> hv: vmbus: use generic driver_override infrastructure
> rpmsg: use generic driver_override infrastructure
I have not picked these up, as they have not received ACKs from the
corresponding subsystem maintainers so far.
> bus: fsl-mc: use generic driver_override infrastructure
> spi: use generic driver_override infrastructure
These have already been picked up via the respective subsystem trees -- thanks!
Thanks,
Danilo
^ permalink raw reply
* Re: [GIT PULL 2/4] i.MX arm dts changes for v7.1
From: Krzysztof Kozlowski @ 2026-04-04 14:47 UTC (permalink / raw)
To: Frank Li
Cc: soc, arm, Shawn Guo, Fabio Estevam, kernel, imx, linux-arm-kernel
In-Reply-To: <20260330141444.3789193-3-Frank.Li@nxp.com>
On Mon, Mar 30, 2026 at 10:14:38AM -0400, Frank Li wrote:
> Frank Li (24):
> ARM: dts: imx35: rename emi to emi-bus to fix CHECK_DTBS warning
> ARM: dts: imx35: rename i2c clock-names to ipg
> ARM: dts: imx35: remove simple-bus 'usbphy'
> ARM: dts: imx51-ts4800: rename fpga@0 to fpga@0,0
> ARM: dts: imx51-babbage: rename at45db321d@1 to flash@1
> ARM: dts: imx53: drop fallback compatible "dlg,da9052"
This, just like arm64 pull, breaks users without explanation. You use
incorrect terms in that commit msg which might mean you did not perform
proper analysis of compatibility. Commit claims compatibility string is
not comaptible and as proof brings dtbs_check warning. So the sole
reason is the binding. What if binding is wrong?
Commit msg must explain that.
I looked at the drivers and it looks 100% compatible, so commit msg is
clearly wrong and this might affect users of DTS.
Please resend pull without this commit.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL 1/4] i.MX arm64 dts changes for v7.1
From: Krzysztof Kozlowski @ 2026-04-04 14:34 UTC (permalink / raw)
To: Frank Li
Cc: soc, arm, Shawn Guo, Fabio Estevam, kernel, imx, linux-arm-kernel
In-Reply-To: <20260330141444.3789193-2-Frank.Li@nxp.com>
On Mon, Mar 30, 2026 at 10:14:37AM -0400, Frank Li wrote:
> 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-dt64-7.1
>
> for you to fetch changes up to 825b8c7e1d2918d89eb378b761530d1e51dba82e:
>
> arm64: dts: imx8qxp-mek: switch Type-C connector power-role to dual (2026-03-27 09:53:32 -0400)
>
> ----------------------------------------------------------------
> i.MX arm64 device tree changes for 7.1:
>
> - New Board Support
> S32N79-RDB, Variscite DART-MX95, DART-MX91 with Sonata carrier boards,
> Verdin iMX95 with multiple carrier boards (Yavia, Mallow, Ivy, Dahlia)
> TQMa93xx/MBa93xxLA-MINI, SolidRun i.MX8MP HummingBoard IIoT,
> SolidRun i.MX8MM SOM and EVB, SolidRun SolidSense-N8 board
> Ka-Ro Electronics tx8m-1610 COM, GOcontroll Moduline IV and Moduline Mini,
> NXP FRDM-IMX91S board, i.MX93 Wireless EVK board with Wireless SiP,
> NXP i.MX8MP audio board v2.
You do not have any bindings for these.
I found them in driver bindings (!!!) pull request so completely
different branch. This is wrong. Bindings come with the user. Who is the
user of board bindings? Not a driver, but exactly this pull request.
This makes this branch full of warnings which is completely unnecessary.
Plus this will spawn multiple checkpatch warnings if tested. It must
have also cause warnings in your case, so probably you do not test your
tree enough.
...
> Marco Felsch (1):
> arm64: dts: imx93: Add parallel display output nodes
>
> Martin Schmiedel (2):
> arm64: dts: freescale: add initial device tree for TQMa93xx/MBa93xxLA-MINI
> arm64: dts: freescale: imx93-tqma9352-mba93xxla-mini: Add WLAN/BT overlay
>
> Maud Spierings (4):
> arm64: dts: imx8mm: Add pinctrl config definitions
> arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM
> arm64: dts: freescale: Add the GOcontroll Moduline IV
> arm64: dts: freescale: Add the GOcontroll Moduline Mini
>
> Nora Schiffer (1):
> arm64: dts: freescale: imx8mp-tqma8mpql-mba8mp-ras314: fix UART1 RTS/CTS muxing
>
> Peng Fan (4):
> arm64: dts: imx94: Add V2X/ELE mailbox nodes
> arm64: dts: imx94: Add SCMI sensor/lmm/cpu nodes
> arm64: dts: imx943-evk: Add nxp,ctrl-ids for scmi_misc
> arm64: dts: imx943-evk: Add pf09/53 thermal zone
>
> Primoz Fiser (1):
> arm64: dts: freescale: imx93-phy{core,board}: Add i2c bus recovery
>
> Ranjani Vaidyanathan (1):
> arm64: dts: imx94: Update pin headers
>
> Rob Herring (Arm) (1):
> arm64: dts: freescale: imx93: Add Ethos-U65 NPU and SRAM nodes
>
> Shengjiu Wang (7):
> arm64: dts: imx8mm-evk: correct the spdif compatible string
This breaks users of DTS and explains nothing about impact or why this
should be changed (corrected). It should not pass review of two people.
Also I could not find explanation of the impact in the tag message.
Device was apparently working fine, so it should have been made
compatible. I know that 10 years ago we did not care that much about
DTS users, but that changes for a few years already.
I am merging this but next time I would postpone the pull till some
clarifications are provided. Please pay attention to OF_UPSTREAM and
other users impact next time.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL 4/7] ARM: tegra: Device tree changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-04-04 14:04 UTC (permalink / raw)
To: Thierry Reding
Cc: arm, soc, Thierry Reding, Jon Hunter, linux-tegra,
linux-arm-kernel
In-Reply-To: <20260329151045.1443133-4-thierry.reding@kernel.org>
On Sun, Mar 29, 2026 at 05:10:41PM +0200, Thierry Reding wrote:
> From: Thierry Reding <thierry.reding@gmail.com>
>
> Hi ARM SoC maintainers,
>
> 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/tegra/linux.git tags/tegra-for-7.1-arm-dt
>
> for you to fetch changes up to ce74a6c6d88ba9ee29a6b99ac97ffcded577c85d:
>
> ARM: tegra: paz00: Configure WiFi rfkill switch through device tree (2026-03-28 00:56:36 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> ARM: tegra: Device tree changes for v7.1-rc1
>
> Various improvements for Tegra114 boards, as well as some legacy cleanup
> for PAZ00 and Transformers devices.
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v5 0/4] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Danilo Krummrich @ 2026-04-04 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: <20260402-nokia770-gpio-swnodes-v5-0-d730db3dd299@oss.qualcomm.com>
On Thu Apr 2, 2026 at 4:15 PM CEST, Bartosz Golaszewski wrote:
Applied to driver-core-testing, thanks!
> Bartosz Golaszewski (4):
> kernel: ksysfs: initialize kernel_kobj earlier
> software node: remove software_node_exit()
> driver core: make software nodes available earlier
[ Fix typo in the commit message: "s/merci/mercy/". - Danilo ]
^ permalink raw reply
* Re: [PATCH v3 1/2] mailbox: Use per-thread completion to fix wrong completion order
From: Joonwon Kang @ 2026-04-04 12:44 UTC (permalink / raw)
To: jassisinghbrar
Cc: angelogioacchino.delregno, jonathanh, joonwonkang,
linux-arm-kernel, linux-kernel, linux-mediatek, linux-tegra,
matthias.bgg, stable, thierry.reding
In-Reply-To: <CABb+yY0uDQh-3cadPQONV=NJKjMtc4mJekgjmHYVaHnfHXvGZQ@mail.gmail.com>
> On Fri, Apr 3, 2026 at 9:51 AM Joonwon Kang <joonwonkang@google.com> wrote:
> >
> > > On Thu, Apr 2, 2026 at 12:07 PM Joonwon Kang <joonwonkang@google.com> wrote:
> > > >
> > > > Previously, a sender thread in mbox_send_message() could be woken up at
> > > > a wrong time in blocking mode. It is because there was only a single
> > > > completion for a channel whereas messages from multiple threads could be
> > > > sent in any order; since the shared completion could be signalled in any
> > > > order, it could wake up a wrong sender thread.
> > > >
> > > > This commit resolves the false wake-up issue with the following changes:
> > > > - Completions are created just as many as the number of concurrent sender
> > > > threads
> > > > - A completion is created on a sender thread's stack
> > > > - Each slot of the message queue, i.e. `msg_data`, contains a pointer to
> > > > its target completion
> > > > - tx_tick() signals the completion of the currently active slot of the
> > > > message queue
> > > >
> > > I think I reviewed it already or is this happening on
> > > one-channel-one-client usage? Because mailbox api does not support
> > > channels shared among multiple clients.
> >
> > Yes, this patch is handling the one-channel-one-client usage but when that
> > single channel is shared between multiple threads.
>
> hmm.... how is this not single-channel-multiple-clients ?
> A channel is returned as an opaque token to the clients, if that
> client shares that with other threads - they will race.
They will race because of the current blocking mode implementation. With this
patch, they should not race as it handles the known racing point. So, I think
it will be important to decide whether to support multi-threads in blocking
mode or not.
> It is the job of the original client to serialize its threads' access
> to the channel.
I can see the disparity with the non-blocking mode here. Currently, the client
does not need to serialize its threads' access to the channel in non-blocking
mode whereas it needs to in blocking mode. It would be nice if the client does
not need to in both modes, but it may also depend on the necessity as you said.
> > From my understanding, the
> > discussion back then ended with how to circumvent the issue rather than whether
> > we will eventually solve this in the mailbox framework or not, and if yes, how
> > we will, and if not, why.
>
> It will be interesting to see how many current clients actually need
> to share channels. If there are enough, it makes sense to implement
> some helper api
> on top of existing code, instead of changing its nature totally.
I agree that we may need research on the current uses of channels and the
necessity of shared channels. However, it may require non-trivial amount of
time since it requires thorough understanding of the context of every client
driver. At this point, I think we at least need a clear documentation in terms
of multi-threads support as we have none now. Since it is obvious that
multi-threads is not supported for now, I can create another patch to add this
to the API doc to be clear. How do you think?
Thanks,
Joonwon Kang
^ permalink raw reply
* [PATCH v2 2/5] arm64/mm: drop vmemmap_pmd helpers and use generic code
From: Muchun Song @ 2026-04-04 12:20 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: linux-mm, akpm, Muchun Song, Muchun Song, Ryan Roberts,
David Hildenbrand, Kevin Brodsky, Dev Jain, Lorenzo Stoakes,
Anshuman Khandual, Yang Shi, Chaitanya S Prakash,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260404122105.3989557-1-songmuchun@bytedance.com>
The generic implementations now suffice; remove the arm64 copies.
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
---
arch/arm64/mm/mmu.c | 14 --------------
1 file changed, 14 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index ec1c6971a561..b87053452641 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1745,20 +1745,6 @@ static void free_empty_tables(unsigned long addr, unsigned long end,
}
#endif
-void __meminit vmemmap_set_pmd(pmd_t *pmdp, void *p, int node,
- unsigned long addr, unsigned long next)
-{
- pmd_set_huge(pmdp, __pa(p), __pgprot(PROT_SECT_NORMAL));
-}
-
-int __meminit vmemmap_check_pmd(pmd_t *pmdp, int node,
- unsigned long addr, unsigned long next)
-{
- vmemmap_verify((pte_t *)pmdp, node, addr, next);
-
- return pmd_sect(READ_ONCE(*pmdp));
-}
-
int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
struct vmem_altmap *altmap)
{
--
2.20.1
^ permalink raw reply related
* [PATCH v2 0/5] mm/sparse-vmemmap: provide generic vmemmap_set_pmd() and vmemmap_check_pmd()
From: Muchun Song @ 2026-04-04 12:20 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Huacai Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, David S. Miller, Andreas Larsson,
Andrew Morton, David Hildenbrand
Cc: linux-mm, Muchun Song, Muchun Song, WANG Xuerui, Alexandre Ghiti,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Ryan Roberts, Kevin Brodsky,
Dev Jain, Anshuman Khandual, Yang Shi, Chaitanya S Prakash,
Petr Tesarik, Vishal Moola (Oracle), Junhui Liu, Austin Kim,
Chengkaitao, Matthew Wilcox (Oracle), Alex Shi, linux-arm-kernel,
linux-kernel, loongarch, linux-riscv, sparclinux
The two weak functions vmemmap_set_pmd() and vmemmap_check_pmd() are
currently no-ops on every architecture, forcing each platform that needs
them to duplicate the same handful of lines. Provide a generic implementation:
- vmemmap_set_pmd() simply sets a huge PMD with PAGE_KERNEL protection.
- vmemmap_check_pmd() verifies that the PMD is present and leaf,
then calls the existing vmemmap_verify() helper.
Architectures that need special handling can continue to override the
weak symbols; everyone else gets the standard version for free.
This series drops the custom implementations in arm64, riscv, loongarch,
and sparc, replacing them with the generic implementation introduced
in the first patch.
v1 -> v2:
- Fixed a tooling issue in v1 where duplicate/conflicting patches
were incorrectly sent to the mailing list. No code changes compared
to the intended v1.
Muchun Song (5):
mm/sparse-vmemmap: provide generic vmemmap_set_pmd() and
vmemmap_check_pmd()
arm64/mm: drop vmemmap_pmd helpers and use generic code
riscv/mm: drop vmemmap_pmd helpers and use generic code
loongarch/mm: drop vmemmap_check_pmd helper and use generic code
sparc/mm: drop vmemmap_check_pmd helper and use generic code
arch/arm64/mm/mmu.c | 14 --------------
arch/loongarch/mm/init.c | 11 -----------
arch/riscv/mm/init.c | 13 -------------
arch/sparc/mm/init_64.c | 11 -----------
mm/sparse-vmemmap.c | 7 ++++++-
5 files changed, 6 insertions(+), 50 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH v3 2/2] mailbox: Make mbox_send_message() return error code when tx fails
From: Joonwon Kang @ 2026-04-04 11:47 UTC (permalink / raw)
To: jassisinghbrar
Cc: akpm, angelogioacchino.delregno, jonathanh, joonwonkang,
linux-arm-kernel, linux-kernel, linux-mediatek, linux-tegra,
matthias.bgg, stable, thierry.reding, lee
In-Reply-To: <CABb+yY23aTXeXu6G-8sHjw32DCqmhsJLu2Mt-txenOgTBiyv+A@mail.gmail.com>
> On Fri, Apr 3, 2026 at 10:19 AM Joonwon Kang <joonwonkang@google.com> wrote:
> >
> > > On Thu, Apr 2, 2026 at 12:07 PM Joonwon Kang <joonwonkang@google.com> wrote:
> > > >
> > > > When the mailbox controller failed transmitting message, the error code
> > > > was only passed to the client's tx done handler and not to
> > > > mbox_send_message(). For this reason, the function could return a false
> > > > success. This commit resolves the issue by introducing the tx status and
> > > > checking it before mbox_send_message() returns.
> > > >
> > > Can you please share the scenario when this becomes necessary? This
> > > can potentially change the ground underneath some clients, so we have
> > > to be sure this is really useful.
> >
> > I would say the problem here is generic enough to apply to all the cases where
> > the send result needs to be checked. Since the return value of the send API is
> > not the real send result, any users who believe that this blocking send API
> > will return the real send result could fall for that. For example, users may
> > think the send was successful even though it was not actually. I believe it is
> > uncommon that users have to register a callback solely to get the send result
> > even though they are using the blocking send API already. Also, I guess there
> > is no special reason why only the mailbox send API should work this way among
> > other typical blocking send APIs. For these reasons, this patch makes the send
> > API return the real send result. This way, users will not need to register the
> > redundant callback and I think the return value will align with their common
> > expectation.
> >
> Clients submit a message into the Mailbox subsystem to be sent out to
> the remote side which can happen immediately or later.
> If submission fails, clients get immediately notified. If transmission
> fails (which is now internal to the subsystem) it is reported to the
> client by a callback.
> If the API was called mbox_submit_message (which it actually is)
> instead of mbox_send_message, there would be no confusion.
> We can argue how good/bad the current implementation is, but the fact
> is that it is here. And I am reluctant to cause churn without good
> reason.
> Again, as I said, any, _legal_, setup scenario will help me come over
> my reluctance.
mbox_send_message() in blocking mode is not only for submitting the message in
the first place if we read through the API docs.
From the API doc for `mbox_send_message()`:
```
* If the client had set 'tx_block', the call will return
* either when the remote receives the data or when 'tx_tout' millisecs
* run out.
```
From the API doc for `struct mbox_client`:
```
* @tx_block: If the mbox_send_message should block until data is
* transmitted.
```
With the docs, I think it is apparent that the API covers "transmission" of the
message, not only submission of it. If sumbitting is the sole purpose of the
API, what does the API block for in the first place? We would not need the
blocking mode at all then.
The current return value of the API in failure cases is as follows:
- When submission fails, returns failure.
- When submission succeeds but timeout occurs during transmission, return
failure, i.e. -ETIME.
- When submission succeeds but transmission fails without timeout, return
success.
The third case looks problematic. This patch is focusing on this. There is also
disparity to handle the failure between timeout(the second case) and
non-timeout(the third case). Why does it not return failure when non-timeout
error occurs during transmission whereas it does when timeout occurs during
transmission? If the API is solely for submission, why does it return failure
instead of success in the second case?
In the third case, the controller(or the client) will inform the mailbox core
of the transmission failure. Then, why not return that failure as a return
value of the API despite having this information in the core?
An alternative to fixing this issue would be adding the API doc by saying like:
- In blocking mode, the send API will return -ETIME when timeout occurs during
transmission, but it will not return failure but success(since submission
itself was successful before transmission) when other errors occur during
transmission. Users have to register a callback to collect the error code
when non-timeout error occurs.
But, I think we can go away with this unnecessary confusion by fixing the API
just to return the error code when error occurs regardless of whether it is
timeout or not. Then, we could simply say:
- In blocking mode, the send API will return failure when error occurs.
Since this patch is pointing out this anomaly of the send API's behavior, I
am not sure what scenario we would need more. In other words, the current way
of working would be more surprising to the users than the fixed version of it
as it was when I found out this issue for the first time.
Do you think that this change will cause any other problem on the client side
than fixing the existing issue? If not, I am wondering why not go fix the
issue with this patch.
Thanks,
Joonwon Kang
^ permalink raw reply
* Re: [PATCH 1/2] pmdomain/rockchip: skip QoS operations for idle-only domains
From: Shawn Lin @ 2026-04-04 11:40 UTC (permalink / raw)
To: Daniel Bozeman, finley.xiao, ulf.hansson, heiko, linux-pm,
linux-arm-kernel, linux-rockchip, linux-kernel, Jonas Karlman
Cc: shawn.lin
In-Reply-To: <adAwtiaU-32qjRRE@claude-dev>
+ Jonas
在 2026/04/04 星期六 5:27, Daniel Bozeman 写道:
> I ran both tests you requested:
>
> Test 1: Added pr_err to rockchip_pd_power_on/off to identify
> the crashing domain. With patch 2 only (skip EPROBE_DEFER),
> the crash occurs on PD_VO:
Thanks for fing the PD_VO, and I'm still requesting more docs internally
to check what's going on. I see there are several qos nodes under PD_VO,
but I'm not sure if they all belong to PD_VO and even not sure if their
registers are define correctly.
Perhaps, could you help dig more by removing the qos one by one from
PD_VO to narrow down the broken qos?
I also loop in Jonas who submited the code, to have a look.(I'm also
surprised to see there aren't any Qos nodes under PD_VO in vendor
kernel for reference, but upstream code has...)
>
> rockchip_pd_power_off: vo pwr_mask=0x0
> Internal error: synchronous external abort: 0000000096000010
> Workqueue: pm genpd_power_off_work_fn
> Call trace:
> regmap_mmio_read32le+0x8/0x20
> _regmap_bus_reg_read+0x6c/0xac
> _regmap_read+0x60/0xd8
> regmap_read+0x4c/0x7c
> rockchip_pmu_set_idle_request.isra.0+0x98/0x16c
> rockchip_pd_power+0x130/0x48c
> rockchip_pd_power_off+0x38/0x48
> genpd_power_off.isra.0+0x1f0/0x2f0
> genpd_power_off_work_fn+0x34/0x54
>
> Test 2: Same debug build, booted with clk_ignore_unused
> added to kernel cmdline via U-Boot. Same crash, same domain:
>
> rockchip_pd_power_off: vo pwr_mask=0x0
> Internal error: synchronous external abort: 0000000096000010
> (identical call trace)
>
> The crash occurs even with clk_ignore_unused. The QoS
> registers for PD_VO are inaccessible when genpd attempts
> to power off this idle-only domain.
>
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: rockchip: Convert rk3399-gru-sound to YAML
From: Krzysztof Kozlowski @ 2026-04-04 11:11 UTC (permalink / raw)
To: Anushka Badhe
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, linux-sound, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260402055635.8798-1-anushkabadhe@gmail.com>
On Thu, Apr 02, 2026 at 11:26:35AM +0530, Anushka Badhe wrote:
> Convert the rockchip,rk3399-gru-sound.txt DT binding to YAML Schema.
DT Schema, not YAML Schema.
Same in subject.
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
...
> +---
> +$id: http://devicetree.org/schemas/sound/rockchip,rk3399-gru-sound.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ROCKCHIP with MAX98357A/RT5514/DA7219 codecs on GRU boards
Rockchip
> +
> +maintainers:
> + - Heiko Stuebner <heiko@sntech.de>
> +
> +properties:
> + compatible:
> + const: rockchip,rk3399-gru-sound
> +
> + rockchip,cpu:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
Need to list items. See msm/gpu.yaml,
allwinner,sun4i-a10-display-engine.yaml and others.
And read the driver code to understand what is supposed to be here.
> + description:
> + The phandle of the Rockchip I2S controller that's connected to the codecs
> +
> + rockchip,codec:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
Same here.
> + description: The phandle of the audio codecs
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v9 0/3] Power Management for Raspberry Pi V3D GPU
From: Maíra Canal @ 2026-04-04 10:52 UTC (permalink / raw)
To: Stefan Wahren, Maxime Ripard, Melissa Wen, Iago Toral Quiroga,
Dave Stevenson, Florian Fainelli, Maíra Canal
Cc: dri-devel, linux-rpi-kernel, linux-arm-kernel,
Broadcom internal kernel review list, kernel-dev, Philipp Zabel
In-Reply-To: <20260331-v3d-power-management-v9-0-f52ff87bfd36@igalia.com>
On Tue, 31 Mar 2026 09:35:50 -0300, Maíra Canal wrote:
> This series introduces Runtime Power Management (PM) support for the
> Raspberry Pi V3D GPU.
>
> Currently, the V3D clock remains enabled for the entire system uptime,
> even when the GPU is idle. With the introduction of Runtime PM, the
> clock can now be disabled during idle periods. For example, with this
> series applied to a Raspberry Pi 5, if we check `vcgencmd measure_clock
> v3d`, we get:
>
> [...]
Applied, thanks for all reviews!
[1/3] drm/v3d: Use devm_reset_control_get_optional_exclusive()
commit: de1e32ef1d625ee4d717bcf10c23df2722324f62
[2/3] drm/v3d: Allocate all resources before enabling the clock
commit: ffd7371ed4179827dcf401543b37b69e5781f924
[3/3] drm/v3d: Introduce Runtime Power Management
commit: 458f2a712ab42b7d3615208862922dc35fe90ef9
Best regards,
- Maíra
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm-smmu: qcom: Add compatible for Hawi SoC
From: Krzysztof Kozlowski @ 2026-04-04 10:50 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Will Deacon, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robin Murphy, linux-arm-kernel, iommu, devicetree,
linux-kernel
In-Reply-To: <20260403080956.2714415-1-mukesh.ojha@oss.qualcomm.com>
On Fri, Apr 03, 2026 at 01:39:56PM +0530, Mukesh Ojha wrote:
> Qualcomm Hawi SoC include apps smmu that implements arm,mmu-500, which
> is used to translate device-visible virtual addresses to physical
> addresses. Add compatible for these items.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v8 0/5] Add i.MX943 PCIe supports
From: Manivannan Sadhasivam @ 2026-04-04 10:42 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, bhelgaas, frank.li, l.stach, lpieralisi,
kwilczynski, s.hauer, kernel, festevam, Richard Zhu
Cc: linux-pci, linux-arm-kernel, devicetree, imx, linux-kernel
In-Reply-To: <20260324023036.784466-1-hongxing.zhu@nxp.com>
On Tue, 24 Mar 2026 10:30:31 +0800, Richard Zhu wrote:
> This patch-set adds i.MX943 PCIe supports on EVK board. Please pay
> attention to that it relies on the patch-set[1], and the PCIe1 port on
> the EVK board relies on the [2].
>
> Both of them are included in the v7.0 kernel.
> [1] https://lore.kernel.org/imx/176649331066.523506.9443864112044699350.b4-ty@kernel.org/
> [2] https://lore.kernel.org/imx/inzg46tc2fwsajxq4vzdyuiq7krzy6xtcg2mjaieninz7zsmgm@mtdjr4tuegpq/
>
> [...]
Applied, thanks!
[1/5] dt-bindings: PCI: imx6q-pcie: Change maxItems of clocks and clock-names to 6
commit: 401359ef44af43b6b775dc01bb7b31396db67aab
[2/5] dt-bindings: PCI: imx6q-pcie: Add i.MX94 and i.MX943 PCIe compatible strings
commit: 4d7937d8cc32b027a14cb8152d9df64d17e9392c
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* Re: [PATCH] PCI: aspeed: Fix IRQ domain leak on platform_get_irq() failure
From: Manivannan Sadhasivam @ 2026-04-04 10:35 UTC (permalink / raw)
To: Jacky Chou, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Bjorn Helgaas, Joel Stanley, Andrew Jeffery,
Felix Gu
Cc: linux-aspeed, linux-pci, linux-arm-kernel, linux-kernel
In-Reply-To: <20260324-aspeed-v1-1-354181624c00@gmail.com>
On Tue, 24 Mar 2026 01:57:59 +0800, Felix Gu wrote:
> The aspeed_pcie_probe() function calls aspeed_pcie_init_irq_domain()
> which allocates pcie->intx_domain and initializes MSI. However, if
> platform_get_irq() fails afterwards, the cleanup action was not yet
> registered via devm_add_action_or_reset(), causing the IRQ domain
> resources to leak.
>
> Fix this by registering the devm cleanup action immediately after
> aspeed_pcie_init_irq_domain() succeeds, before calling
> platform_get_irq(). This ensures proper cleanup on any subsequent
> failure.
>
> [...]
Applied, thanks!
[1/1] PCI: aspeed: Fix IRQ domain leak on platform_get_irq() failure
commit: c54d5f5b33990f2649c20f35407f340bcadb8a53
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ 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