* Re: [PATCH v2 2/3] mailbox: exynos: Add support for Exynos850 mailbox
From: Alexey Klimov @ 2026-04-08 13:08 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Krzysztof Kozlowski, Sylwester Nawrocki, Chanwoo Choi,
Alim Akhtar, Sam Protsenko, Michael Turquette, Stephen Boyd,
Rob Herring, Conor Dooley, Jassi Brar, Krzysztof Kozlowski,
Peter Griffin, linux-samsung-soc, linux-arm-kernel, linux-clk,
devicetree, linux-kernel
In-Reply-To: <a02a693e-b06e-43bf-ac5f-8253f298c83d@linaro.org>
Hi Tudor,
On Thu Apr 2, 2026 at 9:42 AM BST, Tudor Ambarus wrote:
> Hi, Alexey,
>
> On 4/2/26 5:20 AM, Alexey Klimov wrote:
>> Exynos850-based platforms support ACPM and has similar workflow
>> of communicating with ACPM via mailbox, however mailbox controller
>> registers are located at different offsets and writes/reads could be
>> different. To distinguish between such different behaviours,
>> the registers offsets for Exynos850 and the platform-specific data
>> structs are introduced and configuration is described in such structs
>> for gs101 and exynos850 based SoCs. Probe routine now selects the
>> corresponding platform-specific data via device_get_match_data().
>>
>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>> ---
>> drivers/mailbox/exynos-mailbox.c | 67 ++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 64 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mailbox/exynos-mailbox.c b/drivers/mailbox/exynos-mailbox.c
>> index d2355b128ba4..f9c59c07558a 100644
>> --- a/drivers/mailbox/exynos-mailbox.c
>> +++ b/drivers/mailbox/exynos-mailbox.c
>> @@ -31,14 +31,61 @@
>>
>> #define EXYNOS_MBOX_CHAN_COUNT HWEIGHT32(EXYNOS_MBOX_INTGR1_MASK)
>>
>> +#define EXYNOS850_MBOX_MCUCTRL 0x0 /* Mailbox Control Register */
>> +#define EXYNOS850_MBOX_INTGR0 0x8 /* Interrupt Generation Register 0 */
>> +#define EXYNOS850_MBOX_INTCR0 0x0C /* Interrupt Clear Register 0 */
>> +#define EXYNOS850_MBOX_INTMR0 0x10 /* Interrupt Mask Register 0 */
>> +#define EXYNOS850_MBOX_INTSR0 0x14 /* Interrupt Status Register 0 */
>> +#define EXYNOS850_MBOX_INTMSR0 0x18 /* Interrupt Mask Status Register 0 */
>> +#define EXYNOS850_MBOX_INTGR1 0x1C /* Interrupt Generation Register 1 */
>> +#define EXYNOS850_MBOX_INTMR1 0x24 /* Interrupt Mask Register 1 */
>> +#define EXYNOS850_MBOX_INTSR1 0x28 /* Interrupt Status Register 1 */
>> +#define EXYNOS850_MBOX_INTMSR1 0x2C /* Interrupt Mask Status Register 1 */
>> +#define EXYNOS850_MBOX_VERSION 0x70
>
> Please consider defining just the registers that are used, to not
> pollute the driver. You may drop the unused gs101 definitions too.
Sure. Thanks. I was surprised how many unused defines were introduced
by gs101 SoC in the first place all over.
>> +#define EXYNOS850_MBOX_INTMR1_MASK GENMASK(15, 0)
>> +
>> +/**
>> + * struct exynos_mbox_driver_data - platform-specific mailbox configuration.
>> + * @irq_doorbell_offset: offset to the IRQ generation register, doorbell
>> + * to APM co-processor.
>> + * @irq_doorbell_shift: shift to apply to the value written to IRQ
>> + * generation register.
>> + * @irq_mask_offset: offset to the IRQ mask register.
>> + * @irq_mask_value: value to right to the mask register to mask out
>> + * all interrupts.
>> + */
>> +struct exynos_mbox_driver_data {
>> + u16 irq_doorbell_offset;
>> + u16 irq_doorbell_shift;
>> + u16 irq_mask_offset;
>> + u16 irq_mask_value;
>> +};
>> +
>> /**
>> * struct exynos_mbox - driver's private data.
>> * @regs: mailbox registers base address.
>> * @mbox: pointer to the mailbox controller.
>> + * @data: pointer to driver platform-specific data.
>> */
>> struct exynos_mbox {
>> void __iomem *regs;
>> struct mbox_controller *mbox;
>> + const struct exynos_mbox_driver_data *data;
>> +};
>> +
>> +static const struct exynos_mbox_driver_data exynos850_mbox_data = {
>> + .irq_doorbell_offset = EXYNOS850_MBOX_INTGR0,
>> + .irq_doorbell_shift = 16,
>> + .irq_mask_offset = EXYNOS850_MBOX_INTMR1,
>> + .irq_mask_value = EXYNOS850_MBOX_INTMR1_MASK,
>> +};
>> +
>> +static const struct exynos_mbox_driver_data exynos_gs101_mbox_data = {
>> + .irq_doorbell_offset = EXYNOS_MBOX_INTGR1,
>> + .irq_doorbell_shift = 0,
>> + .irq_mask_offset = EXYNOS_MBOX_INTMR0,
>> + .irq_mask_value = EXYNOS_MBOX_INTMR0_MASK,
>> };
>
> I find it strange that the SoCs use different registers. Are you sure you're
> using the right direction? i.e. ring the doorbell to APM and not to AP?
Well, I am not sure I correctly understood the questions and comment. So,
this all was tested with ACPM TMU code with 3 temp sensors and it seems
to work and sensors react in the right way.
Downstream clearly does the following (see also [1],[2]) when sending
ACPM msg:
static void apm_interrupt_gen(unsigned int id)
{
/* APM NVIC INTERRUPT GENERATE */
writel((1 << id) << 16, acpm_ipc->intr + INTGR0);
}
I am aware that gs101 downstream uses INTGR1 in apm_interrupt_gen().
When I use INTGR1 for e850 then I observe acpm timeouts. Hence, out of
curiosity, what's the expected behaviour when/if I ring the doorbell to
AP (to itself as far as I understand)? My understanding that it won't
work at all in such case unless APM firmware does some very fast
polling.
[1]: https://gitlab.com/Linaro/96boards/e850-96/kernel/-/blob/android-exynos-4.14-linaro/drivers/soc/samsung/acpm/acpm_ipc.c?ref_type=heads#L423
[2]: https://github.com/samsungexynos850/android_kernel_samsung_exynos850/blob/0af517be2336bf8e09c59d576c4c314446713101/drivers/soc/samsung/acpm/acpm_ipc.c#L426
>> static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
>> @@ -57,7 +104,8 @@ static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
>> return -EINVAL;
>> }
>>
>> - writel(BIT(msg->chan_id), exynos_mbox->regs + EXYNOS_MBOX_INTGR1);
>> + writel(BIT(msg->chan_id) << exynos_mbox->data->irq_doorbell_shift,
>> + exynos_mbox->regs + exynos_mbox->data->irq_doorbell_offset);
>
> Use FIELD_PREP from <linux/bitfield.h> please. You will use a mask instead of
> a shift.
>
> I would rename irq_doorbell_offset to intgr. It aligns with the register name
> from the datasheet. You won't need to prepend _offset to the name, we already
> see it's an offset when doing the writel().
Sure. Thanks. Let's use FIELD_PREP.
"doorbell" naming was chosen for readability and maintainability reasons.
It seems to be more generic enough name that better reflects the workflow
of what's going on in ACPM+mailbox machinery. We can rename it to just
"doorbell" for instance.
From platform data it will be clear to which register it is set, INTGR0
or INTGR1, to align it with datasheet (which is closed anyway).
Regarding intgr vs doorbell name, the intgr is a bit unclear for a
reader if it means interrupt generation register or something else.
But if you prefer, I can go with "intgr".
One more option is add a comment, smth like /* Ring the doorbell */
before that writel().
[..]
>> @@ -133,7 +194,7 @@ static int exynos_mbox_probe(struct platform_device *pdev)
>> platform_set_drvdata(pdev, exynos_mbox);
>>
>> /* Mask out all interrupts. We support just polling channels for now. */
>> - writel(EXYNOS_MBOX_INTMR0_MASK, exynos_mbox->regs + EXYNOS_MBOX_INTMR0);
>> + writel(data->irq_mask_value, exynos_mbox->regs + data->irq_mask_offset);
>>
>
> and here I would s/irq_mask_value/intmr_mask and irq_mask_offset/intmr.
Ack. Thanks.
Best regards,
Alexey
^ permalink raw reply
* Re: [PATCH v6 21/21] arm64: dts: renesas: r9a09g047e57-smarc: Enable DU0 and DSI support
From: Geert Uytterhoeven @ 2026-04-08 13:01 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, laurent.pinchart, linux-renesas-soc, biju.das.jz,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Magnus Damm,
Laurent Pinchart, Tomi Valkeinen, dri-devel, devicetree,
linux-kernel, linux-clk
In-Reply-To: <481fefa0c9f6f0629a663fe3da1fb17e7f4a1a05.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
Hi Tommaso,
On Wed, 8 Apr 2026 at 12:40, Tommaso Merciai
<tommaso.merciai.xr@bp.renesas.com> wrote:
> Enable DU0, DSI and ADV7535 on RZ/G3E SMARC EVK.
>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
> +++ b/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
> @@ -33,6 +33,7 @@ aliases {
> ethernet0 = ð0;
> ethernet1 = ð1;
> i2c2 = &i2c2;
> + i2c7 = &i2c7;
> mmc0 = &sdhi0;
> mmc2 = &sdhi2;
> };
> @@ -77,12 +78,47 @@ reg_vdd0p8v_others: regulator-vdd0p8v-others {
> regulator-always-on;
> };
>
> + reg_1p8v_adv: regulator-1p8v-adv {
Please preserve sort order (alphabetical, by node name).
> + compatible = "regulator-fixed";
> + regulator-name = "fixed-1.8V";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + reg_3p3v_adv: regulator-3p3v-adv {
> + compatible = "regulator-fixed";
> + regulator-name = "fixed-3.3V";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
Why not reusing the existing reg_1p8v and reg_3p3v?
Note that reg_1p8v driving eMMC and QSPI are also not the same
physical power rail.
> +
> + osc1: cec-clock {
Please preserve sort order (alphabetical, by node name).
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <12000000>;
> + };
> +
> /* 32.768kHz crystal */
> x3: x3-clock {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> clock-frequency = <32768>;
> };
> +
> + dsi-to-hdmi-out {
hdmi-out?
Please preserve sort order (alphabetical, by node name).
> + compatible = "hdmi-connector";
> + type = "d";
> +
> + port {
> + dsi_to_hdmi_out: endpoint {
> + remote-endpoint = <&adv7535_out>;
> + };
> + };
> + };
> };
>
> &audio_extal_clk {
> @@ -107,6 +143,37 @@ ð1 {
> status = "okay";
> };
>
> +&dsi {
Please preserve sort-order (alphabetical, by label).
> + status = "okay";
> +
> + ports {
> + port@0 {
> + dsi_in0: endpoint {
> + remote-endpoint = <&du0_out_dsi>;
> + };
> + };
> +
> + port@2 {
> + dsi_out: endpoint {
> + remote-endpoint = <&adv7535_in>;
> + data-lanes = <1 2 3 4>;
> + };
> + };
> + };
> +};
> +
> +&du0 {
> + status = "okay";
> +
> + ports {
> + port@0 {
> + du0_out_dsi: endpoint {
> + remote-endpoint = <&dsi_in0>;
> + };
> + };
> + };
> +};
> +
> &gpu {
> status = "okay";
> mali-supply = <®_vdd0p8v_others>;
> @@ -132,6 +199,48 @@ raa215300: pmic@12 {
> };
> };
>
> +&i2c7 {
> + pinctrl-0 = <&i2c7_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> + clock-frequency = <400000>;
> +
> + adv7535: hdmi@3d {
> + compatible = "adi,adv7535";
> + reg = <0x3d>, <0x4d>, <0x2d>, <0x5d>;
> + reg-names = "main", "edid", "cec", "packet";
> + clocks = <&osc1>;
> + clock-names = "cec";
> + avdd-supply = <®_1p8v_adv>;
> + dvdd-supply = <®_1p8v_adv>;
> + pvdd-supply = <®_1p8v_adv>;
> + a2vdd-supply = <®_1p8v_adv>;
> + v3p3-supply = <®_3p3v_adv>;
> + v1p2-supply = <®_1p8v_adv>;
> + adi,dsi-lanes = <4>;
> + interrupts-extended = <&pinctrl RZG3E_GPIO(L, 4) IRQ_TYPE_EDGE_FALLING>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7535_in: endpoint {
> + remote-endpoint = <&dsi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7535_out: endpoint {
> + remote-endpoint = <&dsi_to_hdmi_out>;
> + };
> + };
> + };
> + };
> +};
> +
> &i3c {
> pinctrl-0 = <&i3c_pins>;
> pinctrl-names = "default";
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/4] ASoC: dt-bindings: Add support for the GPIOs driven amplifier
From: Mark Brown @ 2026-04-08 13:14 UTC (permalink / raw)
To: Rob Herring
Cc: Herve Codina, Liam Girdwood, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, Jaroslav Kysela, Takashi Iwai, linux-sound,
devicetree, linux-kernel, Christophe Leroy, Thomas Petazzoni
In-Reply-To: <20260408122901.GA42727-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 368 bytes --]
On Wed, Apr 08, 2026 at 07:29:01AM -0500, Rob Herring wrote:
> On Mon, Mar 30, 2026 at 12:16:06PM +0200, Herve Codina wrote:
> > +dependencies:
> > + gain-points: [ gain-gpios ]
> > + gain-range: [ gain-gpios ]
> > + gain-labels: [ gain-gpios ]
> gain-gpios is really optional?
You've still got mute control, and power up/down - each feature should
be optional.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/5] arm64: dts: qcom: qcs8550: add QCS8550 RB5Gen2 board support
From: Konrad Dybcio @ 2026-04-08 13:15 UTC (permalink / raw)
To: Neil Armstrong, jsandom, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <ce9061ea-8961-4d5a-bbb0-b4f50b7e6d29@linaro.org>
On 4/8/26 2:35 PM, Neil Armstrong wrote:
> On 4/8/26 11:57, Konrad Dybcio wrote:
>> On 4/7/26 5:46 PM, Joe Sandom via B4 Relay wrote:
>>> From: Joe Sandom <jsandom@axon.com>
>>>
>>> The RB5gen2 is an embedded development platform for the
>>> QCS8550, based on the Snapdragon 8 Gen 2 SoC (SM8550).
>>
>> [...]
>>
>>
>>> + /* Lontium LT9611UXC fails FW upgrade and has timeouts with geni-i2c */
>>> + /* Workaround is to use bit-banged I2C */
>>
>> Interesting.. I was under the impression that it was only an issue on
>> RB1 and RB2 boards.. perhaps we're missing some magic register write..
>
> On the SM8650-HDK, the HDMI i2c is shared with the battmgr in ADSP, causing a lot
> of issues... the only solution is [1] to declare the bus shared and use GPI DMA.
> I assume it's the same here.
Ohhhh hmm.. doesn't seem to be the case on RB1 but I wouldn't
completely rule that out either (maybe something is poking at the
bus regardless of its usefulness..)
> Sharing the same bus between APPS and ADSP is a weird feat... It seems that having
> 26 i2c busses and 212 gpios available on the system is not enough.
That's only the tip of the iceberg..
Konrad
^ permalink raw reply
* [PATCH net-next v5 1/3] dt-bindings: net: document Microchip PIC64-HPSC/HX MDIO controller
From: Charles Perry @ 2026-04-08 13:18 UTC (permalink / raw)
To: netdev
Cc: MameMaria.Mbaye, Charles Perry, Conor Dooley, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-kernel
In-Reply-To: <20260408131821.1145334-1-charles.perry@microchip.com>
This MDIO hardware is based on a Microsemi design supported in Linux by
mdio-mscc-miim.c. However, The register interface is completely different
with pic64hpsc, hence the need for separate documentation.
The hardware supports C22 and C45.
The documentation recommends an input clock of 156.25MHz and a prescaler
of 39, which yields an MDIO clock of 1.95MHz.
The hardware supports an interrupt pin to signal transaction completion
which is not strictly needed as the software can also poll a "TRIGGER"
bit for this.
Signed-off-by: Charles Perry <charles.perry@microchip.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Notes:
Changes in v5:
- Collect Conor's Acked-by
- Remove the "|" in "description: |" (Rob)
- Don't mention how many instances of the MDIO controller there are (Rob)
- Hex addresses are now in lowercase (Rob)
- Drop the phy DT label in the example (Rob)
Changes in v4: none
Changes in v3: none
Changes in v2:
- Make "clocks" and "interrupts" required (Andrew)
- Add a default value to "clock-frequency" (Andrew)
Changes in v5: none
Changes in v4: none
Changes in v3: none
Changes in v2:
- Make "clocks" and "interrupts" required (Andrew)
- Add a default value to "clock-frequency" (Andrew)
.../net/microchip,pic64hpsc-mdio.yaml | 68 +++++++++++++++++++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
diff --git a/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
new file mode 100644
index 000000000000..20f29b71566b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/microchip,pic64hpsc-mdio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC64-HPSC/HX MDIO controller
+
+maintainers:
+ - Charles Perry <charles.perry@microchip.com>
+
+description:
+ This is the MDIO bus controller present in Microchip PIC64-HPSC/HX SoCs. It
+ supports C22 and C45 register access and is named "MDIO Initiator" in the
+ documentation.
+
+allOf:
+ - $ref: mdio.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: microchip,pic64hpsc-mdio
+ - items:
+ - const: microchip,pic64hx-mdio
+ - const: microchip,pic64hpsc-mdio
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ default: 2500000
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ mdio@4000c21e000 {
+ compatible = "microchip,pic64hpsc-mdio";
+ reg = <0x400 0x0c21e000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&svc_clk>;
+ interrupt-parent = <&saplic0>;
+ interrupts = <168 IRQ_TYPE_LEVEL_HIGH>;
+
+ ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+ };
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v5 0/3] Add support for PIC64-HPSC/HX MDIO controller
From: Charles Perry @ 2026-04-08 13:18 UTC (permalink / raw)
To: netdev
Cc: MameMaria.Mbaye, Charles Perry, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiner Kallweit, Russell King,
devicetree
Hello,
This series adds a driver for the two MDIO controllers of PIC64-HPSC/HX.
The hardware supports C22 and C45 but only C22 is implemented for now.
This MDIO hardware is based on a Microsemi design supported in Linux by
mdio-mscc-miim.c. However, The register interface is completely different
with pic64hpsc, hence the need for a separate driver.
The documentation recommends an input clock of 156.25MHz and a prescaler of
39, which yields an MDIO clock of 1.95MHz.
This was tested on Microchip HB1301 evalkit which has a VSC8574 and a
VSC8541. I've tested with bus frequencies of 0.6, 1.95 and 2.5 MHz.
This series also adds a PHY write barrier when disabling PHY interrupts as
discussed in [1].
Thanks,
Charles
[1]: https://lore.kernel.org/all/acvUqDgepCIScs8M@shell.armlinux.org.uk/
Changes in v5:
- 1/3: Collect Conor's Acked-by
- 1/3: Remove the "|" in "description: |" (Rob)
- 1/3: Don't mention how many instances of the MDIO controller there are
(Rob)
- 1/3: Hex addresses are now in lowercase (Rob)
- 1/3: Drop the phy DT label in the example (Rob)
- 3/3: Support MDIO controllers that only support C45 (Russell, Andrew)
Changes in v4:
- 2/3: return FIELD_GET() directly instead of using "ret" (Russell)
- 3/3: Add the PHY barrier patch (Russell, Andrew)
Changes in v3:
- 2/2: Add a MAINTAINERS entry (Jakub)
Changes in v2:
- 1/2: Make "clocks" and "interrupts" required (Andrew)
- 1/2: Add a default value to "clock-frequency" (Andrew)
- 2/2: Remove #define for unused registers (Maxime)
- 2/2: Add "c22" to clause 22 read/write ops (Maxime)
- 2/2: Remove the call to platform_set_drvdata() (Andrew)
- 2/2: Make the clock mandatory (Andrew)
- 2/2: Use 2.5MHz if no clock-frequency was specified (Andrew)
- 2/2: Change the error message for bad clock-frequency (Andrew)
- 2/2: Fix a use without initialization on bus_freq (Andrew)
CC: Andrew Lunn <andrew+netdev@lunn.ch>
CC: "David S. Miller" <davem@davemloft.net>
CC: Eric Dumazet <edumazet@google.com>
CC: Jakub Kicinski <kuba@kernel.org>
CC: Paolo Abeni <pabeni@redhat.com>
CC: Rob Herring <robh@kernel.org>
CC: Krzysztof Kozlowski <krzk+dt@kernel.org>
CC: Conor Dooley <conor+dt@kernel.org>
CC: Heiner Kallweit <hkallweit1@gmail.com>
CC: Russell King <linux@armlinux.org.uk>
CC: netdev@vger.kernel.org
CC: devicetree@vger.kernel.org
Charles Perry (3):
dt-bindings: net: document Microchip PIC64-HPSC/HX MDIO controller
net: mdio: add a driver for PIC64-HPSC/HX MDIO controller
net: phy: add a PHY write barrier when disabling interrupts
.../net/microchip,pic64hpsc-mdio.yaml | 68 +++++++
MAINTAINERS | 6 +
drivers/net/mdio/Kconfig | 7 +
drivers/net/mdio/Makefile | 1 +
drivers/net/mdio/mdio-pic64hpsc.c | 190 ++++++++++++++++++
drivers/net/phy/phy.c | 25 ++-
6 files changed, 296 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
create mode 100644 drivers/net/mdio/mdio-pic64hpsc.c
--
2.47.3
^ permalink raw reply
* Re: [PATCH v6 01/21] clk: renesas: rzv2h: Add PLLDSI clk mux support
From: Geert Uytterhoeven @ 2026-04-08 13:19 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, laurent.pinchart, linux-renesas-soc, biju.das.jz,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Turquette, Stephen Boyd, Magnus Damm, Laurent Pinchart,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <24d3853ca2522df21e6a071a23e23ba4ca4b7276.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, 8 Apr 2026 at 12:38, Tommaso Merciai
<tommaso.merciai.xr@bp.renesas.com> wrote:
> Add PLLDSI clk mux support to select PLLDSI clock from different clock
> sources.
>
> Introduce the DEF_PLLDSI_SMUX() macro to define these muxes and register
> them in the clock driver.
>
> Extend the determine_rate callback to calculate and propagate PLL
> parameters via rzv2h_get_pll_dtable_pars() when LVDS output is selected,
> using a new helper function rzv2h_cpg_plldsi_smux_lvds_determine_rate().
>
> The CLK_SMUX2_DSI{0,1}_CLK clock multiplexers select between two paths
> with different duty cycles:
>
> - CDIV7_DSIx_CLK (LVDS path, parent index 0): asymmetric H/L=4/3 duty (4/7)
> - CSDIV_DSIx (DSI/RGB path, parent index 1): symmetric 50% duty (1/2)
>
> Implement rzv2h_cpg_plldsi_smux_{get,set}_duty_cycle clock operations to
> allow the DRM driver to query and configure the appropriate clock path
> based on the required output duty cycle.
>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> ---
> v5->v6:
> - Fixed rzv2h_cpg_plldsi_smux_clk_register() removed u8 width, mask
> variables and replaced with direct use of smux.width and clk_div_mask(smux.width).
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH V3 1/9] dt-bindings: iio: imu: icm42607: Add devicetree binding
From: Rob Herring @ 2026-04-08 13:19 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260330195853.392877-2-macroalpha82@gmail.com>
On Mon, Mar 30, 2026 at 02:58:45PM -0500, Chris Morgan wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
Subject space is limited, so don't say devicetree binding twice:
dt-bindings: iio: imu: Add Invensense ICM42607
> Add devicetree binding for the Invensense ICM42607 and Invensense
> ICM42607P inertial measurement unit. This unit is a combined
> accelerometer, gyroscope, and thermometer available via I2C or SPI.
>
> This device is functionally very similar to the icm42600 series with a
> very different register layout.
Similar enough to use the same binding schema?
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> ---
> .../bindings/iio/imu/invensense,icm42607.yaml | 95 +++++++++++++++++++
> 1 file changed, 95 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/imu/invensense,icm42607.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm42607.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm42607.yaml
> new file mode 100644
> index 000000000000..bbacdee5b906
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42607.yaml
> @@ -0,0 +1,95 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/imu/invensense,icm42607.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: InvenSense ICM-42607 Inertial Measurement Unit
> +
> +maintainers:
> + - Chris Morgan <macromorgan@hotmail.com>
> +
> +description: |
Don't need '|'.
> + 6-axis MotionTracking device that combines a 3-axis gyroscope and a 3-axis
> + accelerometer.
> +
> +properties:
> + compatible:
> + enum:
> + - invensense,icm42607
> + - invensense,icm42607p
blank line
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + minItems: 1
> + maxItems: 2
> +
> + interrupt-names:
> + minItems: 1
> + maxItems: 2
> + items:
> + enum:
> + - INT1
> + - INT2
> +
> + drive-open-drain:
> + type: boolean
> +
> + mount-matrix: true
> +
> + spi-cpha: true
> + spi-cpol: true
> +
> + vdd-supply:
> + description: Regulator that provides power to the sensor
> +
> + vddio-supply:
> + description: Regulator that provides power to the bus
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +allOf:
> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + icm42607p@68 {
> + compatible = "invensense,icm42607p";
> + reg = <0x68>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
> + interrupt-names = "INT1";
> + vdd-supply = <&vdd>;
> + vddio-supply = <&vddio>;
> + };
> + };
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + icm42607p@0 {
> + compatible = "invensense,icm42607p";
> + reg = <0>;
> + spi-max-frequency = <24000000>;
> + spi-cpha;
> + spi-cpol;
> + interrupt-parent = <&gpio1>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> + interrupt-names = "INT1";
> + vdd-supply = <&vdd>;
> + vddio-supply = <&vddio>;
> + };
> + };
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 2/2] pwm: clk-pwm: add GPIO and pinctrl support for constant output levels
From: Xilin Wu @ 2026-04-08 13:19 UTC (permalink / raw)
To: Nikita Travkin
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-pwm, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <8030cac3703f9aa1b7a8b476ad92aeae@trvn.ru>
On 4/8/2026 6:42 PM, Nikita Travkin wrote:
> Xilin Wu писал(а) 08.04.2026 15:07:
>> The clk-pwm driver cannot guarantee a defined output level when the
>> PWM is disabled or when 0%/100% duty cycle is requested, because the
>> pin state when the clock is stopped is hardware-dependent.
>>
>> Add optional GPIO and pinctrl support: when a GPIO descriptor and
>> pinctrl states ("default" for clock mux, "gpio" for GPIO mode) are
>> provided in the device tree, the driver switches the pin to GPIO mode
>> and drives the appropriate level for disabled/0%/100% states. For
>> normal PWM output, the pin is switched back to its clock function mux.
>>
>> If no GPIO is provided, the driver falls back to the original
>> clock-only behavior.
>>
>> Signed-off-by: Xilin Wu <sophon@radxa.com>
>> ---
>> drivers/pwm/pwm-clk.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++---
>> 1 file changed, 80 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/pwm/pwm-clk.c b/drivers/pwm/pwm-clk.c
>> index f8f5af57acba..d7d8d2c2dd0f 100644
>> --- a/drivers/pwm/pwm-clk.c
>> +++ b/drivers/pwm/pwm-clk.c
>> @@ -11,11 +11,20 @@
>> * - Due to the fact that exact behavior depends on the underlying
>> * clock driver, various limitations are possible.
>> * - Underlying clock may not be able to give 0% or 100% duty cycle
>> - * (constant off or on), exact behavior will depend on the clock.
>> + * (constant off or on), exact behavior will depend on the clock,
>> + * unless a gpio pinctrl state is supplied.
>> * - When the PWM is disabled, the clock will be disabled as well,
>> - * line state will depend on the clock.
>> + * line state will depend on the clock, unless a gpio pinctrl
>> + * state is supplied.
>> * - The clk API doesn't expose the necessary calls to implement
>> * .get_state().
>> + *
>> + * Optionally, a GPIO descriptor and pinctrl states ("default" and
>> + * "gpio") can be provided. When a constant output level is needed
>> + * (0% duty, 100% duty, or disabled), the driver switches the pin to
>> + * GPIO mode and drives the appropriate level. For normal PWM output
>> + * the pin is switched back to its clock function mux. If no GPIO is
>> + * provided, the driver falls back to the original clock-only behavior.
>> */
>>
>> #include <linux/kernel.h>
>> @@ -25,11 +34,17 @@
>> #include <linux/of.h>
>> #include <linux/platform_device.h>
>> #include <linux/clk.h>
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/pinctrl/consumer.h>
>> #include <linux/pwm.h>
>>
>> struct pwm_clk_chip {
>> struct clk *clk;
>> bool clk_enabled;
>> + struct pinctrl *pinctrl;
>> + struct pinctrl_state *pins_default; /* clock function mux */
>> + struct pinctrl_state *pins_gpio; /* GPIO mode */
>> + struct gpio_desc *gpiod;
>> };
>>
>> static inline struct pwm_clk_chip *to_pwm_clk_chip(struct pwm_chip *chip)
>> @@ -45,14 +60,36 @@ static int pwm_clk_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>> u32 rate;
>> u64 period = state->period;
>> u64 duty_cycle = state->duty_cycle;
>> + bool constant_level = false;
>> + int gpio_value = 0;
>>
>> if (!state->enabled) {
>> - if (pwm->state.enabled) {
>> + constant_level = true;
>> + gpio_value = 0;
>> + } else if (state->duty_cycle == 0) {
>> + constant_level = true;
>> + gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 1 : 0;
>> + } else if (state->duty_cycle >= state->period) {
>> + constant_level = true;
>> + gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 0 : 1;
>> + }
>> +
>
> So I'm looking at it again, and I'm a bit confused.
>
> Old behavior was:
> - pwm was enabled and being disabled -> stop the clock and hope state is 0;
> - pwm is still enabled but
> - duty=0% -> set clk duty to 0%
> - duty=100% -> set clk duty to 100%
>
> New behavior if we have gpio:
> - pwm was enabled and being disabled -> constant 0
> - pwm is still enabled but
> - duty=0% -> constant 0
> - duty=100% -> constant 1
>
> New behavior if we don't have gpio:
> Same as above but
> - if we need constant 0 -> clock is halted and we pray it's 0
> - if we need constant 1 -> clock is halted and we pray it's 1 (??)
>
> Per my recollection, when I wrote this driver 5 years ago, I've manually
> verified that at least on qcom setting duty cycle to 0% and 100% worked
> properly, so this feels like it would regress it if left as-is...
>
> (Btw I wonder what's the platform you need this for?)
>
I took a careful look at clk_rcg2_set_duty_cycle() in
drivers/clk/qcom/clk-rcg2.c, and I believe the Qualcomm RCG2 MND counter
cannot produce a true 0% or 100% duty cycle. For a 0% duty request, the
actual duty cycle can become very small, but never exactly zero.
Likewise, for a 100% duty request, it can get very close to 100%, but
not exactly 100%.
I agree that the current change may cause a regression. Do you think it
would make more sense to keep the old behavior when no GPIO is
available, and still set the clock duty cycle to 0% or 100% in that case?
We need this for many of our future Qualcomm-based products, because the
PMIC that comes with the SoC usually provides only one PWM output.
>> + if (constant_level) {
>> + if (pcchip->gpiod) {
>> + gpiod_direction_output(pcchip->gpiod, gpio_value);
>> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
>> + }
>> + if (pcchip->clk_enabled) {
>> clk_disable(pcchip->clk);
>> pcchip->clk_enabled = false;
>> }
>> return 0;
>> - } else if (!pwm->state.enabled) {
>> + }
>> +
>> + if (pcchip->gpiod)
>> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_default);
>> +
>> + if (!pcchip->clk_enabled) {
>> ret = clk_enable(pcchip->clk);
>> if (ret)
>> return ret;
>> @@ -97,6 +134,45 @@ static int pwm_clk_probe(struct platform_device *pdev)
>> return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->clk),
>> "Failed to get clock\n");
>>
>> + pcchip->pinctrl = devm_pinctrl_get(&pdev->dev);
>> + if (IS_ERR(pcchip->pinctrl)) {
>> + ret = PTR_ERR(pcchip->pinctrl);
>> + pcchip->pinctrl = NULL;
>> + if (ret == -EPROBE_DEFER)
>> + return ret;
>> + } else {
>> + pcchip->pins_default = pinctrl_lookup_state(pcchip->pinctrl,
>> + PINCTRL_STATE_DEFAULT);
>> + pcchip->pins_gpio = pinctrl_lookup_state(pcchip->pinctrl,
>> + "gpio");
>> + if (IS_ERR(pcchip->pins_default) || IS_ERR(pcchip->pins_gpio))
>> + pcchip->pinctrl = NULL;
>> + }
>> +
>> + /*
>> + * Switch to GPIO pinctrl state before requesting the GPIO.
>> + * The driver core has already applied the "default" state, which
>> + * muxes the pin to the clock function and claims it. We must
>> + * release that claim first so that gpiolib can request the pin.
>> + */
>> + if (pcchip->pinctrl)
>> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
>> +
>> + pcchip->gpiod = devm_gpiod_get_optional(&pdev->dev, NULL, GPIOD_ASIS);
>> + if (IS_ERR(pcchip->gpiod))
>> + return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->gpiod),
>> + "Failed to get gpio\n");
>> +
>> + /*
>> + * If pinctrl states were found but no GPIO was provided, the pin is
>> + * stuck in GPIO mode from the switch above. Restore the default
>> + * (clock-function) mux and fall back to clock-only operation.
>> + */
>
> Feels slightly weird to silently allow "broken" DT, it would make no sense
> for it to have "gpio" pinctrl and not have a gpio defined, would it?
>
> Perhaps it makes more sense to put getting a gpio under having pins_gpio
> and make it strict, so two allowed states for the driver would be either
> no pinctrl-1 and no gpio, or having both at the same time?
>
> (maybe then also worth adding cross dependency of pinctrl-1 and gpio in
> the binding, it's one way only currently, not sure what's the correct
> way to describe it tho)
>
> Nikita
>
Yeah, good point. Having a gpio pinctrl state without an actual gpio
property is indeed a broken DT and there's no reason to silently work
around it. Do you think the following change would work?
if (pcchip->pinctrl) {
pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
pcchip->gpiod = devm_gpiod_get(&pdev->dev, NULL, GPIOD_ASIS);
if (IS_ERR(pcchip->gpiod))
return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->gpiod),
"GPIO required when 'gpio' pinctrl state is present\n");
}
>> + if (pcchip->pinctrl && !pcchip->gpiod) {
>> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_default);
>> + pcchip->pinctrl = NULL;
>> + }
>> +
>> chip->ops = &pwm_clk_ops;
>>
>> ret = pwmchip_add(chip);
>
--
Best regards,
Xilin Wu <sophon@radxa.com>
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: clock: qcom-rpmhcc: Add RPMHCC bindings for Hawi
From: Rob Herring (Arm) @ 2026-04-08 13:26 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: Bjorn Andersson, Taniya Das, linux-clk, Michael Turquette,
Krzysztof Kozlowski, Taniya Das, Stephen Boyd, Mike Tipton,
devicetree, linux-arm-msm, linux-kernel, Conor Dooley
In-Reply-To: <20260330-clk-hawi-v1-1-c2a663e1d35b@oss.qualcomm.com>
On Mon, 30 Mar 2026 17:34:56 -0700, Vivek Aknurwar wrote:
> Update documentation for the RPMH clock controller on the Hawi SoC.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml | 1 +
> include/dt-bindings/clock/qcom,rpmh.h | 2 ++
> 2 files changed, 3 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/7] dt-bindings: clock: qcom: Add Hawi TCSR clock controller
From: Rob Herring (Arm) @ 2026-04-08 13:26 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: Taniya Das, Stephen Boyd, Taniya Das, linux-kernel, Conor Dooley,
Bjorn Andersson, Mike Tipton, linux-clk, Michael Turquette,
devicetree, Krzysztof Kozlowski, linux-arm-msm
In-Reply-To: <20260330-clk-hawi-v1-2-c2a663e1d35b@oss.qualcomm.com>
On Mon, 30 Mar 2026 17:34:57 -0700, Vivek Aknurwar wrote:
> Add bindings documentation for TCSR clock controller on the Hawi SoC.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
> .../devicetree/bindings/clock/qcom,sm8550-tcsr.yaml | 2 ++
> include/dt-bindings/clock/qcom,hawi-tcsrcc.h | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: milos: Add IMEM node
From: Konrad Dybcio @ 2026-04-08 13:26 UTC (permalink / raw)
To: Luca Weiss, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260407-milos-imem-v2-2-5084a490340c@fairphone.com>
On 4/7/26 5:11 PM, Luca Weiss wrote:
> Add a node for the IMEM found on Milos, which contains pil-reloc-info
> and the modem tables for IPA, among others.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> Not happy about the names of the subnodes. pil-reloc-sram is not allowed
> it seems. Glymur calls it "pil-sram@94c", not sure this is wanted?
Not really.. I had a patch for that, I'll send it rn
Konrad
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: clock: qcom: Add Hawi global clock controller
From: Rob Herring (Arm) @ 2026-04-08 13:26 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: Bjorn Andersson, linux-kernel, linux-arm-msm, Taniya Das,
Michael Turquette, Stephen Boyd, Taniya Das, devicetree,
Conor Dooley, Mike Tipton, Krzysztof Kozlowski, linux-clk
In-Reply-To: <20260330-clk-hawi-v1-3-c2a663e1d35b@oss.qualcomm.com>
On Mon, 30 Mar 2026 17:34:58 -0700, Vivek Aknurwar wrote:
> Add device tree bindings for the global clock controller on the Hawi SoC.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
> .../devicetree/bindings/clock/qcom,hawi-gcc.yaml | 63 +++++
> include/dt-bindings/clock/qcom,hawi-gcc.h | 253 +++++++++++++++++++++
> 2 files changed, 316 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 1/7] dt-bindings: pwm: Document Tegra264 controller
From: Rob Herring (Arm) @ 2026-04-08 13:27 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Uwe Kleine-König, Krzysztof Kozlowski,
devicetree, linux-kernel, linux-tegra, Conor Dooley, linux-pwm,
Thierry Reding, Jonathan Hunter
In-Reply-To: <20260331-t264-pwm-v4-1-c041659677cf@nvidia.com>
On Tue, 31 Mar 2026 11:12:13 +0900, Mikko Perttunen wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Add a new compatible string for the PWM controller found on Tegra264.
> The controller is similar to earlier generations but not compatible
> with them.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> [mperttunen: Drop extra Tegra194 compatible string]
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH] dt-bindings: sram: Allow multiple-word prefixes to sram subnode
From: Konrad Dybcio @ 2026-04-08 13:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: devicetree, linux-kernel, Luca Weiss, Konrad Dybcio
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Currently, foo-sram is allowed, but foo-bar-sram is not.
Allow it so that more complex names aren't unnecessarily simplified.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
Documentation/devicetree/bindings/sram/sram.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index c451140962c8..b65c2ff846f1 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -65,7 +65,7 @@ properties:
type: boolean
patternProperties:
- "^([a-z0-9]*-)?sram(-section)?@[a-f0-9]+$":
+ "^([a-z0-9]*-|)+sram(-section)?@[a-f0-9]+$":
type: object
description:
Each child of the sram node specifies a region of reserved memory.
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-topic-sram_dtbindings_misc-5e8834f63d51
Best regards,
--
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v5 2/3] dt-bindings: mfd: aspeed,ast2x00-scu: Describe AST2700 SCU0
From: Rob Herring @ 2026-04-08 13:31 UTC (permalink / raw)
To: Billy Tsai
Cc: Krzysztof Kozlowski, Lee Jones, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Linus Walleij, Bartosz Golaszewski,
Ryan Chen, Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <OSQPR06MB725204B2FAE543A71AEA52C38B51A@OSQPR06MB7252.apcprd06.prod.outlook.com>
On Thu, Apr 02, 2026 at 06:14:06AM +0000, Billy Tsai wrote:
> > > AST2700 consists of two interconnected SoC instances, each with its own
> > > System Control Unit (SCU). The SCU0 provides pin control, interrupt
> > > controllers, clocks, resets, and address-space mappings for the
> > > Secondary and Tertiary Service Processors (SSP and TSP).
> > >
> > > Describe the SSP/TSP address mappings using the standard
> > > memory-region and memory-region-names properties.
> > >
> > > Disallow legacy child nodes that are not present on AST2700, including
> > > p2a-control and smp-memram. The latter is unnecessary as software can
> > > access the scratch registers via the SCU syscon.
> > >
> > > Also allow the AST2700 SoC0 pin controller to be described as a child
> > > node of the SCU0, and add an example illustrating the SCU0 layout,
> > > including reserved-memory, interrupt controllers, and pinctrl.
> > >
> > > Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
> > > ---
> > > .../bindings/mfd/aspeed,ast2x00-scu.yaml | 117 +++++++++++++++++++++
> > > 1 file changed, 117 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > > index a87f31fce019..86d51389689c 100644
> > > --- a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > > +++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > > @@ -46,6 +46,9 @@ properties:
> > > '#reset-cells':
> > > const: 1
> > >
> > > + memory-region: true
> > > + memory-region-names: true
>
> > Missing constraints. From where did you take such syntax (so I can fix
> > it)?
>
> The intention was to constrain these properties conditionally for
> AST2700 SCU0 as done further down in the patch.
>
> I can update the binding so that memory-region and memory-region-names
> have baseline constraints (e.g. minItems and maxItems), and then refine them in the
> conditional branches for AST2700SCU0, AST2700SCU1 and others
>
> memory-region:
> minItems: 2
> maxItems: 3
> memory-region-names:
> minItems: 2
> maxItems: 3
As of this patch, you don't need that. You can just define the regions
and names at the top-level. And the conditional schema only needs to
disallow them for the appropriate case.
Rob
^ permalink raw reply
* Re: [PATCH v6 06/21] clk: renesas: r9a09g047: Add support for SMUX2_DSI{0,1}_CLK
From: Geert Uytterhoeven @ 2026-04-08 13:23 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, laurent.pinchart, linux-renesas-soc, biju.das.jz,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Turquette, Stephen Boyd, Magnus Damm, Laurent Pinchart,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <9595f56ce8ab120477bfc11eaafb0f2b655d049a.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, 8 Apr 2026 at 12:38, Tommaso Merciai
<tommaso.merciai.xr@bp.renesas.com> wrote:
> Add support for the SMUX2_DSI0_CLK and SMUX2_DSI1_CLK clock muxes
> present on the r9a09g047 SoC.
>
> These muxes select between CDIV7_DSI{0,1}_CLK and CSDIV_2to16_PLLDSI{0,1}
> using the CPG_SSEL3 register (SELCTL0 and SELCTL1 bits).
>
> According to the hardware manual, when LVDS0 or LVDS1 outputs are used,
> SELCTL0 or SELCTL1 must be set accordingly.
>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 5/6] drm/msm/adreno: add Adreno 810 GPU support
From: Konrad Dybcio @ 2026-04-08 13:32 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Akhil P Oommen,
Bjorn Andersson, Luca Weiss, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel
In-Reply-To: <hvcBm15eFRX0ZonD34zzneuD50ceOzKGo1pE8LkQrQL1qEb4t0pEA4ankxEViVr7lwghJeGOoYp2ub8Ti2idrIzMfBXHBqnXejwukigxz9s=@pm.me>
On 4/3/26 12:14 AM, Alexander Koskovich wrote:
> On Wednesday, April 1st, 2026 at 6:15 AM, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
>
>>
>> I may be on an older tag or something, but:
>>
>> $ diff /tmp/downstream.txt /tmp/upstream.txt
>> 24a25
>>> { GEN7_SP_READ_SEL, 0x0001ff00, BIT(PIPE_NONE) },
>> 27,28c28,29
>> < { GEN8_TPL1_DBG_ECO_CNTL1, 0x04000724, BIT(PIPE_NONE) },
>> < { GEN8_UCHE_MODE_CNTL, 0x00020000, BIT(PIPE_NONE) },
>> ---
>>> { GEN8_TPL1_DBG_ECO_CNTL1, 0x04000720, BIT(PIPE_NONE) },
>>> { GEN8_UCHE_MODE_CNTL, 0x80080000, BIT(PIPE_NONE) },
>> 31,32c32
>> < /* Disable write slow pointer in data phase queue */
>> < { GEN8_UCHE_HW_DBG_CNTL, BIT(8), BIT(PIPE_NONE) },
>> ---
>>> { GEN8_UCHE_CACHE_WAYS, 0x00080000, BIT(PIPE_NONE) },
>>
>>
>>> +};
>>> +
>>> +static const u32 a810_protect_regs[] = {
>>
>> $ diff /tmp/downstream.txt /tmp/upstream.txt
>>
>> < A6XX_PROTECT_NORDWR(0x0ae00, 0x0),
>> < A6XX_PROTECT_NORDWR(0x0ae02, 0x4),
>> ---
>>> A6XX_PROTECT_NORDWR(0x0ae00, 0x6),
>>
>> -> the difference is that
>>
>> SP_DBG_ECO_CNTL and SP_ADDR_MODE_CNTL are not protected
>>
>> that might have been a part of the ^ difference
>
> Going back for v2 and making sure this is 1:1 to GRAPHICS.LA.14.0.r5-03100-lanai.0, I
> think I was going back and forth between my own downstream from the OEM,
> GRAPHICS.LA.14.0.r5 and GRAPHICS.LA.15.0.r1.
>
> GRAPHICS.LA.15.0.r1 has gen8_3_0 support, but I'm not sure if there are any
> devices that actually ship with it on that branch. Seemed to be fairly out
> of sync from LA.14.
>
>>
>> Also it may be that the better name for this table is a830_protect_regs[]
>
> Can you elaborate on this? The only names I know this GPU by are "a810" and
> "gen8_3_0".
gen8_0_x is A830 (8750), which seems to have some sort of a common lineage
Konrad
^ permalink raw reply
* RE: [PATCH v4 1/2] dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
From: Biju Das @ 2026-04-08 13:33 UTC (permalink / raw)
To: Mark Brown, biju.das.au
Cc: Fabrizio Castro, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, magnus.damm, linux-spi@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Prabhakar Mahadev Lad,
Krzysztof Kozlowski
In-Reply-To: <b36fa28f-4885-433b-bc5b-c0069636663c@sirena.org.uk>
Hi Mark,
Thanks for the feedback.
> -----Original Message-----
> From: Mark Brown <broonie@kernel.org>
> Sent: 08 April 2026 13:07
> Subject: Re: [PATCH v4 1/2] dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
>
> On Wed, Apr 08, 2026 at 09:54:14AM +0100, Biju wrote:
> > From: Biju Das <biju.das.jz@bp.renesas.com>
> >
> > Document RSPI IP found on the RZ/G3L SoC. The RSPI IP is compatible
> > with the RZ/V2H RSPI IP, but has 2 clocks compared to 3 on RZ/V2H.
>
> Please submit patches using subject lines reflecting the style for the subsystem, this makes it easier
> for people to identify relevant patches.
> Look at what existing commits in the area you're changing are doing and make sure your subject lines
> visually resemble what they're doing.
> There's no need to resubmit to fix this alone.
Oops, I missed it, it supposed to be "spi: dt-bindings: renesas,rzv2h-rspi"
I will take care next time.
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: renesas: Add missing #mux-state-cells to usb2phy-reset nodes
From: Tommaso Merciai @ 2026-04-08 13:38 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: tomm.merciai, peda, p.zabel, linux-renesas-soc, biju.das.jz,
Magnus Damm, Rob Herring, Krzysztof Kozlowski, Ulf Hansson,
Conor Dooley, devicetree, linux-kernel
In-Reply-To: <CAMuHMdXHhd150mpUT5-VPcHW0W5Hs-rFC-Bjrc7Z8Szco9P_Xw@mail.gmail.com>
Hi Geert,
Thanks for your comments.
On Wed, Apr 08, 2026 at 03:07:44PM +0200, Geert Uytterhoeven wrote:
> Hi Tommaso,
>
> On Tue, 7 Apr 2026 at 17:35, Tommaso Merciai
> <tommaso.merciai.xr@bp.renesas.com> wrote:
> > The renesas,rzv2h-usb2phy-reset binding schema defines #mux-state-cells as a
> > required property. Add it to the USB2 PHY reset nodes in the RZ/V2H and RZ/V2N
> > device trees to fix dtbs_check warnings.
> >
> > "arch/arm64/boot/dts/renesas/r9a09g056n48-rzv2n-evk.dtb: usb20phy-reset@15830000 (renesas,r9a09g056-usb2phy-reset): '#mux-state-cells' is a required property"
> > "arch/arm64/boot/dts/renesas/r9a09g056n48-rzv2n-evk-cn15-emmc.dtb: usb20phy-reset@15830000 (renesas,r9a09g056-usb2phy-reset): '#mux-state-cells' is a required property"
> > "arch/arm64/boot/dts/renesas/r9a09g056n48-rzv2n-evk-cn15-sd.dtb: usb20phy-reset@15830000 (renesas,r9a09g056-usb2phy-reset): '#mux-state-cells' is a required property"
> > "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dtb: usb20phy-reset@15830000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> > "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dtb: usb21phy-reset@15840000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> > "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk-cn15-emmc.dtb: usb20phy-reset@15830000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> > "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk-cn15-emmc.dtb: usb21phy-reset@15840000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> > "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk-cn15-sd.dtb: usb20phy-reset@15830000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> > "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk-cn15-sd.dtb: usb21phy-reset@15840000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> >
> > Kind Regards,
> > Tommaso
> >
> > Tommaso Merciai (2):
> > arm64: dts: renesas: r9a09g057: Add #mux-state-cells to
> > usb2{0,1}phyrst
> > arm64: dts: renesas: r9a09g056: Add #mux-state-cells to usb20phyrst
>
> Does this series supersedes "[PATCH v5 16/22] arm64: dts: renesas:
> r9a09g056: Add USB2.0 VBUS_SEL mux-controller support"[1] and "[PATCH
> v5 17/22] arm64: dts: renesas: r9a09g056: Add USB2.0 PHY VBUS internal
> regulator node"[2]?
Yes, thanks.
From v5 only [0] missing.
But I think Ulf is planning to pick [0].
I will rebase/send RZ/G3E USB2.0 dt patches later.
[0] https://patchwork.kernel.org/project/linux-renesas-soc/patch/cda933586ef7ca119dbbcef45a921c29dd517698.1775047175.git.tommaso.merciai.xr@bp.renesas.com/
Kind Regards,
Tommaso
>
> Thanks!
>
> [1] https://lore.kernel.org/c63d0a62d439a78e9ccc0b4176b84bbc32629a8e.1764241212.git.tommaso.merciai.xr@bp.renesas.com
> [2] https://lore.kernel.org/f33b5566511a946e4e909854213e75c12d89a441.1764241212.git.tommaso.merciai.xr@bp.renesas.com
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
^ permalink raw reply
* Re: [PATCH v4 net-next 01/14] dt-bindings: net: dsa: update the description of 'dsa,member' property
From: Rob Herring (Arm) @ 2026-04-08 13:40 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, kuba, andrew, linux, davem, frank.li, edumazet,
imx, pabeni, devicetree, horms, conor+dt, netdev, linuxppc-dev,
andrew+netdev, f.fainelli, linux-kernel, xiaoning.wang, krzk+dt,
vladimir.oltean, linux-arm-kernel, chleroy
In-Reply-To: <20260331113025.1566878-2-wei.fang@nxp.com>
On Tue, 31 Mar 2026 19:30:12 +0800, Wei Fang wrote:
> The current description indicates that the 'dsa,member' property cannot
> be set for a switch that is not part of any cluster. Vladimir thinks
> that this is a case where the actual technical limitation was poorly
> transposed into words when this restriction was first documented, in
> commit 8c5ad1d6179d ("net: dsa: Document new binding").
>
> The true technical limitation is that many DSA tagging protocols are
> topology-unaware, and always call dsa_conduit_find_user() with a
> switch_id of 0. Specifying a custom "dsa,member" property with a
> non-zero switch_id would break them.
>
> Therefore, for topology-aware switches, it is fine to specify this
> property for them, even if they are not part of any cluster. Our NETC
> switch is a good example which is topology-aware, the switch_id is
> carried in the switch tag, but the switch_id 0 is reserved for VEPA
> switch and cannot be used, so we need to use this property to assign
> a non-zero switch_id for it.
>
> Suggested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> ---
> Documentation/devicetree/bindings/net/dsa/dsa.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 net-next 02/14] dt-bindings: net: dsa: add NETC switch
From: Rob Herring @ 2026-04-08 13:43 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, krzk+dt, conor+dt, f.fainelli,
frank.li, chleroy, horms, linux, andrew, netdev, linux-kernel,
devicetree, linuxppc-dev, linux-arm-kernel, imx
In-Reply-To: <20260331113025.1566878-3-wei.fang@nxp.com>
On Tue, Mar 31, 2026 at 07:30:13PM +0800, Wei Fang wrote:
> Add bindings for NETC switch. This switch is a PCIe function of NETC IP,
> it supports advanced QoS with 8 traffic classes and 4 drop resilience
> levels, and a full range of TSN standards capabilities. The switch CPU
> port connects to an internal ENETC port, which is also a PCIe function
> of NETC IP. So these two ports use a light-weight "pseudo MAC" instead
> of a back-to-back MAC, because the "pseudo MAC" provides the delineation
> between switch and ENETC, this translates to lower power (less logic and
> memory) and lower delay (as there is no serialization delay across this
> link).
>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> .../bindings/net/dsa/nxp,netc-switch.yaml | 130 ++++++++++++++++++
> 1 file changed, 130 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
> new file mode 100644
> index 000000000000..5577f3ef987f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
> @@ -0,0 +1,130 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/dsa/nxp,netc-switch.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NETC Switch family
> +
> +description: >
> + The NETC presents itself as a multi-function PCIe Root Complex Integrated
> + Endpoint (RCiEP) and provides full 802.1Q Ethernet switch functionality,
> + advanced QoS with 8 traffic classes and 4 drop resilience levels, and a
> + full range of TSN standards capabilities.
> +
> + The CPU port of the switch connects to an internal ENETC. The switch and
> + the internal ENETC are fully integrated into the NETC IP, a back-to-back
> + MAC is not required. Instead, a light-weight "pseudo MAC" provides the
> + delineation between the switch and ENETC. This translates to lower power
> + (less logic and memory) and lower delay (as there is no serialization
> + delay across this link).
> +
> +maintainers:
> + - Wei Fang <wei.fang@nxp.com>
> +
> +properties:
> + compatible:
> + enum:
> + - pci1131,eef2
> +
> + reg:
> + maxItems: 1
> +
> + dsa,member:
> + description: >
> + The property indicates DSA cluster and switch index. For NETC switch,
> + the valid range of the switch index is 1 ~ 7, the index is reflected
> + in the switch tag as an indication of the switch ID where the frame
> + originated. The value 0 is reserved for ENETC VEPA switch, whose ID
> + is hardwired to zero.
> +
> +$ref: dsa.yaml#
Move this under the 'allOf' so all $ref's are together.
> +
> +patternProperties:
> + "^(ethernet-)?ports$":
'ethernet-ports' for new bindings.
> + type: object
> + additionalProperties: true
> + patternProperties:
> + "^(ethernet-)?port@[0-9a-f]$":
And 'ethernet-port'
> + type: object
> +
> + $ref: dsa-port.yaml#
> +
> + properties:
> + clocks:
> + items:
> + - description: MAC transmit/receive reference clock.
> +
> + clock-names:
> + items:
> + - const: ref
> +
> + mdio:
> + $ref: /schemas/net/mdio.yaml#
> + unevaluatedProperties: false
> + description:
> + Optional child node for switch port, otherwise use NETC EMDIO.
> +
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - dsa,member
> +
> +allOf:
> + - $ref: /schemas/pci/pci-device.yaml
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + pcie {
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + ethernet-switch@0,2 {
> + compatible = "pci1131,eef2";
> + reg = <0x200 0 0 0 0>;
> + dsa,member = <0 1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_switch>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + phy-handle = <ðphy0>;
> + phy-mode = "mii";
> + };
> +
> + port@1 {
> + reg = <1>;
> + phy-handle = <ðphy1>;
> + phy-mode = "mii";
> + };
> +
> + port@2 {
> + reg = <2>;
> + clocks = <&scmi_clk 103>;
> + clock-names = "ref";
> + phy-handle = <ðphy2>;
> + phy-mode = "rgmii-id";
> + };
> +
> + port@3 {
> + reg = <3>;
> + ethernet = <&enetc3>;
> + phy-mode = "internal";
> +
> + fixed-link {
> + speed = <2500>;
> + full-duplex;
> + pause;
> + };
> + };
> + };
> + };
> + };
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 0/3] arm-smmu-v3: Add PMCG child support and update PMU MMIO mapping
From: Peng Fan @ 2026-04-08 13:47 UTC (permalink / raw)
To: Robin Murphy
Cc: Will Deacon, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mark Rutland, linux-arm-kernel, iommu, devicetree,
linux-kernel, linux-perf-users, Peng Fan
In-Reply-To: <2c1a1694-9597-400d-b441-714225b5377b@arm.com>
On Wed, Apr 08, 2026 at 12:15:31PM +0100, Robin Murphy wrote:
>On 2026-04-08 8:51 am, Peng Fan (OSS) wrote:
>> This patch series adds proper support for describing and probing the
>> Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
>> the SMMU in Devicetree, and updates the relevant drivers accordingly.
>>
>> The SMMU v3 architecture allows an optional PMCG block, typically
>> associated with TCUs, to be implemented within the SMMU register
>> address space. For example, mmu700 PMCG is at the offset 0x2000 of the
>> TCU page 0.
>
>But what's wrong with the existing binding? Especially given that it even has
>an upstream user already:
>
>https://git.kernel.org/torvalds/c/aef9703dcbf8
>
>> Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
>> referencing the existing arm,smmu-v3-pmcg binding.
>>
>> Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
>> child nodes described in DT once the SMMU probe succeeds.
>>
>> Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
>> PMCG is described as a child node. The PMCG registers occupy a sub-region
>> of the parent SMMU MMIO window, which is already requested by the SMMU
>
>That has not been the case since 52f3fab0067d ("iommu/arm-smmu-v3: Don't
>reserve implementation defined register space") nearly 6 years ago, where the
>whole purpose was to support Arm's PMCG implementation properly. What kernel
>is this based on?
Seems I am wrong. I thought PMCG is in page 0, so there were resource
conflicts. I just retest without this patchset, all goes well.
But from dt perspective, should the TCU PMCG node be child node of
SMMU node?
Thanks,
Peng
>
>Thanks,
>Robin.
>
>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>> ---
>> Peng Fan (3):
>> dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
>> iommu/arm-smmu-v3: Populate PMU child devices from Devicetree
>> perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG
>>
>> .../devicetree/bindings/iommu/arm,smmu-v3.yaml | 10 ++++++++++
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++
>> drivers/perf/arm_smmuv3_pmu.c | 19 ++++++++++++++++---
>> 3 files changed, 29 insertions(+), 3 deletions(-)
>> ---
>> base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
>> change-id: 20260408-smmu-perf-754367fe66c8
>>
>> Best regards,
>
>
^ permalink raw reply
* Re: [PATCH v2 2/2] pwm: clk-pwm: add GPIO and pinctrl support for constant output levels
From: Nikita Travkin @ 2026-04-08 13:53 UTC (permalink / raw)
To: Xilin Wu
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-pwm, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <7BA26FC036D1C9AF+64204287-21b5-4664-ae75-be3dd54ec092@radxa.com>
Xilin Wu писал(а) 08.04.2026 18:19:
> On 4/8/2026 6:42 PM, Nikita Travkin wrote:
>> Xilin Wu писал(а) 08.04.2026 15:07:
>>> The clk-pwm driver cannot guarantee a defined output level when the
>>> PWM is disabled or when 0%/100% duty cycle is requested, because the
>>> pin state when the clock is stopped is hardware-dependent.
>>>
>>> Add optional GPIO and pinctrl support: when a GPIO descriptor and
>>> pinctrl states ("default" for clock mux, "gpio" for GPIO mode) are
>>> provided in the device tree, the driver switches the pin to GPIO mode
>>> and drives the appropriate level for disabled/0%/100% states. For
>>> normal PWM output, the pin is switched back to its clock function mux.
>>>
>>> If no GPIO is provided, the driver falls back to the original
>>> clock-only behavior.
>>>
>>> Signed-off-by: Xilin Wu <sophon@radxa.com>
>>> ---
>>> drivers/pwm/pwm-clk.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++---
>>> 1 file changed, 80 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/pwm/pwm-clk.c b/drivers/pwm/pwm-clk.c
>>> index f8f5af57acba..d7d8d2c2dd0f 100644
>>> --- a/drivers/pwm/pwm-clk.c
>>> +++ b/drivers/pwm/pwm-clk.c
>>> @@ -11,11 +11,20 @@
>>> * - Due to the fact that exact behavior depends on the underlying
>>> * clock driver, various limitations are possible.
>>> * - Underlying clock may not be able to give 0% or 100% duty cycle
>>> - * (constant off or on), exact behavior will depend on the clock.
>>> + * (constant off or on), exact behavior will depend on the clock,
>>> + * unless a gpio pinctrl state is supplied.
>>> * - When the PWM is disabled, the clock will be disabled as well,
>>> - * line state will depend on the clock.
>>> + * line state will depend on the clock, unless a gpio pinctrl
>>> + * state is supplied.
>>> * - The clk API doesn't expose the necessary calls to implement
>>> * .get_state().
>>> + *
>>> + * Optionally, a GPIO descriptor and pinctrl states ("default" and
>>> + * "gpio") can be provided. When a constant output level is needed
>>> + * (0% duty, 100% duty, or disabled), the driver switches the pin to
>>> + * GPIO mode and drives the appropriate level. For normal PWM output
>>> + * the pin is switched back to its clock function mux. If no GPIO is
>>> + * provided, the driver falls back to the original clock-only behavior.
>>> */
>>> #include <linux/kernel.h>
>>> @@ -25,11 +34,17 @@
>>> #include <linux/of.h>
>>> #include <linux/platform_device.h>
>>> #include <linux/clk.h>
>>> +#include <linux/gpio/consumer.h>
>>> +#include <linux/pinctrl/consumer.h>
>>> #include <linux/pwm.h>
>>> struct pwm_clk_chip {
>>> struct clk *clk;
>>> bool clk_enabled;
>>> + struct pinctrl *pinctrl;
>>> + struct pinctrl_state *pins_default; /* clock function mux */
>>> + struct pinctrl_state *pins_gpio; /* GPIO mode */
>>> + struct gpio_desc *gpiod;
>>> };
>>> static inline struct pwm_clk_chip *to_pwm_clk_chip(struct pwm_chip *chip)
>>> @@ -45,14 +60,36 @@ static int pwm_clk_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>>> u32 rate;
>>> u64 period = state->period;
>>> u64 duty_cycle = state->duty_cycle;
>>> + bool constant_level = false;
>>> + int gpio_value = 0;
>>> if (!state->enabled) {
>>> - if (pwm->state.enabled) {
>>> + constant_level = true;
>>> + gpio_value = 0;
>>> + } else if (state->duty_cycle == 0) {
>>> + constant_level = true;
>>> + gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 1 : 0;
>>> + } else if (state->duty_cycle >= state->period) {
>>> + constant_level = true;
>>> + gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 0 : 1;
>>> + }
>>> +
>>
>> So I'm looking at it again, and I'm a bit confused.
>>
>> Old behavior was:
>> - pwm was enabled and being disabled -> stop the clock and hope state is 0;
>> - pwm is still enabled but
>> - duty=0% -> set clk duty to 0%
>> - duty=100% -> set clk duty to 100%
>>
>> New behavior if we have gpio:
>> - pwm was enabled and being disabled -> constant 0
>> - pwm is still enabled but
>> - duty=0% -> constant 0
>> - duty=100% -> constant 1
>>
>> New behavior if we don't have gpio:
>> Same as above but
>> - if we need constant 0 -> clock is halted and we pray it's 0
>> - if we need constant 1 -> clock is halted and we pray it's 1 (??)
>>
>> Per my recollection, when I wrote this driver 5 years ago, I've manually
>> verified that at least on qcom setting duty cycle to 0% and 100% worked
>> properly, so this feels like it would regress it if left as-is...
>>
>> (Btw I wonder what's the platform you need this for?)
>>
>
> I took a careful look at clk_rcg2_set_duty_cycle() in drivers/clk/qcom/clk-rcg2.c, and I believe the Qualcomm RCG2 MND counter cannot produce a true 0% or 100% duty cycle. For a 0% duty request, the actual duty cycle can become very small, but never exactly zero. Likewise, for a 100% duty request, it can get very close to 100%, but not exactly 100%.
>
Are you aware of the hardware quick of the clock [1] where you can't get
full range if your dividers aren't configured properly? I don't know if
new hardware is different in that regard comapred to the old sd410 I was
working with, but I recall spending a while with oscilloscope until I've
figured out why I wasn't getting full range from 0 to 100%.
I'm pretty convinced I saw full coverage (i.e. flat 0 when clock is at
0% and flat 1 when clock is at 100%) but perhaps I was measuring it wrong
or I misremember as it was long ago... I still think your solution here
is clever though, as long as you don't accidentally mask bugged gcc config.
[1] https://elixir.bootlin.com/linux/v6.19/source/drivers/clk/qcom/gcc-msm8916.c#L958-L973
> I agree that the current change may cause a regression. Do you think it would make more sense to keep the old behavior when no GPIO is available, and still set the clock duty cycle to 0% or 100% in that case?
>
Yes please, keep the old behavior when there is no gpio. There are
certainly a few existing users for this and it would be sad to have
someone's backlight go out when they set it to 100% xD
> We need this for many of our future Qualcomm-based products, because the PMIC that comes with the SoC usually provides only one PWM output.
>
>>> + if (constant_level) {
>>> + if (pcchip->gpiod) {
>>> + gpiod_direction_output(pcchip->gpiod, gpio_value);
>>> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
>>> + }
>>> + if (pcchip->clk_enabled) {
>>> clk_disable(pcchip->clk);
>>> pcchip->clk_enabled = false;
>>> }
>>> return 0;
>>> - } else if (!pwm->state.enabled) {
>>> + }
>>> +
>>> + if (pcchip->gpiod)
>>> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_default);
>>> +
>>> + if (!pcchip->clk_enabled) {
>>> ret = clk_enable(pcchip->clk);
>>> if (ret)
>>> return ret;
>>> @@ -97,6 +134,45 @@ static int pwm_clk_probe(struct platform_device *pdev)
>>> return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->clk),
>>> "Failed to get clock\n");
>>> + pcchip->pinctrl = devm_pinctrl_get(&pdev->dev);
>>> + if (IS_ERR(pcchip->pinctrl)) {
>>> + ret = PTR_ERR(pcchip->pinctrl);
>>> + pcchip->pinctrl = NULL;
>>> + if (ret == -EPROBE_DEFER)
>>> + return ret;
>>> + } else {
>>> + pcchip->pins_default = pinctrl_lookup_state(pcchip->pinctrl,
>>> + PINCTRL_STATE_DEFAULT);
>>> + pcchip->pins_gpio = pinctrl_lookup_state(pcchip->pinctrl,
>>> + "gpio");
>>> + if (IS_ERR(pcchip->pins_default) || IS_ERR(pcchip->pins_gpio))
>>> + pcchip->pinctrl = NULL;
>>> + }
>>> +
>>> + /*
>>> + * Switch to GPIO pinctrl state before requesting the GPIO.
>>> + * The driver core has already applied the "default" state, which
>>> + * muxes the pin to the clock function and claims it. We must
>>> + * release that claim first so that gpiolib can request the pin.
>>> + */
>>> + if (pcchip->pinctrl)
>>> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
>>> +
>>> + pcchip->gpiod = devm_gpiod_get_optional(&pdev->dev, NULL, GPIOD_ASIS);
>>> + if (IS_ERR(pcchip->gpiod))
>>> + return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->gpiod),
>>> + "Failed to get gpio\n");
>>> +
>>> + /*
>>> + * If pinctrl states were found but no GPIO was provided, the pin is
>>> + * stuck in GPIO mode from the switch above. Restore the default
>>> + * (clock-function) mux and fall back to clock-only operation.
>>> + */
>>
>> Feels slightly weird to silently allow "broken" DT, it would make no sense
>> for it to have "gpio" pinctrl and not have a gpio defined, would it?
>>
>> Perhaps it makes more sense to put getting a gpio under having pins_gpio
>> and make it strict, so two allowed states for the driver would be either
>> no pinctrl-1 and no gpio, or having both at the same time?
>>
>> (maybe then also worth adding cross dependency of pinctrl-1 and gpio in
>> the binding, it's one way only currently, not sure what's the correct
>> way to describe it tho)
>>
>> Nikita
>>
>
> Yeah, good point. Having a gpio pinctrl state without an actual gpio property is indeed a broken DT and there's no reason to silently work around it. Do you think the following change would work?
>
> if (pcchip->pinctrl) {
> pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
>
> pcchip->gpiod = devm_gpiod_get(&pdev->dev, NULL, GPIOD_ASIS);
> if (IS_ERR(pcchip->gpiod))
> return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->gpiod),
> "GPIO required when 'gpio' pinctrl state is present\n");
> }
>
This makes sense to me, yes.
Nikita
>>> + if (pcchip->pinctrl && !pcchip->gpiod) {
>>> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_default);
>>> + pcchip->pinctrl = NULL;
>>> + }
>>> +
>>> chip->ops = &pwm_clk_ops;
>>> ret = pwmchip_add(chip);
>>
^ permalink raw reply
* Re: [PATCH V11 04/12] PCI: imx6: Add support for parsing the reset property in new Root Port binding
From: Manivannan Sadhasivam @ 2026-04-08 13:55 UTC (permalink / raw)
To: Sherry Sun
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB12114AAA709016DADF0B45DA6925BA@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Wed, Apr 08, 2026 at 08:34:03AM +0000, Sherry Sun wrote:
> > On Tue, Apr 07, 2026 at 06:41:46PM +0800, Sherry Sun wrote:
> > > The current DT binding for pci-imx6 specifies the 'reset-gpios'
> > > property in the host bridge node. However, the PERST# signal logically
> > > belongs to individual Root Ports rather than the host bridge itself.
> > > This becomes important when supporting PCIe KeyE connector and PCI
> > > power control framework for pci-imx6 driver, which requires properties
> > > to be specified in Root Port nodes.
> > >
> > > Add support for parsing 'reset-gpios' from Root Port child nodes using
> > > the common helper pci_host_common_parse_ports(), and update the reset
> > > GPIO handling to use the parsed port list from bridge->ports. To
> > > maintain DT backwards compatibility, fallback to the legacy method of
> > > parsing the host bridge node if the reset property is not present in
> > > the Root Port node.
> > >
> > > Since now the reset GPIO is obtained with GPIOD_ASIS flag, it may be
> > > in input mode, using gpiod_direction_output() instead of
> > > gpiod_set_value_cansleep() to ensure the reset GPIO is properly
> > > configured as output before setting its value.
> > >
> > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > ---
> > > drivers/pci/controller/dwc/pci-imx6.c | 75
> > > +++++++++++++++++++++------
> > > 1 file changed, 60 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > index d99da7e42590..dd8f9c0fcec4 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -34,6 +34,7 @@
> > > #include <linux/pm_runtime.h>
> > >
> > > #include "../../pci.h"
> > > +#include "../pci-host-common.h"
> > > #include "pcie-designware.h"
> > >
> > > #define IMX8MQ_GPR_PCIE_REF_USE_PAD BIT(9)
> > > @@ -152,7 +153,6 @@ struct imx_lut_data {
> > >
> > > struct imx_pcie {
> > > struct dw_pcie *pci;
> > > - struct gpio_desc *reset_gpiod;
> > > struct clk_bulk_data *clks;
> > > int num_clks;
> > > bool supports_clkreq;
> > > @@ -1224,6 +1224,32 @@ static void imx_pcie_disable_device(struct
> > pci_host_bridge *bridge,
> > > imx_pcie_remove_lut(imx_pcie, pci_dev_id(pdev)); }
> > >
> > > +static int imx_pcie_parse_legacy_binding(struct imx_pcie *pcie) {
> > > + struct device *dev = pcie->pci->dev;
> > > + struct pci_host_bridge *bridge = pcie->pci->pp.bridge;
> > > + struct pci_host_port *port;
> > > + struct gpio_desc *reset;
> > > +
> > > + reset = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
> > > + if (IS_ERR(reset))
> > > + return PTR_ERR(reset);
> > > +
> > > + if (!reset)
> > > + return 0;
> > > +
> > > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > > + if (!port)
> > > + return -ENOMEM;
> > > +
> > > + port->reset = reset;
> > > + INIT_LIST_HEAD(&port->list);
> > > + list_add_tail(&port->list, &bridge->ports);
> > > +
> > > + return devm_add_action_or_reset(dev,
> > pci_host_common_delete_ports,
> > > + &bridge->ports);
> > > +}
> > > +
> > > static void imx_pcie_vpcie_aux_disable(void *data) {
> > > struct regulator *vpcie_aux = data;
> > > @@ -1233,13 +1259,22 @@ static void imx_pcie_vpcie_aux_disable(void
> > > *data)
> > >
> > > static void imx_pcie_assert_perst(struct imx_pcie *imx_pcie, bool
> > > assert) {
> > > - if (assert) {
> > > - gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 1);
> > > - } else {
> > > - if (imx_pcie->reset_gpiod) {
> > > - msleep(PCIE_T_PVPERL_MS);
> > > - gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 0);
> > > - msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > > + struct dw_pcie *pci = imx_pcie->pci;
> > > + struct pci_host_bridge *bridge = pci->pp.bridge;
> > > + struct pci_host_port *port;
> > > +
> > > + if (!bridge)
> > > + return;
> > > +
> > > + list_for_each_entry(port, &bridge->ports, list) {
> > > + if (assert) {
> > > + gpiod_direction_output(port->reset, 1);
> > > + } else {
> > > + if (port->reset) {
> > > + msleep(PCIE_T_PVPERL_MS);
> > > + gpiod_direction_output(port->reset, 0);
> > > + msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > > + }
> >
> > Sashiko flagged this loop:
> >
> > ```
> > Does this loop multiply the initialization delays?
> > If a controller has multiple Root Ports, the msleep calls will run sequentially
> > for each port, linearly increasing the delay. Could we optimize this by
> > asserting all reset GPIOs, waiting the pre-delay once, de-asserting all GPIOs,
> > and waiting the post-delay once for the entire bus?
> > ```
> >
> > Maybe you should do:
> >
> > if (!list_empty(&bridge->ports) && !assert)
> > msleep(PCIE_T_PVPERL_MS);
> >
> > list_for_each_entry(port, &bridge->ports, list) {
> > ...
> > gpiod_direction_output(port->reset, 0);
> > ...
> > }
> >
> > if (!list_empty(&bridge->ports) && !assert)
> > msleep(PCIE_RESET_CONFIG_WAIT_MS);
> >
>
> Hi Mani, I think the code below looks clearer, is that ok for you?
>
> if (assert) {
> list_for_each_entry(port, &bridge->ports, list)
> gpiod_direction_output(port->reset, 1);
> } else {
> if (list_empty(&bridge->ports))
> return;
>
This check should be moved out of the if() condition. Other than this, the
change looks good.
> msleep(PCIE_T_PVPERL_MS);
> list_for_each_entry(port, &bridge->ports, list)
> gpiod_direction_output(port->reset, 0);
> msleep(PCIE_RESET_CONFIG_WAIT_MS);
> }
>
> > And then this:
> >
> > ```
> > Also, since this function is called from imx_pcie_resume_noirq, which
> > executes with hardware interrupts disabled, does the use of msleep here
> > trigger a 'sleeping while atomic' bug?
> > ```
> >
> > This is a valid concern. You should use mdelay(). But I'd recommend switching
> > to IRQ enabled callback, resume() instead. There is no complelling reason to
> > use resume_noirq() in this driver and adding delays in noirq() callbacks is not
> > recommended as it may increase the overall system resume time.
> >
> > I will submit a separate series to convert dw_pcie_resume_noirq() and its
> > callers to IRQ enabled callbacks since this dw_pcie_resume_noirq() could
> > potentially cause delay up to 1sec.
>
> Yes, this is not a new bug introduced by this patch. I agree we should covert the
> convert dw_pcie_resume_noirq() and the caller to IRQ enabled callbacks to fix
> this in a separate patch series.
> For now, should I leave it as is, or switch to mdelay in this patch?
>
Just use mdelay() in your patch for now.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ 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