* [PATCH v5 04/10] arm64: dts: rockchip: Add missing hclk for RK3588 eDP1
From: Damon Ding @ 2026-05-13 7:44 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260513074414.2053435-1-damon.ding@rock-chips.com>
Add the required HCLK_VO1 bus clock to RK3588 eDP1 node with
corresponding clock-name "hclk". This clock is necessary for
the eDP controller to access video output GRF and work properly.
Previously the clock was enabled implicitly via GRF phandle
reference. Add it explicitly now to align with updated binding.
Fixes: a481bb0b1ad9 ("arm64: dts: rockchip: Add eDP1 dt node for rk3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--git a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
index a2640014ee04..b251bb129cdb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
@@ -285,8 +285,8 @@ hdmi1_out: port@1 {
edp1: edp@fded0000 {
compatible = "rockchip,rk3588-edp";
reg = <0x0 0xfded0000 0x0 0x1000>;
- clocks = <&cru CLK_EDP1_24M>, <&cru PCLK_EDP1>;
- clock-names = "dp", "pclk";
+ clocks = <&cru CLK_EDP1_24M>, <&cru PCLK_EDP1>, <&cru HCLK_VO1>;
+ clock-names = "dp", "pclk", "hclk";
interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH 0>;
phys = <&hdptxphy1>;
phy-names = "dp";
--
2.34.1
^ permalink raw reply related
* [PATCH v5 01/10] dt-bindings: display: rockchip: analogix-dp: Fix hclk as third clock for RK3588
From: Damon Ding @ 2026-05-13 7:44 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260513074414.2053435-1-damon.ding@rock-chips.com>
RK3588 eDP controller requires HCLK_VO1 (video output bus clock)
to access the VO1 GRF registers and enable the video datapath.
Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
phandle reference, which allowed the eDP to work without explicitly
managing the hclk_vo1 clock. However, this is not safe or explicit.
Enforce the correct third clock name on a per-compatible basis to
standardize clock requirements per SoC. This makes the clock
dependency clear and removes reliance on implicit clock enablement
from GRF phandle.
Fixes: f855146263b1 ("dt-bindings: display: rockchip: analogix-dp: Add support for RK3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
Changes in v5:
- Enforce the correct third clock name on a per-compatible basis.
- Modify the commit msg simultaneously.
---
.../rockchip/rockchip,analogix-dp.yaml | 37 +++++++++++++++++--
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
index d99b23b88cc5..8001c1facf98 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
@@ -23,10 +23,7 @@ properties:
clock-names:
minItems: 2
- items:
- - const: dp
- - const: pclk
- - const: grf
+ maxItems: 3
power-domains:
maxItems: 1
@@ -60,6 +57,33 @@ required:
allOf:
- $ref: /schemas/display/bridge/analogix,dp.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3288-dp
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: dp
+ - const: pclk
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3399-edp
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: dp
+ - const: pclk
+ - const: grf
+
- if:
properties:
compatible:
@@ -68,6 +92,11 @@ allOf:
- rockchip,rk3588-edp
then:
properties:
+ clock-names:
+ items:
+ - const: dp
+ - const: pclk
+ - const: hclk
resets:
minItems: 2
reset-names:
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 1/3] dt-bindings: gpio: add Axiado SGPIO controller
From: Petar Stepanovic @ 2026-05-13 8:59 UTC (permalink / raw)
To: Linus Walleij
Cc: Tzu-Hao Wei, Swark Yang, Prasad Bolisetty, Bartosz Golaszewski,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Harshit Shah,
SriNavmani A, linux-gpio, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <CAD++jL=51iWK2SyxoWOTxSQHAq-Frd0mm6cPxqYu81qifFfHGg@mail.gmail.com>
On 5/11/2026 10:36 AM, Linus Walleij wrote:
> Are they connected to the same physical output line/pin or
> not? That is the only thing that matters. If they in the end control
> the same physical entitiy, it *is* the same GPIO line from Linux'
> point of view.
No, they are not connected to the same physical line/pin.
DIN and DOUT are separate physical SGPIO signals in this hardware. DIN
signals are input-only and DOUT signals are output-only; they are not
bidirectional or interchangeable paths for the same physical pin.
So I agree that Linux should model physical GPIO entities rather than
internal register bits. My previous wording was not clear enough: the
intention was to describe separate physical SGPIO signals, not just separate
register fields.
>> Because the direction is fixed by hardware, the standard
>> lines-initial-states property, which encodes both direction and initial state,
>> does not map cleanly to this design.
> GPIOs with fixed direction is nothing new for Linux, we've had
> that for ages.
>
> I would just have the driver reject configurations that does
> not apply and bail out.
>
> If you absolutely want to enforce the lines-initial-states to match what the
> hardware can do, then use YAML schema restriuctions on what
> values can be encoded into that array.
>
>> For the output lines (DOUT), should their initial values be described in the
>> device tree, or should they be configured by userspace, with the driver only
>> providing default initialization?
> I don't see why userspace should deal with that. The Linux userspace
> ABI is for hacking and odd usecases (like industrial). The nominal
> use is kernel-internal consumers and those must be able to
> request their GPIOs as well without any userspace shenanigans.
>
> But avoiding to deal with initial line states at all is a solution
> of course.
>
> What I don't understand is what purpose this dout-init actually
> does and why it cannot be set dynamically by the driver at runtime.
Some SGPIO outputs may control host-critical signals. For example, if the
BMC reboots while the host/server remains powered on, changing SGPIO output
values during driver initialization could potentially reset or shut down the
running host.
The purpose of `dout-init` is to provide a deterministic safe output state
during SGPIO initialization, before any GPIO consumer has requested the line.
That said, if the preferred approach is to preserve the existing hardware
DOUT state during probe and only change the value when a GPIO consumer
requests the line, I can rework the driver in that direction.
Thnaks,
Petar
^ permalink raw reply
* Re: [PATCH v4 02/15] mm: Make empty_zero_page __ro_after_init
From: Ard Biesheuvel @ 2026-05-13 8:53 UTC (permalink / raw)
To: Mike Rapoport
Cc: Jann Horn, Ard Biesheuvel, linux-arm-kernel, linux-kernel,
Will Deacon, Catalin Marinas, Mark Rutland, Ryan Roberts,
Anshuman Khandual, Liz Prucka, Seth Jenkins, Kees Cook,
David Hildenbrand, Andrew Morton, linux-mm, linux-hardening
In-Reply-To: <agQ7RMAw51RlNUOj@kernel.org>
On Wed, 13 May 2026, at 10:50, Mike Rapoport wrote:
> On Tue, May 12, 2026 at 02:56:16PM +0200, Ard Biesheuvel wrote:
>> On Mon, 11 May 2026, at 16:40, Jann Horn wrote:
>> > On Mon, May 11, 2026 at 10:59 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>> >> I think we should simply do something along the lines of the below,
>> >> considering that the size of a data object tends to correlate with
>> >> its minimum alignment.
>> >>
>> >> I do find it rather puzzling that the compiler emits empty_zero_page
>> >> *after* zero_page_pfn - ideally, we'd combine the below with
>> >> -fdata-sections so that the linker sees all individual objects, but
>> >> I suspect that would create some problems elsewhere.
>> >>
>> >>
>> >> --- a/include/asm-generic/vmlinux.lds.h
>> >> +++ b/include/asm-generic/vmlinux.lds.h
>> >> @@ -452,7 +452,7 @@
>> >> #define RO_AFTER_INIT_DATA \
>> >> . = ALIGN(8); \
>> >> __start_ro_after_init = .; \
>> >> - *(.data..ro_after_init) \
>> >> + *(SORT_BY_ALIGNMENT(.data..ro_after_init)) \
>> >
>> > Oh, neat, I didn't realize that's possible. That seems like a nicer
>> > approach...
>>
>> Neat but rather ineffective, unfortunately. (I don't see a size
>> difference with the arm64 defconfig kernel)
>>
>> Given that empty_zero_page only ever gets its address taken, we
>> might just move it into the linker script if that requires tweaking
>> anyway. We can just place it at the start of .rodata, which is
>> already page aligned on most architectures (and will become page
>> aligned unless EMPTY_ZERO_PAGE is #define'd by the arch linker
>> script to something else)
>>
>>
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -472,6 +472,17 @@
>> #endif
>> #endif
>>
>> +#ifndef EMPTY_ZERO_PAGE
>> +#ifndef __HAVE_COLOR_ZERO_PAGE
>
> I don't think we want let architectures that don't use colored zero pages
> redefine it.
> If it will be really required we can add the ability to redefine
> EMPTY_ZERO_PAGE later.
>
I was actually intending to add use this for arm64 in the next patch. It
already has a reserved_pg_dir in .rodata which is page-sized (i.e., up
to 64k in size) and guaranteed to remain all zeroes, so empty_zero_page
could actually be an alias for that. This is what I had in a previous
revision, before you turned the empty_zero_page definition into common
code:
https://lore.kernel.org/all/20260320145934.2349881-16-ardb+git@google.com/
^ permalink raw reply
* Re: [PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub
From: Aneesh Kumar K.V @ 2026-05-13 8:53 UTC (permalink / raw)
To: Greg KH
Cc: Catalin Marinas, linux-kernel, linux-arm-kernel, Jeremy Linton,
Jonathan Cameron, Lorenzo Pieralisi, Mark Rutland, Sudeep Holla,
Will Deacon, Jonathan Cameron, Suzuki K Poulose
In-Reply-To: <2026051352-albatross-contents-7113@gregkh>
Greg KH <gregkh@linuxfoundation.org> writes:
> On Wed, May 13, 2026 at 12:28:12PM +0530, Aneesh Kumar K.V wrote:
>> Catalin Marinas <catalin.marinas@arm.com> writes:
>>
>> > + Suzuki again
>> >
>> > On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
>> >> The SMCCC firmware driver now creates the `arm-smccc` platform device
>> >> and also creates the CCA auxiliary devices once the RSI ABI is
>> >> discovered. This makes the arch-specific arm64_create_dummy_rsi_dev()
>> >> helper redundant. Remove the arm-cca-dev platform device registration
>> >> and let the SMCCC probe manage the RSI device.
>> >>
>> >> systemd match on platform:arm-cca-dev for confidential vm detection [1].
>> >> Losing the platform device registration can break that. Keeping this
>> >> removal in its own change makes it easy to revert if that regression
>> >> blocks the rollout.
>> >>
>> >> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>> >
>> > I wouldn't merge this now given that systemd checks this file. Could we
>> > have a symbolic link instead for some time until systemd eventually gets
>> > updated (years?).
>> >
>>
>> I’ll add this in the next revision.
>>
>> static int create_rsi_compat_link(struct device *target_dev)
>> {
>> struct kobject *platform_kobj;
>> /*
>> * target_dev is:
>> * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
>> * Create compat link /sys/devices/platform/arm-cca-dev
>> */
>> platform_kobj = target_dev->kobj.parent->parent;
>
> What? That is crazy, you don't know that is always going to be ok.
>
>> return sysfs_create_link(platform_kobj,
>> &target_dev->kobj,
>> "arm-cca-dev");
>
> No, don't do that, if a driver calls a sysfs* function, something is
> almost always wrong. Don't be making random sysfs symlinks please.
>
Sure, but could you explain why this is wrong? Below is the full version
of the updated patch.
coco: guest: arm64 Replace RSI platform device with compat symlink
The SMCCC firmware driver now creates the arm-smccc platform device and
registers the RSI device as an auxiliary device once the RSI ABI has been
discovered. This makes the arch-specific arm64 arm-cca-dev platform device
redundant.
Remove the arm64 platform device stub and let the SMCCC core manage RSI
device creation.
This changes the real device location from the old platform device path to:
/sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
Keep userspace compatibility by creating a sysfs symlink at the old path:
/sys/devices/platform/arm-cca-dev
A Debian Code Search check found systemd matching on the old
platform:arm-cca-dev device path for confidential VM detection. No other
userspace dependency on the old platform device path was found, but keeping
the compatibility symlink avoids breaking existing systemd-based detection
[1].
[1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
modified arch/arm64/kernel/rsi.c
@@ -159,18 +159,3 @@ void __init arm64_rsi_init(void)
static_branch_enable(&rsi_present);
}
-
-static struct platform_device rsi_dev = {
- .name = "arm-cca-dev",
- .id = PLATFORM_DEVID_NONE
-};
-
-static int __init arm64_create_dummy_rsi_dev(void)
-{
- if (is_realm_world() &&
- platform_device_register(&rsi_dev))
- pr_err("failed to register rsi platform device\n");
- return 0;
-}
-
-arch_initcall(arm64_create_dummy_rsi_dev)
modified drivers/firmware/smccc/rmm.c
@@ -4,13 +4,31 @@
*/
#include <linux/auxiliary_bus.h>
+#include <linux/sysfs.h>
+#include <linux/device.h>
#include "rmm.h"
+static int create_rsi_compat_link(struct device *target_dev)
+{
+ struct kobject *platform_kobj;
+ /*
+ * target_dev is:
+ * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
+ * Create compat link /sys/devices/platform/arm-cca-dev
+ */
+ platform_kobj = target_dev->kobj.parent->parent;
+
+ return sysfs_create_link(platform_kobj,
+ &target_dev->kobj,
+ "arm-cca-dev");
+}
+
void __init register_rsi_device(struct platform_device *pdev)
{
unsigned long ret;
unsigned long ver_lower, ver_higher;
+ struct auxiliary_device *adev;
if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)
return;
@@ -19,6 +37,10 @@ void __init register_rsi_device(struct platform_device *pdev)
if (ret != RSI_SUCCESS)
return;
- __devm_auxiliary_device_create(&pdev->dev,
- "arm_cca_guest", RSI_DEV_NAME, NULL, 0);
+ adev = __devm_auxiliary_device_create(&pdev->dev,
+ "arm_cca_guest", RSI_DEV_NAME, NULL, 0);
+ if (!adev)
+ return;
+
+ create_rsi_compat_link(&adev->dev);
}
>
> If userspace can not find the device anymore, that's fine, that's how
> sysfs works, devices move around all the time. Especially platform
> devices as those are almost always not supposed to be platform devices :)
>
> thanks,
>
> greg k-h
-aneesh
^ permalink raw reply
* Re: [PATCH 09/10] clk: amlogic: Add A9 peripherals clock controller driver
From: Jian Hu @ 2026-05-13 8:50 UTC (permalink / raw)
To: Brian Masney
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Jerome Brunet, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-kernel, linux-clk,
devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <agH4_gClJW8CVV75@redhat.com>
On 5/11/2026 11:42 PM, Brian Masney wrote:
> [ EXTERNAL EMAIL ]
>
> Hi Jian,
>
> On Mon, May 11, 2026 at 08:47:31PM +0800, Jian Hu via B4 Relay wrote:
>> From: Jian Hu <jian.hu@amlogic.com>
>>
>> Add the peripherals clock controller driver for the Amlogic A9 SoC family.
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>> ---
>> drivers/clk/meson/Kconfig | 15 +
>> drivers/clk/meson/Makefile | 1 +
>> drivers/clk/meson/a9-peripherals.c | 2317 ++++++++++++++++++++++++++++++++++++
>> 3 files changed, 2333 insertions(+)
>>
>> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
>> index 3549e67d6988..48a15a5e1323 100644
>> --- a/drivers/clk/meson/Kconfig
>> +++ b/drivers/clk/meson/Kconfig
>> @@ -145,6 +145,21 @@ config COMMON_CLK_A9_PLL
>> device, AKA A9. PLLs are required by most peripheral to operate.
>> Say Y if you want A9 PLL clock controller to work.
>>
>> +config COMMON_CLK_A9_PERIPHERALS
>> + tristate "Amlogic A9 SoC peripherals clock controller support"
>> + depends on ARM64
> depends on ARM64 || COMPILE_TEST
Ok, I will add COMPILE_TEST in the next version.
>> + default ARCH_MESON
>> + select COMMON_CLK_MESON_REGMAP
>> + select COMMON_CLK_MESON_CLKC_UTILS
>> + select COMMON_CLK_MESON_DUALDIV
>> + select COMMON_CLK_MESON_VID_PLL_DIV
>> + imply COMMON_CLK_SCMI
>> + imply COMMON_CLK_A9_PLL
>> + help
>> + Support for the peripherals clock controller on Amlogic A311Y3 based
>> + device, AKA A9. Peripherals are required by most peripheral to operate.
>> + Say Y if you want A9 peripherals clock controller to work.
>> +
>> config COMMON_CLK_C3_PLL
>> tristate "Amlogic C3 PLL clock controller"
>> depends on ARM64
>> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
>> index 77636033061f..2b5b67b14efc 100644
>> --- a/drivers/clk/meson/Makefile
>> +++ b/drivers/clk/meson/Makefile
>> @@ -20,6 +20,7 @@ obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
>> obj-$(CONFIG_COMMON_CLK_A1_PLL) += a1-pll.o
>> obj-$(CONFIG_COMMON_CLK_A1_PERIPHERALS) += a1-peripherals.o
>> obj-$(CONFIG_COMMON_CLK_A9_PLL) += a9-pll.o
>> +obj-$(CONFIG_COMMON_CLK_A9_PERIPHERALS) += a9-peripherals.o
>> obj-$(CONFIG_COMMON_CLK_C3_PLL) += c3-pll.o
>> obj-$(CONFIG_COMMON_CLK_C3_PERIPHERALS) += c3-peripherals.o
>> obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o
>> diff --git a/drivers/clk/meson/a9-peripherals.c b/drivers/clk/meson/a9-peripherals.c
>> new file mode 100644
>> index 000000000000..338a91c473ea
>> --- /dev/null
>> +++ b/drivers/clk/meson/a9-peripherals.c
>> @@ -0,0 +1,2317 @@
>> +// SPDX-License-Identifier: (GPL-2.0-only OR MIT)
>> +/*
>> + * Copyright (C) 2026 Amlogic, Inc. All rights reserved
>> + */
>> +
>> +#include <linux/clk-provider.h>
>> +#include <linux/platform_device.h>
>> +#include <dt-bindings/clock/amlogic,a9-peripherals-clkc.h>
>> +#include "clk-regmap.h"
>> +#include "clk-dualdiv.h"
>> +#include "vid-pll-div.h"
>> +#include "meson-clkc-utils.h"
> Sort the headers.
Ok, I will place them in order.
After updated:
#include <dt-bindings/clock/amlogic,a9-peripherals-clkc.h>
#include <linux/clk-provider.h>
#include <linux/platform_device.h>
#include "clk-regmap.h"
#include "clk-dualdiv.h"
#include "meson-clkc-utils.h"
#include "vid-pll-div.h"
[......]
>> +static const struct clk_parent_data a9_nna_parents[] = {
>> + { .fw_name = "xtal", },
>> + { .fw_name = "fdiv2p5", },
>> + { .fw_name = "fdiv4", },
>> + { .fw_name = "fdiv3", },
>> + { .fw_name = "fdiv5", },
>> + { .fw_name = "fdiv2", },
>> + { .fw_name = "gp2", },
>> + { .fw_name = "hifi", }
> hifi isn't in the dt bindings. Should this be hifi0 and/or hifi1?
It should be hifi0，I will fix it in the next version.
Thank you for pointing it out.
[......]
>> +
>> +static struct clk_regmap a9_sc = {
>> + .data = &(struct clk_regmap_div_data) {
>> + .offset = SC_CLK_CTRL,
>> + .shift = 16,
>> + .width = 4,
>> + },
>> + .hw.init = &(struct clk_init_data) {
>> + .name = "sc",
>> + .ops = &clk_regmap_divider_ops,
>> + .parent_hws = (const struct clk_hw *[]) {
>> + &a9_sc_pre.hw
>> + },
>> + .num_parents = 1,
>> + .flags = CLK_SET_RATE_PARENT,
>> + },
> You can use CLK_HW_INIT_HWS() here.
>
> Brian
Ok, I will use CLK_HW_INIT_HWS instead, and the same below.
Best regards,
Jian
^ permalink raw reply
* Re: [PATCH v4 02/15] mm: Make empty_zero_page __ro_after_init
From: Mike Rapoport @ 2026-05-13 8:50 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Jann Horn, Ard Biesheuvel, linux-arm-kernel, linux-kernel,
Will Deacon, Catalin Marinas, Mark Rutland, Ryan Roberts,
Anshuman Khandual, Liz Prucka, Seth Jenkins, Kees Cook,
David Hildenbrand, Andrew Morton, linux-mm, linux-hardening
In-Reply-To: <fb5749bb-bc87-4f0b-9ec9-8a1eb7ded3b5@app.fastmail.com>
On Tue, May 12, 2026 at 02:56:16PM +0200, Ard Biesheuvel wrote:
> On Mon, 11 May 2026, at 16:40, Jann Horn wrote:
> > On Mon, May 11, 2026 at 10:59 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> >> I think we should simply do something along the lines of the below,
> >> considering that the size of a data object tends to correlate with
> >> its minimum alignment.
> >>
> >> I do find it rather puzzling that the compiler emits empty_zero_page
> >> *after* zero_page_pfn - ideally, we'd combine the below with
> >> -fdata-sections so that the linker sees all individual objects, but
> >> I suspect that would create some problems elsewhere.
> >>
> >>
> >> --- a/include/asm-generic/vmlinux.lds.h
> >> +++ b/include/asm-generic/vmlinux.lds.h
> >> @@ -452,7 +452,7 @@
> >> #define RO_AFTER_INIT_DATA \
> >> . = ALIGN(8); \
> >> __start_ro_after_init = .; \
> >> - *(.data..ro_after_init) \
> >> + *(SORT_BY_ALIGNMENT(.data..ro_after_init)) \
> >
> > Oh, neat, I didn't realize that's possible. That seems like a nicer
> > approach...
>
> Neat but rather ineffective, unfortunately. (I don't see a size
> difference with the arm64 defconfig kernel)
>
> Given that empty_zero_page only ever gets its address taken, we
> might just move it into the linker script if that requires tweaking
> anyway. We can just place it at the start of .rodata, which is
> already page aligned on most architectures (and will become page
> aligned unless EMPTY_ZERO_PAGE is #define'd by the arch linker
> script to something else)
>
>
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -472,6 +472,17 @@
> #endif
> #endif
>
> +#ifndef EMPTY_ZERO_PAGE
> +#ifndef __HAVE_COLOR_ZERO_PAGE
I don't think we want let architectures that don't use colored zero pages
redefine it.
If it will be really required we can add the ability to redefine
EMPTY_ZERO_PAGE later.
> +#define EMPTY_ZERO_PAGE \
> + . = ALIGN(PAGE_SIZE); \
> + empty_zero_page = .; \
> + . += PAGE_SIZE;
> +#else
> +#define EMPTY_ZERO_PAGE
> +#endif
> +#endif
> +
> /*
> * Read only Data
> */
> @@ -479,6 +490,7 @@
> . = ALIGN((align)); \
> .rodata : AT(ADDR(.rodata) - LOAD_OFFSET) { \
> __start_rodata = .; \
> + EMPTY_ZERO_PAGE \
> *(.rodata) *(.rodata.*) *(.data.rel.ro*) \
> SCHED_DATA \
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH net-next v6 04/12] net: airoha: Move airoha_qdma pointer in airoha_gdm_dev struct
From: Lorenzo Bianconi @ 2026-05-13 8:45 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Christian Marangi, Benjamin Larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree, Xuegang Lu
In-Reply-To: <20260511-airoha-eth-multi-serdes-v6-4-c899462c4f75@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 18121 bytes --]
On May 11, Lorenzo Bianconi wrote:
> Move airoha_qdma pointer from airoha_gdm_port struct to airoha_gdm_dev
> one since the QDMA block used depends on the particular net_device
> WAN/LAN configuration and in the current codebase net_device pointer is
> associated to airoha_gdm_dev struct.
> This is a preliminary patch to support multiple net_devices connected
> to the same GDM{3,4} port via an external hw arbiter.
>
> Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 105 +++++++++++++++----------------
> drivers/net/ethernet/airoha/airoha_eth.h | 9 ++-
> drivers/net/ethernet/airoha/airoha_ppe.c | 17 ++---
> 3 files changed, 64 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 18a89de4d58a..e0cd401bbf67 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -71,9 +71,10 @@ static void airoha_qdma_irq_disable(struct airoha_irq_bank *irq_bank,
> airoha_qdma_set_irqmask(irq_bank, index, mask, 0);
> }
>
> -static void airoha_set_macaddr(struct airoha_gdm_port *port, const u8 *addr)
> +static void airoha_set_macaddr(struct airoha_gdm_dev *dev, const u8 *addr)
> {
> - struct airoha_eth *eth = port->qdma->eth;
> + struct airoha_gdm_port *port = dev->port;
> + struct airoha_eth *eth = dev->eth;
> u32 val, reg;
>
> reg = airoha_is_lan_gdm_port(port) ? REG_FE_LAN_MAC_H
> @@ -85,7 +86,7 @@ static void airoha_set_macaddr(struct airoha_gdm_port *port, const u8 *addr)
> airoha_fe_wr(eth, REG_FE_MAC_LMIN(reg), val);
> airoha_fe_wr(eth, REG_FE_MAC_LMAX(reg), val);
>
> - airoha_ppe_init_upd_mem(port);
> + airoha_ppe_init_upd_mem(dev);
> }
>
> static void airoha_set_gdm_port_fwd_cfg(struct airoha_eth *eth, u32 addr,
> @@ -101,10 +102,10 @@ static void airoha_set_gdm_port_fwd_cfg(struct airoha_eth *eth, u32 addr,
> FIELD_PREP(GDM_UCFQ_MASK, val));
> }
>
> -static int airoha_set_vip_for_gdm_port(struct airoha_gdm_port *port,
> - bool enable)
> +static int airoha_set_vip_for_gdm_port(struct airoha_gdm_dev *dev, bool enable)
> {
> - struct airoha_eth *eth = port->qdma->eth;
> + struct airoha_gdm_port *port = dev->port;
> + struct airoha_eth *eth = dev->eth;
> u32 vip_port;
>
> vip_port = eth->soc->ops.get_vip_port(port, port->nbq);
> @@ -858,10 +859,13 @@ static void airoha_qdma_wake_netdev_txqs(struct airoha_queue *q)
> if (!port)
> continue;
>
> - if (port->qdma != qdma)
> + dev = port->dev;
> + if (!dev)
> + continue;
> +
> + if (dev->qdma != qdma)
> continue;
>
> - dev = port->dev;
> for (j = 0; j < dev->dev->num_tx_queues; j++) {
> if (airoha_qdma_get_txq(qdma, j) != qid)
> continue;
> @@ -1562,9 +1566,10 @@ static void airoha_qdma_stop_napi(struct airoha_qdma *qdma)
> }
> }
>
> -static void airoha_update_hw_stats(struct airoha_gdm_port *port)
> +static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
> {
> - struct airoha_eth *eth = port->qdma->eth;
> + struct airoha_gdm_port *port = dev->port;
> + struct airoha_eth *eth = dev->eth;
> u32 val, i = 0;
>
> spin_lock(&port->stats.lock);
> @@ -1711,11 +1716,11 @@ static int airoha_dev_open(struct net_device *netdev)
> int err, len = ETH_HLEN + netdev->mtu + ETH_FCS_LEN;
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> struct airoha_gdm_port *port = dev->port;
> - struct airoha_qdma *qdma = port->qdma;
> + struct airoha_qdma *qdma = dev->qdma;
> u32 pse_port = FE_PSE_PORT_PPE1;
>
> netif_tx_start_all_queues(netdev);
> - err = airoha_set_vip_for_gdm_port(port, true);
> + err = airoha_set_vip_for_gdm_port(dev, true);
> if (err)
> return err;
>
> @@ -1751,11 +1756,11 @@ static int airoha_dev_stop(struct net_device *netdev)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> struct airoha_gdm_port *port = dev->port;
> - struct airoha_qdma *qdma = port->qdma;
> + struct airoha_qdma *qdma = dev->qdma;
> int i;
>
> netif_tx_disable(netdev);
> - airoha_set_vip_for_gdm_port(port, false);
> + airoha_set_vip_for_gdm_port(dev, false);
> for (i = 0; i < netdev->num_tx_queues; i++)
> netdev_tx_reset_subqueue(netdev, i);
>
> @@ -1781,21 +1786,21 @@ static int airoha_dev_stop(struct net_device *netdev)
> static int airoha_dev_set_macaddr(struct net_device *netdev, void *p)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> - struct airoha_gdm_port *port = dev->port;
> int err;
>
> err = eth_mac_addr(netdev, p);
> if (err)
> return err;
>
> - airoha_set_macaddr(port, netdev->dev_addr);
> + airoha_set_macaddr(dev, netdev->dev_addr);
>
> return 0;
> }
>
> -static int airoha_set_gdm2_loopback(struct airoha_gdm_port *port)
> +static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
> {
> - struct airoha_eth *eth = port->qdma->eth;
> + struct airoha_gdm_port *port = dev->port;
> + struct airoha_eth *eth = dev->eth;
> u32 val, pse_port, chan;
> int i, src_port;
>
> @@ -1840,7 +1845,7 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_port *port)
> __field_prep(SP_CPORT_MASK(val), FE_PSE_PORT_CDM2));
>
> for (i = 0; i < eth->soc->num_ppe; i++)
> - airoha_ppe_set_cpu_port(port, i, AIROHA_GDM2_IDX);
> + airoha_ppe_set_cpu_port(dev, i, AIROHA_GDM2_IDX);
>
> if (port->id == AIROHA_GDM4_IDX && airoha_is_7581(eth)) {
> u32 mask = FC_ID_OF_SRC_PORT_MASK(port->nbq);
> @@ -1860,9 +1865,9 @@ static int airoha_dev_init(struct net_device *netdev)
> int i;
>
> /* QDMA0 is used for lan ports while QDMA1 is used for WAN ports */
> - port->qdma = ð->qdma[!airoha_is_lan_gdm_port(port)];
> - dev->dev->irq = port->qdma->irq_banks[0].irq;
> - airoha_set_macaddr(port, netdev->dev_addr);
> + dev->qdma = ð->qdma[!airoha_is_lan_gdm_port(port)];
> + dev->dev->irq = dev->qdma->irq_banks[0].irq;
> + airoha_set_macaddr(dev, netdev->dev_addr);
>
> switch (port->id) {
> case AIROHA_GDM3_IDX:
> @@ -1871,7 +1876,7 @@ static int airoha_dev_init(struct net_device *netdev)
> if (!eth->ports[1]) {
> int err;
>
> - err = airoha_set_gdm2_loopback(port);
> + err = airoha_set_gdm2_loopback(dev);
> if (err)
> return err;
> }
> @@ -1881,8 +1886,7 @@ static int airoha_dev_init(struct net_device *netdev)
> }
>
> for (i = 0; i < eth->soc->num_ppe; i++)
> - airoha_ppe_set_cpu_port(port, i,
> - airoha_get_fe_port(port));
> + airoha_ppe_set_cpu_port(dev, i, airoha_get_fe_port(dev));
>
> return 0;
> }
> @@ -1894,7 +1898,7 @@ static void airoha_dev_get_stats64(struct net_device *netdev,
> struct airoha_gdm_port *port = dev->port;
> unsigned int start;
>
> - airoha_update_hw_stats(port);
> + airoha_update_hw_stats(dev);
> do {
> start = u64_stats_fetch_begin(&port->stats.syncp);
> storage->rx_packets = port->stats.rx_ok_pkts;
> @@ -1914,8 +1918,8 @@ static int airoha_dev_change_mtu(struct net_device *netdev, int mtu)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> struct airoha_gdm_port *port = dev->port;
> - struct airoha_eth *eth = port->qdma->eth;
> u32 len = ETH_HLEN + mtu + ETH_FCS_LEN;
> + struct airoha_eth *eth = dev->eth;
>
> airoha_fe_rmw(eth, REG_GDM_LEN_CFG(port->id),
> GDM_LONG_LEN_MASK,
> @@ -1989,10 +1993,10 @@ static u32 airoha_get_dsa_tag(struct sk_buff *skb, struct net_device *dev)
> #endif
> }
>
> -int airoha_get_fe_port(struct airoha_gdm_port *port)
> +int airoha_get_fe_port(struct airoha_gdm_dev *dev)
> {
> - struct airoha_qdma *qdma = port->qdma;
> - struct airoha_eth *eth = qdma->eth;
> + struct airoha_gdm_port *port = dev->port;
> + struct airoha_eth *eth = dev->eth;
>
> switch (eth->soc->version) {
> case 0x7583:
> @@ -2009,8 +2013,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> struct net_device *netdev)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> - struct airoha_gdm_port *port = dev->port;
> - struct airoha_qdma *qdma = port->qdma;
> + struct airoha_qdma *qdma = dev->qdma;
> u32 nr_frags, tag, msg0, msg1, len;
> struct airoha_queue_entry *e;
> struct netdev_queue *txq;
> @@ -2048,7 +2051,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> }
> }
>
> - fport = airoha_get_fe_port(port);
> + fport = airoha_get_fe_port(dev);
> msg1 = FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
> FIELD_PREP(QDMA_ETH_TXMSG_METER_MASK, 0x7f);
>
> @@ -2151,8 +2154,7 @@ static void airoha_ethtool_get_drvinfo(struct net_device *netdev,
> struct ethtool_drvinfo *info)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> - struct airoha_gdm_port *port = dev->port;
> - struct airoha_eth *eth = port->qdma->eth;
> + struct airoha_eth *eth = dev->eth;
>
> strscpy(info->driver, eth->dev->driver->name, sizeof(info->driver));
> strscpy(info->bus_info, dev_name(eth->dev), sizeof(info->bus_info));
> @@ -2165,7 +2167,7 @@ static void airoha_ethtool_get_mac_stats(struct net_device *netdev,
> struct airoha_gdm_port *port = dev->port;
> unsigned int start;
>
> - airoha_update_hw_stats(port);
> + airoha_update_hw_stats(dev);
> do {
> start = u64_stats_fetch_begin(&port->stats.syncp);
> stats->FramesTransmittedOK = port->stats.tx_ok_pkts;
> @@ -2205,7 +2207,7 @@ airoha_ethtool_get_rmon_stats(struct net_device *netdev,
> ARRAY_SIZE(hw_stats->rx_len) + 1);
>
> *ranges = airoha_ethtool_rmon_ranges;
> - airoha_update_hw_stats(port);
> + airoha_update_hw_stats(dev);
> do {
> int i;
>
> @@ -2225,18 +2227,17 @@ static int airoha_qdma_set_chan_tx_sched(struct net_device *netdev,
> const u16 *weights, u8 n_weights)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> - struct airoha_gdm_port *port = dev->port;
> int i;
>
> for (i = 0; i < AIROHA_NUM_TX_RING; i++)
> - airoha_qdma_clear(port->qdma, REG_QUEUE_CLOSE_CFG(channel),
> + airoha_qdma_clear(dev->qdma, REG_QUEUE_CLOSE_CFG(channel),
> TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i));
>
> for (i = 0; i < n_weights; i++) {
> u32 status;
> int err;
>
> - airoha_qdma_wr(port->qdma, REG_TXWRR_WEIGHT_CFG,
> + airoha_qdma_wr(dev->qdma, REG_TXWRR_WEIGHT_CFG,
> TWRR_RW_CMD_MASK |
> FIELD_PREP(TWRR_CHAN_IDX_MASK, channel) |
> FIELD_PREP(TWRR_QUEUE_IDX_MASK, i) |
> @@ -2244,13 +2245,12 @@ static int airoha_qdma_set_chan_tx_sched(struct net_device *netdev,
> err = read_poll_timeout(airoha_qdma_rr, status,
> status & TWRR_RW_CMD_DONE,
> USEC_PER_MSEC, 10 * USEC_PER_MSEC,
> - true, port->qdma,
> - REG_TXWRR_WEIGHT_CFG);
> + true, dev->qdma, REG_TXWRR_WEIGHT_CFG);
> if (err)
> return err;
> }
>
> - airoha_qdma_rmw(port->qdma, REG_CHAN_QOS_MODE(channel >> 3),
> + airoha_qdma_rmw(dev->qdma, REG_CHAN_QOS_MODE(channel >> 3),
> CHAN_QOS_MODE_MASK(channel),
> __field_prep(CHAN_QOS_MODE_MASK(channel), mode));
>
> @@ -2316,9 +2316,9 @@ static int airoha_qdma_get_tx_ets_stats(struct net_device *netdev, int channel,
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> struct airoha_gdm_port *port = dev->port;
>
> - u64 cpu_tx_packets = airoha_qdma_rr(port->qdma,
> + u64 cpu_tx_packets = airoha_qdma_rr(dev->qdma,
> REG_CNTR_VAL(channel << 1));
> - u64 fwd_tx_packets = airoha_qdma_rr(port->qdma,
> + u64 fwd_tx_packets = airoha_qdma_rr(dev->qdma,
> REG_CNTR_VAL((channel << 1) + 1));
> u64 tx_packets = (cpu_tx_packets - port->cpu_tx_packets) +
> (fwd_tx_packets - port->fwd_tx_packets);
> @@ -2582,17 +2582,16 @@ static int airoha_qdma_set_tx_rate_limit(struct net_device *netdev,
> u32 bucket_size)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> - struct airoha_gdm_port *port = dev->port;
> int i, err;
>
> for (i = 0; i <= TRTCM_PEAK_MODE; i++) {
> - err = airoha_qdma_set_trtcm_config(port->qdma, channel,
> + err = airoha_qdma_set_trtcm_config(dev->qdma, channel,
> REG_EGRESS_TRTCM_CFG, i,
> !!rate, TRTCM_METER_MODE);
> if (err)
> return err;
>
> - err = airoha_qdma_set_trtcm_token_bucket(port->qdma, channel,
> + err = airoha_qdma_set_trtcm_token_bucket(dev->qdma, channel,
> REG_EGRESS_TRTCM_CFG,
> i, rate, bucket_size);
> if (err)
> @@ -2642,11 +2641,11 @@ static int airoha_tc_htb_alloc_leaf_queue(struct net_device *netdev,
> return 0;
> }
>
> -static int airoha_qdma_set_rx_meter(struct airoha_gdm_port *port,
> +static int airoha_qdma_set_rx_meter(struct airoha_gdm_dev *dev,
> u32 rate, u32 bucket_size,
> enum trtcm_unit_type unit_type)
> {
> - struct airoha_qdma *qdma = port->qdma;
> + struct airoha_qdma *qdma = dev->qdma;
> int i;
>
> for (i = 0; i < ARRAY_SIZE(qdma->q_rx); i++) {
> @@ -2725,7 +2724,6 @@ static int airoha_dev_tc_matchall(struct net_device *netdev,
> {
> enum trtcm_unit_type unit_type = TRTCM_BYTE_UNIT;
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> - struct airoha_gdm_port *port = dev->port;
> u32 rate = 0, bucket_size = 0;
>
> switch (f->command) {
> @@ -2750,7 +2748,7 @@ static int airoha_dev_tc_matchall(struct net_device *netdev,
> fallthrough;
> }
> case TC_CLSMATCHALL_DESTROY:
> - return airoha_qdma_set_rx_meter(port, rate, bucket_size,
> + return airoha_qdma_set_rx_meter(dev, rate, bucket_size,
> unit_type);
> default:
> return -EOPNOTSUPP;
> @@ -2762,8 +2760,7 @@ static int airoha_dev_setup_tc_block_cb(enum tc_setup_type type,
> {
> struct net_device *netdev = cb_priv;
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> - struct airoha_gdm_port *port = dev->port;
> - struct airoha_eth *eth = port->qdma->eth;
> + struct airoha_eth *eth = dev->eth;
>
> if (!tc_can_offload(netdev))
> return -EOPNOTSUPP;
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index c78cabbec753..f1eea492217c 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -537,12 +537,12 @@ struct airoha_qdma {
>
> struct airoha_gdm_dev {
> struct airoha_gdm_port *port;
> + struct airoha_qdma *qdma;
> struct net_device *dev;
> struct airoha_eth *eth;
> };
>
> struct airoha_gdm_port {
> - struct airoha_qdma *qdma;
> struct airoha_gdm_dev *dev;
> int id;
> int nbq;
> @@ -666,19 +666,18 @@ static inline bool airoha_is_7583(struct airoha_eth *eth)
> return eth->soc->version == 0x7583;
> }
>
> -int airoha_get_fe_port(struct airoha_gdm_port *port);
> +int airoha_get_fe_port(struct airoha_gdm_dev *dev);
> bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
> struct airoha_gdm_dev *dev);
>
> -void airoha_ppe_set_cpu_port(struct airoha_gdm_port *port, u8 ppe_id,
> - u8 fport);
> +void airoha_ppe_set_cpu_port(struct airoha_gdm_dev *dev, u8 ppe_id, u8 fport);
> bool airoha_ppe_is_enabled(struct airoha_eth *eth, int index);
> void airoha_ppe_check_skb(struct airoha_ppe_dev *dev, struct sk_buff *skb,
> u16 hash, bool rx_wlan);
> int airoha_ppe_setup_tc_block_cb(struct airoha_ppe_dev *dev, void *type_data);
> int airoha_ppe_init(struct airoha_eth *eth);
> void airoha_ppe_deinit(struct airoha_eth *eth);
> -void airoha_ppe_init_upd_mem(struct airoha_gdm_port *port);
> +void airoha_ppe_init_upd_mem(struct airoha_gdm_dev *dev);
> u32 airoha_ppe_get_total_num_entries(struct airoha_ppe *ppe);
> struct airoha_foe_entry *airoha_ppe_foe_get_entry(struct airoha_ppe *ppe,
> u32 hash);
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index af7af4097b98..22f5f1bae730 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> @@ -84,9 +84,9 @@ static u32 airoha_ppe_get_timestamp(struct airoha_ppe *ppe)
> AIROHA_FOE_IB1_BIND_TIMESTAMP);
> }
>
> -void airoha_ppe_set_cpu_port(struct airoha_gdm_port *port, u8 ppe_id, u8 fport)
> +void airoha_ppe_set_cpu_port(struct airoha_gdm_dev *dev, u8 ppe_id, u8 fport)
> {
> - struct airoha_qdma *qdma = port->qdma;
> + struct airoha_qdma *qdma = dev->qdma;
> struct airoha_eth *eth = qdma->eth;
> u8 qdma_id = qdma - ð->qdma[0];
> u32 fe_cpu_port;
> @@ -180,8 +180,8 @@ static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> if (!port)
> continue;
>
> - airoha_ppe_set_cpu_port(port, i,
> - airoha_get_fe_port(port));
> + airoha_ppe_set_cpu_port(port->dev, i,
> + airoha_get_fe_port(port->dev));
> }
> }
> }
> @@ -1473,11 +1473,12 @@ void airoha_ppe_check_skb(struct airoha_ppe_dev *dev, struct sk_buff *skb,
> airoha_ppe_foe_insert_entry(ppe, skb, hash, rx_wlan);
> }
>
> -void airoha_ppe_init_upd_mem(struct airoha_gdm_port *port)
> +void airoha_ppe_init_upd_mem(struct airoha_gdm_dev *dev)
> {
> - struct airoha_eth *eth = port->qdma->eth;
> - struct net_device *dev = port->dev->dev;
> - const u8 *addr = dev->dev_addr;
> + struct airoha_gdm_port *port = dev->port;
> + struct net_device *netdev = dev->dev;
> + struct airoha_eth *eth = dev->eth;
> + const u8 *addr = netdev->dev_addr;
> u32 val;
>
> val = (addr[2] << 24) | (addr[3] << 16) | (addr[4] << 8) | addr[5];
>
> --
> 2.54.0
>
Commenting on sashiko's report:
https://sashiko.dev/#/patchset/20260511-airoha-eth-multi-serdes-v6-0-c899462c4f75%40kernel.org
- This isn't a regression introduced by this patch, but is it safe to use
spin_lock() here instead of spin_lock_bh()?
- According to my understanding ndo_get_stats64 callback can't run softirq
context.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: Marc Zyngier @ 2026-05-13 8:42 UTC (permalink / raw)
To: Paolo Bonzini
Cc: David Woodhouse, Jonathan Corbet, Shuah Khan, kvm, linux-doc,
linux-kernel, Sean Christopherson, Jim Mattson, Oliver Upton,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Will Deacon, Raghavendra Rao Ananta, Eric Auger, Kees Cook,
Arnd Bergmann, Nathan Chancellor, linux-arm-kernel, kvmarm,
linux-kselftest
In-Reply-To: <baff82ca-6321-4b16-aa61-b2d6d60b6535@redhat.com>
On Mon, 11 May 2026 17:56:15 +0100,
Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 5/11/26 18:38, David Woodhouse wrote:
> > Not *everything* is in CPUID; one recent exception that comes to mind
> > is the SUPPRESS_EOI_BROADCAST quirk. But on x86 we preserve the
> > existing behaviour of older kernels — even when that behaviour doesn't
> > make much sense, as with SUPPRESS_EOI_BROADCAST where older KVM would
> > *advertise* the feature, but not actually *implement* it. Nevertheless,
> > that remains the default behaviour of future kernels unless userspace
> > explicitly opts in to fully enable (or disable) the feature.
> >
> > But this documentation update isn't even asking for that compatible-by-
> > default behaviour, even though that is the right thing to do. It's only
> > asking that it be *possible* to reinstate the old behaviour, for
> > userspace that *knows* about the change and explicitly wants to go back
> > to the old way to remain compatible.
>
> Yep, these are the "quirks"---if it's too early for Arm to commit to
> that, I guess it's fine.
Compatible by default means nothing, because userspace needs to
discover the combined capabilities of the host and KVM. This is not a
"CPU model" architecture.
If userspace is not a total joke, it will read all the ID registers,
and configure what it wants to see, assuming it is a feature that can
be configured (not everything can, because the architecture itself is
not fully backward compatible).
Yes, this is buggy at times, because the combinatorial explosion of
CPU capabilities and supported features makes it pretty hard to test
(and really nobody actually does). But overall, it works, and QEMU is
growing an infrastructure to manage it in a "user friendly" way.
But really, this isn't what David is asking. He's demanding "bug for
bug" compatibility. For that, we have two possible cases:
- this is a behaviour that, while undesirable, is allowed by the
architecture: fine, we preserve the behaviour and add another way to
expose the one we really want. it is ugly, but we manage.
- this is a behaviour that is not allowed by the architecture: we fix
it for good. We do that on every release. Some minor, some much more
visible. And there is no way we will add this sort of "bring the
bugs back" type of behaviours. Specially when it is really obvious
that no SW can make any reasonable use of the defect. We allow
userspace to keep behaving as before, but the guest will not see a
non-compliant behaviour.
That being said, there is a way out of that: convince people in charge
of the architecture that the non-compliant KVM behaviour is actually
valuable, and deserves to be tolerated. This has happened before (VHE
only and NV2 only, just to name two recent changes).
Other terrible hacks (such as GICv3's GICD_TYPER.num_LPIs which KVM
doesn't support) were added at the request of cloud vendors that David
might be familiar with, so it isn't like it is a brand new process.
And once it is in the architecture, it becomes a behaviour that is
allowed to be exposed to a guest, for better or worse.
These are the rules we have followed since we started KVM/arm, and I
intend to stick to them.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 0/2] Khadas VIM4 PWM status LED support
From: Neil Armstrong @ 2026-05-13 8:29 UTC (permalink / raw)
To: linux-kernel-dev, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel
In-Reply-To: <20260512-add-kvim4-sysled-v1-0-7178719a43e7@aliel.fr>
On 5/12/26 19:47, Ronald Claveau via B4 Relay wrote:
> This series adds support for the PWM-driven status LED on the Khadas
> VIM4 board (Amlogic T7).
>
> The VIM4 exposes a heartbeat LED wired to the PWM_AO_C output, routed
> through pin group pwm_ao_c_d. Before wiring it up in the board DTS,
> the SoC pinmux definitions had to be corrected: the original
> pwm_ao_c node was conflating two distinct pin groups (pwm_ao_c_d and
> pwm_ao_c_e) into a single ambiguous entry.
>
> Patch 1 fixes the pwm_ao_c pinmux entries in the T7 DTSI by splitting
> them into two properly named nodes. Neither alternate is in use yet,
> so there is no functional impact on existing boards.
>
> Patch 2 enables the pwm_ao_cd controller on the VIM4 and adds a
> pwm-leds node with a heartbeat trigger. The xtal-clk node is also
> moved to restore alphabetical ordering among root node children.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> Ronald Claveau (2):
> arm64: dts: amlogic: t7: Fix pwm_ao_c pinmux definitions
> arm64: dts: amlogic: t7: khadas-vim4: add PWM-driven status LED
>
> .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 30 +++++++++++++++++-----
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 12 +++++++--
> 2 files changed, 33 insertions(+), 9 deletions(-)
> ---
> base-commit: 31f32e8cdf59291e467250dfc57d1a8c718f63d2
> change-id: 20260512-add-kvim4-sysled-8cc159524561
>
> Best regards,
Squashed patch 1 on ee6e05a49b93 ("arm64: dts: amlogic: t7: Add PWM pinctrl nodes")
Neil
^ permalink raw reply
* [PATCH v5 09/10] drm/bridge: analogix_dp: Add support for RK3576
From: Damon Ding @ 2026-05-13 7:44 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260513074414.2053435-1-damon.ding@rock-chips.com>
Add RK3576_EDP device type entry and extend Rockchip check
to match existing hardware capabilities shared with RK3588.
Set identical maximum link rate and lane count parameters
for RK3576 eDP controller to reuse existing RK3588 config.
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v3:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
include/drm/bridge/analogix_dp.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 116de3bd83a3..c8eb3511f92a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1249,6 +1249,7 @@ static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
video_info->max_link_rate = 0x0A;
video_info->max_lane_count = 0x04;
break;
+ case RK3576_EDP:
case RK3588_EDP:
video_info->max_link_rate = 0x14;
video_info->max_lane_count = 0x04;
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 7b670dd769e9..0e0b87abee59 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -16,6 +16,7 @@ enum analogix_dp_devtype {
EXYNOS_DP,
RK3288_DP,
RK3399_EDP,
+ RK3576_EDP,
RK3588_EDP,
};
@@ -24,6 +25,7 @@ static inline bool analogix_dp_is_rockchip(enum analogix_dp_devtype type)
switch (type) {
case RK3288_DP:
case RK3399_EDP:
+ case RK3576_EDP:
case RK3588_EDP:
return true;
default:
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] coresight: trbe: Hide enable_sink sysfs file
From: Leo Yan @ 2026-05-13 8:15 UTC (permalink / raw)
To: James Clark
Cc: Suzuki K Poulose, Mike Leach, Alexander Shishkin, coresight,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260507-james-cs-hide-trbe-enable-v1-1-b4e40439f44c@linaro.org>
On Thu, May 07, 2026 at 11:53:45AM +0100, James Clark wrote:
[...]
> +static umode_t coresight_attr_is_visible(struct kobject *kobj,
> + struct attribute *attr, int n)
> {
> struct device *dev = kobj_to_dev(kobj);
> + struct coresight_device *csdev = to_coresight_device(dev);
>
> if (attr == &dev_attr_label.attr) {
> if (fwnode_property_present(dev_fwnode(dev), "label"))
> return attr->mode;
> else
> return 0;
> + } else if (attr == &dev_attr_enable_sink.attr ||
> + attr == &dev_attr_enable_source.attr) {
> + if (csdev->no_sysfs_mode)
> + return 0;
> + else
> + return attr->mode;
I'd prefer no_sysfs_mode to work as a general flag rather than being
limited to sink/source devices only. Otherwise, LGTM.
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: amlogic: t7: khadas-vim4: add PWM-driven status LED
From: Neil Armstrong @ 2026-05-13 8:05 UTC (permalink / raw)
To: linux-kernel-dev, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel
In-Reply-To: <20260512-add-kvim4-sysled-v1-2-7178719a43e7@aliel.fr>
On 5/12/26 19:47, Ronald Claveau via B4 Relay wrote:
> From: Ronald Claveau <linux-kernel-dev@aliel.fr>
>
> The VIM4 board exposes a status LED wired to the PWM_AO_C_D output.
> Enable the pwm_ao_cd controller with its pinmux, and declare a
> pwm-leds node with a heartbeat trigger.
>
> Also, move the xtal-clk node to restore alphabetical ordering.
Please send a separate patch for that
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 30 +++++++++++++++++-----
> 1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> index 69d6118ba57e7..c41525a34b721 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> @@ -45,13 +45,6 @@ secmon_reserved_bl32: secmon@5300000 {
> };
> };
>
> - xtal: xtal-clk {
> - compatible = "fixed-clock";
> - clock-frequency = <24000000>;
> - clock-output-names = "xtal";
> - #clock-cells = <0>;
> - };
> -
> dc_in: regulator-dc-in {
> compatible = "regulator-fixed";
> regulator-name = "DC_IN";
> @@ -60,6 +53,16 @@ dc_in: regulator-dc-in {
> regulator-always-on;
> };
>
> + pwm-leds {
> + compatible = "pwm-leds";
> +
> + status {
> + linux,default-trigger="heartbeat";
> + max-brightness = <255>;
> + pwms = <&pwm_ao_cd 0 30040 0>;
> + };
> + };
> +
> sd_3v3: regulator-sdcard-3v3 {
> compatible = "regulator-fixed";
> regulator-name = "SD_3V3";
> @@ -155,6 +158,13 @@ wifi32k: wifi32k {
> clock-frequency = <32768>;
> pwms = <&pwm_ab 0 30518 0>;
> };
> +
> + xtal: xtal-clk {
> + compatible = "fixed-clock";
> + clock-frequency = <24000000>;
> + clock-output-names = "xtal";
> + #clock-cells = <0>;
> + };
> };
>
> &pwm_ab {
> @@ -163,6 +173,12 @@ &pwm_ab {
> pinctrl-names = "default";
> };
>
> +&pwm_ao_cd {
> + status = "okay";
> + pinctrl-0 = <&pwm_ao_c_d_pins>;
> + pinctrl-names = "default";
> +};
> +
> /* SDIO */
> &sd_emmc_a {
> status = "okay";
>
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: amlogic: t7: Fix pwm_ao_c pinmux definitions
From: Neil Armstrong @ 2026-05-13 8:04 UTC (permalink / raw)
To: linux-kernel-dev, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel
In-Reply-To: <20260512-add-kvim4-sysled-v1-1-7178719a43e7@aliel.fr>
On 5/12/26 19:47, Ronald Claveau via B4 Relay wrote:
> From: Ronald Claveau <linux-kernel-dev@aliel.fr>
>
> The pwm_ao_c pin node was incomplete: it was missing the group name
> suffix, conflating two distinct pin groups (pwm_ao_c_d and pwm_ao_c_e)
> into a single, ambiguous entry.
>
> Split the node into two separate pinmux entries:
> - pwm_ao_c_d_pins: uses group "pwm_ao_c_d"
> - pwm_ao_c_e_pins: uses group "pwm_ao_c_e"
>
> Both alternate pins are not yet referenced by any peripheral node,
> so this has no functional impact on existing boards. No backport needed.
>
> Fixes: ee6e05a49b93 ("arm64: dts: amlogic: t7: Add PWM pinctrl nodes")
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 7fe72c94ed623..62f6b9baad28b 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -400,9 +400,17 @@ mux {
> };
> };
>
> - pwm_ao_c_pins: pwm-ao-c {
> + pwm_ao_c_d_pins: pwm-ao-c-d {
> mux {
> - groups = "pwm_ao_c";
> + groups = "pwm_ao_c_d";
> + function = "pwm_ao_c";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_c_e_pins: pwm-ao-c-e {
> + mux {
> + groups = "pwm_ao_c_e";
> function = "pwm_ao_c";
> bias-disable;
> };
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
I'll squash it on the old commit.
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v5 4/6] dt-bindings: display: mediatek: tdshp: Add support for MT8196
From: CK Hu (胡俊光) @ 2026-05-13 8:03 UTC (permalink / raw)
To: matthias.bgg@gmail.com, tzimmermann@suse.de, simona@ffwll.ch,
chunkuang.hu@kernel.org, AngeloGioacchino Del Regno,
Jay Liu (刘博), airlied@gmail.com, krzk+dt@kernel.org,
robh@kernel.org, p.zabel@pengutronix.de,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
conor+dt@kernel.org
Cc: dri-devel@lists.freedesktop.org,
linux-mediatek@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260427112131.23423-5-jay.liu@mediatek.com>
On Mon, 2026-04-27 at 19:20 +0800, Jay Liu wrote:
> Add tdshp hardware description for MediaTek MT8196 SoC
>
> Signed-off-by: Jay Liu <jay.liu@mediatek.com>
> ---
> .../display/mediatek/mediatek,tdshp.yaml | 46 +++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,tdshp.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,tdshp.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,tdshp.yaml
> new file mode 100644
> index 000000000000..50b24cc22420
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,tdshp.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: https://urldefense.com/v3/__http://devicetree.org/schemas/display/mediatek/mediatek,tdshp.yaml*__;Iw!!CTRNKA9wMg0ARbw!jvLiL6w7ScJqhkM0IyiLok4cwzb-e1gME-mO9r5lLT3JTrgaBBiiV1j8LFkmJkIafaGiBya2GJN6h38e$
> +$schema: https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!jvLiL6w7ScJqhkM0IyiLok4cwzb-e1gME-mO9r5lLT3JTrgaBBiiV1j8LFkmJkIafaGiBya2GCPflrFz$
> +
> +title: MediaTek display 2D sharpness processor
> +
> +maintainers:
> + - Chun-Kuang Hu <chunkuang.hu@kernel.org>
> + - Philipp Zabel <p.zabel@pengutronix.de>
> +
> +description: |
> + MediaTek display 2D sharpness processor, namely TDSHP, provides a
a -> an
> + operation used to adjust sharpness in display system.
> +
> +properties:
> + compatible:
> + enum:
> + - mediatek,mt8196-disp-tdshp
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
Refer to other display block binding document, and find out the common property.
Such as power-domains, gce-client-reg, ports.
Regards,
CK
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + tdshp@321e0000 {
> + compatible = "mediatek,mt8196-disp-tdshp";
> + reg = <0 0x321e0000 0 0x1000>;
> + clocks = <&dispsys_config_clk 107>;
> + };
> + };
^ permalink raw reply
* RE: [PATCH] clk: imx: Add audio PLL debugfs for K-divider control
From: Jacky Bai @ 2026-05-13 8:01 UTC (permalink / raw)
To: Frank Li
Cc: Abel Vesa, Peng Fan, Michael Turquette, Stephen Boyd,
Brian Masney, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-clk@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <agNDbQsJn2jcnA9q@lizhi-Precision-Tower-5810>
> Subject: Re: [PATCH] clk: imx: Add audio PLL debugfs for K-divider control
>
> On Tue, May 12, 2026 at 05:08:10PM +0800, Jacky Bai wrote:
> > Add debugfs support for runtime tuning of the audio PLL K divider,
> > which enables fine-grained frequency adjustments for audio PLL.
> > This is used for:
> > - Audio clock calibration and testing
> > - Debugging audio synchronization issues
> >
> > Two debug interfaces are exported to userspace:
> > - delta_k: It is used to adjust the K divider in PLL based on small
> > steps
> > - pll_parameter: It is used for get PLL's current M-divider,
> > P-divider, S-divider & K-divider setting in PLL register
> >
> > examples for the usage of the two interfaces:
> > 1): Get the current PLL setting of dividers
> > cat /sys/kernel/debug/audio_pll_monitor/audio_pll1/pll_parameter
> >
> > 2): if want to adjust the K-divider by a delta_k '1', then
> > echo 1 > /sys/kernel/debug/audio_pll_monitor/audio_pll1/delta_k;
> >
> > 3): if want to adjust the K-divider by a delta_k '-1', then
> > echo -1 > /sys/kernel/debug/audio_pll_monitor/audio_pll1/delta_k;
>
> Nit: needn't example, it is basic usage mode for debugfs.
>
will drop it.
> >
> > Signed-off-by: Jacky Bai <ping.bai@nxp.com>
> > ---
> > drivers/clk/imx/clk-imx8mm.c | 6 ++++
> > drivers/clk/imx/clk-pll14xx.c | 79
> +++++++++++++++++++++++++++++++++++++++++++
> > drivers/clk/imx/clk.h | 1 +
> > 3 files changed, 86 insertions(+)
[...]
> > + * 3): if want to adjust the K-divider by a delta_k '-1', then
> > + * echo -1 >
> /sys/kernel/debug/audio_pll_monitor/audio_pll1/delta_k;
> > + */
>
> 2) and 3) keep one is enough, you better descript validate range for delta_k
> here, which is more valuable information.
>
Ok, will refine the comment in next version.
> > +#ifdef CONFIG_DEBUG_FS
> > +static int pll_delta_k_set(void *data, u64 val) {
> > + struct clk_pll14xx *pll = to_clk_pll14xx(data);
> > + s16 delta_k = (s16)val;
> > + u32 div_ctl1;
> > + s16 kdiv;
> > +
> > + div_ctl1 = readl_relaxed(pll->base + DIV_CTL1);
> > + kdiv = FIELD_GET(KDIV_MASK, div_ctl1) + delta_k;
> > + writel_relaxed(FIELD_PREP(KDIV_MASK, kdiv), pll->base + DIV_CTL1);
> > +
> > + return 0;
> > +}
> > +DEFINE_DEBUGFS_ATTRIBUTE_SIGNED(delta_k_fops, NULL,
> pll_delta_k_set,
> > +"%lld\n");
>
> generally, better also provide read for delta_k
>
> cat /sys/kernel/debug/audio_pll_monitor/audio_pll1/delta_k because user
> want to check value by read it back naturally.
>
Thx, will add it.
BR
> Frank
> > +
> > +static int pll_setting_show(struct seq_file *s, void *data) {
> > + struct clk_pll14xx *pll = to_clk_pll14xx(s->private);
> > + u32 div_ctl0, div_ctl1;
> > + u32 mdiv, pdiv, sdiv, kdiv;
> > +
> > + div_ctl0 = readl_relaxed(pll->base + DIV_CTL0);
> > + div_ctl1 = readl_relaxed(pll->base + DIV_CTL1);
> > +
> > + mdiv = FIELD_GET(MDIV_MASK, div_ctl0);
> > + pdiv = FIELD_GET(PDIV_MASK, div_ctl0);
> > + sdiv = FIELD_GET(SDIV_MASK, div_ctl0);
> > + kdiv = FIELD_GET(KDIV_MASK, div_ctl1);
> > +
> > + seq_printf(s, "Mdiv: 0x%x; Pdiv: 0x%x; Sdiv: 0x%x; Kdiv: 0x%x\n",
> > + mdiv, pdiv, sdiv, kdiv);
> > +
> > + return 0;
> > +}
> > +DEFINE_SHOW_ATTRIBUTE(pll_setting);
> > +
> > +void audio_pll_debug_init(struct clk_hw *hws[], unsigned int
> > +num_plls) {
> > + struct dentry *rootdir, *audio_pll_dir;
> > + const char *pll_name;
> > + int i;
> > +
> > + rootdir = debugfs_create_dir("audio_pll_monitor", NULL);
> > +
> > + for (i = 0; i < num_plls; i++) {
> > + pll_name = clk_hw_get_name(hws[i]);
> > + audio_pll_dir = debugfs_create_dir(pll_name, rootdir);
> > + debugfs_create_file_unsafe("delta_k", 0200, audio_pll_dir,
> > + hws[i], &delta_k_fops);
> > + debugfs_create_file("pll_parameter", 0444, audio_pll_dir,
> > + hws[i], &pll_setting_fops);
> > + }
> > +}
> > +#else /* !CONFIG_DEBUG_FS */
> > +void audio_pll_debug_init(struct clk_hw *hws[], unsigned int
> > +num_plls) { } #endif /* CONFIG_DEBUG_FS */
> > +EXPORT_SYMBOL_GPL(audio_pll_debug_init);
> > diff --git a/drivers/clk/imx/clk.h b/drivers/clk/imx/clk.h index
> >
> aa5202f284f3d1b7c1b4bf65e2329831832b43a5..9611ab127dad6f23770c18e
> 22e1a
> > cbe2fc22bd4e 100644
> > --- a/drivers/clk/imx/clk.h
> > +++ b/drivers/clk/imx/clk.h
> > @@ -487,4 +487,5 @@ struct clk_hw *imx_clk_gpr_mux(const char *name,
> const char *compatible,
> > u32 reg, const char **parent_names,
> > u8 num_parents, const u32 *mux_table, u32 mask);
> >
> > +void audio_pll_debug_init(struct clk_hw **hws, unsigned int
> > +num_plls);
> > #endif
> >
> > ---
> > base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
> > change-id: 20260421-imx8m_pll_debugfs-246d0fbbb617
> >
> > Best regards,
> > --
> > Jacky Bai <ping.bai@nxp.com>
> >
^ permalink raw reply
* Re: [PATCH v7 09/20] KVM: arm64: Set up MDCR_EL2 to handle a Partitioned PMU
From: Oliver Upton @ 2026-05-13 7:57 UTC (permalink / raw)
To: Colton Lewis
Cc: kvm, Alexandru Elisei, Paolo Bonzini, Jonathan Corbet,
Russell King, Catalin Marinas, Will Deacon, Marc Zyngier,
Oliver Upton, Mingwei Zhang, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Mark Rutland, Shuah Khan, Ganapatrao Kulkarni,
James Clark, linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest
In-Reply-To: <20260504211813.1804997-10-coltonlewis@google.com>
On Mon, May 04, 2026 at 09:18:02PM +0000, Colton Lewis wrote:
> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> index 3ad6b7c6e4ba7..0ab89c91e19cb 100644
> --- a/arch/arm64/kvm/debug.c
> +++ b/arch/arm64/kvm/debug.c
> @@ -36,20 +36,43 @@ static int cpu_has_spe(u64 dfr0)
> */
> static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu)
> {
> + int hpmn = kvm_pmu_hpmn(vcpu);
> +
> preempt_disable();
>
> /*
> * This also clears MDCR_EL2_E2PB_MASK and MDCR_EL2_E2TB_MASK
> * to disable guest access to the profiling and trace buffers
> */
> - vcpu->arch.mdcr_el2 = FIELD_PREP(MDCR_EL2_HPMN,
> - *host_data_ptr(nr_event_counters));
> +
> + vcpu->arch.mdcr_el2 = FIELD_PREP(MDCR_EL2_HPMN, hpmn);
> vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
> MDCR_EL2_TPMS |
> MDCR_EL2_TTRF |
> MDCR_EL2_TPMCR |
> MDCR_EL2_TDRA |
> - MDCR_EL2_TDOSA);
> + MDCR_EL2_TDOSA |
> + MDCR_EL2_HPME);
> +
> + if (kvm_vcpu_pmu_is_partitioned(vcpu)) {
> + /*
> + * Filtering these should be redundant because we trap
> + * all the TYPER and FILTR registers anyway and ensure
> + * they filter EL2, but set the bits if they are here.
> + */
> + if (is_pmuv3p1(read_pmuver()))
> + vcpu->arch.mdcr_el2 |= MDCR_EL2_HPMD;
> + if (is_pmuv3p5(read_pmuver()))
> + vcpu->arch.mdcr_el2 |= MDCR_EL2_HCCD;
Neither of these controls are of any consequence on unsupported
hardware (RES0). Set them unconditionally?
> + /*
> + * Take out the coarse grain traps if we are using
> + * fine grain traps.
> + */
> + if (kvm_vcpu_pmu_use_fgt(vcpu))
I think open coding the check here would actually improve readability.
if (cpus_have_final_cap(ARM64_HAS_FGT) &&
(cpus_have_final_cap(ARM64_HAS_HPMN0) ||
vcpu->kvm->arch.nr_pmu_counters != 0))
vcpu->arch.mdcr_el2 &= ~(MDCR_EL2_TPM | MDCR_EL2_TPMCR);
> +
> +/**
> + * kvm_pmu_hpmn() - Calculate HPMN field value
> + * @vcpu: Pointer to struct kvm_vcpu
> + *
> + * Calculate the appropriate value to set for MDCR_EL2.HPMN. If
> + * partitioned, this is the number of counters set for the guest if
> + * supported, falling back to max_guest_counters if needed. If we are not
> + * partitioned or can't set the implied HPMN value, fall back to the
> + * host value.
> + *
> + * Return: A valid HPMN value
> + */
> +u8 kvm_pmu_hpmn(struct kvm_vcpu *vcpu)
> +{
> + u8 nr_guest_cntr = vcpu->kvm->arch.nr_pmu_counters;
> +
> + if (kvm_vcpu_pmu_is_partitioned(vcpu)
> + && !vcpu_on_unsupported_cpu(vcpu)
> + && (cpus_have_final_cap(ARM64_HAS_HPMN0) || nr_guest_cntr > 0))
> + return nr_guest_cntr;
> +
> + return *host_data_ptr(nr_event_counters);
> +}
This helper isn't helpful. Just open code it in the place where we are
computing MDCR_EL2.
> @@ -542,6 +542,13 @@ u8 kvm_arm_pmu_get_max_counters(struct kvm *kvm)
> if (cpus_have_final_cap(ARM64_WORKAROUND_PMUV3_IMPDEF_TRAPS))
> return 1;
>
> + /*
> + * If partitioned then we are limited by the max counters in
> + * the guest partition.
> + */
> + if (kvm_pmu_is_partitioned(arm_pmu))
> + return arm_pmu->max_guest_counters;
> +
Ok, this is exactly what I was getting at earlier. What about a VM with
an emulated PMU? It should use cntr_mask calculation, not the guest
range.
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH 03/15] dt-bindings: mfd: syscon: Add ti,am625-dss-dpi0-clk-ctrl compatible
From: Tomi Valkeinen @ 2026-05-13 7:55 UTC (permalink / raw)
To: Rob Herring
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra, Swamil Jain,
Devarsh Thakkar, Louis Chauvet, devicetree, dri-devel,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260505193538.GA3785056-robh@kernel.org>
Hi,
On 05/05/2026 22:35, Rob Herring wrote:
> On Mon, Apr 20, 2026 at 03:54:10PM +0300, Tomi Valkeinen wrote:
>> The DPI output pipeline in K3 SoCs contains the display subsystem (DSS)
>> which produces the in-SoC parallel video signal, and a DPI block which
>> adjusts the signal to the external MIPI DPI output.
>>
>> The DSS IP has registers to configure whether the data and sync signals
>> are driven on rising or falling clock edge, and on some SoCs these are
>> automatically conveyed to the DPI block which needs that configuration
>> to properly output the MIPI DPI signal.
>>
>> However, on some SoCs the DPI block configuration has to be done
>> manually, using an extra register outside the DSS, DPI0_CLK_CTRL in
>> MAIN_CTRL_MMR_CFG0 block, which controls the DPI block's behavior. Note
>> that while the register is named "CLK_CTRL", it's not really related to
>> clocks, but the sync and data signals.
>>
>> Currently the DPI0_CLK_CTRL is never written, so it's always 0, meaning
>> the data and sync are always driven on a rising clock edge regardless of
>> the DSS configuration.
>>
>> DPI0_CLK_CTRL register seems to be an independent "quirk" register,
>> inside MAIN_CTRL_MMR_CFG0 block, which contains general purpose system
>> registers. The registers surrounding DPI0_CLK_CTRL seem to be controlled
>> by the system firmware or linux clock drivers. So, it is just this
>> single register we can map, and we can't create a syscon node for the
>> whole (or big parts of) MAIN_CTRL_MMR_CFG0.
>>
>> I see two options to handle the register:
>>
>> 1) We could add that single register to the DSS binding as a new reg
>> block. That feels wrong, as it's not a DSS register.
>> 2) Add it as a syscon node, which can then be used by tidss driver.
>> It is a bit silly to create a syscon node for a single 32-bit
>> register, though.
>
> Is it really 1 register and nothing else in that h/w block? That's quite
> unusual.
It is just this one register that the DSS driver is interested in, and
that register is surrounded by registers used by other, unrelated,
drivers or the system firmware.
This has been discussed in some older threads, and to summarize:
The Soc has a so called CTRL_MMR (control memory-mapped-registers) area
at 0x100000, size 0x20000. It's a dumping ground for all kinds of system
integration registers. In the current binding, this has been just a
simple-bus, containing some sub-nodes (shortened version):
main_conf: bus@100000 {
compatible = "simple-bus";
reg = <0x00 0x00100000 0x00 0x20000>;
phy_gmii_sel: phy@4044 {
compatible = "ti,am654-phy-gmii-sel";
};
audio_refclk0: clock-controller@82e0 {
compatible = "ti,am62-audio-refclk";
};
dss_oldi_io_ctrl: dss-oldi-io-ctrl@8600 {
compatible = "ti,am625-dss-oldi-io-ctrl", "syscon";
};
};
There already was the dss-oldi-io-ctrl, so this new
am625-dss-dpi0-clk-ctrl was added the same way as we needed a syscon.
After some testing, changing the whole main_conf to a syscon seems to
work ok, even if inside it there are devices mapping parts of the same
memory area (although I'm not sure how to test all those devices). I
originally thought mapping the same memory area from two different
driers would immediately fail.
So, instead of adding a new special syscon node for this single
register, as done in this patch, I think we can just make the whole
main_conf a syscon, and point to it from the display subsystem node:
ti,dpi-io-ctrl = <&main_conf>;
Then the driver would need to access the register with offset 0x8300.
But I'm a bit reluctant to add such a SoC-integration related offset to
the driver. Even if the register would stay the same from SoC model to
another, the offset could change. So, we could, in the display subsystem
node, do:
ti,dpi-io-ctrl = <&main_conf 0x8300>;
The driver can use syscon_regmap_lookup_by_phandle_args() and thus get
the offset from the dts. I think this works ok, so I'll make that change
for v2 unless someone has better ideas.
Tomi
^ permalink raw reply
* [PATCH v5 08/10] drm/bridge: analogix_dp: Rename and simplify is_rockchip()
From: Damon Ding @ 2026-05-13 7:44 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260513074414.2053435-1-damon.ding@rock-chips.com>
Rename inline helper is_rockchip() to analogix_dp_is_rockchip()
to follow driver namespace convention consistently across code.
Replace chained equality comparisons with switch-case layout
to improve readability and simplify adding new SoC entries later.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Suggested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v3:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
.../gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +-
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 18 +++++++++---------
include/drm/bridge/analogix_dp.h | 11 +++++++++--
3 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 8cf6b73bceac..116de3bd83a3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -870,7 +870,7 @@ static int analogix_dp_bridge_atomic_check(struct drm_bridge *bridge,
struct drm_display_info *di = &conn_state->connector->display_info;
u32 mask = BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) | BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422);
- if (is_rockchip(dp->plat_data->dev_type)) {
+ if (analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
if ((di->color_formats & mask)) {
DRM_DEBUG_KMS("Swapping display color format from YUV to RGB\n");
di->color_formats &= ~mask;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 38fd8d5014d2..6207ded7ffd5 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -72,7 +72,7 @@ void analogix_dp_init_analog_param(struct analogix_dp_device *dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
reg = REF_CLK_24M;
if (dp->plat_data->dev_type == RK3288_DP)
reg ^= REF_CLK_MASK;
@@ -123,7 +123,7 @@ void analogix_dp_reset(struct analogix_dp_device *dp)
analogix_dp_stop_video(dp);
analogix_dp_enable_video_mute(dp, 0);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
reg = RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N |
SW_FUNC_EN_N;
else
@@ -233,7 +233,7 @@ void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool enable)
u32 mask = DP_PLL_PD;
u32 pd_addr = ANALOGIX_DP_PLL_CTL;
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
pd_addr = ANALOGIX_DP_PD;
mask = RK_PLL_PD;
}
@@ -254,12 +254,12 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
u32 mask;
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
phy_pd_addr = ANALOGIX_DP_PD;
switch (block) {
case AUX_BLOCK:
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
mask = RK_AUX_PD;
else
mask = AUX_PD;
@@ -317,7 +317,7 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
* to power off everything instead of DP_PHY_PD in
* Rockchip
*/
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
mask = DP_INC_BG;
else
mask = DP_PHY_PD;
@@ -329,7 +329,7 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
reg &= ~mask;
writel(reg, dp->reg_base + phy_pd_addr);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
usleep_range(10, 15);
break;
case POWER_ALL:
@@ -465,7 +465,7 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
analogix_dp_reset_aux(dp);
/* AUX_BIT_PERIOD_EXPECTED_DELAY doesn't apply to Rockchip IP */
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
reg = 0;
else
reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3);
@@ -837,7 +837,7 @@ void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp)
u32 reg;
reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
reg &= ~(RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N);
} else {
reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 854af692229b..7b670dd769e9 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -19,9 +19,16 @@ enum analogix_dp_devtype {
RK3588_EDP,
};
-static inline bool is_rockchip(enum analogix_dp_devtype type)
+static inline bool analogix_dp_is_rockchip(enum analogix_dp_devtype type)
{
- return type == RK3288_DP || type == RK3399_EDP || type == RK3588_EDP;
+ switch (type) {
+ case RK3288_DP:
+ case RK3399_EDP:
+ case RK3588_EDP:
+ return true;
+ default:
+ return false;
+ }
}
struct analogix_dp_plat_data {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 05/10] drm/rockchip: analogix_dp: Enable hclk for RK3588
From: Damon Ding @ 2026-05-13 7:44 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260513074414.2053435-1-damon.ding@rock-chips.com>
Acquire and enable the HCLK_VO1 bus clock explicitly for RK3588
eDP controller to guarantee register and datapath access.
The clock was previously enabled implicitly via rockchip,vo-grf
phandle reference, which relies on side effect and is fragile.
Fetch optional "hclk" clock in driver to align with updated device
tree binding and keep consistent with hardware clock dependency.
Fixes: 729f8eefdcad ("drm/rockchip: analogix_dp: Add support for RK3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 06072efd7fca..d2af5eb29dbb 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -311,6 +311,7 @@ static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
{
struct device *dev = dp->dev;
struct device_node *np = dev->of_node;
+ struct clk *clk;
dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
if (IS_ERR(dp->grf))
@@ -327,6 +328,11 @@ static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
return dev_err_probe(dev, PTR_ERR(dp->pclk),
"failed to get pclk property\n");
+ clk = devm_clk_get_optional_enabled(dev, "hclk");
+ if (IS_ERR(clk))
+ return dev_err_probe(dev, PTR_ERR(clk),
+ "failed to get hclk property\n");
+
dp->rst = devm_reset_control_get(dev, "dp");
if (IS_ERR(dp->rst))
return dev_err_probe(dev, PTR_ERR(dp->rst),
--
2.34.1
^ permalink raw reply related
* [PATCH v5 00/10] Add eDP support for RK3576
From: Damon Ding @ 2026-05-13 7:44 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
Patch 1-5 are to add missing clock "hclk" for RK3588 eDP nodes.
Patch 6-7 are to add the RK3576 eDP node.
Patch 8~10 are to support the RK3576 Analogix DP controller.
This series is followed by the [0] series.
[0] https://lore.kernel.org/all/20260409065301.446670-1-damon.ding@rock-chips.com/
Damon Ding (10):
dt-bindings: display: rockchip: analogix-dp: Fix hclk as third clock
for RK3588
dt-bindings: display: rockchip: analogix-dp: Add per-clock
descriptions
arm64: dts: rockchip: Add missing hclk for RK3588 eDP0
arm64: dts: rockchip: Add missing hclk for RK3588 eDP1
drm/rockchip: analogix_dp: Enable hclk for RK3588
dt-bindings: display: rockchip: analogix-dp: Add support for RK3576
arm64: dts: rockchip: Add eDP node for RK3576
drm/bridge: analogix_dp: Rename and simplify is_rockchip()
drm/bridge: analogix_dp: Add support for RK3576
drm/rockchip: analogix_dp: Add support for RK3576
.../rockchip/rockchip,analogix-dp.yaml | 44 ++++++++++++++++---
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 28 ++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 4 +-
.../arm64/boot/dts/rockchip/rk3588-extra.dtsi | 4 +-
.../drm/bridge/analogix/analogix_dp_core.c | 3 +-
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 18 ++++----
.../gpu/drm/rockchip/analogix_dp-rockchip.c | 15 +++++++
include/drm/bridge/analogix_dp.h | 13 +++++-
8 files changed, 108 insertions(+), 21 deletions(-)
---
Changes in v2:
- Split out separate patches to add the "hclk" clock reference.
- Split out separate patches to enable the "hclk" clock.
- Add Reviewed-by tag.
Changes in v3:
- Add a patch to expand descriptions for clocks of the eDP node.
- Add Reviewed-by tag.
Changes in v4:
- Modify commit msg.
Changes in v5:
- Enforce the correct third clock name on a per-compatible basis.
- Modify the commit msg simultaneously.
- Add Acked-by tag.
--
2.34.1
^ permalink raw reply
* Re: [PATCH v3 11/21] objtool: Allow empty alternatives
From: Peter Zijlstra @ 2026-05-13 7:37 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: x86, linux-kernel, live-patching, Joe Lawrence, Song Liu,
Catalin Marinas, Will Deacon, linux-arm-kernel, Mark Rutland,
Miroslav Benes, Petr Mladek
In-Reply-To: <3c474673ec5ddc9f27fbf5ddb1fd0f66ef6a779f.1778642120.git.jpoimboe@kernel.org>
On Tue, May 12, 2026 at 08:33:45PM -0700, Josh Poimboeuf wrote:
> arm64 can have empty alternatives, which are effectively no-ops. Ignore
> them. While at it, fix a memory leak.
How does this happen?
^ permalink raw reply
* Re: [PATCH v3 10/21] objtool: Ignore jumps to the end of the function for checksum runs
From: Peter Zijlstra @ 2026-05-13 7:36 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: x86, linux-kernel, live-patching, Joe Lawrence, Song Liu,
Catalin Marinas, Will Deacon, linux-arm-kernel, Mark Rutland,
Miroslav Benes, Petr Mladek
In-Reply-To: <b3b58101e15e1bb5266e57134f0b65f7d8efdd4b.1778642120.git.jpoimboe@kernel.org>
On Tue, May 12, 2026 at 08:33:44PM -0700, Josh Poimboeuf wrote:
> Sometimes Clang arm64 code jumps to the end of the function for UB.
> No need to make that an error for checksum runs.
I'm not sure I understand the rationale. If the compiler trips UB, we
want to be complaining about that no?
Same as when clang just stops code-gen, also something we commonly see
when it hits UB.
^ permalink raw reply
* Re: [PATCH v7 08/20] KVM: arm64: Add Partitioned PMU register trap handlers
From: Oliver Upton @ 2026-05-13 7:45 UTC (permalink / raw)
To: Colton Lewis
Cc: kvm, Alexandru Elisei, Paolo Bonzini, Jonathan Corbet,
Russell King, Catalin Marinas, Will Deacon, Marc Zyngier,
Oliver Upton, Mingwei Zhang, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Mark Rutland, Shuah Khan, Ganapatrao Kulkarni,
James Clark, linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest
In-Reply-To: <20260504211813.1804997-9-coltonlewis@google.com>
On Mon, May 04, 2026 at 09:18:01PM +0000, Colton Lewis wrote:
> We may want a partitioned PMU but not have FEAT_FGT to untrap the
> specific registers that would normally be untrapped. Add handling for
> those trapped register accesses that does the right thing if the PMU
> is partitioned.
>
> For registers that shouldn't be written to hardware because they
> require special handling (PMEVTYPER and PMOVS), write to the virtual
> register. A later patch will ensure these are handled correctly at
> vcpu_load time.
>
> Signed-off-by: Colton Lewis <coltonlewis@google.com>
I'd prefer an approach that provides a single accessor helper that takes
a vcpu_sysreg enum as an argument and internally handles the dispatch
between partitioned and emulated PMUs. That goes for all of the PMU
sysregs.
This will help you reuse some of the PMU emuation code that you'll still
need for things like nested...
Thanks,
Oliver
^ permalink raw reply
* [PATCH v5 10/10] drm/rockchip: analogix_dp: Add support for RK3576
From: Damon Ding @ 2026-05-13 7:44 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260513074414.2053435-1-damon.ding@rock-chips.com>
RK3576 integrates Analogix eDP 1.3 TX and Samsung combo PHY
hardware blocks that fully match the proven RK3588 design.
Add dedicated chip data table and device tree matching entry
to bring up basic eDP functionality for the RK3576 platform.
Support is limited to RGB output up to 4K@60Hz for now; audio,
PSR and other advanced eDP 1.3 features remain unvalidated.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v2:
- Split out a separate patch to enable the "hclk" clock.
- Add Reviewed-by tag.
Changes in v3:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index d2af5eb29dbb..d4c5dd61e95b 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -522,6 +522,14 @@ static const struct rockchip_dp_chip_data rk3288_dp[] = {
{ /* sentinel */ }
};
+static const struct rockchip_dp_chip_data rk3576_edp[] = {
+ {
+ .chip_type = RK3576_EDP,
+ .reg = 0x27dc0000,
+ },
+ { /* sentinel */ }
+};
+
static const struct rockchip_dp_chip_data rk3588_edp[] = {
{
.edp_mode = GRF_REG_FIELD(0x0000, 0, 0),
@@ -539,6 +547,7 @@ static const struct rockchip_dp_chip_data rk3588_edp[] = {
static const struct of_device_id rockchip_dp_dt_ids[] = {
{.compatible = "rockchip,rk3288-dp", .data = &rk3288_dp },
{.compatible = "rockchip,rk3399-edp", .data = &rk3399_edp },
+ {.compatible = "rockchip,rk3576-edp", .data = &rk3576_edp },
{.compatible = "rockchip,rk3588-edp", .data = &rk3588_edp },
{}
};
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox