* Re: [PATCH 04/10] dt-bindings: clock: Add Amlogic A9 AO clock controller
From: Krzysztof Kozlowski @ 2026-05-15 8:10 UTC (permalink / raw)
To: Jian Hu
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: <20260511-b4-a9_clk-v1-4-41cb4071b7c9@amlogic.com>
On Mon, May 11, 2026 at 08:47:26PM +0800, Jian Hu wrote:
> Add the Always-On clock controller dt-bindings for the Amlogic A9
> SoC family.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> ---
> .../bindings/clock/amlogic,a9-aoclkc.yaml | 76 ++++++++++++++++++++++
> include/dt-bindings/clock/amlogic,a9-aoclkc.h | 76 ++++++++++++++++++++++
> 2 files changed, 152 insertions(+)
All comments apply.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 03/10] dt-bindings: clock: Add Amlogic A9 peripherals clock controller
From: Krzysztof Kozlowski @ 2026-05-15 8:10 UTC (permalink / raw)
To: Jian Hu
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: <20260511-b4-a9_clk-v1-3-41cb4071b7c9@amlogic.com>
On Mon, May 11, 2026 at 08:47:25PM +0800, Jian Hu wrote:
> Add the peripherals clock controller dt-bindings for the Amlogic A9
> SoC family.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> ---
> .../clock/amlogic,a9-peripherals-clkc.yaml | 150 +++++++++
> .../clock/amlogic,a9-peripherals-clkc.h | 352 +++++++++++++++++++++
> 2 files changed, 502 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a9-peripherals-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a9-peripherals-clkc.yaml
> new file mode 100644
> index 000000000000..97e2c44d8630
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/amlogic,a9-peripherals-clkc.yaml
> @@ -0,0 +1,150 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2026 Amlogic, Inc. All rights reserved
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/amlogic,a9-peripherals-clkc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Amlogic A9 Series Peripherals Clock Controller
> +
> +maintainers:
> + - Neil Armstrong <neil.armstrong@linaro.org>
> + - Jerome Brunet <jbrunet@baylibre.com>
> + - Jian Hu <jian.hu@amlogic.com>
> + - Xianwei Zhao <xianwei.zhao@amlogic.com>
> +
> +properties:
> + compatible:
> + const: amlogic,a9-peripherals-clkc
> +
> + reg:
> + maxItems: 1
> +
> + '#clock-cells':
> + const: 1
> +
> + clocks:
> + minItems: 20
I don't think so. How they could be optional in silicon? How does
exactly work from silicon point of view?
> + items:
> + - description: input oscillator
> + - description: input fclk div 2
> + - description: input fclk div 3
> + - description: input fclk div 4
> + - description: input fclk div 5
> + - description: input fclk div 7
> + - description: input fclk div 2p5
> + - description: input sys clk
> + - description: input gp1 pll
> + - description: input gp2 pll
> + - description: input sys pll div 16
> + - description: input cpu clk div 16
> + - description: input a78 clk div 16
> + - description: input dsu clk div 16
> + - description: input rtc clk
> + - description: input gp0 pll
> + - description: input hifi0 pll
> + - description: input hifi1 pll
> + - description: input mclk0 pll
> + - description: input mclk1 pll
> + - description: input video1 pll (optional)
> + - description: input video2 pll (optional)
> + - description: input hdmi out2 clk (optional)
> + - description: input hdmi pixel clk (optional)
> + - description: input pixel0 pll (optional)
> + - description: input pixel1 pll (optional)
> + - description: input usb2 drd clk (optional)
> + - description: external input rmii oscillator (optional)
> +
> + clock-names:
> + minItems: 20
> + items:
> + - const: xtal
> + - const: fdiv2
> + - const: fdiv3
> + - const: fdiv4
> + - const: fdiv5
> + - const: fdiv7
> + - const: fdiv2p5
> + - const: sys
> + - const: gp1
> + - const: gp2
> + - const: sysplldiv16
> + - const: cpudiv16
> + - const: a78div16
> + - const: dsudiv16
> + - const: rtc
> + - const: gp0
> + - const: hifi0
> + - const: hifi1
> + - const: mclk0
> + - const: mclk1
> + - const: vid1
> + - const: vid2
> + - const: hdmiout2
> + - const: hdmipix
> + - const: pix0
> + - const: pix1
> + - const: u2drd
> + - const: ext_rmii
> +
> +required:
> + - compatible
> + - reg
> + - '#clock-cells'
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + apb4 {
Same comments as other patches. Do not come with your own style, but
adjust to mainline. Do you see this anywhere?
git grep apb4 -- Documentation/devicetree/bindings/clock/
So why coming with something COMPLETELY different?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 02/10] dt-bindings: clock: Add Amlogic A9 PLL clock controller
From: Krzysztof Kozlowski @ 2026-05-15 8:09 UTC (permalink / raw)
To: Jian Hu
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: <20260511-b4-a9_clk-v1-2-41cb4071b7c9@amlogic.com>
On Mon, May 11, 2026 at 08:47:24PM +0800, Jian Hu wrote:
> Add the PLL clock controller dt-bindings for the Amlogic A9 SoC family.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> ---
> .../bindings/clock/amlogic,a9-pll-clkc.yaml | 110 +++++++++++++++++++++
> include/dt-bindings/clock/amlogic,a9-pll-clkc.h | 55 +++++++++++
> 2 files changed, 165 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
> new file mode 100644
> index 000000000000..4ee6013ba1a1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
> @@ -0,0 +1,110 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2026 Amlogic, Inc. All rights reserved
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/amlogic,a9-pll-clkc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Amlogic A9 Series PLL Clock Controller
> +
> +maintainers:
> + - Neil Armstrong <neil.armstrong@linaro.org>
> + - Jerome Brunet <jbrunet@baylibre.com>
> + - Jian Hu <jian.hu@amlogic.com>
> + - Xianwei Zhao <xianwei.zhao@amlogic.com>
> +
> +properties:
> + compatible:
> + enum:
> + - amlogic,a9-gp0-pll
> + - amlogic,a9-hifi0-pll
> + - amlogic,a9-hifi1-pll
> + - amlogic,a9-mclk0-pll
> + - amlogic,a9-mclk1-pll
> +
> + reg:
> + maxItems: 1
> +
> + '#clock-cells':
> + const: 1
> +
> + clocks:
> + items:
> + - description: pll input oscillator gate
> + - description: fixed input clock source for mclk_sel_0
> + - description: u3p2pll input clock source for mclk_sel_0 (optional)
Second clock is also optional. Drop "(optional)" comment, just
confusing.
> + minItems: 1
> +
> + clock-names:
> + items:
> + - const: in0
> + - const: in1
> + - const: in2
Pretty pointless names, drop property.
> + minItems: 1
> +
> +required:
> + - compatible
> + - '#clock-cells'
> + - reg
> + - clocks
> + - clock-names
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - amlogic,a9-mclk0-pll
> + - amlogic,a9-mclk1-pll
> +
> + then:
> + properties:
> + clocks:
> + maxItems: 3
No, minItems instead. maxItems is already 3, so what is the point of
redefining it?
> +
> + clock-names:
> + maxItems: 3
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - amlogic,a9-gp0-pll
> + - amlogic,a9-hifi0-pll
> + - amlogic,a9-hifi1-pll
> +
> + then:
> + properties:
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + maxItems: 1
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + apb4 {
soc
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + clock-controller@8200 {
> + compatible = "amlogic,a9-gp0-pll";
> + reg = <0x0 0x8200 0x0 0x20>;
> + #clock-cells = <1>;
> + clocks = <&scmi_clk 0>;
> + clock-names = "in0";
> + };
> +
> + clock-controller@8330 {
> + compatible = "amlogic,a9-mclk0-pll";
> + reg = <0x0 0x8330 0x0 0x14>;
> + #clock-cells = <1>;
> + clocks = <&scmi_clk 4>,
> + <&scmi_clk 8>;
> + clock-names = "in0", "in1";
One example is enough, you have exactly the same properties.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/6] firmware: samsung: acpm: TMU support and cleanups
From: Tudor Ambarus @ 2026-05-15 8:07 UTC (permalink / raw)
To: Krzysztof Kozlowski, Michael Turquette, Stephen Boyd, Lee Jones
Cc: Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
peter.griffin, jyescas, kernel-team, Krzysztof Kozlowski
In-Reply-To: <20260506-acpm-tmu-helpers-v1-0-a9cd5daf8355@linaro.org>
Hi,
I'm going to resend this as it seems sashiko couldn't apply it:
https://sashiko.dev/#/patchset/20260506-acpm-tmu-helpers-v1-0-a9cd5daf8355%40linaro.org
Cheers,
ta
^ permalink raw reply
* Re: [PATCH 5/6] firmware: samsung: acpm: Add TMU protocol support
From: Tudor Ambarus @ 2026-05-15 7:56 UTC (permalink / raw)
To: Alexey Klimov
Cc: Krzysztof Kozlowski, Michael Turquette, Stephen Boyd, Lee Jones,
Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
peter.griffin, jyescas, kernel-team, Krzysztof Kozlowski
In-Reply-To: <DIFVKM72KZDI.14EVGUMQ0NV9S@linaro.org>
On 5/11/26 4:17 PM, Alexey Klimov wrote:
> On Thu May 7, 2026 at 9:31 AM BST, Tudor Ambarus wrote:
>> On 5/6/26 6:13 PM, Alexey Klimov wrote:
>>> On Wed May 6, 2026 at 12:39 PM BST, Tudor Ambarus wrote:
>
> [..]
>
>>>> new file mode 100644
>>>> index 000000000000..c68d60b4c0b3
>>>> --- /dev/null
>>>> +++ b/drivers/firmware/samsung/exynos-acpm-tmu.c
>>>
>>> [..]
>>>
>>>> +static int acpm_tmu_to_linux_err(s8 fw_err)
>>>> +{
>>>> + /*
>>>> + * ACPM_TMU_INIT uses BIT(0) and BIT(1) of msg.rx.ret to flag APM
>>>> + * capabilities. Treat zero and all positive values as success.
>>>
>>> ACPM_TMU_INIT returns capabilities inside designated error field?
>>
>> yes
>
> Heh. Okay.
>
>>> What about other messages/commands? They just return error code there?
>>
>> all the other commands either return -1 for errors, regardless of the error
>> type, or 0 for success.
>>>
>>>> + */
>>>> + if (fw_err >= 0)
>>>> + return 0;
>>>> +
>>>> + if (fw_err == -1)
>>>> + return -EACCES;
>>>> +
>>>> + return -EIO;
>>>> +}
>>>
>>> Could we map these return values with better granularity instead of
>>> returning -EIO for everything else that is not minus one?
>>
>> I think we're good as we are now. The firmware returns either -1 for errors,
>> zero for success, or BIT(0) and BIT(1) for TMU_INIT to flag some capabilities.
>> I can't tell if there are other commands that return capabilities as well,
>> or if there are other capabilities for TMU_INIT, I don't have access to the
>> firmware code.
>
> On Exynos850 I see more than just one returned error codes. I definitely
> see 0xfe and 0xfd at least. I don't have any data to confirm that ff
> maps to -1 and fd-s, fe-s to -2,-3 though and what they mean. From my
for these error codes we will return -EIO which is alright. We can have
a more granular approach depending on the SoC if you want.
For GS101 above is alright, it matches the info I got from the firmware guys.
> experiments I suspect that 0xfe means that call/msg type is not
> implemented or not accessible and 0xfd means that passed parameter is
> wrong or incorrect or not found.
>
> I am also not sure that I saw 0xff-s but, well, maybe that needs more
> experimenting.
>
fe and ff will be covered as well by -EIO.
Let's keep this as it is for now, and if you need a more granular approach
we can differentiate that for e850.
Thanks,
ta
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: cix: add Sky1 USB4 and USB5 controllers
From: Krzysztof Kozlowski @ 2026-05-15 7:54 UTC (permalink / raw)
To: Peter Chen
Cc: robh, krzk+dt, conor+dt, gregkh, pawell, rogerq, devicetree,
linux-kernel, linux-usb, cix-kernel-upstream, linux-arm-kernel,
arnd
In-Reply-To: <20260511024244.981941-5-peter.chen@cixtech.com>
On Mon, May 11, 2026 at 10:42:44AM +0800, Peter Chen wrote:
> Add the Sky1 USB4 and USB5 Cadence USB3 controller nodes with their
> registers, interrupts, clocks, resets and S5 syscon control. Enable both
> ports on the Orion O6 board in host mode with the required VBUS pinctrl.
>
> Signed-off-by: Peter Chen <peter.chen@cixtech.com>
> ---
> arch/arm64/boot/dts/cix/sky1-orion-o6.dts | 30 ++++++++++
> arch/arm64/boot/dts/cix/sky1.dtsi | 68 +++++++++++++++++++++++
DTS cannot be part of USB patchset.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: usb: add CIX Sky1 Cadence USB3 controller
From: Krzysztof Kozlowski @ 2026-05-15 7:54 UTC (permalink / raw)
To: Peter Chen
Cc: robh, krzk+dt, conor+dt, gregkh, pawell, rogerq, devicetree,
linux-kernel, linux-usb, cix-kernel-upstream, linux-arm-kernel,
arnd
In-Reply-To: <20260511024244.981941-4-peter.chen@cixtech.com>
On Mon, May 11, 2026 at 10:42:43AM +0800, Peter Chen wrote:
> Add a binding for the CIX Sky1 integration of the Cadence USBSSP DRD
> controller. The schema documents the glue register window, clocks,
> resets, interrupts and S5 system controller phandle.
>
> Signed-off-by: Peter Chen <peter.chen@cixtech.com>
> ---
> .../bindings/usb/cix,sky1-cdns3.yaml | 151 ++++++++++++++++++
Why are you mixing USB patches with DTS in one patchset? Don't.
> 1 file changed, 151 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/cix,sky1-cdns3.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/cix,sky1-cdns3.yaml b/Documentation/devicetree/bindings/usb/cix,sky1-cdns3.yaml
> new file mode 100644
> index 000000000000..23d82d8cc9bc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/cix,sky1-cdns3.yaml
Complete mess of filename. There is no such compatible.
> @@ -0,0 +1,151 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/usb/cix,sky1-cdns3.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: CIX Sky1 Cadence USB3 Controller
> +
> +maintainers:
> + - Peter Chen <peter.chen@cixtech.com>
> +
> +description:
> + The CIX Sky1 USB3 controller is based on the Cadence USBSSP DRD
> + controller. The integration adds glue registers and mode strap controls
> + in the Sky1 S5 system controller.
> +
> +allOf:
> + - $ref: usb-drd.yaml#
> + - $ref: usb-xhci.yaml#
> +
> +properties:
> + compatible:
> + items:
> + - const: cix,sky1-usb3
> + - const: cix,cdns-usb3
I don't understand the fallback compatible. You claim this device is
called EXACTLY like vendor cdns? Nope, you SoC specific compatibles.
> +
> + reg:
> + items:
> + - description: OTG controller registers
> + - description: Device controller registers
> + - description: XHCI host controller registers
> + - description: Sky1 USB glue registers
> +
> + reg-names:
> + items:
> + - const: otg
> + - const: dev
> + - const: xhci
Wrong order, look at cdns,usb3 schema.
> + - const: glue
> +
> + interrupts:
> + items:
> + - description: XHCI host controller interrupt
> + - description: Device controller interrupt
> + - description: OTG/DRD controller interrupt
> + - description: Wakeup interrupt
> +
> + interrupt-names:
> + items:
> + - const: host
> + - const: peripheral
> + - const: otg
> + - const: wakeup
> +
> + clocks:
> + items:
> + - description: Start-of-frame clock
> + - description: AXI bus clock
> + - description: Low-power mode clock
> + - description: APB register interface clock
> +
> + clock-names:
> + items:
> + - const: sof
> + - const: aclk
> + - const: lpm
> + - const: pclk
> +
> + resets:
> + items:
> + - description: APB register reset
> + - description: Controller reset
> +
> + reset-names:
> + items:
> + - const: prst
apb
> + - const: rst
controller or core
> +
> + cix,syscon-usb:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Phandle to the Sky1 S5 system controller used to program USB mode
> + strap controls.
> +
> + dma-coherent: true
> +
> + maximum-speed:
> + enum: [super-speed-plus, super-speed, high-speed, full-speed]
Why isn't this deducible from the compatible?
> +
> + phys:
> + minItems: 1
> + maxItems: 2
No, this is not flexible.
> +
> + phy-names:
> + minItems: 1
> + maxItems: 2
> + items:
> + anyOf:
> + - const: cdns3,usb2-phy
> + - const: cdns3,usb3-phy
Drop all this and define standard names.
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> + - interrupt-names
> + - clocks
> + - clock-names
> + - resets
> + - reset-names
> + - cix,syscon-usb
phys should be required, no?
> +
> +unevaluatedProperties: false
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH tty v4 2/6] serial: Replace driver usage of UPF_CONS_FLOW
From: John Ogness @ 2026-05-15 7:53 UTC (permalink / raw)
To: Krzysztof Kozlowski, Greg Kroah-Hartman, Jiri Slaby, Alim Akhtar
Cc: Andy Shevchenko, linux-kernel, David S. Miller,
Ilpo Järvinen, Andy Shevchenko, Thomas Fourier, Kees Cook,
linux-serial, linux-arm-kernel, linux-samsung-soc, sparclinux,
Peter Griffin, Tudor Ambarus, André Draszik, Alexey Klimov
In-Reply-To: <1a5abd2e-e9ab-4a48-94c2-5e082f57adde@kernel.org>
On 2026-05-13, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> (This email is particularly directed at the Samsung folks.)
>>
>> Responding to Sashiko:
>>
>> https://sashiko.dev/#/patchset/20260506121606.5805-1-john.ogness%40linutronix.de
>>
>> On 2026-05-06, Sashiko wrote:
>>>> diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
>>>> index e27806bf2cf3e..2f94fc798cffb 100644
>>>> --- a/drivers/tty/serial/samsung_tty.c
>>>> +++ b/drivers/tty/serial/samsung_tty.c
>>>> @@ -319,7 +319,7 @@ static void s3c24xx_serial_stop_tx(struct uart_port *port)
>>>> ourport->tx_enabled = 0;
>>>> ourport->tx_in_progress = 0;
>>>>
>>>> - if (port->flags & UPF_CONS_FLOW)
>>>> + if (uart_cons_flow_enabled(port))
>>>> s3c24xx_serial_rx_enable(port);
>>>
>>> This isn't a new bug introduced by this patch, but does this code
>>> result in a recursive spinlock acquisition and deadlock when console
>>> flow control is enabled?
>>>
>>> The serial core framework calls port->ops->stop_tx() with the
>>> port->lock spinlock already held. When uart_cons_flow_enabled(port)
>>> evaluates to true, s3c24xx_serial_stop_tx() invokes
>>> s3c24xx_serial_rx_enable().
>>>
>>> Looking at s3c24xx_serial_rx_enable(), it unconditionally attempts to
>>> acquire the exact same lock again:
>>>
>>> static void s3c24xx_serial_rx_enable(struct uart_port *port)
>>> {
>>> struct s3c24xx_uart_port *ourport = to_ourport(port);
>>> unsigned long flags;
>>> ...
>>> uart_port_lock_irqsave(port, &flags);
>>> ...
>>> }
>>>
>>> Because spinlocks are not recursive in the kernel, it appears this
>>> sequence would cause an immediate deadlock on the same CPU.
>>
>> Although out of scope for my series, the reported issue is real. Perhaps
>> something for Krzysztof or Alim to look into.
>>
>>>> @@ -493,7 +493,7 @@ static void s3c24xx_serial_start_tx(struct uart_port *port)
>>>> struct tty_port *tport = &port->state->port;
>>>>
>>>> if (!ourport->tx_enabled) {
>>>> - if (port->flags & UPF_CONS_FLOW)
>>>> + if (uart_cons_flow_enabled(port))
>>>> s3c24xx_serial_rx_disable(port);
>>>
>>> Similarly here, s3c24xx_serial_start_tx() is also called with
>>> port->lock held, and s3c24xx_serial_rx_disable() will attempt to
>>> acquire port->lock again:
>>>
>>> static void s3c24xx_serial_rx_disable(struct uart_port *port)
>>> {
>>> struct s3c24xx_uart_port *ourport = to_ourport(port);
>>> unsigned long flags;
>>> ...
>>> uart_port_lock_irqsave(port, &flags);
>>> ...
>>> }
>>>
>>> Could this pre-existing locking issue in the samsung_tty driver be
>>> addressed so that the rx enable/disable helpers do not try to take the
>>> port lock when it is already held by the caller?
>>
>> Also legitimate. But out of scope for my series.
>
>
> Thanks for letting us know. Deadlock did not happen so far, so something
> is missing in Sashiko's report. :)
Nothing is missing. I am guessing you never use console flow
control. The deadlock is clearly visible:
->stop_tx() (always called with the port locked)
s3c24xx_serial_stop_tx()
s3c24xx_serial_rx_enable()
uart_port_lock_irqsave() (DEADLOCK!)
John Ogness
^ permalink raw reply
* Re: [PATCH v2 09/11] m68k: stmark2: use ioport.h macros for resources
From: Andy Shevchenko @ 2026-05-15 7:38 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Greg Ungerer,
linux-m68k, linux-kernel, linux-stm32, linux-arm-kernel,
linux-iio
In-Reply-To: <cabngw2wuxh7cfx4cw4ik46dmxs72u47jyo6hcwgdd7a5whny2@dsp4cysetarw>
On Thu, May 14, 2026 at 09:20:38AM +0200, Angelo Dureghello wrote:
> On 13.05.2026 23:18, Andy Shevchenko wrote:
> > On Wed, May 13, 2026 at 11:14:33AM +0200, Angelo Dureghello wrote:
...
> > This conversion drops hard indices, would it be a problem (for example,
> > some code modifies the fields based on the [hard coded] index...)?
> >
> > If not, perhaps good to mention in the commit message and move IRQ to be the
> > second one?
>
> i can't see any directly-related code accessing these resources by index,
> so would not change this if there isn't any risk.
> Also i see DEFINE_RES_() stuff widely used in other arch, so thios make me
> think accessing by index is something wrong.
OK, thanks for confirming.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 08/11] m68k: stmark2: add mcf5441x DAC platform devices
From: Andy Shevchenko @ 2026-05-15 7:37 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Greg Ungerer,
linux-m68k, linux-kernel, linux-stm32, linux-arm-kernel,
linux-iio
In-Reply-To: <y4zg2d5zghoz3miqevutiin5swfnx5y2zew2zlv4jklxsyly5g@sxeyvth2tkrk>
On Thu, May 14, 2026 at 09:15:09AM +0200, Angelo Dureghello wrote:
> On 13.05.2026 23:16, Andy Shevchenko wrote:
> > On Wed, May 13, 2026 at 11:14:32AM +0200, Angelo Dureghello wrote:
...
> > Same for the rest. But I haven't seen the followups and don't know if those
> > structures are going to be expanded. The commit message doesn't say anything
> > about that. So I assume my suggestion valid.
>
> no. They are not going to be expanded, anyway, is there a real gain
> using an hardcoded 1 there ?
The 1 is a side-effect the whole point is to avoid array of 1 element.
> Would not reissue a v3 for this honestly.
Seems you will need to have a v3 based on other comments. Indeed, for its own
it's not needed to reissue a new version.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: Re: [PATCH net v1 1/2] dt-bindings: ethernet: eswin: refine delay model and HSP register description
From: 李志 @ 2026-05-15 7:31 UTC (permalink / raw)
To: Andrew Lunn
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, netdev, devicetree, linux-kernel, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, maxime.chevallier, linux-stm32,
linux-arm-kernel, ningyu, linmin, pinkesh.vaghela, pritesh.patel,
weishangjuan
In-Reply-To: <2436c6e9-4aad-4ffd-9fef-0cbbe38dc66d@lunn.ch>
> -----Original Messages-----
> From: "Andrew Lunn" <andrew@lunn.ch>
> Send time:Thursday, 07/05/2026 20:29:10
> To: lizhi2@eswincomputing.com
> Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com, rmk+kernel@armlinux.org.uk, maxime.chevallier@bootlin.com, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, ningyu@eswincomputing.com, linmin@eswincomputing.com, pinkesh.vaghela@einfochips.com, pritesh.patel@einfochips.com, weishangjuan@eswincomputing.com
> Subject: Re: [PATCH net v1 1/2] dt-bindings: ethernet: eswin: refine delay model and HSP register description
>
> > ethernet@50400000 {
> > compatible = "eswin,eic7700-qos-eth", "snps,dwmac-5.20";
> > reg = <0x50400000 0x10000>;
> > - clocks = <&d0_clock 186>, <&d0_clock 171>, <&d0_clock 40>,
> > - <&d0_clock 193>;
> > - clock-names = "axi", "cfg", "stmmaceth", "tx";
> > interrupt-parent = <&plic>;
> > interrupts = <61>;
> > interrupt-names = "macirq";
> > - phy-mode = "rgmii-id";
> > - phy-handle = <&phy0>;
> > + clocks = <&d0_clock 186>, <&d0_clock 171>, <&d0_clock 40>,
> > + <&d0_clock 193>;
> > + clock-names = "axi", "cfg", "stmmaceth", "tx";
>
> Please don't move the clocks around, since they have nothing to do
> with RGMII delays.
>
>
> > resets = <&reset 95>;
> > reset-names = "stmmaceth";
> > - rx-internal-delay-ps = <200>;
> > - tx-internal-delay-ps = <200>;
> > - eswin,hsp-sp-csr = <&hsp_sp_csr 0x100 0x108 0x118>;
> > - snps,axi-config = <&stmmac_axi_setup>;
> > + eswin,hsp-sp-csr = <&hsp_sp_csr 0x100 0x108 0x118 0x114 0x11c>;
> > + phy-handle = <&phy0>;
> > + phy-mode = "rgmii-id";
> > snps,aal;
> > snps,fixed-burst;
> > snps,tso;
> > - stmmac_axi_setup: stmmac-axi-config {
> > + snps,axi-config = <&stmmac_axi_setup_gmac0>;
> > +
> > + stmmac_axi_setup_gmac0: stmmac-axi-config {
>
> And what do these changes have to do with RGMII delays?
>
Hi Andrew,
Before sending the next revision, I would like to confirm one point about
the binding update.
In your previous review comment:
https://lore.kernel.org/lkml/7e593ede-59eb-4316-ab72-949a51c008c6@lunn.ch/
you mentioned that "a well designed board should not need delays".
Based on that, I am planning to remove rx-internal-delay-ps and
tx-internal-delay-ps from the required list.
The intention is that these properties remain available for MAC-side
fine tuning when needed, but are optional since the required RGMII delay
may instead be provided by the PHY (for example with rgmii-id) or by the
board design.
Would you consider this to be a fix to an overly restrictive schema
requirement, or more of a schema relaxation / improvement?
This will help determine whether this change should remain in the net
series or be moved to a follow-up net-next series.
Thanks,
Zhi Li
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding
From: Krzysztof Kozlowski @ 2026-05-15 7:19 UTC (permalink / raw)
To: Chancel Liu
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam, mturquette,
sboyd, kernel, devicetree, linux-kernel, imx, linux-arm-kernel,
linux-clk
In-Reply-To: <20260509024846.2094049-3-chancel.liu@nxp.com>
On Sat, May 09, 2026 at 11:48:43AM +0900, Chancel Liu wrote:
> The NXP I/O connector represents a physically present I/O connector on
> the base board. It acts as a nexus that exposes a constrained set of
> I/O resources, such as GPIOs, clocks, PWMs and interrupts, through
> fixed electrical wiring. All actual hardware providers reside on the
> base board. The connector node only defines index-based mappings to
> those providers.
>
> Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> ---
> .../bindings/connector/fsl,io-connector.yaml | 94 +++++++++++++++++++
> 1 file changed, 94 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/connector/fsl,io-connector.yaml
>
> diff --git a/Documentation/devicetree/bindings/connector/fsl,io-connector.yaml b/Documentation/devicetree/bindings/connector/fsl,io-connector.yaml
> new file mode 100644
> index 000000000000..8b5038a2332e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/connector/fsl,io-connector.yaml
> @@ -0,0 +1,94 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/connector/fsl,io-connector.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP I/O Connector
> +
> +maintainers:
> + - Frank Li <Frank.li@nxp.com>
> + - Chancel Liu <chancel.liu@nxp.com>
> +
> +description:
> + The NXP I/O connector represents a physically present I/O connector on the
> + base board. It acts as a nexus that exposes a constrained set of I/O
> + resources, such as GPIOs, clocks, PWMs and interrupts, through fixed
> + electrical wiring. All actual hardware providers reside on the base board.
> + The connector node only defines index-based mappings to those providers.
> +
> +properties:
> + compatible:
> + const: fsl,io-connector
Everything is IO. Everything is connector, so your compatible does not
match requirements from writing bindings.
> +
> + gpio-controller: true
> +
> + '#gpio-cells':
> + const: 2
> +
> + gpio-map:
> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
You do not need to redefine the types. You need constraints, though.
> +
> + gpio-map-mask:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> +
> + gpio-map-pass-thru:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> +
> + '#clock-cells':
> + const: 1
> +
> + clock-map:
> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +
> + clock-map-mask:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> +
> + clock-map-pass-thru:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
I do not see these defined anywhere. I also checked cover letter for
references for pulls to dtschema.
> +
> + pwm-map:
> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +
> + pwm-map-mask:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> +
> + pwm-map-pass-thru:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> +
> + '#address-cells':
> + const: 0
> +
> + interrupt-controller: true
> +
> + "#interrupt-cells":
Use consistent quotes.
> + const: 2
> +
> + interrupt-map: true
> +
> + interrupt-map-mask: true
> +
> +required:
> + - compatible
You need to require the properties. You have a FIXED connector, so it
has fixed set of features.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v4 1/3] dt-bindings: PCI: imx6q-pcie: Add intr, aer and pme interrupts
From: Hongxing Zhu @ 2026-05-15 7:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
bhelgaas@google.com, Frank Li, l.stach@pengutronix.de,
lpieralisi@kernel.org, kwilczynski@kernel.org, mani@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <20260514-lush-onyx-trogon-48eca5@quoll>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Thursday, May 14, 2026 6:16 PM
> To: Hongxing Zhu <hongxing.zhu@nxp.com>
> Cc: robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> bhelgaas@google.com; Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de;
> lpieralisi@kernel.org; kwilczynski@kernel.org; mani@kernel.org;
> s.hauer@pengutronix.de; kernel@pengutronix.de; festevam@gmail.com; linux-
> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> devicetree@vger.kernel.org; imx@lists.linux.dev; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v4 1/3] dt-bindings: PCI: imx6q-pcie: Add intr, aer and pme
> interrupts
>
> On Wed, May 13, 2026 at 10:50:59AM +0800, Richard Zhu wrote:
> > Add optional interrupt entries to the i.MX6Q PCIe binding to support
>
> Describe hardware, not "binding".
>
> > event-based interrupt handling:
>
> Same questions as last time.
Hi Krzysztof:
Thank you for the feedback.
What do you think about this updated commit message?
dt-bindings: imx6q-pcie: Add optional interrupt entries for intr, aer and pme
The i.MX95 PCIe controller introduces three dedicated hardware interrupt
lines:
- intr: general controller events
- aer: Advanced Error Reporting
- pme: Power Management Events
Earlier i.MX PCIe variants (imx6q, imx6sx, imx6qp, imx7d, imx8mm, imx8mp,
imx8mq, imx8q) do not have these dedicated interrupt lines.
PCIe basic functionality (enumeration, configuration, and data transfer)
works correctly regardless of whether these interrupts are present. Mark
these interrupts as optional to maintain backward compatibility with SoCs
that lack these hardware interrupt lines.
Best Regards
Richard Zhu
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 05/16] dt-bindings: display: ti,am65x-dss: Add AM62P DSS
From: Krzysztof Kozlowski @ 2026-05-15 6:58 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, 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: <3e5ce95a-10dd-4520-8bd7-7d4cfaf612d2@ideasonboard.com>
On 15/05/2026 08:56, Tomi Valkeinen wrote:
>>> The DSS IP itself is compatible with older SoCs. While we could use
>>> "ti,am625-dss" compatible string, we add a new one "ti,am62p-dss" to be
>>> on the safe side in case the driver needs to do something special for
>>> the dual-DSS case in the future.
>>>
>>> Original patch by Swamil Jain <s-jain1@ti.com>
>>>
>>> Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org>
>>> Tested-by: Swamil Jain <s-jain1@ti.com>
>>
>> Same comments.
> Interesting, looks like "b4 trailers" applies quotes here. I assume the
> parenthesis makes it do that.
I think you need to update your b4. There was a version which had this
issue.
>
> As for the tested-by, yes, it doesn't make sense for bindings. As the
> tested-by was for the series, "b4 trailers" applies it to all patches.
>
> I will manually drop these in v3.
Yes, please.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 05/16] dt-bindings: display: ti,am65x-dss: Add AM62P DSS
From: Tomi Valkeinen @ 2026-05-15 6:56 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, 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: <20260515-certain-honest-wren-f03dfa@quoll>
Hi,
On 15/05/2026 09:52, Krzysztof Kozlowski wrote:
> On Wed, May 13, 2026 at 04:17:27PM +0300, Tomi Valkeinen wrote:
>> TI's AM62P, J722S and AM67A SoCs contain same implementation of the
>> display subsystem (DSS). There are two instances of the DSS (DSS0 and
>> DSS1), each with two video ports (VP) and two video planes.
>> Additionally the SoCs contain two OLDI TXes (OLDI0 and OLDI1), a MIPI
>> DSI TX and a MIPI DPI output path.
>>
>> DSS0 supports:
>> - VP0: OLDI0 in single-link mode, or OLDI0 and OLDI1 in dual-link or
>> clone mode.
>> - VP1: DPI
>>
>> DSS1 supports:
>> - VP0: OLDI1 in single-link mode, or DPI
>> - VP1: DPI or DSI
>>
>> The DSI is only connected to VP1 of DSS1, but OLDI and DPI are shared
>> between the DSS instances. Thus only a single VP can output to DPI, and
>> a single VP can use an OLDI block. Note that in single-link
>> configuration OLDI0 can be used by DSS0, and at the same time OLDI1 can
>> be used by DSS1.
>>
>> The DSS IP itself is compatible with older SoCs. While we could use
>> "ti,am625-dss" compatible string, we add a new one "ti,am62p-dss" to be
>> on the safe side in case the driver needs to do something special for
>> the dual-DSS case in the future.
>>
>> Original patch by Swamil Jain <s-jain1@ti.com>
>>
>> Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org>
>> Tested-by: Swamil Jain <s-jain1@ti.com>
>
> Same comments.
Interesting, looks like "b4 trailers" applies quotes here. I assume the
parenthesis makes it do that.
As for the tested-by, yes, it doesn't make sense for bindings. As the
tested-by was for the series, "b4 trailers" applies it to all patches.
I will manually drop these in v3.
Tomi
^ permalink raw reply
* [PATCH v3] drm/bridge: imx93-mipi-dsi: Fix mode validation
From: Liu Ying @ 2026-05-15 6:54 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Luca Ceresoli
Cc: Dmitry Baryshkov, dri-devel, imx, linux-arm-kernel, linux-kernel,
Liu Ying
i.MX93 MIPI DPHY PLL has limitation for matching with some pixel clock
rates, e.g., the best DPHY PLL frequency is 445.333333MHz for a typical
1920x1080p@60Hz CEA/DMT display mode with a pixel clock rate running
at 148.5MHz with 4 data lanes + RGB888 pixel in MIPI DSI sync pulse mode,
while the expected PLL frequency is (148.5 * 24) / 4 / 2 MHz = 445.5MHz.
Fortunately, VESA Display Monitor Timing Standard allows +/-0.5% pixel
clock rate deviation for timings. So, for those display modes read
from EDID through a bridge with DRM_BRIDGE_OP_DETECT and DRM_BRIDGE_OP_EDID
operation bit masks set, pixel clock rate could be adjusted to match
with the PLL frequency(for the above example, the pixel clock rate is
adjusted to be 148.444444MHz with about -0.03% deviation from the 148.5MHz
nominal rate so that the adjusted rate matches with the 445.333333MHz PLL
frequency).
Instead of checking the last bridge's operation bit masks against
DRM_BRIDGE_OP_DETECT and DRM_BRIDGE_OP_EDID to determine if allowing
+/-0.5% pixel clock rate deviation, check any bridge after this bridge,
because the last bridge is usually a display connector bridge without
any operation bit mask when the clock rate deviation is allowed.
Fixes: ce62f8ea7e3f ("drm/bridge: imx: Add i.MX93 MIPI DSI support")
Fixes: 5849eff7f067 ("drm/bridge: imx93-mipi-dsi: use drm_bridge_chain_get_last_bridge()")
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
Changes in v3:
- Iterate over next bridges manually instead of calling
drm_for_each_bridge_in_chain_from() to avoid deadlock issue. (sashiko bot)
- Fix a typo in commit message - s/modes/mode/.
- Link to v2: https://patch.msgid.link/20260512-imx93-mipi-dsi-fix-mode-validation-v2-1-7aec3be5da2c@nxp.com
Changes in v2:
- Collect Frank's R-b tag.
- Add an explanation to commit message about the reason why mode validation
checks bridge's operation bit masks. (Dmitry)
- Copy Dmitry.
- Link to v1: https://lore.kernel.org/r/20260227-imx93-mipi-dsi-fix-mode-validation-v1-1-a9cd67991280@nxp.com
To: Liu Ying <victor.liu@nxp.com>
To: Andrzej Hajda <andrzej.hajda@intel.com>
To: Neil Armstrong <neil.armstrong@linaro.org>
To: Robert Foss <rfoss@kernel.org>
To: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
To: Jonas Karlman <jonas@kwiboo.se>
To: Jernej Skrabec <jernej.skrabec@gmail.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Maxime Ripard <mripard@kernel.org>
To: Thomas Zimmermann <tzimmermann@suse.de>
To: David Airlie <airlied@gmail.com>
To: Simona Vetter <simona@ffwll.ch>
To: Frank Li <Frank.Li@nxp.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
To: Pengutronix Kernel Team <kernel@pengutronix.de>
To: Fabio Estevam <festevam@gmail.com>
To: Luca Ceresoli <luca.ceresoli@bootlin.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: dri-devel@lists.freedesktop.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c | 44 ++++++++++++++++++++---------
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c b/drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c
index 8f312f9edf97..4a84e00ae563 100644
--- a/drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c
@@ -489,25 +489,43 @@ static int imx93_dsi_get_phy_configure_opts(struct imx93_dsi *dsi,
return 0;
}
+static inline struct drm_bridge *
+imx93_dsi_get_next_bridge_in_chain(struct drm_bridge *bridge)
+{
+ struct drm_bridge *next = drm_bridge_get_next_bridge(bridge);
+
+ drm_bridge_put(bridge);
+
+ return next;
+}
+
static enum drm_mode_status
imx93_dsi_validate_mode(struct imx93_dsi *dsi, const struct drm_display_mode *mode)
{
struct drm_bridge *dmd_bridge = dw_mipi_dsi_get_bridge(dsi->dmd);
- struct drm_bridge *last_bridge __free(drm_bridge_put) =
- drm_bridge_chain_get_last_bridge(dmd_bridge->encoder);
+ struct drm_bridge *bridge;
- if ((last_bridge->ops & DRM_BRIDGE_OP_DETECT) &&
- (last_bridge->ops & DRM_BRIDGE_OP_EDID)) {
- unsigned long pixel_clock_rate = mode->clock * 1000;
- unsigned long rounded_rate;
+ for (bridge = drm_bridge_get_next_bridge(dmd_bridge);
+ bridge;
+ bridge = imx93_dsi_get_next_bridge_in_chain(bridge)) {
+ if ((bridge->ops & DRM_BRIDGE_OP_DETECT) &&
+ (bridge->ops & DRM_BRIDGE_OP_EDID)) {
+ unsigned long pixel_clock_rate = mode->clock * 1000;
+ unsigned long rounded_rate;
- /* Allow +/-0.5% pixel clock rate deviation */
- rounded_rate = clk_round_rate(dsi->clk_pixel, pixel_clock_rate);
- if (rounded_rate < pixel_clock_rate * 995 / 1000 ||
- rounded_rate > pixel_clock_rate * 1005 / 1000) {
- dev_dbg(dsi->dev, "failed to round clock for mode " DRM_MODE_FMT "\n",
- DRM_MODE_ARG(mode));
- return MODE_NOCLOCK;
+ /* Allow +/-0.5% pixel clock rate deviation */
+ rounded_rate = clk_round_rate(dsi->clk_pixel, pixel_clock_rate);
+ if (rounded_rate < pixel_clock_rate * 995 / 1000 ||
+ rounded_rate > pixel_clock_rate * 1005 / 1000) {
+ dev_dbg(dsi->dev,
+ "failed to round clock for mode " DRM_MODE_FMT "\n",
+ DRM_MODE_ARG(mode));
+ drm_bridge_put(bridge);
+ return MODE_NOCLOCK;
+ }
+
+ drm_bridge_put(bridge);
+ break;
}
}
---
base-commit: 877552aa875839314afad7154b5a561889e87ea9
change-id: 20260227-imx93-mipi-dsi-fix-mode-validation-425c872a2493
Best regards,
--
Regards,
Liu Ying
^ permalink raw reply related
* Re: [PATCH v2 05/16] dt-bindings: display: ti,am65x-dss: Add AM62P DSS
From: Krzysztof Kozlowski @ 2026-05-15 6:52 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, 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: <20260513-beagley-ai-display-v2-5-9e9bcefde6bc@ideasonboard.com>
On Wed, May 13, 2026 at 04:17:27PM +0300, Tomi Valkeinen wrote:
> TI's AM62P, J722S and AM67A SoCs contain same implementation of the
> display subsystem (DSS). There are two instances of the DSS (DSS0 and
> DSS1), each with two video ports (VP) and two video planes.
> Additionally the SoCs contain two OLDI TXes (OLDI0 and OLDI1), a MIPI
> DSI TX and a MIPI DPI output path.
>
> DSS0 supports:
> - VP0: OLDI0 in single-link mode, or OLDI0 and OLDI1 in dual-link or
> clone mode.
> - VP1: DPI
>
> DSS1 supports:
> - VP0: OLDI1 in single-link mode, or DPI
> - VP1: DPI or DSI
>
> The DSI is only connected to VP1 of DSS1, but OLDI and DPI are shared
> between the DSS instances. Thus only a single VP can output to DPI, and
> a single VP can use an OLDI block. Note that in single-link
> configuration OLDI0 can be used by DSS0, and at the same time OLDI1 can
> be used by DSS1.
>
> The DSS IP itself is compatible with older SoCs. While we could use
> "ti,am625-dss" compatible string, we add a new one "ti,am62p-dss" to be
> on the safe side in case the driver needs to do something special for
> the dual-DSS case in the future.
>
> Original patch by Swamil Jain <s-jain1@ti.com>
>
> Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org>
> Tested-by: Swamil Jain <s-jain1@ti.com>
Same comments.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 02/16] dt-bindings: display: ti,am65x-dss: Simplify binding
From: Krzysztof Kozlowski @ 2026-05-15 6:51 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, 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: <20260513-beagley-ai-display-v2-2-9e9bcefde6bc@ideasonboard.com>
On Wed, May 13, 2026 at 04:17:24PM +0300, Tomi Valkeinen wrote:
> In principle the DT binding for the DSS IP should mainly cover the DSS
> IP. The current binding also covers the SoC integration topics outside
> the DSS, mainly via the endpoint related rules and descriptions.
>
> A more recent SoC, AM62P, has two instances of the DSS IP, and while
> both DSS IPs are identical, they are integrated slightly differently
> (e.g. which DSS output goes to an in-SoC DSI bridge, which goes to
> DPI pins, etc.).
>
> To make the bindings usable for both DSS instances, relax the binding
> slightly: remove the explicit endpoint rules, and generalize the
> descriptions.
>
> Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org>
> Tested-by: Swamil Jain <s-jain1@ti.com>
Same comments.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 01/16] dt-bindings: display: ti: Move ti,am62l-dss binding to a new binding file
From: Krzysztof Kozlowski @ 2026-05-15 6:51 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, 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: <20260513-beagley-ai-display-v2-1-9e9bcefde6bc@ideasonboard.com>
On Wed, May 13, 2026 at 04:17:23PM +0300, Tomi Valkeinen wrote:
> We currently have two binding files for different TI K3 DSS versions:
> ti,j721e-dss.yaml which contains bindings for the "full" DSS version,
> with four planes and outputs, and ti,am65x-dss.yaml which used to
> contain bindings for the "lite" DSS version, with two planes and
> outputs.
>
> ti,am62l-dss binding was added recently to the ti,am65x-dss.yaml file,
> which only has a single plane and a single output. To keep with the
> above "binding file per DSS model" style, and to simplify the
> ti,am65x-dss.yaml file, let's move the ti,am62l-dss to a separate, new
> file.
>
> Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org>
Drop quotes
> Tested-by: Swamil Jain <s-jain1@ti.com>
Drop
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 03/16] dt-bindings: display: ti,am625-oldi: Add optional power-domain for OLDI
From: Krzysztof Kozlowski @ 2026-05-15 6:51 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, 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: <20260513-beagley-ai-display-v2-3-9e9bcefde6bc@ideasonboard.com>
On Wed, May 13, 2026 at 04:17:25PM +0300, Tomi Valkeinen wrote:
> On some SoCs the OLDI blocks belong to the same power-domain as the main
> DSS block, but on some more recent SoCs the OLDI blocks have a
> controllable power-domain.
>
> Add the power-domain to the DT binding.
>
> Tested-by: Swamil Jain <s-jain1@ti.com>
How exactly? You copied YAML to the device and executed some commands
specific to that device? Which commands?
Or you built something, like run 'make zImage' command? So every build
is a test?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] drm/verisilicon: add support for Nuvoton MA35D1 DCUltra Lite display controller
From: Joey Lu @ 2026-05-15 6:25 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <76a9e9b676509e85484a1eb31c723b46c7e21a19.camel@iscas.ac.cn>
On 5/12/2026 9:12 PM, Icenowy Zheng wrote:
> 在 2026-05-12二的 18:59 +0800，Joey Lu写道：
>> On 5/12/2026 6:01 PM, Icenowy Zheng wrote:
>>> 在 2026-05-12二的 17:06 +0800，Joey Lu写道：
>>>
>>> ======= 8< =============
>>>>>>>> diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>> b/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>> index 7a93049368db..225af322de32 100644
>>>>>>>> --- a/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>> +++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>> @@ -164,13 +164,16 @@ static void
>>>>>>>> vs_bridge_enable_common(struct
>>>>>>>> vs_crtc *crtc,
>>>>>>>> VSDC_DISP_PANEL_CONFIG_CLK_EN);
>>>>>>>> regmap_set_bits(dc->regs,
>>>>>>>> VSDC_DISP_PANEL_CONFIG(output),
>>>>>>>> VSDC_DISP_PANEL_CONFIG_RUNNING);
>>>>>>>> - regmap_clear_bits(dc->regs,
>>>>>>>> VSDC_DISP_PANEL_START,
>>>>>>>> -
>>>>>>>> VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>>>>>>>> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
>>>>>>>> -
>>>>>>>> VSDC_DISP_PANEL_START_RUNNING(ou
>>>>>>>> tput));
>>>>>>>>
>>>>>>>> - regmap_set_bits(dc->regs,
>>>>>>>> VSDC_DISP_PANEL_CONFIG_EX(crtc-
>>>>>>>>> id),
>>>>>>>> -
>>>>>>>> VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
>>>>>>>> + if (dc->info->has_config_ex) {
>>>>>>>> + regmap_clear_bits(dc->regs,
>>>>>>>> VSDC_DISP_PANEL_START,
>>>>>>>> +
>>>>>>>> VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>>>>>>>> + regmap_set_bits(dc->regs,
>>>>>>>> VSDC_DISP_PANEL_START,
>>>>>>>> + VSDC_DISP_PANEL_START_RU
>>>>>>>> NNIN
>>>>>>>> G(ou
>>>>>>>> tput
>>>>>>>> ));
>>>>>>>> +
>>>>>>>> + regmap_set_bits(dc->regs,
>>>>>>>> VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
>>>>>>>> + VSDC_DISP_PANEL_CONFIG_E
>>>>>>>> X_CO
>>>>>>>> MMIT
>>>>>>>> );
>>>>>>> Should the commit operation happen on DC8000/DCUltraLite
>>>>>>> too?
>>>>>>> (By
>>>>>>> writing to DcregFrameBufferConfig0.VALID).
>>>>>>>
>>>>>>> Many registers written has "Note: This field is double
>>>>>>> buffered" in
>>>>>>> the
>>>>>>> DCUltraLite documentation.
>>>>>>>
>>>>>>> I suggest create a static function for commit -- write to
>>>>>>> the
>>>>>>> corresponding commit bit on DC8200, and write to
>>>>>>> DcregFrameBufferConfig0.VALID on DC8000/DCUltraLite.
>>>>>> [a] There is no commit operation for DCUltra Lite.
>>>>>> I'll not add a `VSDC_FB_CONFIG_VALID` macro. VALID (BIT(3))
>>>>>> is a
>>>>>> hardware-managed double-buffer status bit: hardware writes
>>>>>> 1=PENDING
>>>>>> when a new register set is ready and clears to 0=WORKING
>>>>>> after
>>>>>> the
>>>>>> VBLANK copy. Software must never write it, and there is no
>>>>>> polling
>>>>>> use
>>>>> It seems to be writable and controls whether register buffering
>>>>> is
>>>>> enabled, see [1].
>>>>>
>>>>> The description of this bit in MA35D1 TRM says "This ensures a
>>>>> frame
>>>>> will always start with a valid working set if this register is
>>>>> programmed last, which reduces the need for SW to wait for the
>>>>> start of
>>>>> a VBLANK signal in order to ensure all states are loaded before
>>>>> the
>>>>> next VBLANK", which indicates some kind of "committing write",
>>>>> although
>>>>> the code at [1] seems to indicate that double buffering is only
>>>>> enabled
>>>>> when bit is cleared.
>>>>>
>>>>> Anyway this bit should be programmable, and "Software must
>>>>> never
>>>>> write
>>>>> it" contradicts with the MA35D1 TRM.
>>>>>
>>>>> Thanks,
>>>>> Icenowy
>>>>>
>>>>> [1]
>>>>> https://github.com/rockos-riscv/rockos-kernel/blob/rockos-v6.6.y/drivers/gpu/drm/eswin/es_dc_hw.c#L993
>>>> Thank you for the correction. I'll add
>>>> `#define VSDC_FB_CONFIG_VALID BIT(3)` to vs_primary_plane_regs.h
>>>> and
>>>> write it in `vs_primary_plane_commit()` for non-config_ex
>>>> variants.
>>>>>> case in the driver that requires a named constant. For non-
>>>>>> config_ex
>>>>>> variants, `vs_primary_plane_commit()` performs no commit
>>>>>> operation —
>>>>>> `VSDC_FB_CONFIG_ENABLE` (OUTPUT, BIT(0)) is set in
>>>>>> `vs_crtc_atomic_enable()` and `VSDC_FB_CONFIG_RESET` (BIT(4))
>>>>>> is
>>>>>> set/cleared in the bridge enable/disable paths.
>>> Well according to the driver code for DC8000 from Eswin, and the
>>> bit
>>> named "VALID", maybe it should be cleared before programming the
>>> registers, and set after programming registers, to make the process
>>> of
>>> programming registers atomic from the perspective of the display
>>> controller.
>>>
>>> Anyway this should require testing on real hardware to verify.
>>>
>>> By the way, I see multiple peripheral drivers for MA35D1 get
>>> applied in
>>> the torvalds tree, but the device tree is still only a skeleton;
>>> when
>>> will the device tree be updated?
>>>
>>> Thanks,
>>> Icenowy
>> Thanks for pointing this out. I’ll perform tests on real hardware
>> since
>> I haven’t used this bit before.
>>
>> As for the device tree, we plan to update it comprehensively after
>> completing several major IPs, with the goal of releasing the update
>> later this year.
> Well I bought a MA35D1 board (MYIR MYB-LMA35 + RGB LCD) earlier this
> year (and this is where I got the MA35D1 identification register
> values). Hope I can have a chance to test this driver by myself.
>
> As MMC, Ethernet and USB support is all applied, maybe it's already
> worthy to update the device tree ;-)
>
> Thanks,
> Icenowy
Yes you can!
I have performed hardware validation on the MA35D1 and found that this
bit acts as a manual latch for the shadow registers rather than an
auto-clearing trigger, which clarifies the slightly ambiguous
description in the TRM.
Following your suggestion, I will align the implementation with ESWIN's
DC8000 logic: setting the VALID bit at atomic_begin and clearing it at
atomic_flush. My tests confirm this allows the hardware to latch the
plane configuration correctly while avoiding the blank screen issues
observed with other configurations.
I am preparing the v2 patchset with this change, along with the
requested commit splits, and will submit it shortly.🙂
>>>>> ========= 8< ==========
>>>>>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Remove @arch from __load_stage2()
From: Anshuman Khandual @ 2026-05-15 5:48 UTC (permalink / raw)
To: Zenghui Yu, kvmarm, linux-arm-kernel
Cc: maz, oupton, joey.gouly, suzuki.poulose
In-Reply-To: <20260318144305.56831-1-zenghui.yu@linux.dev>
On 18/03/26 8:13 PM, Zenghui Yu wrote:
> From: "Zenghui Yu (Huawei)" <zenghui.yu@linux.dev>
>
> Since commit fe49fd940e22 ("KVM: arm64: Move VTCR_EL2 into struct s2_mmu"),
> @arch is no longer required to obtain the per-kvm_s2_mmu vtcr and can be
> removed from __load_stage2().
>
> Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/include/asm/kvm_mmu.h | 3 +--
> arch/arm64/kvm/at.c | 2 +-
> arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 2 +-
> arch/arm64/kvm/hyp/nvhe/mem_protect.c | 2 +-
> arch/arm64/kvm/hyp/nvhe/switch.c | 2 +-
> arch/arm64/kvm/hyp/nvhe/tlb.c | 4 ++--
> arch/arm64/kvm/hyp/vhe/switch.c | 2 +-
> arch/arm64/kvm/hyp/vhe/tlb.c | 4 ++--
> 8 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index d968aca0461a..c1e535e3d931 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -318,8 +318,7 @@ static __always_inline u64 kvm_get_vttbr(struct kvm_s2_mmu *mmu)
> * Must be called from hyp code running at EL2 with an updated VTTBR
> * and interrupts disabled.
> */
> -static __always_inline void __load_stage2(struct kvm_s2_mmu *mmu,
> - struct kvm_arch *arch)
> +static __always_inline void __load_stage2(struct kvm_s2_mmu *mmu)
> {
> write_sysreg(mmu->vtcr, vtcr_el2);
> write_sysreg(kvm_get_vttbr(mmu), vttbr_el2);
> diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
> index a024d9a770dc..3b61da0a24d8 100644
> --- a/arch/arm64/kvm/at.c
> +++ b/arch/arm64/kvm/at.c
> @@ -1379,7 +1379,7 @@ static u64 __kvm_at_s1e01_fast(struct kvm_vcpu *vcpu, u32 op, u64 vaddr)
> }
> }
> write_sysreg_el1(vcpu_read_sys_reg(vcpu, SCTLR_EL1), SYS_SCTLR);
> - __load_stage2(mmu, mmu->arch);
> + __load_stage2(mmu);
>
> skip_mmu_switch:
> /* Temporarily switch back to guest context */
> diff --git a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
> index 5f9d56754e39..803961cdd39e 100644
> --- a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
> +++ b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
> @@ -63,7 +63,7 @@ int refill_memcache(struct kvm_hyp_memcache *mc, unsigned long min_pages,
> static __always_inline void __load_host_stage2(void)
> {
> if (static_branch_likely(&kvm_protected_mode_initialized))
> - __load_stage2(&host_mmu.arch.mmu, &host_mmu.arch);
> + __load_stage2(&host_mmu.arch.mmu);
> else
> write_sysreg(0, vttbr_el2);
> }
> diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> index d815265bd374..87a169838481 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> @@ -336,7 +336,7 @@ int __pkvm_prot_finalize(void)
> kvm_flush_dcache_to_poc(params, sizeof(*params));
>
> write_sysreg_hcr(params->hcr_el2);
> - __load_stage2(&host_mmu.arch.mmu, &host_mmu.arch);
> + __load_stage2(&host_mmu.arch.mmu);
>
> /*
> * Make sure to have an ISB before the TLB maintenance below but only
> diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
> index 779089e42681..3938997e7963 100644
> --- a/arch/arm64/kvm/hyp/nvhe/switch.c
> +++ b/arch/arm64/kvm/hyp/nvhe/switch.c
> @@ -299,7 +299,7 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
> __sysreg_restore_state_nvhe(guest_ctxt);
>
> mmu = kern_hyp_va(vcpu->arch.hw_mmu);
> - __load_stage2(mmu, kern_hyp_va(mmu->arch));
> + __load_stage2(mmu);
> __activate_traps(vcpu);
>
> __hyp_vgic_restore_state(vcpu);
> diff --git a/arch/arm64/kvm/hyp/nvhe/tlb.c b/arch/arm64/kvm/hyp/nvhe/tlb.c
> index 3dc1ce0d27fe..01226a5168d2 100644
> --- a/arch/arm64/kvm/hyp/nvhe/tlb.c
> +++ b/arch/arm64/kvm/hyp/nvhe/tlb.c
> @@ -110,7 +110,7 @@ static void enter_vmid_context(struct kvm_s2_mmu *mmu,
> if (vcpu)
> __load_host_stage2();
> else
> - __load_stage2(mmu, kern_hyp_va(mmu->arch));
> + __load_stage2(mmu);
>
> asm(ALTERNATIVE("isb", "nop", ARM64_WORKAROUND_SPECULATIVE_AT));
> }
> @@ -128,7 +128,7 @@ static void exit_vmid_context(struct tlb_inv_context *cxt)
> return;
>
> if (vcpu)
> - __load_stage2(mmu, kern_hyp_va(mmu->arch));
> + __load_stage2(mmu);
> else
> __load_host_stage2();
>
> diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
> index 9db3f11a4754..bc8090d915bf 100644
> --- a/arch/arm64/kvm/hyp/vhe/switch.c
> +++ b/arch/arm64/kvm/hyp/vhe/switch.c
> @@ -219,7 +219,7 @@ void kvm_vcpu_load_vhe(struct kvm_vcpu *vcpu)
>
> __vcpu_load_switch_sysregs(vcpu);
> __vcpu_load_activate_traps(vcpu);
> - __load_stage2(vcpu->arch.hw_mmu, vcpu->arch.hw_mmu->arch);
> + __load_stage2(vcpu->arch.hw_mmu);
> }
>
> void kvm_vcpu_put_vhe(struct kvm_vcpu *vcpu)
> diff --git a/arch/arm64/kvm/hyp/vhe/tlb.c b/arch/arm64/kvm/hyp/vhe/tlb.c
> index 35855dadfb1b..539e44d09f17 100644
> --- a/arch/arm64/kvm/hyp/vhe/tlb.c
> +++ b/arch/arm64/kvm/hyp/vhe/tlb.c
> @@ -60,7 +60,7 @@ static void enter_vmid_context(struct kvm_s2_mmu *mmu,
> * place before clearing TGE. __load_stage2() already
> * has an ISB in order to deal with this.
> */
> - __load_stage2(mmu, mmu->arch);
> + __load_stage2(mmu);
> val = read_sysreg(hcr_el2);
> val &= ~HCR_TGE;
> write_sysreg_hcr(val);
> @@ -78,7 +78,7 @@ static void exit_vmid_context(struct tlb_inv_context *cxt)
>
> /* ... and the stage-2 MMU context that we switched away from */
> if (cxt->mmu)
> - __load_stage2(cxt->mmu, cxt->mmu->arch);
> + __load_stage2(cxt->mmu);
>
> if (cpus_have_final_cap(ARM64_WORKAROUND_SPECULATIVE_AT)) {
> /* Restore the registers to what they were */
^ permalink raw reply
* [PATCH] net: stmmac: fix fatal bus error on resume by reinitializing RX buffers
From: Ding Hui @ 2026-05-15 5:38 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Russell King (Oracle), Maxime Chevallier,
open list:STMMAC ETHERNET DRIVER,
moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE, open list
Cc: dinghui, xiasanbo, yangchen11, liuxuanjun
From: Ding Hui <dinghui@lixiang.com>
On suspend, stmmac_suspend() calls stmmac_disable_all_queues() which
stops the RX NAPI, but the RX DMA engine may still be running for a
short window before stmmac_stop_all_dma() takes effect. During that
window the hardware can write incoming frames into the buffers pointed
to by the RX descriptors and write back the descriptors (clearing the
OWN bit, updating length/status). Because NAPI is already disabled,
the driver never refills these descriptors, so the RX ring is left in
a "consumed but not refilled" state with HW-written content in the
descriptor buffer-address fields.
On resume, stmmac_clear_descriptors() only re-arms the OWN bit (rdes3)
and does not repopulate the RX buffer address fields. As a result the
descriptors still contain whatever the hardware wrote back during the
suspend race. When the DMA is restarted, it dereferences these stale
addresses and triggers a fatal bus error.
Fix this by treating the RX ring the same way as on close/open around
a PM transition:
- In stmmac_suspend(), after stmmac_stop_all_dma(), walk every RX
queue and free its buffers via dma_free_rx_xskbufs() when an XSK
pool is attached or dma_free_rx_skbufs() otherwise, then reset
rx_q->buf_alloc_num and clear rx_q->xsk_pool so the queue state
matches a freshly closed queue.
- In stmmac_resume(), call init_dma_rx_desc_rings() before
stmmac_reset_queues_param() so RX buffers are re-allocated and
the descriptor buffer-address fields are properly repopulated
before the DMA is restarted.
After this change, post-resume RX descriptors always reference freshly
allocated, driver-owned buffers, and the bus error no longer occurs.
Signed-off-by: Ding Hui <dinghui@lixiang.com>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 24 +++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3591755ea30b..8ed43187cf20 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -8176,6 +8176,9 @@ int stmmac_suspend(struct device *dev)
{
struct net_device *ndev = dev_get_drvdata(dev);
struct stmmac_priv *priv = netdev_priv(ndev);
+ u32 rx_count = priv->plat->rx_queues_to_use;
+ struct stmmac_rx_queue *rx_q;
+ u32 queue;
u8 chan;
if (!ndev || !netif_running(ndev))
@@ -8198,6 +8201,19 @@ int stmmac_suspend(struct device *dev)
/* Stop TX/RX DMA */
stmmac_stop_all_dma(priv);
+ /* Free RX queue resources */
+ for (queue = 0; queue < rx_count; queue++) {
+ rx_q = &priv->dma_conf.rx_queue[queue];
+
+ /* Release the DMA RX socket buffers */
+ if (rx_q->xsk_pool)
+ dma_free_rx_xskbufs(priv, &priv->dma_conf, queue);
+ else
+ dma_free_rx_skbufs(priv, &priv->dma_conf, queue);
+ rx_q->buf_alloc_num = 0;
+ rx_q->xsk_pool = NULL;
+ }
+
stmmac_legacy_serdes_power_down(priv);
/* Enable Power down mode by programming the PMT regs */
@@ -8316,6 +8332,14 @@ int stmmac_resume(struct device *dev)
mutex_lock(&priv->lock);
+ ret = init_dma_rx_desc_rings(ndev, &priv->dma_conf, GFP_KERNEL);
+ if (ret < 0) {
+ netdev_err(priv->dev, "%s: rx dma desc rings init failed\n", __func__);
+ mutex_unlock(&priv->lock);
+ rtnl_unlock();
+ return ret;
+ }
+
stmmac_reset_queues_param(priv);
stmmac_free_tx_skbufs(priv);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 2/4] PCI: endpoint: Add DOE mailbox support for endpoint functions
From: Aksh Garg @ 2026-05-15 5:35 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: linux-pci, linux-doc, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <hohf2lui4dyu6fzypl7kkwfvgf73ldmvinok7dfukhaornhkqp@n336bwjkvb6f>
On 14/05/26 13:33, Manivannan Sadhasivam wrote:
> On Mon, Apr 27, 2026 at 10:47:23AM +0530, Aksh Garg wrote:
>> DOE (Data Object Exchange) is a standard PCIe extended capability
>> feature introduced in the Data Object Exchange (DOE) ECN for
>> PCIe r5.0. It provides a communication mechanism primarily used for
>> implementing PCIe security features such as device authentication, and
>> secure link establishment. Think of DOE as a sophisticated mailbox
>> system built into PCIe. The root complex can send structured requests
>> to the endpoint device through DOE mailboxes, and the endpoint device
>> responds with appropriate data.
>>
>> Add the DOE support for PCIe endpoint devices, enabling endpoint
>> functions to process the DOE requests from the host. The implementation
>> provides framework APIs for EPC core driver and controller drivers to
>> register mailboxes, and request processing with workqueues ensuring
>> sequential handling per mailbox, and parallel handling across mailboxes.
>> The Discovery protocol is handled internally by the DOE core.
>>
>> This implementation complements the existing DOE implementation for
>> root complex in drivers/pci/doe.c.
>>
>> Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>> Signed-off-by: Aksh Garg <a-garg7@ti.com>
>> ---
>> +
>> +/*
>> + * Global registry of protocol handlers.
>> + * When a new DOE protocol, library is added, add an entry to this array.
>> + */
>> +static const struct pci_doe_protocol pci_doe_protocols[] = {
>> + {
>> + .vid = PCI_VENDOR_ID_PCI_SIG,
>> + .type = PCI_DOE_FEATURE_DISCOVERY,
>> + .handler = pci_ep_doe_handle_discovery,
>> + },
>> +};
>> +
>> +/*
>> + * Combines function number and capability offset into a unique lookup key
>> + * for storing/retrieving DOE mailboxes in an xarray.
>> + */
>> +#define PCI_DOE_MB_KEY(func, offset) \
>> + (((unsigned long)(func) << 16) | (offset))
>> +#define PCI_DOE_PROTOCOL_COUNT ARRAY_SIZE(pci_doe_protocols)
>> +
>> +/**
>> + * pci_ep_doe_init() - Initialize the DOE framework for a controller in EP mode
>> + * @epc: PCI endpoint controller
>> + *
>> + * Initialize the DOE framework data structures. This only initializes
>> + * the xarray that will hold the mailboxes.
>> + *
>> + * RETURNS: 0 on success, -errno on failure
>
> kernel-doc format to describe return value is 'Return:' or 'Returns:".
Thanks for pointing this out. I will update this.
>
>> + */
>> +int pci_ep_doe_init(struct pci_epc *epc)
>> +{
>> + if (!epc)
>> + return -EINVAL;
>> +
>> + xa_init(&epc->doe_mbs);
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(pci_ep_doe_init);
>> +
[...]
>> +
>> +/**
>> + * pci_ep_doe_process_request() - Process DOE request on endpoint
>> + * @epc: PCI endpoint controller
>> + * @func_no: Physical function number
>> + * @cap_offset: DOE capability offset
>> + * @vendor: Vendor ID from request header
>> + * @type: Protocol type from request header
>> + * @request: Request payload in CPU-native format
>> + * @request_sz: Size of request payload (bytes)
>> + * @complete: Callback to invoke upon completion
>> + *
>> + * Asynchronously process a DOE request received on the endpoint. The request
>> + * payload should not include the DOE header (vendor/type/length). The protocol
>> + * handler will allocate the response buffer, which the caller (controller driver)
>> + * must free after use.
>> + *
>> + * This function returns immediately after queuing the request. The completion
>> + * callback will be invoked asynchronously from workqueue context once the
>> + * request is processed. The callback receives the function number and capability
>> + * offset to identify the mailbox, along with a status code (0 on success, -errno
>> + * on failure), and other required arguments.
>> + *
>> + * As per DOE specification, a mailbox processes one request at a time.
>> + * Therefore, this function will never be called concurrently for the same
>> + * mailbox by different callers.
>> + *
>> + * The caller is responsible for the conversion of the received DOE request
>> + * with le32_to_cpu() before calling this function.
>> + * Similarly, it is responsible for converting the response payload with
>> + * cpu_to_le32() before sending it back over the DOE mailbox.
>> + *
>> + * The caller is also responsible for ensuring that the request size
>> + * is within the limits defined by PCI_DOE_MAX_LENGTH.
>> + *
>> + * RETURNS: 0 if the request was successfully queued, -errno on failure
>> + */
>> +int pci_ep_doe_process_request(struct pci_epc *epc, u8 func_no, u16 cap_offset,
>> + u16 vendor, u8 type, const void *request, size_t request_sz,
>> + pci_ep_doe_complete_t complete)
>> +{
>> + struct pci_ep_doe_mb *doe_mb;
>> + struct pci_ep_doe_task *task;
>> + int rc;
>> +
>> + doe_mb = pci_ep_doe_get_mailbox(epc, func_no, cap_offset);
>> + if (!doe_mb) {
>> + kfree(request);
>> + return -ENODEV;
>> + }
>> +
>> + task = kzalloc_obj(*task, GFP_KERNEL);
>> + if (!task) {
>> + kfree(request);
>> + return -ENOMEM;
>> + }
>> +
>> + task->feat.vid = vendor;
>> + task->feat.type = type;
>> + task->request_pl = request;
>> + task->request_pl_sz = request_sz;
>> + task->response_pl = NULL;
>> + task->response_pl_sz = 0;
>> + task->complete = complete;
>> +
>> + rc = pci_ep_doe_submit_task(doe_mb, task);
>> + if (rc) {
>> + kfree(request);
>> + kfree(task);
>> + return rc;
>> + }
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(pci_ep_doe_process_request);
>
> So who is supposed to call this API? EPC driver that receives the DOE interrupt?
Yes, the EPC drivers that receive the DOE interrupts are expected to
call this API.
> But I don't see the any callers of this and below exported APIs in this series.
> Either you should add the callers or limit this series just to adding the DOE
> skeleton implementation with a clear follow-up.
I currently am working on the EPC driver implementation for a platform
which has not been up-streamed yet. I plan to use these APIs to support
the DOE feature for that driver. Currently, I am not aware of any
platform whose EPC driver supports DOE feature and its interrupts, hence
I see no real callers of these APIs to include in this patch series.
Would it be appropriate to add a dummy [NOT-FOR-MERGING] demonstration
patch over an existing EPC driver, showing how these DOE APIs would be
integrated into an EPC driver?
>
> But since you've limited the scope of this series to support only DOE Discovery
> Data Object Protocol, it'd be good to add the EPC implementation to get the full
> picture.>
> - Mani
>
^ permalink raw reply
* Re: [PATCH] pmdomain: ti_sci: add wakeup constraint to parent devices of wakeup source
From: Sebin Francis @ 2026-05-15 5:21 UTC (permalink / raw)
To: Kendall Willis, Nishanth Menon, Tero Kristo, Santosh Shilimkar,
Ulf Hansson, Kevin Hilman, Dhruva Gole
Cc: linux-arm-kernel, linux-pm, linux-kernel, stable, tomi.valkeinen,
devarsht, vigneshr, vishalm, vitor.soares, ivitro
In-Reply-To: <20260506-wkup-constraint-v1-1-0a4bce791b29@ti.com>
On 07/05/26 08:46, Kendall Willis wrote:
> Set wakeup constraint for any device in a wakeup path. All parent devices
> of a wakeup device should not be turned off during suspend. This ensures
> the wakeup device is kept on while the system is suspended.
>
> Cc: stable@vger.kernel.org
> Fixes: 9d8aa0dd3be4 ("pmdomain: ti_sci: add wakeup constraint management")
> Reported-by: Vitor Soares <vitor.soares@toradex.com>
> Closes: https://lore.kernel.org/linux-pm/c0fe43a2339c802e9ce5900092cd530a2ba17a6b.camel@gmail.com/
> Signed-off-by: Kendall Willis <k-willis@ti.com>
> ---
Looks good to me.
Reviewed-by: Sebin Francis <sebin.francis@ti.com>
Sebin Francis
> drivers/pmdomain/ti/ti_sci_pm_domains.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
> index 18d33bc35dee1b3bf6107af1e414db377d515199..949e4115f930b93b18216fde46131b5c8931c9aa 100644
> --- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
> +++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
> @@ -86,7 +86,7 @@ static inline void ti_sci_pd_set_wkup_constraint(struct device *dev)
> const struct ti_sci_handle *ti_sci = pd->parent->ti_sci;
> int ret;
>
> - if (device_may_wakeup(dev)) {
> + if (device_may_wakeup(dev) || device_wakeup_path(dev)) {
> /*
> * If device can wakeup using IO daisy chain wakeups,
> * we do not want to set a constraint.
>
> ---
> base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
> change-id: 20260506-wkup-constraint-9b0261b04df1
> > Best regards,
^ 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