* 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
* Re: [RFC PATCH 0/2] mm: continue using per-VMA lock when retrying page faults after I/O
From: wang lian @ 2026-04-04 9:19 UTC (permalink / raw)
To: 21cnbao
Cc: akpm, linux-arm-kernel, linux-fsdevel, linux-kernel, linux-mm,
linux-riscv, linux-s390, linuxppc-dev, loongarch, surenb, willy,
wang lian, Wang Lian, Kunwu Chan, Kunwu Chan
In-Reply-To: <CAGsJ_4wnwAet4svDrxT4sTdp24sweAU-2VyYn3iNPOoaKdXxPw@mail.gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 6581 bytes --]
Hi Barry,
> If either you or Matthew have a reproducer for this issue, I’d be
> happy to try it out.
Kunwu and I evaluated this series ("mm: continue using per-VMA lock when
retrying page faults after I/O") under a stress scenario specifically
designed to expose the retry behavior in filemap_fault(). This models
the exact situation described by Matthew Wilcox [1], where retries after
I/O fail to make forward progress under memory pressure.
The scenario targets the critical window between I/O completion and
mmap_lock reacquisition. This workload deliberately includes frequent
mmap/munmap operations to simulate a highly contended mmap_lock
environment alongside severe memory pressure (1GB memcg limit). Under
this pressure, folios instantiated by the I/O can be aggressively
reclaimed before the delayed task can re-acquire the lock and install
the PTE, forcing retries to repeat the entire work.
To make this behavior reproducible, we constructed a stress setup that
intentionally extends this interval:
* 256-core x86 system
* 1GB memory cgroup
* 500 threads continuously faulting on a 16MB file
The core reproducer and the execution command are provided below:
#define _GNU_SOURCE
#include <errno.h>
#include <fcntl.h>
#include <pthread.h>
#include <stdatomic.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <unistd.h>
#include <time.h>
#define THREADS 500
#define FILE_SIZE (16 * 1024 * 1024) /* 16MB */
static _Atomic int g_stop = 0;
#define RUN_SECONDS 600
struct worker_arg {
long id;
uint64_t *counts;
};
void *worker(void *arg)
{
struct worker_arg *wa = (struct worker_arg *)arg;
long id = wa->id;
char path[64];
uint64_t local_rounds = 0;
snprintf(path, sizeof(path), "./test_file_%d_%ld.dat",
getpid(), id);
int fd = open(path, O_RDWR | O_CREAT | O_TRUNC, 0666);
if (fd < 0) return NULL;
if (ftruncate(fd, FILE_SIZE) < 0) {
close(fd); return NULL;
}
while (!atomic_load_explicit(&g_stop, memory_order_relaxed)) {
char *f_map = mmap(NULL, FILE_SIZE, PROT_READ,
MAP_SHARED, fd, 0);
if (f_map != MAP_FAILED) {
/* Pure page cache thrashing */
for (int i = 0; i < FILE_SIZE; i += 4096) {
volatile unsigned char c =
(unsigned char)f_map[i];
(void)c;
}
munmap(f_map, FILE_SIZE);
local_rounds++;
}
}
wa->counts[id] = local_rounds;
close(fd);
unlink(path);
return NULL;
}
int main(void)
{
printf("Pure File Thrashing Started. PID: %d\n", getpid());
pthread_t t[THREADS];
uint64_t local_counts[THREADS];
memset(local_counts, 0, sizeof(local_counts));
struct worker_arg args[THREADS];
for (long i = 0; i < THREADS; i++) {
args[i].id = i;
args[i].counts = local_counts;
pthread_create(&t[i], NULL, worker, &args[i]);
}
sleep(RUN_SECONDS);
atomic_store_explicit(&g_stop, 1, memory_order_relaxed);
for (int i = 0; i < THREADS; i++) pthread_join(t[i], NULL);
uint64_t total = 0;
for (int i = 0; i < THREADS; i++) total += local_counts[i];
printf("Total rounds : %llu\n", (unsigned long long)total);
printf("Throughput : %.2f rounds/sec\n",
(double)total / RUN_SECONDS);
return 0;
}
Command line used for the test:
systemd-run --scope -p MemoryHigh=1G -p MemoryMax=1.2G -p MemorySwapMax=0 \
--unit=mmap-thrash-$$ ./mmap_lock & \
TEST_PID=$!
We also added temporary counters in page fault retries [2]:
- RETRY_IO_MISS : folio not present after I/O completion
- RETRY_MMAP_DROP : retry fallback due to waiting for I/O
We report representative runs from our 600-second test iterations
(kernel v7.0-rc3):
| Case | Total Rounds | Throughput | Miss/Drop(%) | RETRY_MMAP_DROP | RETRY_IO_MISS |
| ------------------- | ------------ | ---------- | ------------ | --------------- | ------------- |
| Baseline (Run 1) | 22,711 | 37.85 /s | 45.04 | 970,078 | 436,956 |
| Baseline (Run 2) | 23,530 | 39.22 /s | 44.96 | 972,043 | 437,077 |
| With Series (Run A) | 54,428 | 90.71 /s | 1.69 | 1,204,124 | 20,398 |
| With Series (Run B) | 35,949 | 59.91 /s | 0.03 | 327,023 | 99 |
Notes:
1. Throughput Improvement: During the 600-second testing window, overall
workload throughput can more than double (e.g., Run A jumped from ~38
to 90.71 rounds/sec).
2. Elimination of Race Condition: Without the patch, ~45% of retries
were invalid because newly fetched folios were evicted during the
mmap_lock reacquisition delay. With the per-VMA retry path, the
invalidation ratio plummeted to near zero (0.03% - 1.69%).
3. Counter Scaling and Variance: In Run A, because the I/O wait
bottleneck is eliminated, the threads advance much faster. Thus, the
absolute number of mmap_lock drops naturally scales up with the
increased throughput. In Run B, the primary bottleneck shifts to the
mmap write-lock contention (lock convoying), causing throughput and
total drops to fluctuate. Crucially, the Miss/Drop ratio remains near
zero regardless of this variance.
Without this series, almost half of the retries fail to observe
completed I/O results, causing severe CPU and I/O waste. With the
finer-grained VMA lock, the faulting threads bypass the heavily
contended mmap_lock entirely during retries, completing the fault
almost instantly.
This scenario perfectly aligns with the exact concern raised, and these
results show that the patch not only successfully eliminates the retry
inefficiency but also tangibly boosts macro-level system throughput.
[1] https://lore.kernel.org/linux-mm/aSip2mWX13sqPW_l@casper.infradead.org/
[2] https://github.com/lianux-mm/ioretry_test/
Tested-by: Wang Lian <wanglian@kylinos.cn>
Tested-by: Kunwu Chan <chentao@kylinos.cn>
Reviewed-by: Wang Lian <lianux.mm@gmail.com>
Reviewed-by: Kunwu Chan <kunwu.chan@gmail.com>
--
Best Regards,
wang lian
^ permalink raw reply
* [PATCH] ARM: atags_compat: bound the deprecated command line copy
From: Pengpeng Hou @ 2026-04-03 8:56 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: linux-kernel, pengpeng
`build_tag_list()` still converts the deprecated `param_struct`
command line with `strlen()` and `strcpy()` from a fixed
`commandline[COMMAND_LINE_SIZE]` array.
That source buffer is not locally proven NUL-terminated before the
conversion runs, so malformed old boot parameters can make the helper
read past the end of the source array while sizing or copying the ATAG
command line.
Use `strnlen()` against the source buffer size and copy the bounded
length with an explicit terminator.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
arch/arm/kernel/atags_compat.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/atags_compat.c b/arch/arm/kernel/atags_compat.c
index 10da11c212cc..aa149710f0c0 100644
--- a/arch/arm/kernel/atags_compat.c
+++ b/arch/arm/kernel/atags_compat.c
@@ -92,6 +92,7 @@ static struct tag * __init memtag(struct tag *tag, unsigned long start, unsigned
static void __init build_tag_list(struct param_struct *params, void *taglist)
{
struct tag *tag = taglist;
+ size_t cmdline_len;
if (params->u1.s.page_size != PAGE_SIZE) {
pr_warn("Warning: bad configuration page, trying to continue\n");
@@ -195,9 +196,11 @@ static void __init build_tag_list(struct param_struct *params, void *taglist)
tag = tag_next(tag);
tag->hdr.tag = ATAG_CMDLINE;
- tag->hdr.size = (strlen(params->commandline) + 3 +
+ cmdline_len = strnlen(params->commandline, sizeof(params->commandline));
+ tag->hdr.size = (cmdline_len + 1 + 3 +
sizeof(struct tag_header)) >> 2;
- strcpy(tag->u.cmdline.cmdline, params->commandline);
+ memcpy(tag->u.cmdline.cmdline, params->commandline, cmdline_len);
+ tag->u.cmdline.cmdline[cmdline_len] = '\0';
tag = tag_next(tag);
tag->hdr.tag = ATAG_NONE;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH 0/5] mm/sparse-vmemmap: provide generic vmemmap_set_pmd() and vmemmap_check_pmd()
From: Muchun Song @ 2026-04-04 7:35 UTC (permalink / raw)
To: Muchun Song
Cc: Catalin Marinas, Will Deacon, Huacai Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, David S. Miller, Andreas Larsson,
Andrew Morton, David Hildenbrand, 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,
Yuquan Wang, Petr Tesarik, Austin Kim, Vishal Moola (Oracle),
Junhui Liu, Matthew Wilcox (Oracle), Alex Shi, Chengkaitao,
linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
sparclinux, linux-mm
In-Reply-To: <20260404071720.3577290-1-songmuchun@bytedance.com>
> On Apr 4, 2026, at 15:17, Muchun Song <songmuchun@bytedance.com> wrote:
>
> 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.
>
> 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
Hi all,
Please accept my sincere apologies for the mailing list noise.
Due to an error in my local scripts (failing to clean up the patch
output directory before regenerating the series with an updated commit
range), multiple duplicate and conflicting patches were accidentally
sent to the list simultaneously (10 patches in total instead of the
intended 5).
Sorry again for the inconvenience.
Thanks,
Muchun
>
> 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
* [PATCH 2/5] arm64/mm: drop vmemmap_pmd helpers and use generic code
From: Muchun Song @ 2026-04-04 7:17 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Muchun Song, Muchun Song, Ryan Roberts, Andrew Morton,
Kevin Brodsky, Dev Jain, Anshuman Khandual, Lorenzo Stoakes,
Yang Shi, Chaitanya S Prakash, linux-arm-kernel, linux-kernel
In-Reply-To: <20260404071720.3577290-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 1/4] arm64/mm: drop vmemmap_pmd helpers and use generic code
From: Muchun Song @ 2026-04-04 7:17 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Muchun Song, Muchun Song, Ryan Roberts, Andrew Morton,
David Hildenbrand, Kevin Brodsky, Dev Jain, Lorenzo Stoakes,
Anshuman Khandual, Yang Shi, Chaitanya S Prakash,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260404071720.3577290-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 0/5] mm/sparse-vmemmap: provide generic vmemmap_set_pmd() and vmemmap_check_pmd()
From: Muchun Song @ 2026-04-04 7:17 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: 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,
Yuquan Wang, Petr Tesarik, Austin Kim, Vishal Moola (Oracle),
Junhui Liu, Matthew Wilcox (Oracle), Alex Shi, Chengkaitao,
linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
sparclinux, linux-mm
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.
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: [RFC PATCH v2 3/5] iommu/arm-smmu-v3: Add Stream Table Entry display to debugfs
From: Nicolin Chen @ 2026-04-04 5:43 UTC (permalink / raw)
To: Qinxin Xia
Cc: robin.murphy, will, jpb, linux-arm-kernel, iommu, wangzhou1,
prime.zeng, fanghao11, jonathan.cameron, wuyifan50, linuxarm
In-Reply-To: <20260328101706.3448655-4-xiaqinxin@huawei.com>
On Sat, Mar 28, 2026 at 06:17:04PM +0800, Qinxin Xia wrote:
> +static int smmu_debugfs_ste_show(struct seq_file *seq, void *unused)
> +{
> + struct ste_context *ctx = seq->private;
> + struct arm_smmu_master *master = ctx->master;
> + struct arm_smmu_device *smmu;
> + struct arm_smmu_ste *ste;
> + u32 sid, cfg;
> + int i;
> +
> + if (!master) {
> + seq_puts(seq, "No SMMU master data\n");
> + return 0;
> + }
> +
> + smmu = master->smmu;
> + scoped_guard(mutex, &smmu->streams_mutex) {
Instead:
guard(mutex)(&smmu->streams_mutex);
> + sid = ctx->sid;
> +
> + if (!arm_smmu_sid_in_range(smmu, sid)) {
> + seq_printf(seq, "Invalid Stream ID: %u (max %u)\n",
> + sid, (1 << smmu->sid_bits) - 1);
> + return 0;
> + }
> +
> + ste = arm_smmu_get_step_for_sid(smmu, sid);
> + if (!ste) {
> + seq_printf(seq, "STE not available for SID %u\n", sid);
> + return 0;
> + }
> +
> + seq_printf(seq, "STE for Stream ID %u\n", sid);
> + seq_printf(seq, " Valid: %s\n",
> + le64_to_cpu(ste->data[0]) & STRTAB_STE_0_V ? "Yes" : "No");
> +
> + seq_puts(seq, " Config: ");
> +
> + cfg = FIELD_GET(STRTAB_STE_0_CFG, le64_to_cpu(ste->data[0]));
> +
> + switch (cfg) {
> + case STRTAB_STE_0_CFG_BYPASS:
> + seq_puts(seq, "BYPASS\n");
> + break;
> + case STRTAB_STE_0_CFG_S1_TRANS:
> + seq_puts(seq, "only S1_TRANS\n");
> + break;
> + case STRTAB_STE_0_CFG_S2_TRANS:
> + seq_puts(seq, "only S2_TRANS\n");
> + break;
> + case STRTAB_STE_0_CFG_NESTED:
> + seq_puts(seq, "S1+S2_TRANS\n");
> + break;
> + case STRTAB_STE_0_CFG_ABORT:
> + seq_puts(seq, "ABORT\n");
> + break;
> + default:
> + seq_puts(seq, "UNKNOWN\n");
> + }
> +
> + if (le64_to_cpu(ste->data[0]) & STRTAB_STE_0_CFG_S1_TRANS) {
> + seq_printf(seq, " S1ContextPtr: 0x%016llx\n",
> + le64_to_cpu(ste->data[1]) & STRTAB_STE_0_S1CTXPTR_MASK);
> + }
> +
> + if (le64_to_cpu(ste->data[0]) & STRTAB_STE_0_CFG_S2_TRANS) {
> + seq_printf(seq, " S2ContextPtr: 0x%016llx\n",
> + le64_to_cpu(ste->data[3]) & STRTAB_STE_3_S2TTB_MASK);
> + }
> +
> + /* Display raw STE data */
> + seq_puts(seq, " Raw Data:\n");
> + for (i = 0; i < STRTAB_STE_DWORDS; i++)
> + seq_printf(seq, " STE[%d]: 0x%016llx\n", i,
> + le64_to_cpu(ste->data[i]));
> + }
> + return 0;
Check the indentation of the return line.
> +/**
> + * arm_smmu_debugfs_create_stream_table() - Create debugfs entries for stream table
> + * @dev: device to create entries for
> + * @smmu: SMMU device
> + *
> + * Return: 0 on success, negative error code on failure
> + */
> +int arm_smmu_debugfs_create_stream_table(struct device *dev,
> + struct arm_smmu_device *smmu)
Usually @smmu would be the first parameter.
> +{
> + struct dentry *stream_dir, *dev_dir;
> + struct arm_smmu_master *master;
> + struct ste_context *ctx;
> + char name[64];
> + u32 sid;
> + int i;
> +
> + scoped_guard(mutex, &arm_smmu_debugfs_lock) {
> + if (!smmu->debugfs->stream_dir) {
> + stream_dir = debugfs_create_dir("stream_table",
> + smmu->debugfs->smmu_dir);
> + if (!stream_dir)
> + return -ENOMEM;
> +
> + smmu->debugfs->stream_dir = stream_dir;
> + } else {
> + stream_dir = smmu->debugfs->stream_dir;
> + }
> + }
> +
> + master = dev_iommu_priv_get(dev);
> + if (!master || !master->num_streams)
> + return -ENODEV;
> +
> + for (i = 0; i < master->num_streams; i++) {
> + sid = master->streams[i].id;
> + snprintf(name, sizeof(name), "%u", sid);
> + dev_dir = debugfs_create_dir(name, stream_dir);
> + if (!dev_dir)
> + continue;
> +
> + /* Create STE file */
> + ctx = kzalloc_obj(*ctx);
> + ctx->master = master;
> + ctx->sid = sid;
> + spin_lock(&smmu->debugfs->stream_lock);
> + list_add_tail(&ctx->node, &smmu->debugfs->stream_list);
> + spin_unlock(&smmu->debugfs->stream_lock);
May consider an RCU list instead of locking.
> +/**
> + * arm_smmu_debugfs_remove_stream_table() - Remove debugfs entries for stream table
> + * @dev: device to remove entries for
> + * @smmu: SMMU device
Again, @smmu could be the first parameter.
> + * This function removes the debugfs directories created by
> + * arm_smmu_debugfs_create_stream_table().
> + */
> +void arm_smmu_debugfs_remove_stream_table(struct device *dev,
> + struct arm_smmu_device *smmu)
Please double check the indentation. It looks odd on my side.
> -static struct arm_smmu_ste *
> +#ifndef CONFIG_ARM_SMMU_V3_DEBUGFS
> +static
> +#endif
> +struct arm_smmu_ste *
> arm_smmu_get_step_for_sid(struct arm_smmu_device *smmu, u32 sid)
Could probably move this to the header.
> -static bool arm_smmu_sid_in_range(struct arm_smmu_device *smmu, u32 sid)
> +#ifndef CONFIG_ARM_SMMU_V3_DEBUGFS
> +static
> +#endif
> +bool arm_smmu_sid_in_range(struct arm_smmu_device *smmu, u32 sid)
Ditto
> @@ -3648,10 +3658,14 @@ static void arm_smmu_release_device(struct device *dev)
>
> WARN_ON(master->iopf_refcount);
>
> +#ifdef CONFIG_ARM_SMMU_V3_DEBUGFS
> + arm_smmu_debugfs_remove_stream_table(dev, master->smmu);
> +#endif
> arm_smmu_disable_pasid(master);
> arm_smmu_remove_master(master);
> if (arm_smmu_cdtab_allocated(&master->cd_table))
> arm_smmu_free_cd_tables(master);
> +
> kfree(master);
Meaningless line.
> struct arm_smmu_debugfs {
> + struct list_head stream_list;
> + spinlock_t stream_lock;
> struct dentry *smmu_dir;
> + struct dentry *stream_dir;
> /* Reserved for future extensions */
> };
That's the end of the struct. What do you reserve?
Nicolin
^ permalink raw reply
* [PATCH v3 2/8] perf build loongarch: Remove reference to missing file
From: Ian Rogers @ 2026-04-04 5:40 UTC (permalink / raw)
To: acme
Cc: irogers, 9erthalion6, adrian.hunter, alex, alexander.shishkin,
andrew.jones, aou, atrajeev, blakejones, ctshao, dapeng1.mi,
howardchu95, james.clark, john.g.garry, jolsa, leo.yan,
libunwind-devel, linux-arm-kernel, linux-kernel, linux-perf-users,
linux-riscv, mingo, namhyung, palmer, peterz, pjw, shimin.guo,
tglozar, tmricht, will, yuzhuo
In-Reply-To: <20260404054032.1538095-1-irogers@google.com>
The file was removed in commit e62fae9d9e85 ("perf unwind-libdw: Fix a
cross-arch unwinding bug") but the Build file not updated.
Fixes: e62fae9d9e85 ("perf unwind-libdw: Fix a cross-arch unwinding bug")
Signed-off-by: Ian Rogers <irogers@google.com>
---
tools/perf/arch/loongarch/util/Build | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/perf/arch/loongarch/util/Build b/tools/perf/arch/loongarch/util/Build
index 3ad73d0289f3..8d91e78d31c9 100644
--- a/tools/perf/arch/loongarch/util/Build
+++ b/tools/perf/arch/loongarch/util/Build
@@ -1,4 +1,3 @@
perf-util-y += header.o
perf-util-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
-perf-util-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o
--
2.53.0.1213.gd9a14994de-goog
^ 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