* Re: [PATCH v2 8/8] mips: dts: Add PCIe to EcoNet EN751221
From: Caleb James DeLisle @ 2026-04-08 12:58 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: linux-mips, naseefkm, mturquette, sboyd, robh, krzk+dt, conor+dt,
ryder.lee, jianjun.wang, lpieralisi, kwilczynski, mani, bhelgaas,
vkoul, neil.armstrong, p.zabel, matthias.bgg,
angelogioacchino.delregno, nbd, ansuelsmth, linux-clk, devicetree,
linux-kernel, linux-pci, linux-mediatek, linux-phy,
linux-arm-kernel
In-Reply-To: <adOo9xZxXT3FkufM@alpha.franken.de>
On 06/04/2026 14:37, Thomas Bogendoerfer wrote:
> On Mon, Mar 09, 2026 at 01:18:18PM +0000, Caleb James DeLisle wrote:
>> Add PCIe based on EN7528 PCIe driver, also add two MT76 wifi devices
>> to SmartFiber XP8421-B.
>>
>> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
>> ---
>> arch/mips/boot/dts/econet/en751221.dtsi | 114 ++++++++++++++++++
>> .../econet/en751221_smartfiber_xp8421-b.dts | 21 ++++
>> arch/mips/econet/Kconfig | 2 +
>> 3 files changed, 137 insertions(+)
>>
> applied to mips-next
Thank you very much.
Caleb
>
> Thomas.
>
^ permalink raw reply
* Re: [PATCH net-next v2 1/4] dt-bindings: net: dsa: add MT7628 ESW
From: Rob Herring @ 2026-04-08 13:00 UTC (permalink / raw)
To: Joris Vaisvila
Cc: netdev, horms, pabeni, kuba, edumazet, davem, olteanv,
Andrew Lunn, devicetree, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260330184017.766200-2-joey@tinyisr.com>
On Mon, Mar 30, 2026 at 09:40:14PM +0300, Joris Vaisvila wrote:
> Add bindings for MT7628 SoC's Embedded Switch.
>
> Signed-off-by: Joris Vaisvila <joey@tinyisr.com>
> ---
> .../bindings/net/dsa/mediatek,mt7628-esw.yaml | 101 ++++++++++++++++++
> 1 file changed, 101 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml
> new file mode 100644
> index 000000000000..d6c66ab677d0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml
> @@ -0,0 +1,101 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/dsa/mediatek,mt7628-esw.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek MT7628 Embedded Ethernet Switch
> +
> +maintainers:
> + - Joris Vaisvila <joey@tinyisr.com>
> +
> +description:
> + The MT7628 SoC's built-in Ethernet Switch is a five port switch with
> + integrated 10/100 PHYs. The switch registers are directly mapped in the SoC's
> + memory. The switch has an internally connected 1G CPU port and 5 user ports
> + connected to the built-in Fast Ethernet PHYs.
> +
> +unevaluatedProperties: false
> +
> +allOf:
> + - $ref: dsa.yaml#/$defs/ethernet-ports
> +
> +properties:
> + compatible:
> + const: mediatek,mt7628-esw
> +
> + reg:
> + maxItems: 1
> + description: MMIO address of the switch
Drop the description.
> +
> + resets:
> + items:
> + - description: Phandle of system reset controller with ESW reset index
> + - description: Phandle of system reset controller with EPHY reset index
Just describe these in terms of what they reset, not the provider.
> +
> + reset-names:
> + items:
> + - const: esw
> + - const: ephy
> +
> + mdio:
> + $ref: /schemas/net/mdio.yaml#
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - resets
> + - reset-names
Surely 'ethernet-ports' is required?
> +
> +examples:
> + - |
> + switch0: switch@10110000 {
> + reg = <0x10110000 0x8000>;
> +
> + resets = <&sysc 23>, <&sysc 24>;
> + reset-names = "esw", "ephy";
> +
> + compatible = "mediatek,mt7628-esw";
compatible goes before reg.
> +
> + ports {
"ethernet-ports" for new bindings.
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
And ethernet-port
> + reg = <0>;
> + phy-mode = "internal";
> + };
> +
> + port@1 {
> + reg = <1>;
> + phy-mode = "internal";
> + };
> +
> + port@2 {
> + reg = <2>;
> + phy-mode = "internal";
> + };
> +
> + port@3 {
> + reg = <3>;
> + phy-mode = "internal";
> + };
> +
> + port@4 {
> + reg = <4>;
> + phy-mode = "internal";
> + };
> +
> + port@6 {
> + reg = <6>;
> + phy-mode = "internal";
> + ethernet = <ðernet>;
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> + };
> + };
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v2 02/11] dt-bindings: regulator: ti,pbias-regulator: Add pbias_sim_omap4 regulator
From: Thomas Richard @ 2026-04-08 13:01 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Thomas Petazzoni,
linux-omap, linux-kernel, devicetree
In-Reply-To: <20260408124109.GB1864812-robh@kernel.org>
On 4/8/26 2:41 PM, Rob Herring wrote:
> On Wed, Apr 08, 2026 at 09:58:15AM +0200, Thomas Richard wrote:
>> Hello Krzysztof,
>>
>> On 3/31/26 10:22 AM, Krzysztof Kozlowski wrote:
>>> On Mon, Mar 30, 2026 at 03:43:59PM +0200, Thomas Richard wrote:
>>>> Define pbias_sim_omap4 regulator for OMAP4. This regulators drives SIM_VDDS
>>>> supply and allows to unlock USB I/O cell.
>>>>
>>>> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
>>>> ---
>>>> Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
>>>> index 3e020d87701b..908fbb46b5cf 100644
>>>> --- a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
>>>> +++ b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
>>>> @@ -89,6 +89,7 @@ allOf:
>>>> contains:
>>>> enum:
>>>> - pbias_mmc_omap4
>>>> + - pbias_sim_omap4
>>>
>>> Names cannot be fixed, because they represent different board naming.
>>> Why growing the deprecated style?
>>
>> Okay, so I'll drop all if statements, add a regex which matches
>> regulator names and fix the regulator name in the driver.
>
> If a driver depends on the names, you can't change them.
>
I mean the new regulator I add with this series. At this time it does
not exist yet in the driver.
Best Regards,
Thomas
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: PCI: mediatek: Add support for EcoNet EN7528
From: Caleb James DeLisle @ 2026-04-08 13:03 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-pci, linux-mips, naseefkm, ryder.lee, helgaas, lpieralisi,
kwilczynski, mani, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, ansuelsmth, linux-mediatek, devicetree,
linux-kernel
In-Reply-To: <20260405-phenomenal-messy-shark-bdefbd@quoll>
On 05/04/2026 09:03, Krzysztof Kozlowski wrote:
> On Sat, Apr 04, 2026 at 06:28:53PM +0000, Caleb James DeLisle wrote:
>> Introduce EcoNet EN7528 SoC compatible in MediaTek PCIe controller
>> binding.
>>
>> EcoNet PCIe controller has the same configuration model as
>> Mediatek v2 but is initialized more similarly to an MT7621
>> PCIe.
>>
> <form letter>
> This is a friendly reminder during the review process.
>
> It looks like you received a tag and forgot to add it.
>
Whoops, that was a failed-to-press-save error, thanks for catching it, I
will update in a few days after waiting for any additional commentary.
Caleb
The missing line:
Acked-by: Conor Dooley <conor.dooley@microchip.com>
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: renesas: Add missing #mux-state-cells to usb2phy-reset nodes
From: Geert Uytterhoeven @ 2026-04-08 13:07 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, peda, p.zabel, linux-renesas-soc, biju.das.jz,
Magnus Damm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-kernel
In-Reply-To: <cover.1775575276.git.tommaso.merciai.xr@bp.renesas.com>
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]?
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 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
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