* [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
* 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
* 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: [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: [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 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: (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] 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: [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 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 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 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 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: [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: (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 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: 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: (subset) [PATCH 00/12] treewide: Convert buses to use generic driver_override
From: Christophe Leroy (CS GROUP) @ 2026-04-04 17:09 UTC (permalink / raw)
To: Danilo Krummrich
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: <DHKJ7VWI1CHO.3ETHUGQVPFFDE@kernel.org>
Le 04/04/2026 à 19:04, Danilo Krummrich a écrit :
> 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.
Yes please pick it up as my tree is based on rc1.
Thanks
Christophe
>
>>>> 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 V2 0/8] PCI: imx6: Integrate pwrctrl API and update device trees
From: Manivannan Sadhasivam @ 2026-04-04 17:10 UTC (permalink / raw)
To: Sherry Sun
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, bhelgaas, hongxing.zhu, l.stach, imx,
linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260402101007.208419-1-sherry.sun@nxp.com>
On Thu, Apr 02, 2026 at 06:09:59PM +0800, Sherry Sun wrote:
> Note: This patch set depends on my previous patch set [1] which adds
> Root Port device tree nodes and support parsing the reset property in
> new Root Port binding in pci-imx6 driver.
>
> This series integrates the PCI pwrctrl framework into the pci-imx6
> driver and updates i.MX EVK board device trees to support it.
>
> Patches 2-8 update device trees for i.MX EVK boards which maintained
> by NXP to move power supply properties from the PCIe controller node
> to the Root Port child node, which is required for pwrctrl framework.
> Affected boards:
> - i.MX6Q/DL SABRESD
> - i.MX6SX SDB
> - i.MX8MM EVK
> - i.MX8MP EVK
> - i.MX8MQ EVK
> - i.MX8DXL/QM/QXP EVK
> - i.MX95 15x15/19x19 EVK
>
> The driver maintains legacy regulator handling for device trees that
> haven't been updated yet. Both old and new device tree structures are
> supported.
>
Thanks for the work! Due to some recently merged patches, this series (Patch 1)
doesn't apply on top of pci/controller/dwc-imx6 branch. Please rebase and
resend!
- Mani
> [1] https://lore.kernel.org/all/20260318062916.2747472-1-sherry.sun@nxp.com/
>
> Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> ---
> Changes in V2:
> 1. After commit 2d8c5098b847 ("PCI/pwrctrl: Do not power off on pwrctrl
> device removal"), the pwrctrl drivers no longer power off devices
> during removal. Update pci-imx6 driver's shutdown callback in patch#1
> to explicitly call pci_pwrctrl_power_off_devices() before
> pci_pwrctrl_destroy_devices() to ensure devices are properly powered
> off.
> ---
>
> Sherry Sun (8):
> PCI: imx6: Integrate new pwrctrl API for pci-imx6
> arm: dts: imx6qdl-sabresd: Move power supply property to Root Port
> node
> arm: dts: imx6sx-sdb: Move power supply property to Root Port node
> arm64: dts: imx8mm-evk: Move power supply property to Root Port node
> arm64: dts: imx8mp-evk: Move power supply properties to Root Port node
> arm64: dts: imx8mq-evk: Move power supply properties to Root Port node
> arm64: dts: imx8dxl/qm/qxp: Move power supply properties to Root Port
> node
> arm64: dts: imx95: Move power supply properties to Root Port node
>
> .../arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi | 2 +-
> arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 2 +-
> arch/arm64/boot/dts/freescale/imx8dxl-evk.dts | 4 ++--
> arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 2 +-
> arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 4 ++--
> arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 4 ++--
> arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 4 ++--
> arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 4 ++--
> .../boot/dts/freescale/imx95-15x15-evk.dts | 4 ++--
> .../boot/dts/freescale/imx95-19x19-evk.dts | 8 +++----
> drivers/pci/controller/dwc/Kconfig | 1 +
> drivers/pci/controller/dwc/pci-imx6.c | 24 ++++++++++++++++++-
> 12 files changed, 43 insertions(+), 20 deletions(-)
>
> --
> 2.37.1
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] ASoC: rockchip: rockchip_sai: Set slot width for non-TDM mode
From: Nicolas Frattaroli @ 2026-04-04 17:16 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Heiko Stuebner, Sugar Zhang, Alexey Charkov
Cc: linux-rockchip, linux-sound, linux-arm-kernel, linux-kernel,
Alexey Charkov
In-Reply-To: <20260318-sai-slot-width-v1-1-1f68186f71e3@flipper.net>
On Wednesday, 18 March 2026 15:50:25 Central European Summer Time Alexey Charkov wrote:
> Currently the slot width in non-TDM mode is always kept at the POR value
> of 32 bits, regardless of the sample width, which doesn't work well for
> some codecs such as NAU8822.
>
> Set the slot width according to the sample width in non-TDM mode, which
> is what other CPU DAI drivers do.
>
> Tested on the following RK3576 configurations:
> - SAI2 + NAU8822 (codec as the clock master), custom board
> - SAI1 + ES8388 (codec as the clock master), RK3576 EVB1
> - SAI2 + RT5616 (SAI as the clock master), FriendlyElec NanoPi M5
>
> NAU8822 didn't work prior to this patch but works after the patch. Other
> two configurations work both before and after the patch.
>
> Fixes: cc78d1eaabad ("ASoC: rockchip: add Serial Audio Interface (SAI) driver")
> Signed-off-by: Alexey Charkov <alchark@flipper.net>
> ---
> sound/soc/rockchip/rockchip_sai.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/sound/soc/rockchip/rockchip_sai.c b/sound/soc/rockchip/rockchip_sai.c
> index 1bf614dbdf4d..ed393e5034a4 100644
> --- a/sound/soc/rockchip/rockchip_sai.c
> +++ b/sound/soc/rockchip/rockchip_sai.c
> @@ -628,6 +628,10 @@ static int rockchip_sai_hw_params(struct snd_pcm_substream *substream,
>
> regmap_update_bits(sai->regmap, reg, SAI_XCR_VDW_MASK | SAI_XCR_CSR_MASK, val);
>
> + if (!sai->is_tdm)
> + regmap_update_bits(sai->regmap, reg, SAI_XCR_SBW_MASK,
> + SAI_XCR_SBW(params_physical_width(params)));
> +
> regmap_read(sai->regmap, reg, &val);
>
> slot_width = SAI_XCR_SBW_V(val);
>
> ---
> base-commit: 8e5a478b6d6a5bb0a3d52147862b15e4d826af19
> change-id: 20260318-sai-slot-width-378eed5c22cd
>
> Best regards,
>
Okay, so I took a logic analyzer to the SAI today and found the following:
It seems we've always been sending 16-bit samples in 32-bit width slots per
channel before. With this change, we're now correctly sending 16-bit samples
in 16-bit slots.
In a follow-up patch (doesn't have to be in this one, this is fine to merge
as-is) we could also refactor the switch statement just above to no longer
exist but set val = SAI_XCR_VDW(params_width(params)).
So:
Acked-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Advertise ID_AA64PFR2_EL1.GCIE
From: Nathan Chancellor @ 2026-04-04 18:13 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, Sascha Bischoff, Will Deacon,
Catalin Marinas
In-Reply-To: <20260401170017.369529-1-maz@kernel.org>
Hi Marc,
On Wed, Apr 01, 2026 at 06:00:17PM +0100, Marc Zyngier wrote:
> As we are missing ID_AA64PFR2_EL1.GCIE from the kernel feature set,
> userspace cannot write ID_AA64PFR2_EL1 with GCIE set, even if we are
> on a GICv5 host.
>
> Add the required field description.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kernel/cpufeature.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 32c2dbcc0c641..5bca6e064ca72 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -327,6 +327,7 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr2[] = {
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_FPMR_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_MTEFAR_SHIFT, 4, ID_AA64PFR2_EL1_MTEFAR_NI),
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_MTESTOREONLY_SHIFT, 4, ID_AA64PFR2_EL1_MTESTOREONLY_NI),
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_GCIE_SHIFT, 4, ID_AA64PFR2_EL1_GCIE_NI),
> ARM64_FTR_END,
> };
>
> --
> 2.47.3
>
After this change in -next as commit 899ff451fcee ("KVM: arm64:
Advertise ID_AA64PFR2_EL1.GCIE"), I am seeing a warning on boot in my
simple QEMU boot tests.
$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux- mrproper virtconfig Image.gz
$ curl -LSs https://github.com/ClangBuiltLinux/boot-utils/releases/download/20241120-044434/arm64-rootfs.cpio.zst | zstd -d >rootfs.cpio
$ qemu-system-aarch64 \
-display none \
-nodefaults \
-machine virt,gic-version=max \
-append 'console=ttyAMA0 earlycon' \
-kernel arch/arm64/boot/Image.gz \
-initrd rootfs.cpio \
-cpu host \
-enable-kvm \
-m 1G \
-smp 8 \
-serial mon:stdio
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x413fd0c1]
[ 0.000000] Linux version 7.0.0-rc4-00058-g899ff451fcee (nathan@aadp) (aarch64-linux-gcc (GCC) 15.2.0, GNU ld (GNU Binutils) 2.45) #1 SMP PREEMPT Sat Apr 4 06:55:05 MST 2026
...
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] SYS_ID_AA64PFR2_EL1 has feature overlap at shift 12
[ 0.000000] WARNING: arch/arm64/kernel/cpufeature.c:986 at init_cpu_features+0xbc/0x344, CPU#0: swapper/0
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.0.0-rc4-00058-g899ff451fcee #1 PREEMPT
[ 0.000000] Hardware name: linux,dummy-virt (DT)
[ 0.000000] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.000000] pc : init_cpu_features+0xbc/0x344
[ 0.000000] lr : init_cpu_features+0xbc/0x344
[ 0.000000] sp : ffffcd0982373db0
[ 0.000000] x29: ffffcd0982373db0 x28: 0000000000000010 x27: ffffcd0981c63878
[ 0.000000] x26: 0000000000000018 x25: ffffcd0982013f38 x24: ffffcd0981c69068
[ 0.000000] x23: ffffcd0981c635f0 x22: ffffcd0982388640 x21: 0000000000000003
[ 0.000000] x20: 0000000000000017 x19: ffffcd09824c9308 x18: 000000000000000a
[ 0.000000] x17: 5d305b203837205d x16: 305b203737205d30 x15: 0000000000000000
[ 0.000000] x14: 0000000000000000 x13: 3231207466696873 x12: 2074612070616c72
[ 0.000000] x11: 0000000000000058 x10: 0000000000000018 x9 : ffffcd0982396598
[ 0.000000] x8 : 0000000000057fa8 x7 : 000000000000002a x6 : ffffcd09823ee598
[ 0.000000] x5 : ffffcd09823ee598 x4 : 0000000000000000 x3 : 0000000000000000
[ 0.000000] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffcd09823852c0
[ 0.000000] Call trace:
[ 0.000000] init_cpu_features+0xbc/0x344 (P)
[ 0.000000] cpuinfo_store_boot_cpu+0x48/0x54
[ 0.000000] smp_prepare_boot_cpu+0x28/0x38
[ 0.000000] start_kernel+0x248/0x780
[ 0.000000] __primary_switched+0x88/0x90
[ 0.000000] ---[ end trace 0000000000000000 ]---
...
```
Is this expected? I assume not, hence the report. If there is any
information I can provide or patches I can test, I am more than happy to
do so.
Cheers,
Nathan
# bad: [2febe6e6ee6e34c7754eff3c4d81aa7b0dcb7979] Add linux-next specific files for 20260403
# good: [d8a9a4b11a137909e306e50346148fc5c3b63f9d] Merge tag 'v7.0-rc6-smb3-client-fix' of git://git.samba.org/sfrench/cifs-2.6
git bisect start 'origin/master' 'origin/stable'
# bad: [dc9c72702de7e46679f8c2ab2175ab7070baa3ee] Merge branch 'main' of https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
git bisect bad dc9c72702de7e46679f8c2ab2175ab7070baa3ee
# bad: [d5ea83fae6558b2431b022781f6ccb74d241b2bb] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git
git bisect bad d5ea83fae6558b2431b022781f6ccb74d241b2bb
# bad: [d16ebd2d0dc90f1561d0a44a828db2c9148ad5f4] Merge branch 'for-next/perf' of https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git
git bisect bad d16ebd2d0dc90f1561d0a44a828db2c9148ad5f4
# bad: [768784742008ccebbf3e88a26a6e9e6aad76dc8e] Merge branch 'timekeeping-next' of https://github.com/Rust-for-Linux/linux.git
git bisect bad 768784742008ccebbf3e88a26a6e9e6aad76dc8e
# good: [b671065be2bef906bb3e0c1bc7be4055e84ea1d3] Merge branch 'at91-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git
git bisect good b671065be2bef906bb3e0c1bc7be4055e84ea1d3
# bad: [bd1f7328e25426f08cafa8333293411788c7957b] Merge branch kvm-arm64/vgic-fixes-7.1 into kvmarm-master/next
git bisect bad bd1f7328e25426f08cafa8333293411788c7957b
# good: [1cd0bb0425594cea9baf862393a4ca9cc0c018a3] Merge branch kvm-arm64/pkvm-psci into kvmarm-master/next
git bisect good 1cd0bb0425594cea9baf862393a4ca9cc0c018a3
# good: [bc20692f528b2ac8226bafe5b1db9a1f8be96dbf] KVM: arm64: Don't hold 'vm_table_lock' across guest page reclaim
git bisect good bc20692f528b2ac8226bafe5b1db9a1f8be96dbf
# good: [adb70b3a8b31e9eb05f2ec3c76d85f9a7a8c8cbc] KVM: arm64: Directly expose mapping prot and kill kvm_s2_fault
git bisect good adb70b3a8b31e9eb05f2ec3c76d85f9a7a8c8cbc
# good: [be46a408f376df31762e8a9914dc6d082755e686] KVM: arm64: Correctly plumb ID_AA64PFR2_EL1 into pkvm idreg handling
git bisect good be46a408f376df31762e8a9914dc6d082755e686
# good: [33cdd7f8fa32c92317aa521bd6f407a3cba8474b] Merge branch kvm-arm64/spe-trbe-nvhe into kvmarm-master/next
git bisect good 33cdd7f8fa32c92317aa521bd6f407a3cba8474b
# good: [e54971a0468a8bc82b1976d5b010392d7cb689b9] Merge branch kvm-arm64/vgic-fixes-7.1 into kvmarm-master/next
git bisect good e54971a0468a8bc82b1976d5b010392d7cb689b9
# bad: [899ff451fcee1289f3f37d061da66c3e38748a69] KVM: arm64: Advertise ID_AA64PFR2_EL1.GCIE
git bisect bad 899ff451fcee1289f3f37d061da66c3e38748a69
# good: [9c1ac77ddfc90b6292ef63a4fa5ab6f9e4b29981] KVM: arm64: vgic-v5: Fold PPI state for all exposed PPIs
git bisect good 9c1ac77ddfc90b6292ef63a4fa5ab6f9e4b29981
# first bad commit: [899ff451fcee1289f3f37d061da66c3e38748a69] KVM: arm64: Advertise ID_AA64PFR2_EL1.GCIE
^ permalink raw reply
* Re: (subset) [PATCH 00/12] treewide: Convert buses to use generic driver_override
From: Danilo Krummrich @ 2026-04-04 19:20 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: <a8c85884-e2ba-4a3a-a660-9715f0de2704@kernel.org>
On Sat Apr 4, 2026 at 7:09 PM CEST, Christophe Leroy (CS GROUP) wrote:
> Yes please pick it up as my tree is based on rc1.
Applied the patch to driver-core-testing, thanks!
^ permalink raw reply
* Re: [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA
From: Paul Kocialkowski @ 2026-04-04 19:29 UTC (permalink / raw)
To: Krzysztof Hałasa
Cc: dri-devel, imx, linux-arm-kernel, linux-kernel, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lucas Stach, Marco Felsch,
Liu Ying
In-Reply-To: <m3ldf4mzh4.fsf@t19.piap.pl>
[-- Attachment #1: Type: text/plain, Size: 2661 bytes --]
Hi Krzysztof,
Le Fri 03 Apr 26, 06:36, Krzysztof Hałasa a écrit :
> Paul Kocialkowski <paulk@sys-base.io> writes:
> > Interestingly I tried to keep the clocks always on as an experiment and it
> > had the opposite effect: the DMA engine would get confused every time after the
> > first mode set and disable. So for some reason the disabling of the clocks seems
> > to mitigate the issue rather than aggravate it.
>
> Interesting. Fortunately we have a workaround.
>
> >> > + ret = readl_poll_timeout(lcdif->base + LCDC_V8_CTRLDESCL0_5,
> >> > + reg, !(reg & CTRLDESCL0_5_SHADOW_LOAD_EN),
> >> > + 0, 36000); /* Wait ~2 frame times max */
> >>
> >> I guess this comment is not necessarily correct - at 2160p30 one frame =
> >> ca. 33 ms. Still works, though (I guess anything more than one frame is
> >> enough). I don't know how long a frame on HDMI (or LVDS, MIPI etc.) can
> >> take. 30 FPS on 2160p is common because the i.MX8MP can't display 2160p60.
> >
> > Honestly I think we're good assuming 30 fps (33 ms) is a lower bound.
> > And the current 36 ms goes even beyond, so I think it's fine.
>
> Right. It is just the comment in the code which is not exactly true.
> I.e., we "wait for at least 1 complete frame time". I guess.
> Also, the 25 ms in the patch (commit) message is no longer accurate.
In the end I made it 50 ms, which should be fine for all modes, and
adapted the comment in v2.
> >> Also, found an issue. Perhaps unrelated? Powered the board without HDMI
> >> connected. Then connected 1080p60 display. It came in 1024x768, console
> >> 64x24 :-)
> >
> > That looks more related to a failure to fetch the EDID from the monitor.
> > 1024x768 is the default fallback that is used in this situation.
> > Maybe check if there is something wrong with the DDC lines from the hdmi
> > controller, maybe pinmux etc.
>
> No no no, I did that on purpose - the monitor was really disconnected at
> the boot time. Only then (but before starting weston) i reconnected it.
> But it indeed appears to be a separate issue, a software one - a mutex
> deadlock on access to clocks and power management. Both enable and
> disable paths interfere there. "I will post a patch when I have a patch
> to post" :-)
Okay good to know, I'll get back to you if I also see this in the future :)
All the best,
Paul
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] ARM: dts: rockchip: Remove invalid properies from rk3288-veyron-analog-audio
From: Fabio Estevam @ 2026-04-04 19:50 UTC (permalink / raw)
To: heiko
Cc: robh, krzk+dt, conor+dt, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Fabio Estevam
From: Fabio Estevam <festevam@nabladev.com>
The 'rockchip,mic-det-gpios' property is not documented anywhere.
The 'rockchip,hp-det-gpios' property is not a valid property for the
'rockchip,rockchip-audio-max98090' compatible.
Remove both invalid properties.
Signed-off-by: Fabio Estevam <festevam@nabladev.com>
---
arch/arm/boot/dts/rockchip/rk3288-veyron-analog-audio.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/rockchip/rk3288-veyron-analog-audio.dtsi b/arch/arm/boot/dts/rockchip/rk3288-veyron-analog-audio.dtsi
index 51208d161d65..25c7c0667856 100644
--- a/arch/arm/boot/dts/rockchip/rk3288-veyron-analog-audio.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3288-veyron-analog-audio.dtsi
@@ -14,8 +14,6 @@ sound {
rockchip,model = "VEYRON-I2S";
rockchip,i2s-controller = <&i2s>;
rockchip,audio-codec = <&max98090>;
- rockchip,hp-det-gpios = <&gpio6 RK_PA5 GPIO_ACTIVE_HIGH>;
- rockchip,mic-det-gpios = <&gpio6 RK_PB3 GPIO_ACTIVE_LOW>;
rockchip,headset-codec = <&headsetcodec>;
rockchip,hdmi-codec = <&hdmi>;
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: Advertise ID_AA64PFR2_EL1.GCIE
From: Marc Zyngier @ 2026-04-04 21:07 UTC (permalink / raw)
To: Nathan Chancellor
Cc: kvmarm, linux-arm-kernel, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, Sascha Bischoff, Will Deacon,
Catalin Marinas
In-Reply-To: <20260404181330.GA3987102@ax162>
On Sat, 04 Apr 2026 19:13:30 +0100,
Nathan Chancellor <nathan@kernel.org> wrote:
>
> Hi Marc,
>
> On Wed, Apr 01, 2026 at 06:00:17PM +0100, Marc Zyngier wrote:
> > As we are missing ID_AA64PFR2_EL1.GCIE from the kernel feature set,
> > userspace cannot write ID_AA64PFR2_EL1 with GCIE set, even if we are
> > on a GICv5 host.
> >
> > Add the required field description.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kernel/cpufeature.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 32c2dbcc0c641..5bca6e064ca72 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -327,6 +327,7 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr2[] = {
> > ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_FPMR_SHIFT, 4, 0),
> > ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_MTEFAR_SHIFT, 4, ID_AA64PFR2_EL1_MTEFAR_NI),
> > ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_MTESTOREONLY_SHIFT, 4, ID_AA64PFR2_EL1_MTESTOREONLY_NI),
> > + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_GCIE_SHIFT, 4, ID_AA64PFR2_EL1_GCIE_NI),
> > ARM64_FTR_END,
> > };
> >
> > --
> > 2.47.3
> >
>
> After this change in -next as commit 899ff451fcee ("KVM: arm64:
> Advertise ID_AA64PFR2_EL1.GCIE"), I am seeing a warning on boot in my
> simple QEMU boot tests.
>
> $ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux- mrproper virtconfig Image.gz
>
> $ curl -LSs https://github.com/ClangBuiltLinux/boot-utils/releases/download/20241120-044434/arm64-rootfs.cpio.zst | zstd -d >rootfs.cpio
>
> $ qemu-system-aarch64 \
> -display none \
> -nodefaults \
> -machine virt,gic-version=max \
> -append 'console=ttyAMA0 earlycon' \
> -kernel arch/arm64/boot/Image.gz \
> -initrd rootfs.cpio \
> -cpu host \
> -enable-kvm \
> -m 1G \
> -smp 8 \
> -serial mon:stdio
> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x413fd0c1]
> [ 0.000000] Linux version 7.0.0-rc4-00058-g899ff451fcee (nathan@aadp) (aarch64-linux-gcc (GCC) 15.2.0, GNU ld (GNU Binutils) 2.45) #1 SMP PREEMPT Sat Apr 4 06:55:05 MST 2026
> ...
> [ 0.000000] ------------[ cut here ]------------
> [ 0.000000] SYS_ID_AA64PFR2_EL1 has feature overlap at shift 12
> [ 0.000000] WARNING: arch/arm64/kernel/cpufeature.c:986 at init_cpu_features+0xbc/0x344, CPU#0: swapper/0
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.0.0-rc4-00058-g899ff451fcee #1 PREEMPT
> [ 0.000000] Hardware name: linux,dummy-virt (DT)
> [ 0.000000] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 0.000000] pc : init_cpu_features+0xbc/0x344
> [ 0.000000] lr : init_cpu_features+0xbc/0x344
> [ 0.000000] sp : ffffcd0982373db0
> [ 0.000000] x29: ffffcd0982373db0 x28: 0000000000000010 x27: ffffcd0981c63878
> [ 0.000000] x26: 0000000000000018 x25: ffffcd0982013f38 x24: ffffcd0981c69068
> [ 0.000000] x23: ffffcd0981c635f0 x22: ffffcd0982388640 x21: 0000000000000003
> [ 0.000000] x20: 0000000000000017 x19: ffffcd09824c9308 x18: 000000000000000a
> [ 0.000000] x17: 5d305b203837205d x16: 305b203737205d30 x15: 0000000000000000
> [ 0.000000] x14: 0000000000000000 x13: 3231207466696873 x12: 2074612070616c72
> [ 0.000000] x11: 0000000000000058 x10: 0000000000000018 x9 : ffffcd0982396598
> [ 0.000000] x8 : 0000000000057fa8 x7 : 000000000000002a x6 : ffffcd09823ee598
> [ 0.000000] x5 : ffffcd09823ee598 x4 : 0000000000000000 x3 : 0000000000000000
> [ 0.000000] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffcd09823852c0
> [ 0.000000] Call trace:
> [ 0.000000] init_cpu_features+0xbc/0x344 (P)
> [ 0.000000] cpuinfo_store_boot_cpu+0x48/0x54
> [ 0.000000] smp_prepare_boot_cpu+0x28/0x38
> [ 0.000000] start_kernel+0x248/0x780
> [ 0.000000] __primary_switched+0x88/0x90
> [ 0.000000] ---[ end trace 0000000000000000 ]---
> ...
> ```
>
> Is this expected? I assume not, hence the report. If there is any
> information I can provide or patches I can test, I am more than happy to
> do so.
Gah. No idea how I managed to miss that: the register fields must be
strictly ordered, and I placed the field in the wrong spot. The
following hack fixes it for me:
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 5bca6e064ca72..1bfaa96881dab 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -325,9 +325,9 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr1[] = {
static const struct arm64_ftr_bits ftr_id_aa64pfr2[] = {
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_FPMR_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_GCIE_SHIFT, 4, ID_AA64PFR2_EL1_GCIE_NI),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_MTEFAR_SHIFT, 4, ID_AA64PFR2_EL1_MTEFAR_NI),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_MTESTOREONLY_SHIFT, 4, ID_AA64PFR2_EL1_MTESTOREONLY_NI),
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_GCIE_SHIFT, 4, ID_AA64PFR2_EL1_GCIE_NI),
ARM64_FTR_END,
};
If that works for you, I'll fold that into the original patch...
Thanks for pointing this out!
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply related
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