* Re: [PATCH v2] iommu: Always fill in gather when unmapping
From: Jason Gunthorpe @ 2026-04-02 16:51 UTC (permalink / raw)
To: Robin Murphy
Cc: Alexandre Ghiti, AngeloGioacchino Del Regno, Albert Ou, asahi,
Baolin Wang, iommu, Janne Grunau, Jernej Skrabec, Joerg Roedel,
Jean-Philippe Brucker, linux-arm-kernel, linux-mediatek,
linux-riscv, linux-sunxi, Matthias Brugger, Neal Gompa,
Orson Zhai, Palmer Dabbelt, Paul Walmsley, Samuel Holland,
Sven Peter, virtualization, Chen-Yu Tsai, Will Deacon, Yong Wu,
Chunyan Zhang, Lu Baolu, Janusz Krzysztofik, Joerg Roedel,
Jon Hunter, patches, Pranjal Shrivastava, Samiullah Khawaja,
stable, Vasant Hegde
In-Reply-To: <70a128f9-d6f0-41b6-8fef-e249c0507149@arm.com>
On Thu, Apr 02, 2026 at 04:59:29PM +0100, Robin Murphy wrote:
> > @@ -666,9 +666,22 @@ static size_t __arm_lpae_unmap(struct arm_lpae_io_pgtable *data,
> > /* Clear the remaining entries */
> > __arm_lpae_clear_pte(ptep, &iop->cfg, i);
> > - if (gather && !iommu_iotlb_gather_queued(gather))
> > - for (int j = 0; j < i; j++)
> > - io_pgtable_tlb_add_page(iop, gather, iova + j * size, size);
> > + if (gather && !iommu_iotlb_gather_queued(gather)) {
> > + if (iop->cfg.tlb && iop->cfg.tlb->tlb_add_range) {
> > + iop->cfg.tlb->tlb_add_range(gather, iova,
> > + i * size, size,
> > + iop->cookie);
> > +
> > + } else {
> > + iommu_iotlb_gather_add_range(gather, iova,
> > + i * size);
> > +
> > + for (int j = 0; j < i; j++)
> > + io_pgtable_tlb_add_page(iop, gather,
> > + iova + j * size,
> > + size);
> > + }
> > + }
>
> NAK, this is insane.
This quite an optimization for SMMUv3 so it doesn't have to fit into
the ill fitting add_page api. What is "insane" here?
> If you'd rather make gathers mandatory for all drivers than fix it in the
> core code, then for goodness' sake just add the trivial one-liner to the
> handful of .unamp_pages implementations which need it,
Do I understand this right, you want to not touch io-pgtable and
instead the unmap trampolines will fix the gather like mkt is doing?
Jason
^ permalink raw reply
* Re: [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA
From: Paul Kocialkowski @ 2026-04-02 16:50 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: <m3y0j8mhoz.fsf@t19.piap.pl>
[-- Attachment #1: Type: text/plain, Size: 9092 bytes --]
Hi Krzysztof,
On Tue 31 Mar 26, 12:11, Krzysztof Hałasa wrote:
> Paul Kocialkowski writes:
> > It is necessary to wait for the full frame to finish streaming
> > through the DMA engine before we can safely disable it by removing
> > the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
> > hardware confused and unable to resume streaming for the next frame.
> >
> > This causes the FIFO underrun and empty status bits to be set and
> > a single solid color to be shown on the display, coming from one of
> > the pixels of the previous frame. The issue occurs sporadically when
> > a new mode is set, which triggers the crtc disable and enable paths.
> >
> > Setting the shadow load bit and waiting for it to be cleared by the
> > DMA engine allows waiting for completion.
> >
> > The NXP BSP driver addresses this issue with a hardcoded 25 ms sleep.
>
> ...or "addressed" in the previous version :-)
>
> Test results: it works for me: at 1080p60 and 2160p30. I.e. it fixed the
> underrun problem. It's interesting how a CRTC shutdown can affect it's
> subsequent start following an SW_RESET.
Thanks for confirming! Indeed it's a bit surprising. I'm not sure what SW_RESET
does exactly but it may not concern the DMA part. I've tried using it in the
irq handler when the underrun is reported and it didn't do anything at all.
> Or... perhaps it has something to do with the clocks? Also see below.
> If somehow the DMA engine was "running" with it's clock disabled, it
> would result in an underrun, or worse.
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.
I think the issue probably boils down to a corrupted internal state of the DMA
engine if it is disabled while streaming pixels. This is more or less what the
comment from NXP suggests.
> BTW apparently something converted your tab characters into spaces.
Ah good to know, thanks!
> > --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > @@ -393,6 +393,22 @@ static void lcdif_disable_controller(struct lcdif_drm_private *lcdif)
> > if (ret)
> > drm_err(lcdif->drm, "Failed to disable controller!\n");
> >
> > + /*
> > + * It is necessary to wait for the full frame to finish streaming
> > + * through the DMA engine before we can safely disable it by removing
> > + * the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
> > + * hardware confused and unable to resume streaming for the next frame.
> > + */
> > + reg = readl(lcdif->base + LCDC_V8_CTRLDESCL0_5);
> > + reg |= CTRLDESCL0_5_SHADOW_LOAD_EN;
> > + writel(reg, lcdif->base + LCDC_V8_CTRLDESCL0_5);
> > +
> > + 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.
> 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.
> Run weston. Pressed ctrl-alt-backspace. It deadlocked. Sysrq (serial
> console, show blocked state) showed (with *lcdif* in it):
> task:systemd-logind state:D stack:0 pid:253 tgid:253 ppid:1 task_flags:0x400100 flags:0x00000800
> Call trace:
> ...
> schedule+0x34/0x118
> rpm_resume+0x188/0x678
> __pm_runtime_resume+0x4c/0x98
> clk_pm_runtime_get.part.0.isra.0+0x1c/0x94
> clk_core_set_rate_nolock+0xd0/0x2fc
> clk_set_rate+0x38/0x158
> lcdif_crtc_atomic_enable+0x74/0x8d0
> drm_atomic_helper_commit_crtc_enable+0xac/0x104
> drm_atomic_helper_commit_tail_rpm+0x68/0xd8
> commit_tail+0xa4/0x1a4
> drm_atomic_helper_commit+0x178/0x1a0
> drm_atomic_commit+0x8c/0xcc
> drm_client_modeset_commit_atomic+0x1f8/0x25c
> drm_client_modeset_commit_locked+0x60/0x17c
> __drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0x2c/0x8c
> drm_fb_helper_set_par+0x5c/0x78
> fb_set_var+0x190/0x35c
> fbcon_blank+0x178/0x24c
> do_unblank_screen+0xa8/0x19c
> vt_ioctl+0x4fc/0x14c0
> tty_ioctl+0x228/0xb88
> __arm64_sys_ioctl+0x90/0xe4
> ...
>
> This is reproducible, though not always.
That seems to be in the enable path and related to runtime pm.
I don't think it is related to my patch at all.
> It seems it locks on some mutex - the shell works until I do 'cat
> log.txt' or similar. Now (with std output/error redirection?), weston
> doesn't even start.
>
> dmesg doesn't show anything of interest.
> weston: 14.0.2
> using /dev/dri/card1
> DRM: supports atomic modesetting
> DRM: supports GBM modifiers
> DRM: does not support Atomic async page flip
> DRM: supports picture aspect ratio
> Loading module '/usr/lib64/libweston-14/gl-renderer.so'
> Using rendering device: /dev/dri/renderD128
> EGL version: 1.5
> EGL vendor: Mesa Project
> EGL client APIs: OpenGL OpenGL_ES
> ...
> Registered plugin API 'weston_drm_output_api_v1' of size 40
> Registered plugin API 'weston_drm_virtual_output_api_v2' of size 48
> Color manager: no-op
> protocol support: no
> Output 'HDMI-A-1' attempts EOTF mode SDR and colorimetry mode default.
> Output 'HDMI-A-1' using color profile: stock sRGB color profile
> Chosen EGL config details: id: 17 rgba: 8 8 8 0 buf: 24 dep: 0 stcl: 0 int: 1-1 type: win vis_id: XRGB8
> )
> Output HDMI-A-1 (crtc 37) video modes:
> 1920x1080@60.0, preferred, current, 148.5 MHz
>
> Output 'HDMI-A-1' enabled with head(s) HDMI-A-1
> Loading module '/usr/lib64/weston/desktop-shell.so'
> launching '/usr/libexec/weston-keyboard'
> launching '/usr/libexec/weston-desktop-shell'
> Warning: computed repaint delay for output [HDMI-A-1] is abnormal: -69164 msec (happens always)
>
> could not load cursor 'dnd-copy'
> could not load cursor 'dnd-copy'
> could not load cursor 'dnd-none'
> could not load cursor 'dnd-none'
>
> Why all these clk* mutexes? Perhaps something didn't work out as it
> should there? clk_set_rate isn't supposed to take much time, is it?
Maybe something to do with the clock driver.
It seems pretty much unrelated to the lcdif driver.
All the best,
Paul
> $ grep clk /tmp/minicom.cap -C1
> [ 728.310054] __pm_runtime_resume+0x4c/0x98
> [ 728.310059] clk_pm_runtime_get.part.0.isra.0+0x1c/0x94
> [ 728.310065] clk_core_set_rate_nolock+0xd0/0x2fc
> [ 728.310071] clk_set_rate+0x38/0x158
> [ 728.310076] lcdif_crtc_atomic_enable+0x74/0x8d0
> --
> [ 728.310210] mutex_lock+0x48/0x58
> [ 728.310216] clk_prepare_lock+0x80/0xc0
> [ 728.310223] clk_unprepare+0x28/0x44
> [ 728.310227] fsl_samsung_hdmi_phy_suspend+0x24/0x40
> --
> [ 728.310344] mutex_lock+0x48/0x58
> [ 728.310350] clk_prepare_lock+0x80/0xc0
> [ 728.310359] clk_unprepare+0x28/0x44
> [ 728.310364] etnaviv_gpu_clk_disable.isra.0+0x28/0x80
> [ 728.310372] etnaviv_gpu_rpm_suspend+0x78/0x1dc
> --
> [ 728.310494] mutex_lock+0x48/0x58
> [ 728.310499] clk_prepare_lock+0x80/0xc0
> [ 728.310506] clk_unprepare+0x28/0x44
> [ 728.310512] sdhci_esdhc_runtime_suspend+0x7c/0x198
> --
> [ 728.310627] mutex_lock+0x48/0x58
> [ 728.310632] clk_prepare_lock+0x80/0xc0
> [ 728.310639] clk_round_rate+0x38/0x1d8
> [ 728.310646] dev_pm_opp_set_rate+0xe4/0x2e0
> --
> [ 728.310760] mutex_lock+0x48/0x58
> [ 728.310765] clk_prepare_lock+0x80/0xc0
> [ 728.310771] clk_prepare+0x1c/0x50
> [ 728.310778] sdhci_esdhc_runtime_resume+0x34/0x180
> --
> [ 728.311286] mutex_lock+0x48/0x58
> [ 728.311292] clk_prepare_lock+0x80/0xc0
> [ 728.311298] clk_prepare+0x1c/0x50
> [ 728.311303] sdhci_esdhc_runtime_resume+0x34/0x180
>
> Something fishy here.
> --
> Krzysztof "Chris" Hałasa
>
> Sieć Badawcza Łukasiewicz
> Przemysłowy Instytut Automatyki i Pomiarów PIAP
> Al. Jerozolimskie 202, 02-486 Warszawa
--
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
* Re: [PATCH 3/8] firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
From: Arnd Bergmann @ 2026-04-02 16:47 UTC (permalink / raw)
To: Thomas Zimmermann, Javier Martinez Canillas, Ard Biesheuvel,
Ilias Apalodimas, Huacai Chen, WANG Xuerui, Maarten Lankhorst,
Maxime Ripard, Dave Airlie, Simona Vetter, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, longli, Helge Deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev
In-Reply-To: <001efe27-9cbb-4a89-8d2d-a1f3ae15e505@suse.de>
On Thu, Apr 2, 2026, at 17:27, Thomas Zimmermann wrote:
> Am 02.04.26 um 16:59 schrieb Arnd Bergmann:
>> On Thu, Apr 2, 2026, at 16:10, Thomas Zimmermann wrote:
>>> Am 02.04.26 um 15:08 schrieb Arnd Bergmann:
>>>> On Thu, Apr 2, 2026, at 11:09, Thomas Zimmermann wrote:
>>>> I don't really like this part of the series and would prefer
>>>> to keep CONFIG_SYSFB hidden as much as possible as an x86
>>>> (and EFI) specific implementation detail, with the hope
>>>> of eventually seperating out the x86 bits from the EFI ones.
>>> You mean, you want to use the EFI-provided framebuffers without the
>>> intermediate step of going through sysfb_primary_display?
>>>
>>> In that case, CONFIG_SYSFB would become an x86-internal thing, right?
>> The part that is still needed from sysfb is the arbitration
>> between DRM_EFI and the PCI device driver for the same hardware,
>> so I think some part of sysfb is clearly needed, in particular
>> the sysfb_disable() function that removes the EFI framebuffer
>> when there is a conflicting simpledrm or hardware specific
>> driver.
>
> We do most of that in the aperture-helper module. (see
> <linux/aperture.h>). Calling sysfb_disable() from there is a workaround
> for some corner cases. We can have an EFI-specific function that does
> the same.
That sounds good, yes. The same change would need to go into
of_platform_default_populate_init() then.
> BTW, simpledrm-on-EFI/VESA is considered obsolete and should preferably
> be removed from that driver. Simpledrm should become a driver for
> Devicetree nodes of type simple-framebuffer (as it originally has been
> intended).
Sure, I was only thinking of the case where there are both
sysfb (from Arm/riscv UEFI) and simpledrm (from devicetree)
objects referring to the same one, not the simpledrm
device created by sysfb_simplefb.
>> The parts that I want to keep out of that is anything
>> related to the x86 boot protocol, non-EFI framebuffers,
>> text console, and kexec handoff, which we don't need on
>> non-x86 UEFI systems.
>>
>> I don't mind the idea of having a sysfb_primary_display
>> in the EFI code if that helps keep EFI sane on x86,
>> but it would be good to make that local to
>> drivers/firmware/efi and (eventually) detached from
>> include/uapi/linux/screen_info.h.
>
> Efidrm retrieves the framebuffer settings from the contained struct
> screen_info. Disconnecting from screen_info would require separate
> graphics drivers for x86 and non-x86. If we split off EFI from sysfb,
> we'd likely need a sysfbdrm driver of some sort. Just saying.
Yes, I saw that as well and don't have an immediate idea for how
to best do it. I saw that you already abstracted the access to
the screen_info members in drm_sysfb_screen_info.c, which I think
is a step in that direction.
I also noticed that efidrm is mostly a subset of vesadrm, so
in theory they could be merged back into an x86 drm driver
along with the drm_sysfb_screen_info helpers, and have a non-x86
driver that constructs a drm_sysfb_device directly from the
EFI structures.
> I think we'd also have to duplicate the framebuffer-relocation code that
> currently works on anything using struct screen_info (see patch 5).
You mean the code from include/linux/screen_info.h? I think
it would make sense to have an x86 specific version of that
to operate on the x86 screen_info, and a simpler version
that just updates the resource for the efirdrm driver, but
that could also be done one level higher or lower.
>>>> In general, I am always in favor of properly using Kconfig
>>>> dependencies over 'select' statements, for the same reasons
>>>> you describe, but I don't want the the x86 logic for
>>>> the legacy VESA and VGA console handling to leak into more
>>>> architectures than necessary.
>>>>
>>>> Do you think we could instead move the sysfb_init()
>>>> function into the same two places that contain the
>>>> sysfb_primary_display definition (arch/x86/kernel/setup.c,
>>>> drivers/firmware/efi/efi-init.c) and simplify the efi version
>>>> to take out the x86 bits? That would reduce the rest
>>>> of sysfb-primary.c to the logic to unregister the device,
>>>> and that could then be selected by both x86 and EFI.
>>> No, I'm more than happy that sysfb finally consolidates all the
>>> init-framebuffer setup and detection that floated around in the kernel.
>>> I would not want it to be duplicated again.
>>>
>>> For now, we could certainly keep CONFIG_SYSFB hidden and autoselected.
>>> Although I think this will require soem sort of solution at a later point.
>> Can you clarify which problem you are trying to solve
>> with that?
>
> One thing is that some users simply what control over their kernel build.
>
> I also think that there might be systems that want to use
> sysfb_primary_display (plus the relocation feature), but not create the
> framebuffer device. Say for efi-earlycon. It needs user-control over the
> SYSFB option to do that.
I'm still not following, sorry. efi-earlycon doesn't require
CONFIG_SYSFB today, and I don't see why that would need to change,
or why it couldn't just 'select SYSFB' if it it does change.
> As a side-effect, user-configurable SYSFB gives us a nice place to put
> SYSFB_SIMPLEFB and FIRMWARE_EDID; two options that currently float
> around in the config somewhat arbitrarily.
You said that SYSFB_SIMPLEFB should get phased out in the future,
right?
I'm also missing your plan for CONFIG_FIRMWARE_EDID. I only
see three legacy drivers using the old fb_firmware_edid()
interface, so I assume this is not what you are interested in.
For the global copy that is filled by x86 and efi, and
consumed by vesadrm and efidrm, does that even need to
be a configuration option rather than get always enabled?
Arnd
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: gpio: Add eio gpio node to gpio-zynq
From: Krzysztof Kozlowski @ 2026-04-02 16:48 UTC (permalink / raw)
To: Shubhrajyoti Datta, linux-kernel
Cc: git, shubhrajyoti.datta, Srinivas Neeli, Michal Simek,
Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <c28e97b2-4266-4a32-b70d-049518c606fe@kernel.org>
On 02/04/2026 18:46, Krzysztof Kozlowski wrote:
> On 02/04/2026 18:38, Shubhrajyoti Datta wrote:
>> Add the EIO gpio node to the device tree.
>
> What is EIO? A name of new SoC? Or you forgot to include the SoC here?
>
>
>> The EIO GPIO block exposes only bank 0 and bank 1 to
>> multiplexed I/O pins, providing a fixed total of 52 GPIO lines
>> (2 banks × 26 pins). Enforce this hardware constraint by requiring
>> exactly 52 entries in gpio-line-names for the EIO variant.
>
> Don't describe the syntax. We can read the diff.
>
I also receive immediate Out of office bounces when replying. Please do
not cc addresses of people who cannot set up correctly their
autoresponder and send to open source Out of office messages.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: gpio: Add eio gpio node to gpio-zynq
From: Krzysztof Kozlowski @ 2026-04-02 16:46 UTC (permalink / raw)
To: Shubhrajyoti Datta, linux-kernel
Cc: git, shubhrajyoti.datta, Srinivas Neeli, Michal Simek,
Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260402163840.938417-2-shubhrajyoti.datta@amd.com>
On 02/04/2026 18:38, Shubhrajyoti Datta wrote:
> Add the EIO gpio node to the device tree.
What is EIO? A name of new SoC? Or you forgot to include the SoC here?
> The EIO GPIO block exposes only bank 0 and bank 1 to
> multiplexed I/O pins, providing a fixed total of 52 GPIO lines
> (2 banks × 26 pins). Enforce this hardware constraint by requiring
> exactly 52 entries in gpio-line-names for the EIO variant.
Don't describe the syntax. We can read the diff.
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
> ---
>
> .../devicetree/bindings/gpio/gpio-zynq.yaml | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
> index 5e2496379a3c..b8dd279753a5 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
> +++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
> @@ -16,6 +16,7 @@ properties:
> - xlnx,zynqmp-gpio-1.0
> - xlnx,versal-gpio-1.0
> - xlnx,pmc-gpio-1.0
> + - xlnx,eio-gpio-1.0
Please keep some sane ordering.
>
Best regards,
Krzysztof
^ permalink raw reply
* ✅ PASS: Test report for for-kernelci (7.0.0-rc6, upstream-arm-next, 2465c01b)
From: cki-project @ 2026-04-02 16:43 UTC (permalink / raw)
To: will, linux-arm-kernel, catalin.marinas
Hi, we tested your kernel and here are the results:
Overall result: PASSED
Merge: OK
Compile: OK
Test: OK
Tested-by: CKI Project <cki-project@redhat.com>
Kernel information:
Commit message: Merge remote-tracking branch 'origin/nocache-cleanup' into for-kernelci
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2425851817
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* Re: [PATCH v5 1/4] kernel: ksysfs: initialize kernel_kobj earlier
From: Bartosz Golaszewski @ 2026-04-02 16:40 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann, driver-core,
linux-kernel, linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <DHITFGL3J4IE.2WZU3K2CSYL7I@kernel.org>
On Thu, Apr 2, 2026 at 6:39 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Thu Apr 2, 2026 at 4:15 PM CEST, Bartosz Golaszewski wrote:
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 0f258aeeacba184d2025b932d90280cf2aabf4b0..8bc934162e712cf8ddf033e53bf3481054cfb7fe 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -7843,6 +7843,7 @@ F: include/linux/debugfs.h
> > F: include/linux/device.h
> > F: include/linux/fwnode.h
> > F: include/linux/kobj*
> > +F: include/linux/ksysfs.h
>
> Currently, kernel/ksysfs.c is not listed in the driver core entry (it is not in
> any entry), but I guess that would make sense.
>
> So, we should probably also add kernel/ksysfs.c. :) But this can be a separate
> patch independent of this series.
Ok, I take it no need to resend this?
Bart
^ permalink raw reply
* [PATCH 2/2] gpio: zynq: Add eio gpio support
From: Shubhrajyoti Datta @ 2026-04-02 16:38 UTC (permalink / raw)
To: linux-kernel
Cc: git, shubhrajyoti.datta, Shubhrajyoti Datta, Srinivas Neeli,
Michal Simek, Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260402163840.938417-1-shubhrajyoti.datta@amd.com>
Add support for the EIO GPIO controller found on
xa2ve3288 silicon.
The EIO GPIO block provides access to multiplexed I/O pins exposed
through the EIO interface. Only bank 0 and bank 1 are connected to
external MIO pins, with 26 GPIOs per bank (52 GPIOs total). This
change extends the Zynq GPIO driver to support the EIO GPIO
variant.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
---
drivers/gpio/gpio-zynq.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
index 571e366624d2..8118ae3412c2 100644
--- a/drivers/gpio/gpio-zynq.c
+++ b/drivers/gpio/gpio-zynq.c
@@ -25,6 +25,7 @@
#define VERSAL_GPIO_MAX_BANK 4
#define PMC_GPIO_MAX_BANK 5
#define VERSAL_UNUSED_BANKS 2
+#define EIO_GPIO_MAX_BANK 2
#define ZYNQ_GPIO_BANK0_NGPIO 32
#define ZYNQ_GPIO_BANK1_NGPIO 22
@@ -818,6 +819,16 @@ static const struct dev_pm_ops zynq_gpio_dev_pm_ops = {
RUNTIME_PM_OPS(zynq_gpio_runtime_suspend, zynq_gpio_runtime_resume, NULL)
};
+static const struct zynq_platform_data eio_gpio_def = {
+ .label = "eio_gpio",
+ .ngpio = 52,
+ .max_bank = EIO_GPIO_MAX_BANK,
+ .bank_min[0] = 0,
+ .bank_max[0] = 25, /* 0 to 25 are connected to MIOs (26 pins) */
+ .bank_min[1] = 26,
+ .bank_max[1] = 51, /* Bank 1 are connected to MIOs (26 pins) */
+};
+
static const struct zynq_platform_data versal_gpio_def = {
.label = "versal_gpio",
.quirks = GPIO_QUIRK_VERSAL,
@@ -882,6 +893,7 @@ static const struct of_device_id zynq_gpio_of_match[] = {
{ .compatible = "xlnx,zynqmp-gpio-1.0", .data = &zynqmp_gpio_def },
{ .compatible = "xlnx,versal-gpio-1.0", .data = &versal_gpio_def },
{ .compatible = "xlnx,pmc-gpio-1.0", .data = &pmc_gpio_def },
+ { .compatible = "xlnx,eio-gpio-1.0", .data = &eio_gpio_def },
{ /* end of table */ }
};
MODULE_DEVICE_TABLE(of, zynq_gpio_of_match);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v5 1/4] kernel: ksysfs: initialize kernel_kobj earlier
From: Danilo Krummrich @ 2026-04-02 16:39 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-1-d730db3dd299@oss.qualcomm.com>
On Thu Apr 2, 2026 at 4:15 PM CEST, Bartosz Golaszewski wrote:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0f258aeeacba184d2025b932d90280cf2aabf4b0..8bc934162e712cf8ddf033e53bf3481054cfb7fe 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7843,6 +7843,7 @@ F: include/linux/debugfs.h
> F: include/linux/device.h
> F: include/linux/fwnode.h
> F: include/linux/kobj*
> +F: include/linux/ksysfs.h
Currently, kernel/ksysfs.c is not listed in the driver core entry (it is not in
any entry), but I guess that would make sense.
So, we should probably also add kernel/ksysfs.c. :) But this can be a separate
patch independent of this series.
^ permalink raw reply
* [PATCH 1/2] dt-bindings: gpio: Add eio gpio node to gpio-zynq
From: Shubhrajyoti Datta @ 2026-04-02 16:38 UTC (permalink / raw)
To: linux-kernel
Cc: git, shubhrajyoti.datta, Shubhrajyoti Datta, Srinivas Neeli,
Michal Simek, Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260402163840.938417-1-shubhrajyoti.datta@amd.com>
Add the EIO gpio node to the device tree.
The EIO GPIO block exposes only bank 0 and bank 1 to
multiplexed I/O pins, providing a fixed total of 52 GPIO lines
(2 banks × 26 pins). Enforce this hardware constraint by requiring
exactly 52 entries in gpio-line-names for the EIO variant.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
---
.../devicetree/bindings/gpio/gpio-zynq.yaml | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
index 5e2496379a3c..b8dd279753a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
@@ -16,6 +16,7 @@ properties:
- xlnx,zynqmp-gpio-1.0
- xlnx,versal-gpio-1.0
- xlnx,pmc-gpio-1.0
+ - xlnx,eio-gpio-1.0
reg:
maxItems: 1
@@ -30,7 +31,7 @@ properties:
gpio-line-names:
description: strings describing the names of each gpio line
- minItems: 58
+ minItems: 52
maxItems: 174
interrupt-controller: true
@@ -89,6 +90,17 @@ allOf:
minItems: 116
maxItems: 116
+ - if:
+ properties:
+ compatible:
+ enum:
+ - xlnx,eio-gpio-1.0
+ then:
+ properties:
+ gpio-line-names:
+ minItems: 52
+ maxItems: 52
+
required:
- compatible
- reg
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] gpio: Add EIO GPIO support
From: Shubhrajyoti Datta @ 2026-04-02 16:38 UTC (permalink / raw)
To: linux-kernel
Cc: git, shubhrajyoti.datta, Shubhrajyoti Datta, Srinivas Neeli,
Michal Simek, Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
Add the EIO GPIO support.
Add the dt description and the compatible to the driver.
Shubhrajyoti Datta (2):
dt-bindings: gpio: Add eio gpio node to gpio-zynq
gpio: zynq: Add eio gpio support
.../devicetree/bindings/gpio/gpio-zynq.yaml | 14 +++++++++++++-
drivers/gpio/gpio-zynq.c | 12 ++++++++++++
2 files changed, 25 insertions(+), 1 deletion(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: usb: dwc3-xilinx: Add MMI USB support on Versal Gen2 platform
From: Krzysztof Kozlowski @ 2026-04-02 16:36 UTC (permalink / raw)
To: Pandey, Radhey Shyam, Radhey Shyam Pandey
Cc: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel, linux-usb, devicetree, linux-arm-kernel, linux-kernel,
git
In-Reply-To: <3d64cd29-d981-4e84-8106-8085250fc502@amd.com>
On 31/03/2026 11:18, Pandey, Radhey Shyam wrote:
>> On Tue, Mar 31, 2026 at 12:33:01AM +0530, Radhey Shyam Pandey wrote:
>>> Versal Gen2 platform multimedia integrated (MMI) module has a USB3.2 Gen
>>> 2x1 Dual Role Device IP. Introduce a new compatibility string to support
>>> it. The USB wrapper registers reside in the MMI UDH system-level control
>>> registers (SLCR) block, so instead of a dedicated reg property, add
>>> xlnx,usb-syscon phandle with four cells specifying register offsets for
>>> USB2 PHY, USB3 PHY, USB DRD, and USB power configuration within the SLCR.
>>>
>>> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
>>> ---
>>> Changes for v2:
>>> - Add blank line after compatible as suggested by Krzysztof.
>>> - Retain the mmi suffix in the compatible string, as this USB 3.2 Gen2
>>> IP from Synopsys is part of the dedicated Multimedia Interface. The
>>> Versal Gen2 platform also includes a separate USB 2.0 controller,
>>> and the mmi suffix uniquely distinguishes between the two USB
>>> controllers. MMI is an independent subsystem particularly targeted for
>>> deployment in Multi-Media related applications. The MMI block include
>>> following submodules: UDH: USB3.2 Gen 2x1 Dual Role Device, DisplayPort
>>> Transmit Controller, Security Module (ESM) for DisplayPort and HDMI
>>> Controllers, DP AUX-I2C PHY.
>>> - For MMI USB define parent address space i.e UDH block.
>>> - Fix inconsistent MHz spacing to use SI convention with spaces.
>>> - Move description before $ref and items in xlnx,usb-syscon property.
>>> - Restore original zynqmp-dwc3 example, add new versal2-mmi-dwc3 example.
>>> - Use 'usb' node name (without unit address) for versal2 example since
>>> it has no reg property.
>>> - Use 1/1 address/size configuration in versal2 example, use lowercase
>>> hex in syscon offsets.
>>> ---
>>> .../devicetree/bindings/usb/dwc3-xilinx.yaml | 70 ++++++++++++++++++-
>>> 1 file changed, 67 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
>>> index d6823ef5f9a7..5e31b961aff7 100644
>>> --- a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
>>> +++ b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
>>> @@ -15,6 +15,8 @@ properties:
>>> - enum:
>>> - xlnx,zynqmp-dwc3
>>> - xlnx,versal-dwc3
>>> + - xlnx,versal2-mmi-dwc3
>> I am not going to ask the same questions.
>
> I have provided the explanation in v2 changelog.
> Retain the mmi suffix in the compatible string, as this USB 3.2 Gen2
> IP from Synopsys is part of the dedicated Multimedia Interface. The
> Versal Gen2 platform also includes a separate USB 2.0 controller,
> and the mmi suffix uniquely distinguishes between the two USB
> controllers.
>
> Let me know if you still have reservation in this approach (using
> <vendor>,<soc>-<subsystem>-<ip>). Or any other alternative
> based on IP version etc please suggest.
Commit msg must explain that you have two different devices. And then
explain what is the difference between versal2-dwc3 and versal2-mmi-dwc3.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH net] net: airoha: Add dma_rmb() and READ_ONCE() in airoha_qdma_rx_process()
From: Lorenzo Bianconi @ 2026-04-02 16:36 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: Xuegang Lu, linux-arm-kernel, linux-mediatek, netdev
Add missing dma_rmb() in airoha_qdma_rx_process routine to make sure the
DMA read operations are completed when the NIC reports the processing on
the current descriptor is done. Moreover, add missing READ_ONCE() in
airoha_qdma_rx_process() for DMA descriptor control fields in order to
avoid any compiler reordering.
Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 95ba99b89428e4cafb91ff7813e43ffeb38e6d9b..29dea8b35f64bfdcf88bc09fd711e0d8b4f7b6fa 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -612,15 +612,17 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
while (done < budget) {
struct airoha_queue_entry *e = &q->entry[q->tail];
struct airoha_qdma_desc *desc = &q->desc[q->tail];
- u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
- struct page *page = virt_to_head_page(e->buf);
- u32 desc_ctrl = le32_to_cpu(desc->ctrl);
+ u32 hash, reason, msg1, desc_ctrl;
struct airoha_gdm_port *port;
int data_len, len, p;
+ struct page *page;
+ desc_ctrl = le32_to_cpu(READ_ONCE(desc->ctrl));
if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
break;
+ dma_rmb();
+
q->tail = (q->tail + 1) % q->ndesc;
q->queued--;
@@ -637,6 +639,7 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
if (p < 0 || !eth->ports[p])
goto free_frag;
+ page = virt_to_head_page(e->buf);
port = eth->ports[p];
if (!q->skb) { /* first buffer */
q->skb = napi_build_skb(e->buf, q->buf_size);
@@ -670,8 +673,8 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
* DMA descriptor. Report DSA tag to the DSA stack
* via skb dst info.
*/
- u32 sptag = FIELD_GET(QDMA_ETH_RXMSG_SPTAG,
- le32_to_cpu(desc->msg0));
+ u32 msg0 = le32_to_cpu(READ_ONCE(desc->msg0));
+ u32 sptag = FIELD_GET(QDMA_ETH_RXMSG_SPTAG, msg0);
if (sptag < ARRAY_SIZE(port->dsa_meta) &&
port->dsa_meta[sptag])
@@ -679,6 +682,7 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
&port->dsa_meta[sptag]->dst);
}
+ msg1 = le32_to_cpu(READ_ONCE(desc->msg1));
hash = FIELD_GET(AIROHA_RXD4_FOE_ENTRY, msg1);
if (hash != AIROHA_RXD4_FOE_ENTRY)
skb_set_hash(q->skb, jhash_1word(hash, 0),
---
base-commit: ec7067e661193403a7a00980bda8612db5954142
change-id: 20260402-airoha_qdma_rx_process-fix-reordering-722308255b65
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH v5 0/4] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Danilo Krummrich @ 2026-04-02 16:29 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:
> Bartosz Golaszewski (4):
> kernel: ksysfs: initialize kernel_kobj earlier
> software node: remove software_node_exit()
> driver core: make software nodes available earlier
Looks good to me now; I will give it a few more days on the list and then pull
it in for v7.1-rc1 if no one else raises concerns.
> ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
^ permalink raw reply
* Re: [PATCH v5 4/4] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
From: Andy Shevchenko @ 2026-04-02 16:23 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
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-4-d730db3dd299@oss.qualcomm.com>
On Thu, Apr 02, 2026 at 04:15:05PM +0200, Bartosz Golaszewski wrote:
> Currently the board file for Nokia 770 creates dummy software nodes not
> attached in any way to the actual GPIO controller devices and uses the
> fact that GPIOLIB matching swnode's name to the GPIO chip's label during
> software node lookup. This behavior is wrong and we want to remove it.
> To that end, we need to first convert all existing users to creating
> actual fwnode links.
>
> Create real software nodes for GPIO controllers on OMAP16xx and
> reference them from the software nodes in the nokia board file.
...
> +static const struct software_node omap16xx_gpio2_swnode = { };
No need to have {} for statically defined variables.
OTOH, if you want to have same style over exported and static,
perhaps it's okay.
> +static const struct software_node omap16xx_gpio3_swnode = { };
> +static const struct software_node omap16xx_gpio4_swnode = { };
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5 3/4] driver core: make software nodes available earlier
From: Andy Shevchenko @ 2026-04-02 16:20 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
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-3-d730db3dd299@oss.qualcomm.com>
On Thu, Apr 02, 2026 at 04:15:04PM +0200, Bartosz Golaszewski wrote:
> Software nodes are currently initialized in a function registered as
> a postcore_initcall(). However, some devices may want to register
> software nodes earlier than that (or also in a postcore_initcall() where
> they're at the merci of the link order). Move the initialization to
> driver_init() making swnode available much earlier as well as making
> their initialization time deterministic.
Okay, if people want this, why not.
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5 2/4] software node: remove software_node_exit()
From: Andy Shevchenko @ 2026-04-02 16:19 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
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-2-d730db3dd299@oss.qualcomm.com>
On Thu, Apr 02, 2026 at 04:15:03PM +0200, Bartosz Golaszewski wrote:
> software_node_exit() is an __exitcall() in a built-in compilation unit
> so effectively dead code. Remove it.
a dead code
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp-phyboard-pollux: Add HDMI support
From: Paul Kocialkowski @ 2026-04-02 16:12 UTC (permalink / raw)
To: Yannic Moog
Cc: devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <573e4ebd9679517086a6b4acb162d72463429f35.camel@phytec.de>
[-- Attachment #1: Type: text/plain, Size: 3212 bytes --]
Hi Yannic,
On Wed 01 Apr 26, 12:06, Yannic Moog wrote:
> On Tue, 2026-03-31 at 00:37 +0200, Paul Kocialkowski wrote:
> > The PHYTEC phyBOARD Pollux comes with a HDMI port on the base board.
> > Add the required device-tree nodes to enable support for it.
>
> "Only" video is supported, but it does work. You could add that to the description since audio is
> also supported upstream and part of HDMI.
You're right, I didn't think about the audio part.
I'll add it in the next iteration.
All the best,
Paul
> Yannic
>
> >
> > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
>
> Reviewed-by: Yannic Moog <y.moog@phytec.de>
> Tested-by: Yannic Moog <y.moog@phytec.de>
>
> > ---
> > .../freescale/imx8mp-phyboard-pollux-rdk.dts | 47 +++++++++++++++++++
> > 1 file changed, 47 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
> > b/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
> > index 0fe52c73fc8f..0d52f29813f1 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
> > @@ -38,6 +38,18 @@ fan0: fan {
> > #cooling-cells = <2>;
> > };
> >
> > + hdmi-connector {
> > + compatible = "hdmi-connector";
> > + label = "hdmi";
> > + type = "a";
> > +
> > + port {
> > + hdmi_connector_in: endpoint {
> > + remote-endpoint = <&hdmi_tx_out>;
> > + };
> > + };
> > + };
> > +
> > panel_lvds1: panel-lvds1 {
> > /* compatible panel in overlay */
> > backlight = <&backlight_lvds1>;
> > @@ -201,6 +213,28 @@ &flexcan2 {
> > status = "okay";
> > };
> >
> > +&hdmi_pvi {
> > + status = "okay";
> > +};
> > +
> > +&hdmi_tx {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hdmi>;
> > + status = "okay";
> > +
> > + ports {
> > + port@1 {
> > + hdmi_tx_out: endpoint {
> > + remote-endpoint = <&hdmi_connector_in>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&hdmi_tx_phy {
> > + status = "okay";
> > +};
> > +
> > &i2c2 {
> > clock-frequency = <400000>;
> > pinctrl-names = "default", "gpio";
> > @@ -244,6 +278,10 @@ &i2c3 {
> > scl-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> > };
> >
> > +&lcdif3 {
> > + status = "okay";
> > +};
> > +
> > &ldb_lvds_ch1 {
> > remote-endpoint = <&panel1_in>;
> > };
> > @@ -444,6 +482,15 @@ MX8MP_IOMUXC_SAI5_RXD0__GPIO3_IO21 0x154
> > >;
> > };
> >
> > + pinctrl_hdmi: hdmigrp {
> > + fsl,pins = <
> > + MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x1c3
> > + MX8MP_IOMUXC_HDMI_DDC_SDA__HDMIMIX_HDMI_SDA 0x1c3
> > + MX8MP_IOMUXC_HDMI_HPD__HDMIMIX_HDMI_HPD 0
> > x19
> > + MX8MP_IOMUXC_HDMI_CEC__HDMIMIX_HDMI_CEC 0
> > x19
> > + >;
> > + };
> > +
> > pinctrl_i2c2: i2c2grp {
> > fsl,pins = <
> > MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001c2
--
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
* Re: [PATCH 2/3] drm: lcdif: Use dedicated set/clr registers for polarity/edge
From: Paul Kocialkowski @ 2026-04-02 16:08 UTC (permalink / raw)
To: Lucas Stach
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, Krzysztof Hałasa,
Marco Felsch, Liu Ying
In-Reply-To: <3b221a4997c367df716bf107a7e98ce10cd6860b.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2792 bytes --]
Hi Lucas,
On Tue 31 Mar 26, 18:04, Lucas Stach wrote:
> Am Dienstag, dem 31.03.2026 um 17:17 +0200 schrieb Paul Kocialkowski:
> > Le Tue 31 Mar 26, 11:09, Lucas Stach a écrit :
> > > Am Dienstag, dem 31.03.2026 um 00:46 +0200 schrieb Paul Kocialkowski:
> > > > The lcdif v3 hardware comes with dedicated registers to set and clear
> > > > polarity bits in the CTRL register. It is unclear if there is a
> > > > difference with writing to the CTRL register directly.
> > > >
> > > > Follow the NXP BSP reference by using these registers, in case there is
> > > > a subtle difference caused by using them.
> > > >
> > > I don't really like that patch, as it blows up what is currently a
> > > single register access to three separate ones. If there is no clear
> > > benefit (as in it has been shown to fix any issue), I would prefer this
> > > code to stay as-is.
> >
> > Well I guess the cost of a few writes vs a single one is rather
> > negligible.
> >
> Yea, a few writes don't really hurt. But I don't think there is a very
> good reason to set this register this way, see below.
>
> > I'm rather worried that there might be an undocumented
> > reason why these registers exist in the first place and why they are
> > used in the BSP.
> >
> > But yes this is only speculation and I could not witness any actual
> > issue. My setup (lcdif3 with hdmi) uses all positive polarities which is
> > the default state, so not a good way to check.
> >
> > It would be great if somebody from NXP could confirm whether this is
> > needed or not. In the meantime I guess we can drop the patch. It'll stay
> > on the list in case someone has polarity issues later :)
>
> The separate clr/set registers are a rather common design feat found on
> Freescale/NXP IP blocks from the MXS era. On some of those IP blocks
> _all_ registers are presented as a base/clr/set triplet in the
> registers space.
Ah yes I vaguely remember seeing this with units used in the imx6.
> As far as I can tell they are mostly useful when you
> want to set/clear individual bits from a register without having to
> remember or executing a readback of the current state.
>
> In cases like the one changed in this patch, where the full register
> state is set in one go, directly writing to the base register is the
> right thing to do.
Okay then if you're confident these registers are just here for
convenience purposes we can continue writing the full register value.
I'll drop this patch in the next iteration.
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
* Re: [PATCH v2] iommu: Always fill in gather when unmapping
From: Robin Murphy @ 2026-04-02 15:59 UTC (permalink / raw)
To: Jason Gunthorpe, Alexandre Ghiti, AngeloGioacchino Del Regno,
Albert Ou, asahi, Baolin Wang, iommu, Janne Grunau,
Jernej Skrabec, Joerg Roedel, Jean-Philippe Brucker,
linux-arm-kernel, linux-mediatek, linux-riscv, linux-sunxi,
Matthias Brugger, Neal Gompa, Orson Zhai, Palmer Dabbelt,
Paul Walmsley, Samuel Holland, Sven Peter, virtualization,
Chen-Yu Tsai, Will Deacon, Yong Wu, Chunyan Zhang
Cc: Lu Baolu, Janusz Krzysztofik, Joerg Roedel, Jon Hunter, patches,
Pranjal Shrivastava, Samiullah Khawaja, stable, Vasant Hegde
In-Reply-To: <0-v2-b24668f107b2+11bbe-iommu_gather_always_jgg@nvidia.com>
On 2026-04-02 3:25 pm, Jason Gunthorpe wrote:
> The fixed commit assumed that the gather would always be populated if an
> iotlb_sync was required.
>
> arm-smmu-v3, amd, VT-d, riscv, s390, and mtk all use information from the
> gather during their iotlb_sync() and this approach works for them.
>
> However, arm-smmu, qcom_iommu, ipmmu-vmsa, sun50i, sprd, virtio, and
> apple-dart all ignore the gather during their iotlb_sync(). They mostly
> issue a full flush.
>
> Unfortunately the latter set of drivers often don't bother to add anything
> to the gather since they don't intend on using it. Since the core code now
> blocks gathers that were never filled, this caused those drivers to stop
> getting their iotlb_sync() calls and breaks them.
>
> Since it is impossible to tell the difference between gathers that are
> empty because there is nothing to do and gathers that are empty because
> they are not used, fill in the gathers for the missing cases.
>
> mtk uses io-pgtable-arm-v7s but added the range to the gather in the unmap
> callback. Move this into the io-pgtable-arm-v7s unmap itself. That will
> fix all the armv7 using drivers (arm-smmu, qcom_iommu, ipmmu-vmsa).
>
> io-pgtable-arm needs to accommodate drivers like arm-smmu that don't want
> to use the gather by just adding a simple range, and drivers like SMMUv3
> that need to use gather->pgsize and also have a disjoint check. Move
> SMMUv3 to a new tlb_add_range() op which replaces calling
> iommu_iotlb_gather_add_page() in a loop with a single call to update the
> gather with the range and required pgsize.
>
> iommu_iotlb_gather_add_page() is repurposed since nothing but SMMUv3 uses it
> now that amd, VT-d and riscv are using iommupt.
>
> Add a trivial gather population to io-pgtable-dart.
>
> Add trivial populations to sprd, sun50i and virtio-iommu in their unmap
> functions.
>
> Fixes: 90c5def10bea ("iommu: Do not call drivers for empty gathers")
> Reported-by: Jon Hunter <jonathanh@nvidia.com>
> Closes: https://lore.kernel.org/r/8800a38b-8515-4bbe-af15-0dae81274bf7@nvidia.com
> Tested-by: Jon Hunter <jonathanh@nvidia.com>
> Acked-by: Pranjal Shrivastava <praan@google.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 11 ++++++-----
> drivers/iommu/io-pgtable-arm-v7s.c | 4 ++++
> drivers/iommu/io-pgtable-arm.c | 19 ++++++++++++++++---
> drivers/iommu/io-pgtable-dart.c | 3 +++
> drivers/iommu/mtk_iommu.c | 1 -
> drivers/iommu/sprd-iommu.c | 1 +
> drivers/iommu/sun50i-iommu.c | 1 +
> drivers/iommu/virtio-iommu.c | 2 ++
> include/linux/io-pgtable.h | 3 +++
> include/linux/iommu.h | 19 ++++++++++---------
> 10 files changed, 46 insertions(+), 18 deletions(-)
>
> v2:
> - Add missed hunk for io-pgtable-armv7
> - Revise the commit message to fix the miss about smmuv3's gather flow
> - Make smmuv3 push its gather with a range instead of per-page
> v1: https://patch.msgid.link/r/0-v1-664d3acaabb9+78b-iommu_gather_always_jgg@nvidia.com
>
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index e8d7dbe495f030..97e78a351cf35b 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -2775,14 +2775,15 @@ void arm_smmu_domain_inv_range(struct arm_smmu_domain *smmu_domain,
> rcu_read_unlock();
> }
>
> -static void arm_smmu_tlb_inv_page_nosync(struct iommu_iotlb_gather *gather,
> - unsigned long iova, size_t granule,
> - void *cookie)
> +static void arm_smmu_tlb_inv_range_nosync(struct iommu_iotlb_gather *gather,
> + unsigned long iova, size_t size,
> + size_t granule, void *cookie)
> {
> struct arm_smmu_domain *smmu_domain = cookie;
> struct iommu_domain *domain = &smmu_domain->domain;
>
> - iommu_iotlb_gather_add_page(domain, gather, iova, granule);
> + iommu_iotlb_gather_add_range_pgsize(domain, gather, iova, size,
> + granule);
> }
>
> static void arm_smmu_tlb_inv_walk(unsigned long iova, size_t size,
> @@ -2796,7 +2797,7 @@ static void arm_smmu_tlb_inv_walk(unsigned long iova, size_t size,
> static const struct iommu_flush_ops arm_smmu_flush_ops = {
> .tlb_flush_all = arm_smmu_tlb_inv_context,
> .tlb_flush_walk = arm_smmu_tlb_inv_walk,
> - .tlb_add_page = arm_smmu_tlb_inv_page_nosync,
> + .tlb_add_range = arm_smmu_tlb_inv_range_nosync,
> };
>
> static bool arm_smmu_dbm_capable(struct arm_smmu_device *smmu)
> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
> index 40e33257d3c2c5..87292a7f094687 100644
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> @@ -596,6 +596,10 @@ static size_t __arm_v7s_unmap(struct arm_v7s_io_pgtable *data,
>
> __arm_v7s_set_pte(ptep, 0, num_entries, &iop->cfg);
>
> + if (!iommu_iotlb_gather_queued(gather))
> + iommu_iotlb_gather_add_range(gather, iova,
> + num_entries * blk_size);
> +
> for (i = 0; i < num_entries; i++) {
> if (ARM_V7S_PTE_IS_TABLE(pte[i], lvl)) {
> /* Also flush any partial walks */
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 0208e5897c299a..d51531330f8dea 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -666,9 +666,22 @@ static size_t __arm_lpae_unmap(struct arm_lpae_io_pgtable *data,
> /* Clear the remaining entries */
> __arm_lpae_clear_pte(ptep, &iop->cfg, i);
>
> - if (gather && !iommu_iotlb_gather_queued(gather))
> - for (int j = 0; j < i; j++)
> - io_pgtable_tlb_add_page(iop, gather, iova + j * size, size);
> + if (gather && !iommu_iotlb_gather_queued(gather)) {
> + if (iop->cfg.tlb && iop->cfg.tlb->tlb_add_range) {
> + iop->cfg.tlb->tlb_add_range(gather, iova,
> + i * size, size,
> + iop->cookie);
> +
> + } else {
> + iommu_iotlb_gather_add_range(gather, iova,
> + i * size);
> +
> + for (int j = 0; j < i; j++)
> + io_pgtable_tlb_add_page(iop, gather,
> + iova + j * size,
> + size);
> + }
> + }
NAK, this is insane.
If you'd rather make gathers mandatory for all drivers than fix it in
the core code, then for goodness' sake just add the trivial one-liner to
the handful of .unamp_pages implementations which need it, consistenly
with those which already exist, plus the ones you're also adding here
anyway. The entire diff should still be smaller than this absurd hunk
alone...
Thanks,
Robin.
> return i * size;
> } else if (iopte_leaf(pte, lvl, iop->fmt)) {
> diff --git a/drivers/iommu/io-pgtable-dart.c b/drivers/iommu/io-pgtable-dart.c
> index cbc5d6aa2daa23..75d699dc28e7b0 100644
> --- a/drivers/iommu/io-pgtable-dart.c
> +++ b/drivers/iommu/io-pgtable-dart.c
> @@ -330,6 +330,9 @@ static size_t dart_unmap_pages(struct io_pgtable_ops *ops, unsigned long iova,
> i++;
> }
>
> + if (i && !iommu_iotlb_gather_queued(gather))
> + iommu_iotlb_gather_add_range(gather, iova, i * pgsize);
> +
> return i * pgsize;
> }
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 2be990c108de2b..a2f80a92f51f2c 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -828,7 +828,6 @@ static size_t mtk_iommu_unmap(struct iommu_domain *domain,
> {
> struct mtk_iommu_domain *dom = to_mtk_domain(domain);
>
> - iommu_iotlb_gather_add_range(gather, iova, pgsize * pgcount);
> return dom->iop->unmap_pages(dom->iop, iova, pgsize, pgcount, gather);
> }
>
> diff --git a/drivers/iommu/sprd-iommu.c b/drivers/iommu/sprd-iommu.c
> index c1a34445d244fb..893ea67d322644 100644
> --- a/drivers/iommu/sprd-iommu.c
> +++ b/drivers/iommu/sprd-iommu.c
> @@ -340,6 +340,7 @@ static size_t sprd_iommu_unmap(struct iommu_domain *domain, unsigned long iova,
> spin_lock_irqsave(&dom->pgtlock, flags);
> memset(pgt_base_iova, 0, pgcount * sizeof(u32));
> spin_unlock_irqrestore(&dom->pgtlock, flags);
> + iommu_iotlb_gather_add_range(iotlb_gather, iova, size);
>
> return size;
> }
> diff --git a/drivers/iommu/sun50i-iommu.c b/drivers/iommu/sun50i-iommu.c
> index be3f1ce696ba29..b9aa4bbc82acad 100644
> --- a/drivers/iommu/sun50i-iommu.c
> +++ b/drivers/iommu/sun50i-iommu.c
> @@ -655,6 +655,7 @@ static size_t sun50i_iommu_unmap(struct iommu_domain *domain, unsigned long iova
>
> memset(pte_addr, 0, sizeof(*pte_addr));
> sun50i_table_flush(sun50i_domain, pte_addr, 1);
> + iommu_iotlb_gather_add_range(gather, iova, SZ_4K);
>
> return SZ_4K;
> }
> diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
> index 587fc13197f122..5865b8f6c6e67a 100644
> --- a/drivers/iommu/virtio-iommu.c
> +++ b/drivers/iommu/virtio-iommu.c
> @@ -897,6 +897,8 @@ static size_t viommu_unmap_pages(struct iommu_domain *domain, unsigned long iova
> if (unmapped < size)
> return 0;
>
> + iommu_iotlb_gather_add_range(gather, iova, unmapped);
> +
> /* Device already removed all mappings after detach. */
> if (!vdomain->nr_endpoints)
> return unmapped;
> diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
> index e19872e37e067f..b109c95b5ff53d 100644
> --- a/include/linux/io-pgtable.h
> +++ b/include/linux/io-pgtable.h
> @@ -42,6 +42,9 @@ struct iommu_flush_ops {
> void *cookie);
> void (*tlb_add_page)(struct iommu_iotlb_gather *gather,
> unsigned long iova, size_t granule, void *cookie);
> + void (*tlb_add_range)(struct iommu_iotlb_gather *gather,
> + unsigned long iova, size_t size, size_t granule,
> + void *cookie);
> };
>
> /**
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index e587d4ac4d3310..d8fcdb61e44c42 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -1034,30 +1034,31 @@ static inline void iommu_iotlb_gather_add_range(struct iommu_iotlb_gather *gathe
> }
>
> /**
> - * iommu_iotlb_gather_add_page - Gather for page-based TLB invalidation
> + * iommu_iotlb_gather_add_range_pgsize - Include pgsize in the gather
> * @domain: IOMMU domain to be invalidated
> * @gather: TLB gather data
> * @iova: start of page to invalidate
> * @size: size of page to invalidate
> + * @pgsize: page granularity of the invalidation
> *
> - * Helper for IOMMU drivers to build invalidation commands based on individual
> - * pages, or with page size/table level hints which cannot be gathered if they
> - * differ.
> + * Helper for IOMMU drivers to build invalidation commands when using the pgsize
> + * hint. Unlike iommu_iotlb_gather_add_range() this also flushes if the range is
> + * disjoint.
> */
> -static inline void iommu_iotlb_gather_add_page(struct iommu_domain *domain,
> - struct iommu_iotlb_gather *gather,
> - unsigned long iova, size_t size)
> +static inline void iommu_iotlb_gather_add_range_pgsize(
> + struct iommu_domain *domain, struct iommu_iotlb_gather *gather,
> + unsigned long iova, size_t size, size_t pgsize)
> {
> /*
> * If the new page is disjoint from the current range or is mapped at
> * a different granularity, then sync the TLB so that the gather
> * structure can be rewritten.
> */
> - if ((gather->pgsize && gather->pgsize != size) ||
> + if ((gather->pgsize && gather->pgsize != pgsize) ||
> iommu_iotlb_gather_is_disjoint(gather, iova, size))
> iommu_iotlb_sync(domain, gather);
>
> - gather->pgsize = size;
> + gather->pgsize = pgsize;
> iommu_iotlb_gather_add_range(gather, iova, size);
> }
>
>
> base-commit: 23f3682fd3605da81b90738ad3d2a30f18c46e98
^ permalink raw reply
* Re: [PATCH v2] iommu: Always fill in gather when unmapping
From: Greg KH @ 2026-04-02 15:49 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Alexandre Ghiti, AngeloGioacchino Del Regno, Albert Ou, asahi,
Baolin Wang, iommu, Janne Grunau, Jernej Skrabec, Joerg Roedel,
Jean-Philippe Brucker, linux-arm-kernel, linux-mediatek,
linux-riscv, linux-sunxi, Matthias Brugger, Neal Gompa,
Orson Zhai, Palmer Dabbelt, Paul Walmsley, Samuel Holland,
Sven Peter, virtualization, Chen-Yu Tsai, Will Deacon, Yong Wu,
Chunyan Zhang, Lu Baolu, Janusz Krzysztofik, Joerg Roedel,
Jon Hunter, patches, Pranjal Shrivastava, Robin Murphy,
Samiullah Khawaja, stable, Vasant Hegde
In-Reply-To: <0-v2-b24668f107b2+11bbe-iommu_gather_always_jgg@nvidia.com>
On Thu, Apr 02, 2026 at 11:25:16AM -0300, Jason Gunthorpe wrote:
> The fixed commit assumed that the gather would always be populated if an
> iotlb_sync was required.
>
> arm-smmu-v3, amd, VT-d, riscv, s390, and mtk all use information from the
> gather during their iotlb_sync() and this approach works for them.
>
> However, arm-smmu, qcom_iommu, ipmmu-vmsa, sun50i, sprd, virtio, and
> apple-dart all ignore the gather during their iotlb_sync(). They mostly
> issue a full flush.
>
> Unfortunately the latter set of drivers often don't bother to add anything
> to the gather since they don't intend on using it. Since the core code now
> blocks gathers that were never filled, this caused those drivers to stop
> getting their iotlb_sync() calls and breaks them.
>
> Since it is impossible to tell the difference between gathers that are
> empty because there is nothing to do and gathers that are empty because
> they are not used, fill in the gathers for the missing cases.
>
> mtk uses io-pgtable-arm-v7s but added the range to the gather in the unmap
> callback. Move this into the io-pgtable-arm-v7s unmap itself. That will
> fix all the armv7 using drivers (arm-smmu, qcom_iommu, ipmmu-vmsa).
>
> io-pgtable-arm needs to accommodate drivers like arm-smmu that don't want
> to use the gather by just adding a simple range, and drivers like SMMUv3
> that need to use gather->pgsize and also have a disjoint check. Move
> SMMUv3 to a new tlb_add_range() op which replaces calling
> iommu_iotlb_gather_add_page() in a loop with a single call to update the
> gather with the range and required pgsize.
>
> iommu_iotlb_gather_add_page() is repurposed since nothing but SMMUv3 uses it
> now that amd, VT-d and riscv are using iommupt.
>
> Add a trivial gather population to io-pgtable-dart.
>
> Add trivial populations to sprd, sun50i and virtio-iommu in their unmap
> functions.
>
> Fixes: 90c5def10bea ("iommu: Do not call drivers for empty gathers")
> Reported-by: Jon Hunter <jonathanh@nvidia.com>
> Closes: https://lore.kernel.org/r/8800a38b-8515-4bbe-af15-0dae81274bf7@nvidia.com
> Tested-by: Jon Hunter <jonathanh@nvidia.com>
> Acked-by: Pranjal Shrivastava <praan@google.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 11 ++++++-----
> drivers/iommu/io-pgtable-arm-v7s.c | 4 ++++
> drivers/iommu/io-pgtable-arm.c | 19 ++++++++++++++++---
> drivers/iommu/io-pgtable-dart.c | 3 +++
> drivers/iommu/mtk_iommu.c | 1 -
> drivers/iommu/sprd-iommu.c | 1 +
> drivers/iommu/sun50i-iommu.c | 1 +
> drivers/iommu/virtio-iommu.c | 2 ++
> include/linux/io-pgtable.h | 3 +++
> include/linux/iommu.h | 19 ++++++++++---------
> 10 files changed, 46 insertions(+), 18 deletions(-)
>
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
^ permalink raw reply
* Re: [PATCH 0/2] pwm: mediatek: fix mt7628 register offset and clock source
From: Uwe Kleine-König @ 2026-04-02 15:44 UTC (permalink / raw)
To: Shiji Yang, Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-pwm, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <OS7PR01MB1360282ADC135931ECCAD9AF6BC74A@OS7PR01MB13602.jpnprd01.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 247 bytes --]
Hello,
On Tue, Feb 24, 2026 at 04:51:00PM +0800, Shiji Yang wrote:
> This patch series fixes support for mt7628.
The series looks reasonable to me. It would be great to get some
feedback from the Mediatek maintainers, though?!
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] array
From: Paul Menzel @ 2026-04-02 15:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno, Javier Tia, Arnd Bergmann, Chris Lu,
Kees Cook, Johan Hovold, Sean Wang, Jiande Lu, linux-bluetooth,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260402141119.2732591-1-arnd@kernel.org>
Dear Arnd,
Thank you for your patch.
Am 02.04.26 um 16:11 schrieb Arnd Bergmann:
> From: Arnd Bergmann <arnd@arndb.de>
>
> When USB support is disabled, the array is not referenced anywhere,
> causing a warning:
>
> drivers/bluetooth/btmtk.c:35:3: error: 'btmtk_mt6639_devs' defined but not used [-Werror=unused-const-variable=]
> 35 | } btmtk_mt6639_devs[] = {
> | ^~~~~~~~~~~~~~~~~
>
> Move it into the #ifdef block.
>
> Fixes: 4cdd001ff03f ("Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/bluetooth/btmtk.c | 32 ++++++++++++++++----------------
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
> index 099188bf772e..6fb6ca274808 100644
> --- a/drivers/bluetooth/btmtk.c
> +++ b/drivers/bluetooth/btmtk.c
> @@ -25,22 +25,6 @@
> /* It is for mt79xx iso data transmission setting */
> #define MTK_ISO_THRESHOLD 264
>
> -/* Known MT6639 (MT7927) Bluetooth USB devices.
> - * Used to scope the zero-CHIPID workaround to real MT6639 hardware,
> - * since some boards return 0x0000 from the MMIO chip ID register.
> - */
> -static const struct {
> - u16 vendor;
> - u16 product;
> -} btmtk_mt6639_devs[] = {
> - { 0x0489, 0xe13a }, /* ASUS ROG Crosshair X870E Hero */
> - { 0x0489, 0xe0fa }, /* Lenovo Legion Pro 7 16ARX9 */
> - { 0x0489, 0xe10f }, /* Gigabyte Z790 AORUS MASTER X */
> - { 0x0489, 0xe110 }, /* MSI X870E Ace Max */
> - { 0x0489, 0xe116 }, /* TP-Link Archer TBE550E */
> - { 0x13d3, 0x3588 }, /* ASUS ROG STRIX X870E-E */
> -};
> -
> struct btmtk_patch_header {
> u8 datetime[16];
> u8 platform[4];
> @@ -483,6 +467,22 @@ int btmtk_process_coredump(struct hci_dev *hdev, struct sk_buff *skb)
> EXPORT_SYMBOL_GPL(btmtk_process_coredump);
>
> #if IS_ENABLED(CONFIG_BT_HCIBTUSB_MTK)
> +/* Known MT6639 (MT7927) Bluetooth USB devices.
> + * Used to scope the zero-CHIPID workaround to real MT6639 hardware,
> + * since some boards return 0x0000 from the MMIO chip ID register.
> + */
> +static const struct {
> + u16 vendor;
> + u16 product;
> +} btmtk_mt6639_devs[] = {
> + { 0x0489, 0xe13a }, /* ASUS ROG Crosshair X870E Hero */
> + { 0x0489, 0xe0fa }, /* Lenovo Legion Pro 7 16ARX9 */
> + { 0x0489, 0xe10f }, /* Gigabyte Z790 AORUS MASTER X */
> + { 0x0489, 0xe110 }, /* MSI X870E Ace Max */
> + { 0x0489, 0xe116 }, /* TP-Link Archer TBE550E */
> + { 0x13d3, 0x3588 }, /* ASUS ROG STRIX X870E-E */
> +};
> +
> static void btmtk_usb_wmt_recv(struct urb *urb)
> {
> struct hci_dev *hdev = urb->context;
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Kind regards,
Paul
^ permalink raw reply
* Re: [PATCH 5/8] thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support
From: Neil Armstrong @ 2026-04-02 15:39 UTC (permalink / raw)
To: Ronald Claveau, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm
In-Reply-To: <20260402-add-mcu-fan-khadas-vim4-v1-5-2b12eb4ac7b0@aliel.fr>
On 4/2/26 16:27, Ronald Claveau wrote:
> Replace the hardcoded MAX_LEVEL constant and fan register
> with values read from platform_data (fan_reg, max_level),
> as new MCUs need different values.
>
> Optionally acquire and enable a "fan" regulator supply
> at probe time and on resume,
> so boards that gate fan power through a regulator are handled.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> drivers/thermal/khadas_mcu_fan.c | 43 ++++++++++++++++++++++++++++++++++------
> 1 file changed, 37 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/thermal/khadas_mcu_fan.c b/drivers/thermal/khadas_mcu_fan.c
> index d35e5313bea41..55b496625e3bd 100644
> --- a/drivers/thermal/khadas_mcu_fan.c
> +++ b/drivers/thermal/khadas_mcu_fan.c
> @@ -13,13 +13,15 @@
> #include <linux/regmap.h>
> #include <linux/sysfs.h>
> #include <linux/thermal.h>
> -
> -#define MAX_LEVEL 3
> +#include <linux/regulator/consumer.h>
>
> struct khadas_mcu_fan_ctx {
> struct khadas_mcu *mcu;
> + unsigned int fan_reg;
> unsigned int level;
> + unsigned int max_level;
> struct thermal_cooling_device *cdev;
> + struct regulator *power;
> };
>
> static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
> @@ -27,8 +29,7 @@ static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
> {
> int ret;
>
> - ret = regmap_write(ctx->mcu->regmap, KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
> - level);
> + ret = regmap_write(ctx->mcu->regmap, ctx->fan_reg, level);
> if (ret)
> return ret;
>
> @@ -40,7 +41,9 @@ static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
> static int khadas_mcu_fan_get_max_state(struct thermal_cooling_device *cdev,
> unsigned long *state)
> {
> - *state = MAX_LEVEL;
> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
> +
> + *state = ctx->max_level;
>
> return 0;
> }
> @@ -61,7 +64,7 @@ khadas_mcu_fan_set_cur_state(struct thermal_cooling_device *cdev,
> {
> struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
>
> - if (state > MAX_LEVEL)
> + if (state > ctx->max_level)
> return -EINVAL;
>
> if (state == ctx->level)
> @@ -83,11 +86,32 @@ static int khadas_mcu_fan_probe(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct khadas_mcu_fan_ctx *ctx;
> int ret;
> + const struct khadas_mcu_fan_pdata *pdata = dev_get_platdata(&pdev->dev);
>
> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> if (!ctx)
> return -ENOMEM;
> +
> ctx->mcu = mcu;
> + ctx->fan_reg = pdata->fan_reg;
> + ctx->max_level = pdata->max_level;
> +
> + ctx->power = devm_regulator_get_optional(dev->parent, "fan");
> + if (IS_ERR(ctx->power)) {
> + if (PTR_ERR(ctx->power) == -ENODEV)
> + ctx->power = NULL;
> + else
> + return PTR_ERR(ctx->power);
> + }
> +
> + if (ctx->power) {
> + ret = regulator_enable(ctx->power);
> + if (ret) {
> + dev_err(dev, "Failed to enable fan power supply: %d\n", ret);
> + return ret;
> + }
> + }
> +
> platform_set_drvdata(pdev, ctx);
>
> cdev = devm_thermal_of_cooling_device_register(dev->parent,
> @@ -130,6 +154,13 @@ static int khadas_mcu_fan_suspend(struct device *dev)
> static int khadas_mcu_fan_resume(struct device *dev)
> {
> struct khadas_mcu_fan_ctx *ctx = dev_get_drvdata(dev);
> + int ret;
> +
> + if (ctx->power) {
> + ret = regulator_enable(ctx->power);
Seems you're missing a regulator_disable() on suspend.
Neil
> + if (ret)
> + return ret;
> + }
>
> return khadas_mcu_fan_set_level(ctx, ctx->level);
> }
>
^ permalink raw reply
* Re: [PATCH 2/4] perf arm_spe: Turn event name mappings into an array
From: Ian Rogers @ 2026-04-02 15:30 UTC (permalink / raw)
To: James Clark
Cc: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Adrian Hunter, Al Grant,
linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <20260401-james-spe-impdef-decode-v1-2-ad0d372c220c@linaro.org>
On Wed, Apr 1, 2026 at 7:26 AM James Clark <james.clark@linaro.org> wrote:
>
> This is so we can have a single function that prints events and can be
> used with multiple mappings from different CPUs. Remove any bit that was
> printed so that later we can print out the remaining unknown impdef
> bits.
>
> No functional changes intended.
>
> Signed-off-by: James Clark <james.clark@linaro.org>
> ---
> .../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 88 +++++++++++-----------
> 1 file changed, 43 insertions(+), 45 deletions(-)
>
> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> index 5769ba2f4140..c880b0dec3a1 100644
> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> @@ -276,6 +276,48 @@ static int arm_spe_pkt_out_string(int *err, char **buf_p, size_t *blen,
> return ret;
> }
>
> +struct ev_string {
> + u8 event;
> + const char *desc;
> +};
> +
> +static const struct ev_string common_ev_strings[] = {
> + { .event = EV_EXCEPTION_GEN, .desc = "EXCEPTION-GEN" },
> + { .event = EV_RETIRED, .desc = "RETIRED" },
> + { .event = EV_L1D_ACCESS, .desc = "L1D-ACCESS" },
> + { .event = EV_L1D_REFILL, .desc = "L1D-REFILL" },
> + { .event = EV_TLB_ACCESS, .desc = "TLB-ACCESS" },
> + { .event = EV_TLB_WALK, .desc = "TLB-REFILL" },
> + { .event = EV_NOT_TAKEN, .desc = "NOT-TAKEN" },
> + { .event = EV_MISPRED, .desc = "MISPRED" },
> + { .event = EV_LLC_ACCESS, .desc = "LLC-ACCESS" },
> + { .event = EV_LLC_MISS, .desc = "LLC-REFILL" },
> + { .event = EV_REMOTE_ACCESS, .desc = "REMOTE-ACCESS" },
> + { .event = EV_ALIGNMENT, .desc = "ALIGNMENT" },
> + { .event = EV_TRANSACTIONAL, .desc = "TXN" },
> + { .event = EV_PARTIAL_PREDICATE, .desc = "SVE-PARTIAL-PRED" },
> + { .event = EV_EMPTY_PREDICATE, .desc = "SVE-EMPTY-PRED" },
> + { .event = EV_L2D_ACCESS, .desc = "L2D-ACCESS" },
> + { .event = EV_L2D_MISS, .desc = "L2D-MISS" },
> + { .event = EV_CACHE_DATA_MODIFIED, .desc = "HITM" },
> + { .event = EV_RECENTLY_FETCHED, .desc = "LFB" },
> + { .event = EV_DATA_SNOOPED, .desc = "SNOOPED" },
> + { .event = EV_STREAMING_SVE_MODE, .desc = "STREAMING-SVE" },
> + { .event = EV_SMCU, .desc = "SMCU" },
> + { .event = 0, .desc = NULL },
> +};
> +
> +static u64 print_event_list(int *err, char **buf, size_t *buf_len,
> + const struct ev_string *ev_strings, u64 payload)
> +{
> + for (const struct ev_string *ev = ev_strings; ev->desc != NULL; ev++) {
> + if (payload & BIT(ev->event))
> + arm_spe_pkt_out_string(err, buf, buf_len, " %s", ev->desc);
> + payload &= ~BIT(ev->event);
Sashiko has a bunch of worries in these patches about 32-bit builds:
https://sashiko.dev/#/patchset/20260401-james-spe-impdef-decode-v1-0-ad0d372c220c%40linaro.org
The one here is:
"""
Since payload is a u64, does using ~BIT(ev->event) unintentionally clear
the upper 32 bits on 32-bit architectures?
On 32-bit systems, BIT() evaluates to a 32-bit unsigned long. The bitwise
NOT operation creates a 32-bit mask, which is then zero-extended to 64 bits
during the compound assignment to the payload.
This would discard bits 32-63, contradicting the intent mentioned in the
commit message to preserve the remaining unknown impdef bits for later
printing.
Would using BIT_ULL() be safer here to ensure a 64-bit inverted mask?
"""
Thanks,
Ian
> + }
> + return payload;
> +}
> +
> static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
> char *buf, size_t buf_len)
> {
> @@ -283,51 +325,7 @@ static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
> int err = 0;
>
> arm_spe_pkt_out_string(&err, &buf, &buf_len, "EV");
> -
> - if (payload & BIT(EV_EXCEPTION_GEN))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " EXCEPTION-GEN");
> - if (payload & BIT(EV_RETIRED))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " RETIRED");
> - if (payload & BIT(EV_L1D_ACCESS))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " L1D-ACCESS");
> - if (payload & BIT(EV_L1D_REFILL))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " L1D-REFILL");
> - if (payload & BIT(EV_TLB_ACCESS))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " TLB-ACCESS");
> - if (payload & BIT(EV_TLB_WALK))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " TLB-REFILL");
> - if (payload & BIT(EV_NOT_TAKEN))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " NOT-TAKEN");
> - if (payload & BIT(EV_MISPRED))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " MISPRED");
> - if (payload & BIT(EV_LLC_ACCESS))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " LLC-ACCESS");
> - if (payload & BIT(EV_LLC_MISS))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " LLC-REFILL");
> - if (payload & BIT(EV_REMOTE_ACCESS))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " REMOTE-ACCESS");
> - if (payload & BIT(EV_ALIGNMENT))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " ALIGNMENT");
> - if (payload & BIT(EV_TRANSACTIONAL))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " TXN");
> - if (payload & BIT(EV_PARTIAL_PREDICATE))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " SVE-PARTIAL-PRED");
> - if (payload & BIT(EV_EMPTY_PREDICATE))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " SVE-EMPTY-PRED");
> - if (payload & BIT(EV_L2D_ACCESS))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " L2D-ACCESS");
> - if (payload & BIT(EV_L2D_MISS))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " L2D-MISS");
> - if (payload & BIT(EV_CACHE_DATA_MODIFIED))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " HITM");
> - if (payload & BIT(EV_RECENTLY_FETCHED))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " LFB");
> - if (payload & BIT(EV_DATA_SNOOPED))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " SNOOPED");
> - if (payload & BIT(EV_STREAMING_SVE_MODE))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " STREAMING-SVE");
> - if (payload & BIT(EV_SMCU))
> - arm_spe_pkt_out_string(&err, &buf, &buf_len, " SMCU");
> + print_event_list(&err, &buf, &buf_len, common_ev_strings, payload);
>
> return err;
> }
>
> --
> 2.34.1
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox