* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Stefan Wahren @ 2026-06-05 16:22 UTC (permalink / raw)
To: Frank Li
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <20260527151414.184823-1-wahrenst@gmx.net>
Hi Frank,
Am 27.05.26 um 17:14 schrieb Stefan Wahren:
> Enable DP83822 PHY driver as a module to support the Ethernet PHY,
> which is placed on phyCORE-i.MX93 SOM.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
could you please take care of this patch?
> ---
>
> Changes in V2:
> - rebase patch
> - add Krzysztof's Reviewed-by
>
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index d905a0777f93..20bbbd310d2f 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
> CONFIG_QCA808X_PHY=m
> CONFIG_REALTEK_PHY=y
> CONFIG_ROCKCHIP_PHY=y
> +CONFIG_DP83822_PHY=m
> CONFIG_DP83867_PHY=y
> CONFIG_DP83869_PHY=m
> CONFIG_DP83TG720_PHY=m
^ permalink raw reply
* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Frank Li @ 2026-06-05 16:29 UTC (permalink / raw)
To: Stefan Wahren
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <5cf05aec-bc70-4758-9c00-812a33a44946@gmx.net>
On Fri, Jun 05, 2026 at 06:22:14PM +0200, Stefan Wahren wrote:
> Hi Frank,
>
> Am 27.05.26 um 17:14 schrieb Stefan Wahren:
> > Enable DP83822 PHY driver as a module to support the Ethernet PHY,
> > which is placed on phyCORE-i.MX93 SOM.
> >
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> could you please take care of this patch?
I will pick it, next time please cc imx@lists.linux.dev, otherwise, my imx
patchwork can't see your patch
Frank
> > ---
> >
> > Changes in V2:
> > - rebase patch
> > - add Krzysztof's Reviewed-by
> >
> > arch/arm64/configs/defconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > index d905a0777f93..20bbbd310d2f 100644
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
> > CONFIG_QCA808X_PHY=m
> > CONFIG_REALTEK_PHY=y
> > CONFIG_ROCKCHIP_PHY=y
> > +CONFIG_DP83822_PHY=m
> > CONFIG_DP83867_PHY=y
> > CONFIG_DP83869_PHY=m
> > CONFIG_DP83TG720_PHY=m
>
>
^ permalink raw reply
* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Frank Li @ 2026-06-05 16:35 UTC (permalink / raw)
To: Stefan Wahren
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <5cf05aec-bc70-4758-9c00-812a33a44946@gmx.net>
On Fri, Jun 05, 2026 at 06:22:14PM +0200, Stefan Wahren wrote:
> Hi Frank,
>
> Am 27.05.26 um 17:14 schrieb Stefan Wahren:
> > Enable DP83822 PHY driver as a module to support the Ethernet PHY,
> > which is placed on phyCORE-i.MX93 SOM.
> >
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> could you please take care of this patch?
which is base commit, I can't apply clearly.
Frank
> > ---
> >
> > Changes in V2:
> > - rebase patch
> > - add Krzysztof's Reviewed-by
> >
> > arch/arm64/configs/defconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > index d905a0777f93..20bbbd310d2f 100644
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
> > CONFIG_QCA808X_PHY=m
> > CONFIG_REALTEK_PHY=y
> > CONFIG_ROCKCHIP_PHY=y
> > +CONFIG_DP83822_PHY=m
> > CONFIG_DP83867_PHY=y
> > CONFIG_DP83869_PHY=m
> > CONFIG_DP83TG720_PHY=m
>
>
^ permalink raw reply
* Re: [PATCH v2 05/12] drm/bridge: synopsys: dw-dp: Add follow-up bridge support
From: Sebastian Reichel @ 2026-06-05 16:42 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, David Airlie,
Simona Vetter, Dmitry Baryshkov, Cristian Ciocaltea, Damon Ding,
Dmitry Baryshkov, Alexey Charkov, dri-devel, linux-rockchip,
linux-kernel, devicetree, kernel, linux-arm-kernel
In-Reply-To: <177918892313.537125.10814687633426590148.b4-review@b4>
[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]
Hello Luca,
On Tue, May 19, 2026 at 01:08:43PM +0200, Luca Ceresoli wrote:
> On Fri, 01 May 2026 00:20:32 +0200, Sebastian Reichel <sebastian.reichel@collabora.com> wrote:
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> > index fc4ddb7792d7..ccc55e40e81c 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> > @@ -2064,6 +2064,20 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
> > goto unregister_aux;
> > }
> >
> > + next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
>
> devm_drm_of_get_bridge() looks for either a panel or a bridge. Is it
> possible to have a panel connected here?
>
> If it isn't, then using of_drm_get_bridge_by_endpoint() which has just been
> merged [0] would be much simpler and cleaner.
Technically this should always be connected to the USBDP PHY
on the Rockchip platforms using this IP (RK3588 & RK3576) and
there are no other upstream platforms using this code so far.
Having said that, we do have some upstream DTs, which directly
connect it to a DP connector instead (as the PHY does not yet
expose a DRM bridge, that's being handled in a different series).
But there is no upstream board connecting it to an eDP panel,
so I will switch over to of_drm_get_bridge_by_endpoint().
Thanks for the info.
Greetings,
-- Sebastian
>
> [0] https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/03d1078112fddd706b2c1e4a7d98cf18700eb5df
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH V2] arm64/mm: Rename ptdesc_t
From: Will Deacon @ 2026-06-05 16:43 UTC (permalink / raw)
To: linux-arm-kernel, Anshuman Khandual
Cc: catalin.marinas, kernel-team, Will Deacon, David Hildenbrand,
Mike Rapoport, linux-efi, linux-kernel
In-Reply-To: <20260520063417.2363417-1-anshuman.khandual@arm.com>
On Wed, 20 May 2026 07:34:17 +0100, Anshuman Khandual wrote:
> ptdesc_t sounds very similar to the core MM struct ptdesc which is actually
> the memory descriptor for page table allocations. Hence rename this typedef
> element as ptval_t instead for better clarity and separation.
>
>
Applied to arm64 (for-next/mm), thanks!
[1/1] arm64/mm: Rename ptdesc_t
https://git.kernel.org/arm64/c/c34d4d48c4a1
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2 0/5] fixes for data/bss linear alias unmap series
From: Will Deacon @ 2026-06-05 16:43 UTC (permalink / raw)
To: linux-arm-kernel, Ard Biesheuvel
Cc: catalin.marinas, kernel-team, Will Deacon, linux-kernel,
Ard Biesheuvel, Kevin Brodsky, Mark Brown, Marc Zyngier
In-Reply-To: <20260604151151.150377-7-ardb+git@google.com>
On Thu, 04 Jun 2026 17:11:52 +0200, Ard Biesheuvel wrote:
> Fixes for the data/bss linear alias unmap series:
>
> - Fix KASAN related issue reported by Mark, by moving all KASAN page
> tables out of BSS [on arm64], not just the ones defined under
> arch/arm64
>
> - Fix two issues spotted by Sashiko
>
> [...]
Applied to arm64 (for-next/mm), thanks!
[1/5] arm64: Rename page table BSS section to .bss..pgtbl
https://git.kernel.org/arm64/c/9c401fa7398f
[2/5] kasan: Move generic KASAN page tables out of BSS too
https://git.kernel.org/arm64/c/9f7f685758c6
[3/5] arm64: Avoid double evaluation of __ptep_get()
https://git.kernel.org/arm64/c/568def8e87fc
[4/5] KVM: arm64: Omit tag sync on stage-2 mappings of the zero page
https://git.kernel.org/arm64/c/2986a6257405
[5/5] arm64: mm: Defer remap of linear alias of data/bss
https://git.kernel.org/arm64/c/53205d56212c
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH] arm64: arch_timer: reuse arch_timer_read_cnt{p,v}ct_el0() helpers
From: Will Deacon @ 2026-06-05 16:43 UTC (permalink / raw)
To: Mark Rutland, Marc Zyngier, Catalin Marinas, Breno Leitao
Cc: kernel-team, Will Deacon, linux-arm-kernel, linux-kernel,
kernel-team
In-Reply-To: <20260523-arch64_fix-v1-1-283bd4b73d49@debian.org>
On Sat, 23 May 2026 12:59:26 -0400, Breno Leitao wrote:
> __arch_counter_get_cntpct() and __arch_counter_get_cntvct() open-code
> the same ECV-aware ALTERNATIVE block that arch_timer_read_cntpct_el0()
> and arch_timer_read_cntvct_el0() already provide in the same header.
> The two pairs are byte-for-byte identical except for the trailing
> arch_counter_enforce_ordering() the __arch_counter_get_* variants add.
>
> Replace the duplicated inline assembly in __arch_counter_get_cntpct()
> and __arch_counter_get_cntvct() with calls to the corresponding helpers.
> This mirrors commit 00b39d150986 ("arm64: vdso: Use
> __arch_counter_get_cntvct()"), which removed similar duplication from
> the vDSO, and keeps the system-counter read sequence in a single place,
> reducing assembly code in the kernell
>
> [...]
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: arch_timer: reuse arch_timer_read_cnt{p,v}ct_el0() helpers
https://git.kernel.org/arm64/c/11c33ffb3a4e
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* [GIT PULL] KVM/arm64 fixes for 7.1, take #5
From: Marc Zyngier @ 2026-06-05 16:45 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Hyunwoo Kim, Joey Gouly, Oliver Upton, Wei-Lin Chang,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, kvmarm,
linux-arm-kernel, kvm
Paolo,
Yes, I said that last week's pull request was the last. I really meant
it, honest. But people (and their AI best mate) keep finding ugly
stuff in dark corners, and I can't sit on this stuff much longer.
So here we have an assorted mess of bad races, broken userspace, and
architectural bugs. What's not to like? As usual, details in the tag
below.
Please pull,
M.
The following changes since commit 83726330748981372bde86ed5411d7b306612991:
KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor (2026-05-29 10:04:00 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-7.1-5
for you to fetch changes up to 17f073f78fc43280891ecde8f8ec3f84f98bb37c:
KVM: arm64: Correctly identify executable PTEs at stage-2 (2026-06-05 14:07:57 +0100)
----------------------------------------------------------------
KVM/arm64 fixes for 7.1, take #5
- Correctly drop the ITS translation cache reference when it actually
gets invalidated
- Take the SRCU lock for SW page table walks
- Restore POR_EL0 access to host EL0, avoiding POR_EL0 becoming
inaccessible from EL0 after running a guest
- Reassign nested_mmus array behind mmu_lock, ensuring that vcpu init
and MMU notifiers are mutually exclusive
- Correctly handle FEAT_XNX at stage-2
----------------------------------------------------------------
Hyunwoo Kim (3):
KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry
KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation
KVM: arm64: Reassign nested_mmus array behind mmu_lock
Joey Gouly (1):
KVM: arm64: Restore POR_EL0 access to host EL0
Oliver Upton (2):
KVM: arm64: nv: Fix handling of XN[0] when !FEAT_XNX
KVM: arm64: Correctly identify executable PTEs at stage-2
arch/arm64/include/asm/kvm_nested.h | 4 ++--
arch/arm64/kvm/at.c | 6 ++++--
arch/arm64/kvm/hyp/include/hyp/switch.h | 2 ++
arch/arm64/kvm/hyp/pgtable.c | 4 +++-
arch/arm64/kvm/nested.c | 33 ++++++++++++++++++++-------------
arch/arm64/kvm/vgic/vgic-its.c | 6 ++++--
6 files changed, 35 insertions(+), 20 deletions(-)
^ permalink raw reply
* Re: [PATCH v4 4/4] arm64: dts: freescale: Add dual-channel LVDS overlay for TQMa8MPxS
From: Frank Li @ 2026-06-05 16:47 UTC (permalink / raw)
To: Alexander Stein
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Geert Uytterhoeven,
Magnus Damm, Shawn Guo, devicetree, linux-kernel, imx,
linux-arm-kernel, linux, linux-renesas-soc
In-Reply-To: <20260603093621.2504490-4-alexander.stein@ew.tq-group.com>
On Wed, Jun 03, 2026 at 11:36:09AM +0200, Alexander Stein wrote:
> This adds an overlay for the supported LVDS display AUO G133HAN01.
> Configure the video PLL frequency to exactly match typical pixel clock of
> 141.200 MHz.
>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> ---
Can you fix W=1 dtb build warnings?
Frank
> Changes in v4:
> * New to series v4
>
> arch/arm64/boot/dts/freescale/Makefile | 2 +
> ...p-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso | 74 +++++++++++++++++++
> 2 files changed, 76 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index dee2bea156740..3f466f102dc1d 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -385,8 +385,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtbo
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33-imx219.dtb
>
> +imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtbo
> imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtbo
> imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtbo
> +dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtb
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
> new file mode 100644
> index 0000000000000..9595cf4d43cd0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
> @@ -0,0 +1,74 @@
> +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
> +/*
> + * Copyright (c) 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
> + * D-82229 Seefeld, Germany.
> + * Author: Martin Schmiedel
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +&backlight_lvds0 {
> + status = "okay";
> +};
> +
> +&panel_lvds0 {
> + compatible = "auo,g133han01";
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dual-lvds-odd-pixels;
> +
> + panel_in_lvds0: endpoint {
> + remote-endpoint = <&ldb_lvds_ch0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dual-lvds-even-pixels;
> +
> + panel_in_lvds1: endpoint {
> + remote-endpoint = <&ldb_lvds_ch1>;
> + };
> + };
> + };
> +};
> +
> +&lcdif2 {
> + status = "okay";
> +};
> +
> +&lvds_bridge {
> + status = "okay";
> +
> + ports {
> + port@1 {
> + ldb_lvds_ch0: endpoint {
> + remote-endpoint = <&panel_in_lvds0>;
> + };
> + };
> +
> + port@2 {
> + ldb_lvds_ch1: endpoint {
> + remote-endpoint = <&panel_in_lvds1>;
> + };
> + };
> + };
> +};
> +
> +// Update VIDEO_PLL1 frequency
> +&media_blk_ctrl {
> + assigned-clock-rates = <500000000>, <200000000>,
> + <0>, <0>, <500000000>,
> + <988400000>;
> +};
> +
> +&pwm3 {
> + status = "okay";
> +};
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v4 2/4] arm64: dts: freescale: add initial device tree for TQMa8MPQS with i.MX8MP
From: Frank Li @ 2026-06-05 16:49 UTC (permalink / raw)
To: Alexander Stein
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Geert Uytterhoeven,
Magnus Damm, Shawn Guo, Paul Gerber, devicetree, linux-kernel,
imx, linux-arm-kernel, linux, linux-renesas-soc
In-Reply-To: <20260603093621.2504490-2-alexander.stein@ew.tq-group.com>
On Wed, Jun 03, 2026 at 11:36:07AM +0200, Alexander Stein wrote:
> From: Paul Gerber <paul.gerber@tq-group.com>
>
> This adds support for TQMa8MPQS module on MB-SMARC-2 board.
>
> Signed-off-by: Paul Gerber <paul.gerber@tq-group.com>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> ---
> Changes in v4:
> * Fix audio codec clock config (similar to commit 6d36cebfb466a
> ("arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio
> codec as well")
> * Fix GPIO line names on gpio4, found by Sashiko bot
> * Move compatible and reg property to top for tmp1075
> * Remove interrupts for tmp1075
> No support in bindings and driver, although HW has ALET pin connected
>
...
> + pcieclk: clock-generator@6a {
> + compatible = "renesas,9fgv0241";
> + reg = <0x6a>;
> + clocks = <&clk_xtal25>;
> + #clock-cells = <1>;
> + };
> +
> + imu@6b {
Please generial node name: inertial-sensor@6b
Frank
^ permalink raw reply
* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Stefan Wahren @ 2026-06-05 16:51 UTC (permalink / raw)
To: Frank Li
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <aiL5Yy7hiL30FENV@lizhi-Precision-Tower-5810>
Am 05.06.26 um 18:29 schrieb Frank Li:
> On Fri, Jun 05, 2026 at 06:22:14PM +0200, Stefan Wahren wrote:
>> Hi Frank,
>>
>> Am 27.05.26 um 17:14 schrieb Stefan Wahren:
>>> Enable DP83822 PHY driver as a module to support the Ethernet PHY,
>>> which is placed on phyCORE-i.MX93 SOM.
>>>
>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
>> could you please take care of this patch?
> I will pick it, next time please cc imx@lists.linux.dev, otherwise, my imx
> patchwork can't see your patch
Sorry for this and thanks for picking
Regards
>
> Frank
>
>>> ---
>>>
>>> Changes in V2:
>>> - rebase patch
>>> - add Krzysztof's Reviewed-by
>>>
>>> arch/arm64/configs/defconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>>> index d905a0777f93..20bbbd310d2f 100644
>>> --- a/arch/arm64/configs/defconfig
>>> +++ b/arch/arm64/configs/defconfig
>>> @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
>>> CONFIG_QCA808X_PHY=m
>>> CONFIG_REALTEK_PHY=y
>>> CONFIG_ROCKCHIP_PHY=y
>>> +CONFIG_DP83822_PHY=m
>>> CONFIG_DP83867_PHY=y
>>> CONFIG_DP83869_PHY=m
>>> CONFIG_DP83TG720_PHY=m
>>
^ permalink raw reply
* Re: [GIT PULL] KVM/arm64 fixes for 7.1, take #5
From: Paolo Bonzini @ 2026-06-05 16:57 UTC (permalink / raw)
To: Marc Zyngier
Cc: Hyunwoo Kim, Joey Gouly, Oliver Upton, Wei-Lin Chang,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, kvmarm,
linux-arm-kernel, kvm
In-Reply-To: <20260605164516.2214533-1-maz@kernel.org>
On Fri, Jun 5, 2026 at 6:45 PM Marc Zyngier <maz@kernel.org> wrote:
>
> Paolo,
>
> Yes, I said that last week's pull request was the last. I really meant
> it, honest. But people (and their AI best mate) keep finding ugly
> stuff in dark corners, and I can't sit on this stuff much longer.
>
> So here we have an assorted mess of bad races, broken userspace, and
> architectural bugs. What's not to like? As usual, details in the tag
> below.
x86 isn't doing any better, so who am I to judge.
Pulled, thanks.
Paolo
>
> Please pull,
>
> M.
>
> The following changes since commit 83726330748981372bde86ed5411d7b306612991:
>
> KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor (2026-05-29 10:04:00 +0100)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-7.1-5
>
> for you to fetch changes up to 17f073f78fc43280891ecde8f8ec3f84f98bb37c:
>
> KVM: arm64: Correctly identify executable PTEs at stage-2 (2026-06-05 14:07:57 +0100)
>
> ----------------------------------------------------------------
> KVM/arm64 fixes for 7.1, take #5
>
> - Correctly drop the ITS translation cache reference when it actually
> gets invalidated
>
> - Take the SRCU lock for SW page table walks
>
> - Restore POR_EL0 access to host EL0, avoiding POR_EL0 becoming
> inaccessible from EL0 after running a guest
>
> - Reassign nested_mmus array behind mmu_lock, ensuring that vcpu init
> and MMU notifiers are mutually exclusive
>
> - Correctly handle FEAT_XNX at stage-2
>
> ----------------------------------------------------------------
> Hyunwoo Kim (3):
> KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry
> KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation
> KVM: arm64: Reassign nested_mmus array behind mmu_lock
>
> Joey Gouly (1):
> KVM: arm64: Restore POR_EL0 access to host EL0
>
> Oliver Upton (2):
> KVM: arm64: nv: Fix handling of XN[0] when !FEAT_XNX
> KVM: arm64: Correctly identify executable PTEs at stage-2
>
> arch/arm64/include/asm/kvm_nested.h | 4 ++--
> arch/arm64/kvm/at.c | 6 ++++--
> arch/arm64/kvm/hyp/include/hyp/switch.h | 2 ++
> arch/arm64/kvm/hyp/pgtable.c | 4 +++-
> arch/arm64/kvm/nested.c | 33 ++++++++++++++++++++-------------
> arch/arm64/kvm/vgic/vgic-its.c | 6 ++++--
> 6 files changed, 35 insertions(+), 20 deletions(-)
>
^ permalink raw reply
* Re: [PATCH RFC v2] drm/rockchip: vop2: Add clock rate mode check
From: Alexey Charkov @ 2026-06-05 16:57 UTC (permalink / raw)
To: Alexey Charkov
Cc: Sebastian Reichel, Sandy Huang, Heiko Stübner, Andy Yan,
Daniel Stone, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, dri-devel, linux-arm-kernel,
linux-rockchip, linux-kernel, kernel
In-Reply-To: <CABjd4Yw_HYpjhrgmonB9FmWV00q=r3yvqnFE4TXEHpM1ZgWOhA@mail.gmail.com>
On Fri, Jun 5, 2026 at 7:58 PM Alexey Charkov <alchark@gmail.com> wrote:
>
> On Fri, Apr 10, 2026 at 2:37 AM Sebastian Reichel
> <sebastian.reichel@collabora.com> wrote:
> >
> > The display might offer modes, which exceed the maximum clock rate of a
> > video output. This usually happens for displays that offer refresh rates
> > above 60 Hz. This results in no picture (or a broken one) being displayed
> > without manual intervention. Fix this by teaching the driver about the
> > maximum achievable clock rates for each video port.
> >
> > The information about the maximum clock rates for each video channel and
> > the tip about multiple pixels being processed per clock were provided by
> > Andy Yan and roughly checked against the information available in the
> > datasheet (which specifies limits like "2560x1600@60Hz with 10-bit"
> > instead of a specific pixel rate).
> >
> > For the video ports supporting a 600 MHz input clock, there is some
> > logic to handle up to 4 pixels in parallel when needed resulting in
> > the extra multiplier.
> >
> > Suggested-by: Andy Yan <andy.yan@rock-chips.com>
> > Link: https://lore.kernel.org/linux-rockchip/1528d788.186b.19d08ed974c.Coremail.andyshrk@163.com/
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> > ---
> > I've kept the RFC tag, as I'm not sure about the 4x parallel pixel
> > processing. IIUIC all of the video ports with a maximum of 600 MHz
> > input clock support it, considering they can go to 4K @ 120Hz,
> > which is above 1.2GHz while Andy mentioned a max. support clock rate
> > of 600 MHz.
> > ---
> > Changes in v2:
> > - Link to v1: https://lore.kernel.org/r/20260217-vop2-clk-rate-check-v1-1-989b569119ba@collabora.com
> > - based on v7.0-rc7
> > - rename max_clock_rate into max_pixel_clock_rate to distinguish from
> > input clock
> > - update max clock rates to the numbers provided by Andy Yan with
> > extra 4x multiplier for 4K 120Hz VPs
> > ---
> > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 3 +++
> > drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 1 +
> > drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 10 ++++++++++
> > 3 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > index a195f5c819a2..35a0edda5375 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > @@ -1434,6 +1434,9 @@ static enum drm_mode_status vop2_crtc_mode_valid(struct drm_crtc *crtc,
> > if (mode->hdisplay > vp->data->max_output.width)
> > return MODE_BAD_HVALUE;
> >
> > + if (mode->clock > vp->data->max_pixel_clock_rate / 1000)
> > + return MODE_CLOCK_HIGH;
> > +
> > return MODE_OK;
> > }
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> > index 9124191899ba..fd46913f3346 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> > @@ -225,6 +225,7 @@ struct vop2_video_port_data {
> > u16 gamma_lut_len;
> > u16 cubic_lut_len;
> > struct vop_rect max_output;
> > + u32 max_pixel_clock_rate;
> > const u8 pre_scan_max_dly[4];
> > unsigned int offset;
> > /**
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> > index f3950e8476a7..6ae3d506c476 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> > @@ -559,18 +559,21 @@ static const struct vop2_video_port_data rk3568_vop_video_ports[] = {
> > .gamma_lut_len = 1024,
> > .cubic_lut_len = 9 * 9 * 9,
> > .max_output = { 4096, 2304 },
> > + .max_pixel_clock_rate = 600000000U,
> > .pre_scan_max_dly = { 69, 53, 53, 42 },
> > .offset = 0xc00,
> > }, {
> > .id = 1,
> > .gamma_lut_len = 1024,
> > .max_output = { 2048, 1536 },
> > + .max_pixel_clock_rate = 200000000U,
> > .pre_scan_max_dly = { 40, 40, 40, 40 },
> > .offset = 0xd00,
> > }, {
> > .id = 2,
> > .gamma_lut_len = 1024,
> > .max_output = { 1920, 1080 },
> > + .max_pixel_clock_rate = 150000000U,
> > .pre_scan_max_dly = { 40, 40, 40, 40 },
> > .offset = 0xe00,
> > },
> > @@ -775,6 +778,7 @@ static const struct vop2_video_port_data rk3576_vop_video_ports[] = {
> > .gamma_lut_len = 1024,
> > .cubic_lut_len = 9 * 9 * 9, /* 9x9x9 */
> > .max_output = { 4096, 2304 },
> > + .max_pixel_clock_rate = 600000000U * 4,
>
> Hi Sebastian,
>
> I've tested it on a bunch of different displays with RK3576 while also
> giving VP0 an unlimited PLL to work with (and also expanding its rates
> table for each of the displays' EDID preferred pixel clocks), and I'm
> pretty sure this should be * 2 here, rather than * 4. That would also
> align with ".pixel_rate = 2" just below.
>
> In its current form, some of the advanced displays with 240 Hz modes
> by default choose modes leading to visual artifacts indicative of
> overclocking strain of the graphics pipeline.
>
> The rest look plausible, so with that change please feel free to include:
>
> Tested-by: Alexey Charkov <alchark@flipper.net> # RK3576
Sorry, wrong mailbox.
Tested-by: Alexey Charkov <alchark@flipper.net> # RK3576
Best regards,
Alexey
^ permalink raw reply
* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Stefan Wahren @ 2026-06-05 17:11 UTC (permalink / raw)
To: Frank Li
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <aiL638OLrfntKmSC@lizhi-Precision-Tower-5810>
Hi Frank,
Am 05.06.26 um 18:35 schrieb Frank Li:
> On Fri, Jun 05, 2026 at 06:22:14PM +0200, Stefan Wahren wrote:
>> Hi Frank,
>>
>> Am 27.05.26 um 17:14 schrieb Stefan Wahren:
>>> Enable DP83822 PHY driver as a module to support the Ethernet PHY,
>>> which is placed on phyCORE-i.MX93 SOM.
>>>
>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
>> could you please take care of this patch?
> which is base commit, I can't apply clearly.
I rebased against torvalds/v7.1-rc1
>
> Frank
>
>>> ---
>>>
>>> Changes in V2:
>>> - rebase patch
>>> - add Krzysztof's Reviewed-by
>>>
>>> arch/arm64/configs/defconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>>> index d905a0777f93..20bbbd310d2f 100644
>>> --- a/arch/arm64/configs/defconfig
>>> +++ b/arch/arm64/configs/defconfig
>>> @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
>>> CONFIG_QCA808X_PHY=m
>>> CONFIG_REALTEK_PHY=y
>>> CONFIG_ROCKCHIP_PHY=y
>>> +CONFIG_DP83822_PHY=m
>>> CONFIG_DP83867_PHY=y
>>> CONFIG_DP83869_PHY=m
>>> CONFIG_DP83TG720_PHY=m
>>
^ permalink raw reply
* Re: [PATCH v02] mailbox: pcc: report errors for PCC clients
From: Adam Young @ 2026-06-05 17:19 UTC (permalink / raw)
To: Sudeep Holla, Adam Young
Cc: Jassi Brar, linux-kernel, linux-hwmon, Rafael J . Wysocki,
Len Brown, linux-acpi, Andi Shyti, Guenter Roeck, Huisong Li,
MyungJoo Ham, Kyungmin Park, Chanwoo Choi, linux-arm-kernel
In-Reply-To: <c61fa285-01a6-4ac3-82ec-2a6357a9e76f@amperemail.onmicrosoft.com>
On 6/3/26 11:15, Adam Young wrote:
>
> On 5/19/26 09:23, Sudeep Holla wrote:
>> On Mon, May 18, 2026 at 03:30:06PM -0400, Adam Young wrote:
>>> The tx_done callback function has a return code (rc) parameter
>>> that the tx_done callback can use to determine how to handle an error.
>>> However the IRQ handler was not setting that value if there is an
>>> error.
>>>
>>> The following clients are affected:
>>>
>>> drivers/acpi/cppc_acpi.c
>>> drivers/i2c/busses/i2c-xgene-slimpro.c
>>> drivers/hwmon/xgene-hwmon.c
>>> drivers/soc/hisilicon/kunpeng_hccs.c
>>> drivers/devfreq/hisi_uncore_freq.c
>>>
>>> All of these only use the error code to report, so they
>>> are expecting an error code to come thorugh, but they
>>> do not modify behavior based on this code.
>>>
>>> In the case of an error code in the IRQ, the handler was returning
>>> IRQ_NONE which is not correct: the IRQ handler was matched
>>> to the IRQ. This mean that multiple error codes returned from
>>> a PCC triggered interrupt would end up disabling the device.
>>>
>>> In addition, if the error code IRQ was coming from a Type4 Device
>>> that was
>>> expecting an IRQ response, that device would then be hung.
>>>
>>> Fixes: c45ded7e1135 ("mailbox: pcc: Add support for PCCT extended
>>> PCC subspaces(type 3/4)")
>>> Signed-off-by: Adam Young <admiyo@os.amperecomputing.com>
>>>
>>> ---
>>> ---
>>> drivers/mailbox/pcc.c | 9 +++++----
>>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
>>> index 636879ae1db7..16b9ce087b9e 100644
>>> --- a/drivers/mailbox/pcc.c
>>> +++ b/drivers/mailbox/pcc.c
>>> @@ -314,6 +314,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>>> {
>>> struct pcc_chan_info *pchan;
>>> struct mbox_chan *chan = p;
>>> + int rc;
>>> pchan = chan->con_priv;
>>> @@ -327,8 +328,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>>> if (!pcc_mbox_cmd_complete_check(pchan))
>>> return IRQ_NONE;
>>> - if (pcc_mbox_error_check_and_clear(pchan))
>>> - return IRQ_NONE;
>>> + rc = pcc_mbox_error_check_and_clear(pchan);
>> I think we may have to skip the check inside
>> pcc_mbox_error_check_and_clear()
>> for Type 4 channel as the spec expects OSPM to ignore it. It is a
>> separate
>> fix, just noting that here.
>
> I think that should be in this patch, for correctness. It is a small
> enough change. I'll update.
>
Actually, it is a fix in its own right, and can be merged regardless of
this patch, so:
https://lore.kernel.org/lkml/20260604163306.160017-1-admiyo@os.amperecomputing.com/
^ permalink raw reply
* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Frank Li @ 2026-06-05 18:06 UTC (permalink / raw)
To: Stefan Wahren
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <a9304534-2d7d-4316-bcd1-36ff0931bcf0@gmx.net>
On Fri, Jun 05, 2026 at 07:11:30PM +0200, Stefan Wahren wrote:
> Hi Frank,
>
> Am 05.06.26 um 18:35 schrieb Frank Li:
> > On Fri, Jun 05, 2026 at 06:22:14PM +0200, Stefan Wahren wrote:
> > > Hi Frank,
> > >
> > > Am 27.05.26 um 17:14 schrieb Stefan Wahren:
> > > > Enable DP83822 PHY driver as a module to support the Ethernet PHY,
> > > > which is placed on phyCORE-i.MX93 SOM.
> > > >
> > > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > > > Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> > > could you please take care of this patch?
> > which is base commit, I can't apply clearly.
> I rebased against torvalds/v7.1-rc1
pick to imx/defconfig
Frank
> >
> > Frank
> >
> > > > ---
> > > >
> > > > Changes in V2:
> > > > - rebase patch
> > > > - add Krzysztof's Reviewed-by
> > > >
> > > > arch/arm64/configs/defconfig | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > > > index d905a0777f93..20bbbd310d2f 100644
> > > > --- a/arch/arm64/configs/defconfig
> > > > +++ b/arch/arm64/configs/defconfig
> > > > @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
> > > > CONFIG_QCA808X_PHY=m
> > > > CONFIG_REALTEK_PHY=y
> > > > CONFIG_ROCKCHIP_PHY=y
> > > > +CONFIG_DP83822_PHY=m
> > > > CONFIG_DP83867_PHY=y
> > > > CONFIG_DP83869_PHY=m
> > > > CONFIG_DP83TG720_PHY=m
> > >
>
>
^ permalink raw reply
* Re: [PATCH 0/3] Subject: [PATCH 0/3] iio: adc: Add Axiado SARADC driver
From: Andy Shevchenko @ 2026-06-05 18:16 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260528-axiado-ax3000-ax3005-saradc-v1-0-345dd5f6608a@axiado.com>
On Thu, May 28, 2026 at 01:10:22AM -0700, Petar Stepanovic wrote:
> This series adds support for the SAR ADC controller found on Axiado
> AX3000 and AX3005 SoCs.
>
> The controller is a 10-bit ADC. AX3000 has sixteen input channels and
> AX3005 has eight input channels. The driver uses SoC match data to
> select the number of available channels for each compatible.
>
> The driver supports single-shot voltage reads through the IIO subsystem
> and uses the reference voltage regulator for scale calculation.
When submit a new driver always answer these two questions:
- why do we even need a new brand driver? (No existing that can be extended?)
- where can we get a datasheet? (URL? Other means?)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 2/3] iio: adc: add Axiado SARADC driver
From: Andy Shevchenko @ 2026-06-05 18:26 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260528-axiado-ax3000-ax3005-saradc-v1-2-345dd5f6608a@axiado.com>
On Thu, May 28, 2026 at 01:10:24AM -0700, Petar Stepanovic wrote:
> Add support for the SARADC controller found on Axiado AX3000 and
> AX3005 SoCs.
>
> The driver supports single-shot voltage reads through the IIO
> subsystem. The number of available input channels is selected from
> the SoC match data, allowing AX3000 and AX3005 variants to use the
> same driver.
(I'll try to not duplicate what Joshua noticed already.)
...
> +config AXIADO_SARADC
> + tristate "Axiado SARADC driver"
> + depends on ARCH_AXIADO || COMPILE_TEST
> + depends on OF
No, in IIO we want a good justification on non-agnostic requirements.
Why can't this device driver be agnostic?
...
> +#include <linux/bitfield.h>
+ bits.h
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/iio/iio.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
No driver should have this header to be included.
Rare and well justified exceptions are possible
(and no, not in this case).
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/regulator/consumer.h>
...
> +struct axiado_saradc {
> + void __iomem *regs;
> + struct clk *clk;
> + unsigned long clk_rate;
> + int vref_uv;
_uV (yes, capital letter as per SI).
> + struct mutex lock; /* Serializes ADC conversions. */
> +};
...
> +static int axiado_saradc_conversion(struct axiado_saradc *info,
> + struct iio_chan_spec const *chan, int *val)
> +{
> + unsigned long usecs;
Missing blank line here.
> + /* Select the channel to be used and trigger conversion */
> + iowrite32(AX_SARADC_MANUAL_CTRL_EN(chan->channel),
> + info->regs + AX_SARADC_MANUAL_CTRL);
Why not writel()?
> +
> + /* Hardware requires 13 conversion cycles at clk_rate */
> + usecs = DIV_ROUND_UP(AX_SARADC_CONV_CYCLES * 1000000, info->clk_rate);
USe USEC_PER_SEC from time.h.
> + usleep_range(usecs, usecs + 10);
> +
> + *val = ioread32(info->regs + AX_SARADC_DOUT) &
> + GENMASK(AX_RESOLUTION_BITS - 1, 0);
> +
> + /* Stop manual conversion */
> + iowrite32(0, info->regs + AX_SARADC_MANUAL_CTRL);
> + return 0;
> +}
...
> +static int axiado_saradc_probe(struct platform_device *pdev)
> +{
> + struct axiado_saradc *info;
> + const struct axiado_saradc_soc_data *soc_data;
> + struct iio_dev *indio_dev;
> + int ret;
> + u32 reg;
> +
> + indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + info = iio_priv(indio_dev);
> +
> + info->regs = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(info->regs))
> + return PTR_ERR(info->regs);
> +
> + info->clk = devm_clk_get_enabled(&pdev->dev, NULL);
Why no name? It will make harder for the next generations of HW in case they
want more than one clock to be used.
> + if (IS_ERR(info->clk))
> + return PTR_ERR(info->clk);
> +
> + info->clk_rate = clk_get_rate(info->clk);
> + if (!info->clk_rate)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "invalid clock rate\n");
> + info->vref_uv = devm_regulator_get_enable_read_voltage(&pdev->dev,
> + "vref");
Having
struct device *dev = &pdev->dev;
will make the code shorter and easier to read.
> + if (info->vref_uv < 0)
> + return dev_err_probe(&pdev->dev, info->vref_uv,
> + "failed to get vref voltage\n");
> +
> + soc_data = device_get_match_data(&pdev->dev);
> + if (!soc_data)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "failed to get match data\n");
> +
> + mutex_init(&info->lock);
> + reg = FIELD_PREP(AX_SARADC_CH_EN_MASK,
> + GENMASK(soc_data->num_channels - 1, 0)) |
> + AX_SARADC_SAMPLE_16 | AX_SARADC_MODE | AX_SARADC_ENABLE;
FIELD_PREP_CONST() ?
> + iowrite32(AX_SARADC_PD, info->regs + AX_SARADC_GLOBAL_CTRL);
> + iowrite32(reg, info->regs + AX_SARADC_GLOBAL_CTRL);
> +
> + indio_dev->name = dev_name(&pdev->dev);
> + indio_dev->dev.parent = &pdev->dev;
> + indio_dev->info = &axiado_saradc_iio_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> + indio_dev->channels = axiado_saradc_iio_channels;
> + indio_dev->num_channels = soc_data->num_channels;
> +
> + ret = devm_iio_device_register(&pdev->dev, indio_dev);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "failed to register IIO device\n");
> +
> + return 0;
> +}
...
> +static const struct of_device_id axiado_saradc_match[] = {
> + {
> + .compatible = "axiado,ax3000-saradc",
> + .data = &ax3000_saradc_data,
> + },
> + {
> + .compatible = "axiado,ax3005-saradc",
> + .data = &ax3005_saradc_data,
> + },
> + {},
No comma for the terminator entry.
> +};
...
> +static struct platform_driver axiado_saradc_driver = {
> + .driver = {
> + .name = KBUILD_MODNAME,
We want to have these kind of strings to be fixed.
> + .of_match_table = axiado_saradc_match,
> + },
> + .probe = axiado_saradc_probe,
> +};
> +
Unnecessary blank line.
> +module_platform_driver(axiado_saradc_driver);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 0/3] x86,fs/resctrl,arm_mpam: Factor MBA parse-time conversion to be per-arch
From: Reinette Chatre @ 2026-06-05 18:41 UTC (permalink / raw)
To: Ben Horgan
Cc: james.morse, fenghuay, linux-kernel, linux-arm-kernel, tglx,
mingo, bp, dave.hansen, hpa, corbet, x86, linux-doc, dave.martin
In-Reply-To: <20260515140612.1205251-1-ben.horgan@arm.com>
Hi Ben,
On 5/15/26 7:06 AM, Ben Horgan wrote:
> This is a new version of Dave Martin's patch [1] to delegate rounding of
> bandwidth control user values to the arch code. As there is now more than one
> architecture using resctrl, I split the original patch into two, a core resctrl
> patch and an x86 patch, and added an MPAM patch. Please let me know if the patch
> break down and ordering is sensible and whether the pattern should be followed
> for any future similar changes.
This ordering is sensible to me. I find the patch breakdown a bit fragmented since
the logical resctrl fs change is split yet I also find that you did what was best
to ensure bisectability. I find small changes that are local to subsystems easier to
consider and believe it would be ideal to only have patches touching multiple
subsystems when it cannot be avoided, for example when doing otherwise would break
bisect. Even so, we may learn of better ways to do this when this series is considered
for x86 inclusion.
Reinette
^ permalink raw reply
* Re: [PATCH v3 1/3] x86/resctrl: Add resctrl_arch_preconvert_bw()
From: Reinette Chatre @ 2026-06-05 18:42 UTC (permalink / raw)
To: Ben Horgan
Cc: james.morse, fenghuay, linux-kernel, linux-arm-kernel, tglx,
mingo, bp, dave.hansen, hpa, corbet, x86, linux-doc, dave.martin
In-Reply-To: <20260515140612.1205251-2-ben.horgan@arm.com>
Hi Ben,
Since this patch also impacts resctrl fs API in include/linux/resctrl.h the
subject prefix would more accurate as "x86,fs/resctrl: Add ..."
On 5/15/26 7:06 AM, Ben Horgan wrote:
...
> @@ -500,6 +500,25 @@ bool resctrl_arch_mbm_cntr_assign_enabled(struct rdt_resource *r);
> */
> int resctrl_arch_mbm_cntr_assign_set(struct rdt_resource *r, bool enable);
>
> +/**
> + * resctrl_arch_preconvert_bw() - Prepare bandwidth control value for arch use.
> + * @val: Bandwidth control value written to the schemata file by userspace.
> + * @r: Resource whose schema was written.
> + *
> + * Convert the user provided bandwidth control value to an appropriate form for
> + * consumption by the hardware driver for resource @r. Converted value is stored
> + * in rdt_ctrl_domain::staged_config[] for later consumption by
> + * resctrl_arch_update_domains(). Is not called when MBA software controller is
> + * enabled.
> + *
> + * Architectures for which this pre-conversion hook is not useful should supply
> + * an implementation of this function that just returns val unmodified.
nit: "val" -> "@val"
> + *
> + * Return:
> + * The converted value.
> + */
> +u32 resctrl_arch_preconvert_bw(u32 val, const struct rdt_resource *r);
Could you please switch the resource to be the first parameter? When comparing
this to other similar arch helpers in include/linux/resctrl.h it is custom for the resource
to be the first parameter.
> +
> /*
> * Update the ctrl_val and apply this config right now.
> * Must be called on one of the domain's CPUs.
| Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Reinette
^ permalink raw reply
* Re: [PATCH v3 2/3] arm_mpam: resctrl: Add pass-through resctrl_arch_preconvert_bw()
From: Reinette Chatre @ 2026-06-05 18:43 UTC (permalink / raw)
To: Ben Horgan
Cc: james.morse, fenghuay, linux-kernel, linux-arm-kernel, tglx,
mingo, bp, dave.hansen, hpa, corbet, x86, linux-doc, dave.martin
In-Reply-To: <20260515140612.1205251-3-ben.horgan@arm.com>
Hi Ben,
On 5/15/26 7:06 AM, Ben Horgan wrote:
> resctrl rounds up the percentage value of the MBA based on the bw_gran. As
> MPAM uses a binary fixed point fraction format for MBA rather than a
> decimal percentage, this introduces rounding errors.
>
> Without this additional rounding, if the user reads the value in an MB
> schema and then writes it back to the schema, the value in hardware won't
> change. However, with this additional rounding, this guarantee is broken
> for systems with mbw_wd < 7.
>
> resctrl is introducing resctrl_arch_preconvert_bw() to allow the arch code
> to specify the conversion resctrl does to the user-provided bandwidth
> value. Add the MPAM version of resctrl_arch_preconvert_bw(). This does no
> conversion.
>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
If rebased on patch #1 proposed changes:
| Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Reinette
^ permalink raw reply
* Re: [PATCH v3 3/3] fs/resctrl: Factor MBA parse-time conversion to be per-arch
From: Reinette Chatre @ 2026-06-05 18:43 UTC (permalink / raw)
To: Ben Horgan
Cc: james.morse, fenghuay, linux-kernel, linux-arm-kernel, tglx,
mingo, bp, dave.hansen, hpa, corbet, x86, linux-doc, dave.martin
In-Reply-To: <20260515140612.1205251-4-ben.horgan@arm.com>
Hi Ben,
On 5/15/26 7:06 AM, Ben Horgan wrote:
> From: Dave Martin <Dave.Martin@arm.com>
>
> The control value parser for the MB resource currently coerces the
> memory bandwidth percentage value from userspace to be an exact
> multiple of the rdt_resource::resctrl_membw::bw_gran parameter.
>
> On MPAM systems, this results in somewhat worse-than-worst-case
> rounding, since the bandwidth granularity advertised to resctrl by the
> MPAM driver is in general only an approximation to the actual hardware
> granularity on these systems, and the hardware bandwidth allocation
> control value is not natively a percentage -- necessitating a further
> conversion in the resctrl_arch_update_domains() path, regardless of the
> conversion done at parse time.
>
> For MPAM and x86 use their custom pre-prepared parse-time conversion,
> resctrl_arch_preconvert_bw(). This will avoid accumulated error
> from rounding the value twice on MPAM systems. For x86 systems there
> is no functional change.
>
> Clarify the documentation, but avoid overly exact promises.
>
> Clamping to bw_min and bw_max still feels generic: leave it in the core
> code, for now.
Same comment as v2: please use max line length available. Some more context here:
When resctrl patches are formatted as above the x86 maintainers end up reformatting
them if they can afford to spend the time doing so. Having changelog formatted
correctly from beginning avoids this extra churn.
You can find related comment from Boris at
https://lore.kernel.org/lkml/20250916105447.GCaMlB976WLxHHeNMD@fat_crate.local/
...
> diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
> index 9a7dfc48cb2e..934e12f5d145 100644
> --- a/fs/resctrl/ctrlmondata.c
> +++ b/fs/resctrl/ctrlmondata.c
> @@ -37,8 +37,8 @@ typedef int (ctrlval_parser_t)(struct rdt_parse_data *data,
> /*
> * Check whether MBA bandwidth percentage value is correct. The value is
> * checked against the minimum and max bandwidth values specified by the
> - * hardware. The allocated bandwidth percentage is rounded to the next
> - * control step available on the hardware.
> + * hardware. The allocated bandwidth percentage is converted as
> + * appropriate for consumption by the specific hardware driver.
Same comment as v2: Adjusting right margin mid-paragraph looks awkward.
> */
> static bool bw_validate(char *buf, u32 *data, struct rdt_resource *r)
> {
> @@ -71,7 +71,7 @@ static bool bw_validate(char *buf, u32 *data, struct rdt_resource *r)
> return false;
> }
>
> - *data = roundup(bw, (unsigned long)r->membw.bw_gran);
> + *data = resctrl_arch_preconvert_bw(bw, r);
> return true;
> }
>
With line lengths adjusted (and rebased on patch #1 proposed changes):
| Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Reinette
^ permalink raw reply
* Re: [PATCH v5 5/5] watchdog: aaeon: Add watchdog driver for SRG-IMX8P MCU
From: Thomas Perrot @ 2026-06-05 18:42 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Lee Jones
Cc: thomas.perrot@bootlin.com, devicetree, linux-kernel, linux-gpio,
imx, linux-arm-kernel, linux-watchdog, Thomas Petazzoni,
Miquel Raynal
In-Reply-To: <bcc88b28-fa45-4a75-8a09-98d25a9377c9@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
Hello Guenter,
On Fri, 2026-04-10 at 08:49 -0700, Guenter Roeck wrote:
> On 4/8/26 10:21, Thomas Perrot (Schneider Electric) wrote:
> > Add watchdog driver for the Aaeon SRG-IMX8P embedded controller.
> > This driver provides system monitoring and recovery capabilities
> > through the MCU's watchdog timer.
> >
> > The watchdog supports start, stop, and ping operations with a
> > maximum
> > hardware heartbeat of 25 seconds and a default timeout of 240
> > seconds.
> >
> > snip
> >
>
> Odd, unusual, unnecessary, I would argue that most people would
> consider a fixed
> timeout of 240s as anything but reasonable, and as the comment says
> arbitrary.
> Since I am sure that I pointed this out before, you still insist, and
> I am
> tired of arguing: Your funeral, so
>
I apologize for not addressing this in previous iterations.
This will be addressed in v6 to make the software timeout configurable.
The 240s value remains as the default fallback.
Kind regards,
Thomas
> Acked-by: Guenter Roeck <linux@roeck-us.net>
>
> Guenter
>
> >
> >
--
Thomas Perrot, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply
* [PATCH] KVM: arm64: Fix block mapping validity check in stage-1 walker
From: Wei-Lin Chang @ 2026-06-05 18:52 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Wei-Lin Chang
For the 64K granule size, FEAT_LPA determines whether a level 1 mapping
is allowed. Using the result of has_52bit_pa() is too restrictive, as it
also checks the selected output addressi size in TCR.(I)PS. Fix it by
only checking FEAT_LPA.
Fixes: 5da3a3b27a01 ("KVM: arm64: Expand valid block mappings to FEAT_LPA/LPA2 support")
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/at.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
index 2ddb5b5a055e..30e6fa8ac07c 100644
--- a/arch/arm64/kvm/at.c
+++ b/arch/arm64/kvm/at.c
@@ -564,15 +564,18 @@ static int walk_s1(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
/* Block mapping, check the validity of the level */
if (!(desc & BIT(1))) {
bool valid_block = false;
+ bool lpa = kvm_has_feat_enum(vcpu->kvm, ID_AA64MMFR0_EL1, PARANGE, 52);
switch (BIT(wi->pgshift)) {
case SZ_4K:
valid_block = level == 1 || level == 2 || (wi->pa52bit && level == 0);
break;
case SZ_16K:
- case SZ_64K:
valid_block = level == 2 || (wi->pa52bit && level == 1);
break;
+ case SZ_64K:
+ valid_block = level == 2 || (lpa && level == 1);
+ break;
}
if (!valid_block)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/3] Add support for NetCube Systems OpenNMC (dobermann)
From: Lukas Schmid @ 2026-06-05 19:13 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Maxime Ripard
Cc: Lukas Schmid, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv
This series adds support for the NetCube Systems OpenNMC
Changes in v2:
- fixed ordering of compatible enum
- fixed gpio line names
Signed-off-by: Lukas Schmid <lukas.schmid@netcube.li>
---
Lukas Schmid (3):
dt-bindings: arm: sunxi: Add NetCube Systems OpenNMC (dobermann)
riscv: dts: allwinner: d1s-t113: Add uart4 pinctrl required by NetCube
Systems OpenNMC
ARM: dts: sunxi: add support for NetCube Systems OpenNMC (dobermann)
.../devicetree/bindings/arm/sunxi.yaml | 1 +
.../sun8i-t113s-netcube-dobermann.dts | 149 ++++++++++++++++++
.../boot/dts/allwinner/sunxi-d1s-t113.dtsi | 6 +
3 files changed, 156 insertions(+)
create mode 100644 arch/arm/boot/dts/allwinner/sun8i-t113s-netcube-dobermann.dts
--
2.47.3
^ 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