* 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 v2 08/11] dt-bindings: mfd: ti,omap-usb-host: Convert to DT schema
From: Rob Herring @ 2026-04-08 12:55 UTC (permalink / raw)
To: Thomas Richard
Cc: 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: <20260330-omap4-fix-usb-support-v2-8-1c1e11b190dc@bootlin.com>
On Mon, Mar 30, 2026 at 03:44:05PM +0200, Thomas Richard wrote:
> Convert OMAP HS USB Host binding to DT schema. The 'ti,hwmods' property is
> not mandatory anymore as it is no longer required when the omap-usb-host
> node is a child of a new interconnect target (ti,sysc).
>
> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
> ---
> .../devicetree/bindings/mfd/omap-usb-host.txt | 103 -------------
> .../devicetree/bindings/mfd/ti,omap-usb-host.yaml | 161 +++++++++++++++++++++
> MAINTAINERS | 1 +
> 3 files changed, 162 insertions(+), 103 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
> deleted file mode 100644
> index a0d8c30c2631..000000000000
> --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
> +++ /dev/null
> @@ -1,103 +0,0 @@
> -OMAP HS USB Host
> -
> -Required properties:
> -
> -- compatible: should be "ti,usbhs-host"
> -- reg: should contain one register range i.e. start and length
> -- ti,hwmods: must contain "usb_host_hs"
> -
> -Optional properties:
> -
> -- num-ports: number of USB ports. Usually this is automatically detected
> - from the IP's revision register but can be overridden by specifying
> - this property. A maximum of 3 ports are supported at the moment.
> -
> -- portN-mode: String specifying the port mode for port N, where N can be
> - from 1 to 3. If the port mode is not specified, that port is treated
> - as unused. When specified, it must be one of the following.
> - "ehci-phy",
> - "ehci-tll",
> - "ehci-hsic",
> - "ohci-phy-6pin-datse0",
> - "ohci-phy-6pin-dpdm",
> - "ohci-phy-3pin-datse0",
> - "ohci-phy-4pin-dpdm",
> - "ohci-tll-6pin-datse0",
> - "ohci-tll-6pin-dpdm",
> - "ohci-tll-3pin-datse0",
> - "ohci-tll-4pin-dpdm",
> - "ohci-tll-2pin-datse0",
> - "ohci-tll-2pin-dpdm",
> -
> -- single-ulpi-bypass: Must be present if the controller contains a single
> - ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
> -
> -- clocks: a list of phandles and clock-specifier pairs, one for each entry in
> - clock-names.
> -
> -- clock-names: should include:
> - For OMAP3
> - * "usbhost_120m_fck" - 120MHz Functional clock.
> -
> - For OMAP4+
> - * "refclk_60m_int" - 60MHz internal reference clock for UTMI clock mux
> - * "refclk_60m_ext_p1" - 60MHz external ref. clock for Port 1's UTMI clock mux.
> - * "refclk_60m_ext_p2" - 60MHz external ref. clock for Port 2's UTMI clock mux
> - * "utmi_p1_gfclk" - Port 1 UTMI clock mux.
> - * "utmi_p2_gfclk" - Port 2 UTMI clock mux.
> - * "usb_host_hs_utmi_p1_clk" - Port 1 UTMI clock gate.
> - * "usb_host_hs_utmi_p2_clk" - Port 2 UTMI clock gate.
> - * "usb_host_hs_utmi_p3_clk" - Port 3 UTMI clock gate.
> - * "usb_host_hs_hsic480m_p1_clk" - Port 1 480MHz HSIC clock gate.
> - * "usb_host_hs_hsic480m_p2_clk" - Port 2 480MHz HSIC clock gate.
> - * "usb_host_hs_hsic480m_p3_clk" - Port 3 480MHz HSIC clock gate.
> - * "usb_host_hs_hsic60m_p1_clk" - Port 1 60MHz HSIC clock gate.
> - * "usb_host_hs_hsic60m_p2_clk" - Port 2 60MHz HSIC clock gate.
> - * "usb_host_hs_hsic60m_p3_clk" - Port 3 60MHz HSIC clock gate.
> -
> -Required properties if child node exists:
> -
> -- #address-cells: Must be 1
> -- #size-cells: Must be 1
> -- ranges: must be present
> -
> -Properties for children:
> -
> -The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
> -See Documentation/devicetree/bindings/usb/generic-ehci.yaml and
> -Documentation/devicetree/bindings/usb/generic-ohci.yaml.
> -
> -Example for OMAP4:
> -
> -usbhshost: usbhshost@4a064000 {
> - compatible = "ti,usbhs-host";
> - reg = <0x4a064000 0x800>;
> - ti,hwmods = "usb_host_hs";
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges;
> -
> - usbhsohci: ohci@4a064800 {
> - compatible = "ti,ohci-omap3";
> - reg = <0x4a064800 0x400>;
> - interrupt-parent = <&gic>;
> - interrupts = <0 76 0x4>;
> - };
> -
> - usbhsehci: ehci@4a064c00 {
> - compatible = "ti,ehci-omap";
> - reg = <0x4a064c00 0x400>;
> - interrupt-parent = <&gic>;
> - interrupts = <0 77 0x4>;
> - };
> -};
> -
> -&usbhshost {
> - port1-mode = "ehci-phy";
> - port2-mode = "ehci-tll";
> - port3-mode = "ehci-phy";
> -};
> -
> -&usbhsehci {
> - phys = <&hsusb1_phy 0 &hsusb3_phy>;
> -};
> diff --git a/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml b/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
> new file mode 100644
> index 000000000000..3b5b041f0321
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
> @@ -0,0 +1,161 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/ti,omap-usb-host.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: OMAP HS USB Host
> +
> +maintainers:
> + - Thomas Richard <thomas.richard@bootlin.com>
> +
> +properties:
> + compatible:
> + const: ti,usbhs-host
> +
> + reg:
> + maxItems: 1
> +
> + ti,hwmods:
> + const: usb_host_hs
> +
> + num-ports:
> + description:
> + number of USB ports. Usually this is automatically detected from the IP's
> + revision register but can be overridden by specifying this property. A
> + maximum of 3 ports are supported at the moment.
> + maximum: 3
> +
> + single-ulpi-bypass:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description:
> + Must be present if the controller contains a single ULPI bypass control
> + bit. e.g. OMAP3 silicon <= ES2.1ULPI bypass control bit.
> + e.g. OMAP3 silicon <= ES2.1.
> +
> + clocks:
> + description: clock-specifier
> +
> + clock-names:
> + oneOf:
> + - items:
> + - const: usbhost_120m_fck
> + - items:
> + - const: refclk_60m_int
> + - const: refclk_60m_ext_p1
> + - const: refclk_60m_ext_p2
> + - items:
> + - const: refclk_60m_int
> + - const: refclk_60m_ext_p1
> + - const: refclk_60m_ext_p2
> + - const: usb_host_hs_utmi_p1_clk
> + - const: usb_host_hs_hsic480m_p1_clk
> + - const: usb_host_hs_hsic60m_p1_clk
> + - items:
> + - const: refclk_60m_int
> + - const: refclk_60m_ext_p1
> + - const: refclk_60m_ext_p2
> + - const: usb_host_hs_utmi_p1_clk
> + - const: usb_host_hs_hsic480m_p1_clk
> + - const: usb_host_hs_hsic60m_p1_clk
> + - const: usb_host_hs_utmi_p2_clk
> + - const: usb_host_hs_hsic480m_p2_clk
> + - const: usb_host_hs_hsic60m_p2_clk
> + - items:
> + - const: refclk_60m_int
> + - const: refclk_60m_ext_p1
> + - const: refclk_60m_ext_p2
> + - const: usb_host_hs_utmi_p1_clk
> + - const: usb_host_hs_hsic480m_p1_clk
> + - const: usb_host_hs_hsic60m_p1_clk
> + - const: usb_host_hs_utmi_p2_clk
> + - const: usb_host_hs_hsic480m_p2_clk
> + - const: usb_host_hs_hsic60m_p2_clk
> + - const: usb_host_hs_utmi_p3_clk
> + - const: usb_host_hs_hsic480m_p3_clk
> + - const: usb_host_hs_hsic60m_p3_clk
All but the first one can be combined to this last entry plus
'minItems: 3'.
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 1
> +
> + ranges: true
> +
> +patternProperties:
> + "^port[0-3]-mode$":
> + $ref: /schemas/types.yaml#/definitions/string
> + description:
> + String specifying the port mode for port N, where N can be from 1 to 3.
> + the port mode is not specified, that port is treated as unused. When
> + specified, it must be one of the following.
> + enum:
> + - ehci-phy
> + - ehci-tll
> + - ehci-hsic
> + - ohci-phy-6pin-datse0
> + - ohci-phy-6pin-dpdm
> + - ohci-phy-3pin-datse0
> + - ohci-phy-4pin-dpdm
> + - ohci-tll-6pin-datse0
> + - ohci-tll-6pin-dpdm
> + - ohci-tll-3pin-datse0
> + - ohci-tll-4pin-dpdm
> + - ohci-tll-2pin-datse0
> + - ohci-tll-2pin-dpdm
> +
> + "^usb@":
> + type: object
> + oneOf:
> + - $ref: /schemas/usb/generic-ohci.yaml#
> + - $ref: /schemas/usb/generic-ehci.yaml#
This causes the schemas to be applied twice and oneOf causes confusing
warnings. Instead just do this:
type: object
properties:
compatible:
contains:
enum:
- ti,ehci-omap
- ti,ohci-omap3
required:
- compatible
> +
> +required:
> + - compatible
> + - reg
> +
> +allOf:
> + - if:
> + patternProperties:
> + "^usb@": true
This will always be true. Unfortunately there's no way to do required
pattern properties in json-schema.
Is it valid to have no usb nodes? I wouldn't think so, so just make
these properties always required.
> + then:
> + required:
> + - ranges
> + - "#address-cells"
> + - "#size-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + bus {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + usbhshost: usbhshost@4a064000 {
> + compatible = "ti,usbhs-host";
> + reg = <0x4a064000 0x800>;
> + ti,hwmods = "usb_host_hs";
> + port1-mode = "ehci-phy";
> + port2-mode = "ehci-tll";
> + port3-mode = "ehci-phy";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + usbhsohci: usb@4a064800 {
> + compatible = "ti,ohci-omap3";
> + reg = <0x4a064800 0x400>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 76 0x4>;
> + };
> +
> + usbhsehci: usb@4a064c00 {
> + compatible = "ti,ehci-omap";
> + reg = <0x4a064c00 0x400>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 77 0x4>;
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 15052c0f5377..d1dadba8ed0a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19406,6 +19406,7 @@ W: http://linux.omap.com/
> Q: http://patchwork.kernel.org/project/linux-omap/list/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
> F: Documentation/devicetree/bindings/arm/ti/omap.yaml
> +F: Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
> F: Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
> F: arch/arm/configs/omap2plus_defconfig
> F: arch/arm/mach-omap2/
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v2] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Andrew Lunn @ 2026-04-08 12:49 UTC (permalink / raw)
To: Fidelio Lawson
Cc: Woojung Huh, UNGLinuxDriver, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Maxime Chevallier,
netdev, devicetree, linux-kernel, Fidelio Lawson
In-Reply-To: <20260408-ksz87xx_errata_low_loss_connections-v2-1-9cfe38691713@exotec.com>
> The register can be read and written from userspace via standard Clause 22 PHY
> accesses (for example using phytool) on DSA user ports.
Please add a phy tunable. .get_tunable/.set_tunable.
Andrew
^ permalink raw reply
* Re: [PATCH v2] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Andrew Lunn @ 2026-04-08 12:43 UTC (permalink / raw)
To: Fidelio Lawson
Cc: Woojung Huh, UNGLinuxDriver, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Maxime Chevallier,
netdev, devicetree, linux-kernel, Fidelio Lawson
In-Reply-To: <20260408-ksz87xx_errata_low_loss_connections-v2-1-9cfe38691713@exotec.com>
> The control register defines the following modes:
> bits [1:0]:
> 00 = workaround disabled
> 01 = workaround 1 (DSP EQ training adjustment, LinkMD reg 0x3c)
> 10 = workaround 2 (receiver LPF bandwidth, LinkMD reg 0x4c)
There was a comment, which i only read after making the suggestion to
use two bits, of exposing the different low pass filter bandwidths,
rather than just picking one value. How useful is that?
Andrew
^ permalink raw reply
* Re: [PATCH v2 02/11] dt-bindings: regulator: ti,pbias-regulator: Add pbias_sim_omap4 regulator
From: Rob Herring @ 2026-04-08 12:41 UTC (permalink / raw)
To: Thomas Richard
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: <9d76f827-3967-4ab6-b6f0-77d1bd564278@bootlin.com>
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.
Rob
^ permalink raw reply
* Re: [PATCH v2 01/11] dt-bindings: regulator: ti,pbias-regulator: Convert to DT schema
From: Rob Herring @ 2026-04-08 12:38 UTC (permalink / raw)
To: Thomas Richard
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: <6b637950-2018-41d8-bdd2-27382a9b67d8@bootlin.com>
On Wed, Apr 08, 2026 at 09:57:20AM +0200, Thomas Richard wrote:
> Hello Krzysztof,
>
> On 3/31/26 10:21 AM, Krzysztof Kozlowski wrote:
> > On Mon, Mar 30, 2026 at 03:43:58PM +0200, Thomas Richard wrote:
> >> +$id: http://devicetree.org/schemas/regulator/ti,pbias-regulator.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: PBIAS internal regulator
> >> +
> >> +maintainers:
> >> + - Thomas Richard <thomas.richard@bootlin.com>
> >> +
> >> +description: |
> >
> > Do not need '|' unless you need to preserve formatting.
> >
> >> + PBIAS internal regulator for SD card dual voltage i/o pads on OMAP SoCs.
> >> +
> >> +properties:
> >> + compatible:
> >> + items:
> >> + - enum:
> >> + - ti,pbias-dra7
> >> + - ti,pbias-omap2
> >> + - ti,pbias-omap3
> >> + - ti,pbias-omap4
> >> + - ti,pbias-omap5
> >> + - const: ti,pbias-omap
> >> +
> >> + reg:
> >> + maxItems: 1
> >> +
> >> + syscon:
> >> + description: Phandle of the system control module
> >> + $ref: /schemas/types.yaml#/definitions/phandle
> >> +
> >> +patternProperties:
> >> + '^pbias_*':
> >
> > That wasn't in old binding and underscore is not allowed, so this needs
> > explanation. Old binding mentioned only the names.
>
> I did it to match existing devicetrees.
> I guess I should define properties like 'pbias-mmc' and 'pbias-sim',
> then update node names in devicetrees to match binding.
For this ancient stuff, I would just leave the dts files alone. Just
explain that in the commit message.
Your pattern should be '^pbias_' though.
Rob
^ permalink raw reply
* Re: [PATCH v2 5/5] arm64: dts: qcom: qcs8550: add QCS8550 RB5Gen2 board support
From: Neil Armstrong @ 2026-04-08 12:35 UTC (permalink / raw)
To: Konrad Dybcio, jsandom, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <4359bb07-d848-4b77-b1a9-f1c6f53caa10@oss.qualcomm.com>
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.
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.
[1] https://lore.kernel.org/all/20241129144357.2008465-1-quic_msavaliy@quicinc.com/
>
>
> [...]
>
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&wlan_en>, <&bt_default>, <&sw_ctrl_default>,
>> + <&pmk8550_sleep_clk>;
>
> nit: let's keep the order of
>
> property-n
> property-names
>
> file-wide
>
> [...]
>
>> +&sdhc_2 {
>> + cd-gpios = <&pm8550_gpios 12 GPIO_ACTIVE_LOW>;
>> +
>> + pinctrl-0 = <&sdc2_default>, <&sdc2_card_det_n>;
>> + pinctrl-1 = <&sdc2_sleep>, <&sdc2_card_det_n>;
>> + pinctrl-names = "default", "sleep";
>> +
>> + vmmc-supply = <&vreg_l9b_2p9>;
>> + vqmmc-supply = <&vreg_l8b_1p8>;
>> +
>> + max-sd-hs-hz = <37000000>;
>
> Are you sure you want to overwrite that? The value in the SoC DTSI is
> set to half a MHz higher
>
>
>> +
>> + no-sdio;
>> + no-mmc;
>> +
>> + status = "okay";
>> +};
>> +
>> +&sleep_clk {
>> + clock-frequency = <32764>;
>> +};
>> +
>> +&spi11 {
>> + status = "okay";
>> +
>> + can@0 {
>> + compatible = "microchip,mcp2518fd";
>> + reg = <0>;
>> + interrupts-extended = <&tlmm 55 IRQ_TYPE_LEVEL_LOW>;
>> + clocks = <&clk40m>;
>> + spi-max-frequency = <10000000>;
>> + vdd-supply = <&vreg_l14b_3p2>;
>> + xceiver-supply = <&vreg_l14b_3p2>;
>
> It may be that for this chip to actually be able to communiate with devices
> on the bus, you need to set the new 'microchip,xstbyen' property
>
> see:
>
> https://lore.kernel.org/linux-arm-msm/20260321135031.3107408-1-viken.dadhaniya@oss.qualcomm.com/
>
> [...]
>
>> +&tlmm {
>> + gpio-reserved-ranges = <32 8>;
>
> Would you happen to know what these pins are connected to, and if
> so, add a comment (like in arch/arm64/boot/dts/qcom/x1-crd.dtsi)?
>
>
>
>> +
>> + bt_default: bt-default-state {
>> + pins = "gpio81";
>
> It would be best to keep these entries ordered by pin idx
>
>> + function = "gpio";
>> + drive-strength = <16>;
>> + bias-disable;
>> + };
>> +
>> + sw_ctrl_default: sw-ctrl-default-state {
>> + pins = "gpio82";
>> + function = "gpio";
>> + bias-pull-down;
>> + };
>> +
>> + lt9611_irq_pin: lt9611-irq-state {
>> + pins = "gpio40";
>> + function = "gpio";
>> + bias-disable;
>> + };
>> +
>> + lt9611_rst_pin: lt9611-rst-state {
>> + pins = "gpio7";
>> + function = "gpio";
>> + output-high;
>
> You shouldn't need to assert the GPIO state in the pin entry node
> - the driver should take care of that
>
>
>> + };
>> +
>> + ntn0_en: ntn0-en-state {
>> + pins = "gpio67";
>> + function = "gpio";
>> + drive-strength = <2>;
>> + bias-disable;
>> + };
>> +
>> + ntn1_en: ntn1-en-state {
>> + pins = "gpio42";
>> + function = "gpio";
>> + drive-strength = <2>;
>> + bias-disable;
>> + };
>> +
>> + upd_1p05_en: upd-1p05-en-state {
>> + pins = "gpio179";
>> + function = "gpio";
>> + drive-strength = <2>;
>> + bias-pull-up;
>> + };
>
> I don't know if pulling up an active-high pin is what you want
> (there's some more occurences)
>
> Konrad
^ permalink raw reply
* Re: [PATCH v12 2/2] arm: dts: aspeed: ventura: add Meta Ventura BMC
From: Andrew Lunn @ 2026-04-08 12:34 UTC (permalink / raw)
To: P.K. Lee
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Jason-Hsu, p.k.lee
In-Reply-To: <CAK8yEOAYC0iApNHBApt+xu1Fz=+N1wX0XrLGOPzmeRq=OjWnhg@mail.gmail.com>
> > > > If there are no devices on the bus, why enable it?
> > >
> > > We intentionally enable it so user-space tools can access the switch
> > > registers. I have added a comment in v13 to clarify this.
> >
> > Why would user space want to access the switch registers for an
> > unmanaged switch? It sounds like you are using Marvells SDK in
> > userspace to manage the switch, rather than using DSA.
> >
>
> We do have a custom user-space daemon that configures the switch
> registers for our specific use case. Should I remove the &mdio0 node
> if it is only enabled and has no other configuration in the upstream
> device tree?
Please just be truthful that you have a user space driver, so need the
bus enabled.
I also guess you have some other kernel code that allows you to
actually use the bus from user space? The typical ethernet IOCTL
handler does not work for you, since you don't have an ethernet device
using this bus. Such code is unlikely to be accepted into mainline. We
don't like user space drivers when there is a perfectly good kernel
driver for this switch.
Andrew
^ permalink raw reply
* Re: [PATCH v6 13/21] drm: renesas: rz-du: mipi_dsi: Add RZ_MIPI_DSI_FEATURE_GPO0R feature
From: Laurent Pinchart @ 2026-04-08 12:31 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, 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,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <9e0f64dd5e1efb0d27219416121c91a19da96ebd.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:36:58PM +0200, Tommaso Merciai wrote:
> The MIPI DSI ip found in the RZ/G3E SoC select the video input clock
> based on the DU instance actually connected using the GPO0R register.
>
> Add this feature to the driver using `RZ_MIPI_DSI_FEATURE_GPO0R`, update
> the code accordingly to manage the vclk selection with the introduction
> of `rzg2l_mipi_dsi_get_input_port()`.
>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> ---
> v5->v6:
> - Moved rzg2l_mipi_dsi_link_write() into rzv2h_mipi_dsi_dphy_init()
> + comments from HW Manual.
>
> v4->v5:
> - No changes.
>
> v3->v4:
> - No changes.
>
> v2->v3:
> - No changes.
>
> v1->v2:
> - No changes.
>
> .../gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c | 71 +++++++++++++++++--
> .../drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h | 3 +
> 2 files changed, 68 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> index be6dbf19a24e..947c8e15fc4b 100644
> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> @@ -37,7 +37,9 @@ MODULE_IMPORT_NS("RZV2H_CPG");
>
> #define RZG2L_DCS_BUF_SIZE 128 /* Maximum DCS buffer size in external memory. */
>
> +#define RZ_MIPI_DSI_MAX_INPUT 2
> #define RZ_MIPI_DSI_FEATURE_16BPP BIT(0)
> +#define RZ_MIPI_DSI_FEATURE_GPO0R BIT(1)
>
> struct rzg2l_mipi_dsi;
>
> @@ -81,13 +83,14 @@ struct rzg2l_mipi_dsi {
> struct drm_bridge bridge;
> struct drm_bridge *next_bridge;
>
> - struct clk *vclk;
> + struct clk *vclk[RZ_MIPI_DSI_MAX_INPUT];
> struct clk *lpclk;
>
> enum mipi_dsi_pixel_format format;
> unsigned int num_data_lanes;
> unsigned int lanes;
> unsigned long mode_flags;
> + u8 vclk_idx;
>
> struct rzv2h_dsi_mode_calc mode_calc;
>
> @@ -543,8 +546,8 @@ static int rzg2l_dphy_conf_clks(struct rzg2l_mipi_dsi *dsi, unsigned long mode_f
> unsigned long vclk_rate;
> unsigned int bpp;
>
> - clk_set_rate(dsi->vclk, mode_freq * KILO);
> - vclk_rate = clk_get_rate(dsi->vclk);
> + clk_set_rate(dsi->vclk[dsi->vclk_idx], mode_freq * KILO);
> + vclk_rate = clk_get_rate(dsi->vclk[dsi->vclk_idx]);
> if (vclk_rate != mode_freq * KILO)
> dev_dbg(dsi->dev, "Requested vclk rate %lu, actual %lu mismatch\n",
> mode_freq * KILO, vclk_rate);
> @@ -687,6 +690,19 @@ static int rzv2h_mipi_dsi_dphy_init(struct rzg2l_mipi_dsi *dsi,
> rzg2l_mipi_dsi_phy_write(dsi, PLLCLKSET1R,
> FIELD_PREP(PLLCLKSET1R_PLL_K, dsi_parameters->k));
>
> + /*
> + * From RZ/G3E HW manual (Rev.1.15) section 9.5.3 Operation,
> + * 9.5.3.1 Power on Reset and Initial Settings for All Operations.
> + * Figure 9.5-4 Power On/Off Sequence show that after writing to
> + * GPO0R.VICH register we need to wait for more than 1 x tp before
> + * writing to PLLENR.PLLEN.
> + *
> + * Note: GPO0R is a link register, not a PHY register. This setting
> + * is specific to RZ/G3E.
> + */
> + if (dsi->info->features & RZ_MIPI_DSI_FEATURE_GPO0R)
> + rzg2l_mipi_dsi_link_write(dsi, GPO0R, dsi->vclk_idx);
> +
> /*
> * From RZ/V2H HW manual (Rev.1.20) section 9.5.3 Operation,
> * (C) After write to D-PHY registers we need to wait for more than 1 x tp
> @@ -1005,6 +1021,37 @@ static int rzg2l_mipi_dsi_stop_video(struct rzg2l_mipi_dsi *dsi)
> return ret;
> }
>
> +static int rzg2l_mipi_dsi_get_input_port(struct rzg2l_mipi_dsi *dsi)
> +{
> + struct device_node *np = dsi->dev->of_node;
> + struct device_node *remote_ep, *ep_node;
> + struct of_endpoint ep;
> + bool ep_enabled;
> + int in_port;
> +
> + /* DSI can have only one port enabled */
Why is that ? The hardware supports dynamic input selection, why can't
it be supported at runtime ?
> + for_each_endpoint_of_node(np, ep_node) {
> + of_graph_parse_endpoint(ep_node, &ep);
> + if (ep.port >= RZ_MIPI_DSI_MAX_INPUT)
> + break;
> +
> + remote_ep = of_graph_get_remote_endpoint(ep_node);
> + ep_enabled = of_device_is_available(remote_ep);
> + of_node_put(remote_ep);
> +
> + if (ep_enabled) {
> + in_port = ep.port;
> + break;
> + }
> + }
> +
> + if (!ep_enabled)
> + return -EINVAL;
> +
> + dev_dbg(dsi->dev, "input port@%d\n", in_port);
> + return in_port;
> +}
> +
> /* -----------------------------------------------------------------------------
> * Bridge
> */
> @@ -1425,9 +1472,21 @@ static int rzg2l_mipi_dsi_probe(struct platform_device *pdev)
> if (IS_ERR(dsi->mmio))
> return PTR_ERR(dsi->mmio);
>
> - dsi->vclk = devm_clk_get(dsi->dev, "vclk");
> - if (IS_ERR(dsi->vclk))
> - return PTR_ERR(dsi->vclk);
> + dsi->vclk[0] = devm_clk_get(dsi->dev, "vclk");
> + if (IS_ERR(dsi->vclk[0]))
> + return PTR_ERR(dsi->vclk[0]);
> +
> + if (dsi->info->features & RZ_MIPI_DSI_FEATURE_GPO0R) {
> + dsi->vclk[1] = devm_clk_get(dsi->dev, "vclk2");
> + if (IS_ERR(dsi->vclk[1]))
> + return PTR_ERR(dsi->vclk[1]);
> +
> + ret = rzg2l_mipi_dsi_get_input_port(dsi);
> + if (ret < 0)
> + return dev_err_probe(dsi->dev, -EINVAL,
> + "No available input port\n");
> + dsi->vclk_idx = ret;
> + }
>
> dsi->lpclk = devm_clk_get(dsi->dev, "lpclk");
> if (IS_ERR(dsi->lpclk))
> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h
> index 2bef20566648..cee2e0bc5dc5 100644
> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h
> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h
> @@ -83,6 +83,9 @@
> #define LINKSR_SQCHRUN1 BIT(4)
> #define LINKSR_SQCHRUN0 BIT(0)
>
> +/* RZ/G3E General Purpose Output 0 Register */
> +#define GPO0R 0xc0
> +
> /* Tx Set Register */
> #define TXSETR 0x100
> #define TXSETR_NUMLANECAP (0x3 << 16)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v6 12/21] drm: renesas: rz-du: mipi_dsi: Add out_port to OF data
From: Laurent Pinchart @ 2026-04-08 12:30 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, 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,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <d4d1d75183944f17d392256d9123523a6bd1a3c0.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:36:57PM +0200, Tommaso Merciai wrote:
> Add `out_port` field to the `rzg2l_mipi_dsi_hw_info` structure to store
> the DSI output port index. RZ/G2L and RZ/V2H(P) use port 1 for DSI
> output, while RZ/G3E uses port 2.
>
> Update `rzg2l_mipi_dsi_host_attach()` and `rzg2l_mipi_dsi_probe()` to
> use this `out_port` from the OF data, facilitating future support for
> RZ/G3E SoC.
>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Another option would be to add the second input port for G3E as port@2,
keeping port@1 as the output port on all SoCs. Both options work.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> v5->v6:
> - No changes.
>
> v4->v5:
> - No changes.
>
> v3->v4:
> - No changes.
>
> v2->v3:
> - No changes.
>
> v1->v2:
> - No changes.
>
> drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> index 715872130780..be6dbf19a24e 100644
> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> @@ -58,6 +58,7 @@ struct rzg2l_mipi_dsi_hw_info {
> u32 link_reg_offset;
> unsigned long min_dclk;
> unsigned long max_dclk;
> + u8 out_port;
> u8 features;
> };
>
> @@ -1158,7 +1159,7 @@ static int rzg2l_mipi_dsi_host_attach(struct mipi_dsi_host *host,
> dsi->mode_flags = device->mode_flags;
>
> dsi->next_bridge = devm_drm_of_get_bridge(dsi->dev, dsi->dev->of_node,
> - 1, 0);
> + dsi->info->out_port, 0);
> if (IS_ERR(dsi->next_bridge)) {
> ret = PTR_ERR(dsi->next_bridge);
> dev_err(dsi->dev, "failed to get next bridge: %d\n", ret);
> @@ -1411,7 +1412,9 @@ static int rzg2l_mipi_dsi_probe(struct platform_device *pdev)
>
> dsi->info = of_device_get_match_data(&pdev->dev);
>
> - ret = drm_of_get_data_lanes_count_ep(dsi->dev->of_node, 1, 0, 1, 4);
> + ret = drm_of_get_data_lanes_count_ep(dsi->dev->of_node,
> + dsi->info->out_port,
> + 0, 1, 4);
> if (ret < 0)
> return dev_err_probe(dsi->dev, ret,
> "missing or invalid data-lanes property\n");
> @@ -1525,6 +1528,7 @@ static const struct rzg2l_mipi_dsi_hw_info rzv2h_mipi_dsi_info = {
> .link_reg_offset = 0,
> .min_dclk = 5440,
> .max_dclk = 187500,
> + .out_port = 1,
> .features = RZ_MIPI_DSI_FEATURE_16BPP,
> };
>
> @@ -1535,6 +1539,7 @@ static const struct rzg2l_mipi_dsi_hw_info rzg2l_mipi_dsi_info = {
> .link_reg_offset = 0x10000,
> .min_dclk = 5803,
> .max_dclk = 148500,
> + .out_port = 1,
> };
>
> static const struct of_device_id rzg2l_mipi_dsi_of_table[] = {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] media: dt-bindings: media: renesas,fcp: Document RZ/G3L FCPVD IP
From: Rob Herring (Arm) @ 2026-04-08 12:29 UTC (permalink / raw)
To: Biju
Cc: Mauro Carvalho Chehab, Geert Uytterhoeven, linux-kernel,
Krzysztof Kozlowski, Magnus Damm, Prabhakar Mahadev Lad,
Conor Dooley, devicetree, linux-renesas-soc, Laurent Pinchart,
Biju Das, linux-media
In-Reply-To: <20260330110012.131273-1-biju.das.jz@bp.renesas.com>
On Mon, 30 Mar 2026 12:00:10 +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> The FCPVD block on the RZ/G3L SoC is identical to the one found on the
> RZ/G2L SoC. Document RZ/G3L FCPVD IP.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/media/renesas,fcp.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] media: dt-bindings: media: renesas,vsp1: Document RZ/G3L VSPD
From: Rob Herring (Arm) @ 2026-04-08 12:29 UTC (permalink / raw)
To: Biju
Cc: linux-renesas-soc, Conor Dooley, Geert Uytterhoeven,
Prabhakar Mahadev Lad, Mauro Carvalho Chehab, Biju Das,
devicetree, Magnus Damm, linux-media, Kieran Bingham,
Laurent Pinchart, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260330105637.130189-1-biju.das.jz@bp.renesas.com>
On Mon, 30 Mar 2026 11:56:29 +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> The VSPD block on the RZ/G3L SoC is identical to the one found on the
> RZ/G2L SoC. Document RZ/G3L VSPD.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/media/renesas,vsp1.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/4] ASoC: dt-bindings: Add support for the GPIOs driven amplifier
From: Rob Herring @ 2026-04-08 12:29 UTC (permalink / raw)
To: Herve Codina
Cc: Liam Girdwood, Mark Brown, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, Jaroslav Kysela, Takashi Iwai, linux-sound,
devicetree, linux-kernel, Christophe Leroy, Thomas Petazzoni
In-Reply-To: <20260330101610.57942-3-herve.codina@bootlin.com>
On Mon, Mar 30, 2026 at 12:16:06PM +0200, Herve Codina wrote:
> Some amplifiers based on analog switches and op-amps can be present in
> the audio path and can be driven by GPIOs in order to control their gain
> value, their mute and/or bypass functions.
>
> Those components needs to be viewed as audio components in order to be
> fully integrated in the audio path.
>
> audio-gpio-amplifier allows to consider these GPIO driven amplifiers as
> auxiliary audio devices.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
> .../bindings/sound/audio-gpio-amp.yaml | 309 ++++++++++++++++++
> 1 file changed, 309 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/audio-gpio-amp.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/audio-gpio-amp.yaml b/Documentation/devicetree/bindings/sound/audio-gpio-amp.yaml
> new file mode 100644
> index 000000000000..15dc898f8574
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/audio-gpio-amp.yaml
> @@ -0,0 +1,309 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/audio-gpio-amp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Audio amplifier driven by GPIOs
> +
> +maintainers:
> + - Herve Codina <herve.codina@bootlin.com>
> +
> +description: |
> + Audio GPIO amplifiers are driven by GPIO in order to control the gain value
> + of the amplifier, its mute function and/or its bypass function.
> +
> + Those amplifiers are based on discrete components (analog switches, op-amps
> + and more) where some of them, mostly analog switches, are controlled by GPIOs
> + to adjust the gain value of the whole amplifier and/or to control
> + the mute and/or bypass function.
> +
> + For instance, the following piece of hardware is a GPIO amplifier
> +
> + +5VA
> + ^
> + |\ |
> + | \
> + Vin >---------------------------|+ \
> + | +-------+-----> Vout
> + .--\/\/\/--+------------|- / |
> + | | | / |
> + v | |/ | |
> + GND o v |
> + \ GND |
> + gpio >-----------> \ |
> + o o |
> + | | |
> + | '--\/\/\/--. |
> + | +--\/\/\/--'
> + '---------------'
> +
> + A GPIO driven amplifier can work in several mode depending on the electronic
> + design.
> + - points defined:
> + The values of GPIOs used to control gain set a specific gain value
> + without any specific relationship between each value. For instance,
> + using 2 GPIOS:
> + 0b00 <-> -10.0 dB
> + 0b01 <-> +3.0 dB
> + 0b10 <-> 0 dB
> + 0b11 <-> +6.0 dB
> +
> + This can be described using the gain-points property.
> +
> + - range defined:
> + The values of GPIOs used to control gain set a specific gain value
> + following a linear dB range from a minimum dB value to a maximum dB
> + value. For instance, using 2 GPIOS:
> + 0b00 <-> -3.0 dB
> + 0b01 <-> 0 db
> + 0b10 <-> +3.0 dB
> + 0b11 <-> +6.0 dB
> +
> + This can be described using the gain-range property.
> +
> + - labels defined:
> + Some electronic design are not meant to a specific dB gain value. In
> + that case it is relevant to use labels to describe them. For instance,
> + using 2 GPIOS:
> + 0b00 <-> Low boost
> + 0b01 <-> Middle boost
> + 0b10 <-> High boost
> + 0b11 <-> Max boost
> +
> + This can be described using the gain-labels property
> +
> +properties:
> + compatible:
> + const: audio-gpio-amp
To be consistent with other GPIO controlled devices: gpio-audio-amp
> +
> + vdd-supply:
> + description: Main power supply of the amplifier
> +
> + vddio-supply:
> + description: Power supply related to the control path
> +
> + vdda1-supply:
> + description: Analog power supply
> +
> + vdda2-supply:
> + description: Additional analog power supply
> +
> + mute-gpios:
> + description: GPIO to control the mute function
> + maxItems: 1
> +
> + bypass-gpios:
> + description: GPIO to control the bypass function
> + maxItems: 1
> +
> + gain-gpios:
> + description: |
> + GPIOs to control the amplifier gain
> +
> + The gain value is computed from GPIOs value from 0 to 2^N-1 with N the
> + number of GPIO described. The first GPIO described is the lsb of the gain
> + value.
> +
> + For instance assuming 2 gpios
> + gain-gpios = <&gpio1 GPIO_ACTIVE_HIGH> <&gpio2 GPIO_ACTIVE_HIGH>;
> + The gain value will be the following:
> +
> + gpio1 | gpio2 | gain
> + ------+-------+-----
> + 0 | 0 | 0b00 -> 0
> + 1 | 0 | 0b01 -> 1
> + 0 | 1 | 0b10 -> 2
> + 1 | 1 | 0b11 -> 3
> + ------+-------+-----
> +
> + Note: The gain value, bits set to 1 or 0, indicate the state active (bit
> + set) or the state inactive (bit unset) of the related GPIO. The
> + physical voltage corresponding to this active/inactive state is
> + given by the GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags.
> +
> + minItems: 1
> + maxItems: 32
2^32 levels? Seems like a bit much. Also, unless you can change the
values of all the GPIOs atomically, aren't you going to get some
artifacts while the gain is being changed? Unless you mute I guess.
> +
> + gain-points:
> + $ref: /schemas/types.yaml#/definitions/int32-matrix
> + items:
> + items:
> + - description: The GPIOs value
Can't this just be the index?
If not, then gain-range could be expressed using gain-points instead.
> + - description: The related amplifier gain in 0.01 dB unit
> + minItems: 2
> + description: |
> + List of the GPIOs value / Gain value in dB pair defining the gain
> + set on each GPIOs value.
> +
> + With 2 GPIOs controlling the gain, GPIOs value can be 0, 1, 2 and 3.
> + Assuming that GPIOs values set the hardware gains according to the
> + following table:
> +
> + GPIOs | Hardware
> + value | amplification
> + ------+--------------
> + 0 | -10.0 dB
> + 1 | +3.0 dB
> + 2 | 0 dB
> + 3 | +6.0 dB
> + ------+--------------
> +
> + The description using gain points can be:
> + gain-points = <0 (-1000)>, <1 300>, <2 0>, <3 600>;
> +
> + gain-range:
> + $ref: /schemas/types.yaml#/definitions/int32-array
> + items:
> + - description: Gain in 0.01 dB unit when all GPIOs are inactive
> + - description: Gain in 0.01 dB unit when all GPIOs are active
> + description: |
> + Gains (in 0.01 dB unit) set by the extremum (minimal and maximum) value
> + of GPIOs. The following formula must be satisfied.
> +
> + gain-range[1] - gain-range[0]
> + Gain = ------------------------------- x GPIO_value + gain-range[0]
> + 2^N - 1
> +
> + With N, the number of GPIOs used to control the gain and Gain computed in
> + 0.01 dB unit.
> +
> + With 2 GPIOs controlling the gain, GPIOs value can be 0, 1, 2 and 3.
> + Assuming that gain value set the hardware according to the following
> + table:
> +
> + GPIOs | Hardware 1 | Hardware 2
> + value | amplification | amplification
> + ------+---------------+---------------
> + 0 | -3.0 dB | +10.0 dB
> + 1 | 0 dB | +5.0 dB
> + 2 | +3.0 dB | 0 dB
> + 3 | +6.0 dB | -5.0 dB
> + ------+---------------+---------------
> +
> + The description for hardware 1 using a gain range can be:
> + gain-range = <(-300) 600>;
> +
> + The description for hardware 2 using a gain range can be:
> + gain-range = <1000 (-500)>;
> +
> + gain-labels:
> + $ref: /schemas/types.yaml#/definitions/string-array
minItems: 2
maxItems: 0x100000000
> + description: |
> + List of the gain labels attached to the combination of GPIOs controlling
> + the gain. The first label is related to the gain value 0, the second label
> + is related to the gain value 1 and so on.
> +
> + With 2 GPIOs controlling the gain, GPIOs value can be 0, 1, 2 and 3.
> + Assuming that gain value set the hardware according to the following
> + table:
> +
> + GPIOs | Hardware
> + value | amplification
> + ------+--------------
> + 0 | Low
> + 1 | Middle
> + 2 | High
> + 3 | Max
> + ------+--------------
> +
> + The description using gain labels can be:
> + gain-labels = "Low", "Middle", "High", "Max";
Do we need to allow these to be anything? It's going to get hard to come
up with 2^32 names.
> +
> +dependencies:
> + gain-points: [ gain-gpios ]
> + gain-range: [ gain-gpios ]
> + gain-labels: [ gain-gpios ]
gain-gpios is really optional?
> +
> +required:
> + - compatible
> + - vdd-supply
> +
> +anyOf:
> + - required:
> + - gain-gpios
> + - required:
> + - mute-gpios
> + - required:
> + - bypass-gpios
> +
> +allOf:
> + - $ref: dai-common.yaml#
> + - if:
> + required:
> + - gain-points
> + then:
> + properties:
> + gain-range: false
> + gain-labels: false
> + - if:
> + required:
> + - gain-range
> + then:
> + properties:
> + gain-points: false
> + gain-labels: false
> + - if:
> + required:
> + - gain-labels
> + then:
> + properties:
> + gain-points: false
> + gain-range: false
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + /* Gain controlled by gpios */
> + amplifier0 {
amplifier-0
> + compatible = "audio-gpio-amp";
> + vdd-supply = <®ulator>;
> + gain-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>, <&gpio 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + /* Gain controlled by gpio using range */
> + amplifier1 {
> + compatible = "audio-gpio-amp";
> + vdd-supply = <®ulator>;
> + gain-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>, <&gpio 1 GPIO_ACTIVE_HIGH>;
> + gain-range = <(-300) 600>;
> + };
> +
> + /* Gain controlled by gpio using points */
> + amplifier2 {
> + compatible = "audio-gpio-amp";
> + vdd-supply = <®ulator>;
> + gain-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>, <&gpio 1 GPIO_ACTIVE_HIGH>;
> + gain-points = <0 (-1000)>, <1 300>, <2 0>, <3 600>;
> + };
> +
> + /* Gain controlled by gpio with labels */
> + amplifier3 {
> + compatible = "audio-gpio-amp";
> + vdd-supply = <®ulator>;
> + gain-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
> + gain-labels = "Low", "High";
> + };
> +
> + /* A mutable amplifier without any gain control */
> + amplifier4 {
> + compatible = "audio-gpio-amp";
> + vdd-supply = <®ulator>;
> + mute-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
This case is just simple-amplifier...
> + };
> +
> + /* Several supplies, gain controlled using range, mute and bypass */
> + amplifier5 {
> + compatible = "audio-gpio-amp";
> + vdd-supply = <®ulator>;
> + vddio-supply = <®ulator1>;
> + vdda1-supply = <®ulator2>;
> + gain-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>, <&gpio 1 GPIO_ACTIVE_HIGH>;
> + gain-range = <(-300) 600>;
> + mute-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>;
> + bypass-gpios = <&gpio 3 GPIO_ACTIVE_HIGH>;
> + };
> +...
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v6 10/21] dt-bindings: display: renesas,rzg2l-du: Add support for RZ/G3E SoC
From: Laurent Pinchart @ 2026-04-08 12:24 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, 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,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <8f814f22ff62dcde6153260e2c8c29a5415c9a89.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:36:55PM +0200, Tommaso Merciai wrote:
> The RZ/G3E SoC has 2 LCD controllers (LCDC), each containing a Frame
> Compression Processor (FCPVD), a Video Signal Processor (VSPD), and a
> Display Unit (DU).
>
> - LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
> - LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
>
> Add a new SoC-specific compatible string 'renesas,r9a09g047-du'.
>
> Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" to
> allow up to four output ports, and explicitly disable port@2 and port@3
> for existing SoCs that do not expose them.
>
> Describe the four output ports of the RZ/G3E DU:
>
> - port@0: DSI (available on both LCDC instances)
> - port@1: DPAD / parallel RGB (LCDC1 only)
> - port@2: LVDS channel 0 (LCDC0 only)
> - port@3: LVDS channel 1 (available on both LCDC instances)
>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> ---
> v5->v6:
> - Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" and
> explicitly disable port@2 and port@3 for existing SoCs that do not expose
> them.
> - Reworked ports numbering + improved/fixed ports descriptions in the
> bindings documentation.
> - Improved commit body.
>
> v4->v5:
> - Dropped renesas,id property and updated bindings
> accordingly.
>
> v2->v3:
> - No changes.
>
> v2->v3:
> - No changes.
>
> v1->v2:
> - Use single compatible string instead of multiple compatible strings
> for the two DU instances, leveraging a 'renesas,id' property to
> differentiate between DU0 and DU1.
> - Updated commit message accordingly.
>
> .../bindings/display/renesas,rzg2l-du.yaml | 30 ++++++++++++++++++-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> index 5add3b832eab..32da0b5ec88c 100644
> --- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> @@ -20,6 +20,7 @@ properties:
> - enum:
> - renesas,r9a07g043u-du # RZ/G2UL
> - renesas,r9a07g044-du # RZ/G2{L,LC}
> + - renesas,r9a09g047-du # RZ/G3E
> - renesas,r9a09g057-du # RZ/V2H(P)
> - items:
> - enum:
> @@ -61,7 +62,7 @@ properties:
> model-dependent. Each port shall have a single endpoint.
>
> patternProperties:
> - "^port@[0-1]$":
> + "^port@[0-3]$":
> $ref: /schemas/graph.yaml#/properties/port
> unevaluatedProperties: false
>
> @@ -103,6 +104,8 @@ allOf:
> port@0:
> description: DPI
> port@1: false
> + port@2: false
> + port@3: false
>
> required:
> - port@0
> @@ -119,6 +122,8 @@ allOf:
> description: DSI
> port@1:
> description: DPI
> + port@2: false
> + port@3: false
>
> required:
> - port@0
> @@ -135,9 +140,32 @@ allOf:
> port@0:
> description: DSI
> port@1: false
> + port@2: false
> + port@3: false
>
> required:
> - port@0
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: renesas,r9a09g047-du
> + then:
> + properties:
> + ports:
> + properties:
> + port@0:
> + description: DSI
> + port@1:
> + description: DPAD
> + port@2:
> + description: LVDS, Channel 0
> + port@3:
> + description: LVDS, Channel 1
> +
> + required:
> + - port@0
> + - port@3
Why are ports 1 and 2 not required ?
>
> examples:
> # RZ/G2L DU
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v6 09/21] dt-bindings: display: renesas,rzg2l-du: Refuse port@1 for RZ/G2UL
From: Laurent Pinchart @ 2026-04-08 12:21 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, 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,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk,
stable
In-Reply-To: <8a3dd4df30a6d950e5f38d46f4d9f396da67aa71.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:36:54PM +0200, Tommaso Merciai wrote:
> The RZ/G2UL DU supports only a single port@0 DPI. Explicitly refuse
> port@1 in the ports node.
>
> Fixes: 2ef7cb1cea7d ("dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> v5->v6:
> - New patch.
>
> Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> index 2cc66dcef870..5add3b832eab 100644
> --- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> @@ -102,6 +102,7 @@ allOf:
> properties:
> port@0:
> description: DPI
> + port@1: false
>
> required:
> - port@0
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v6 20/21] arm64: dts: renesas: r9a09g047: Add DU{0,1} and DSI nodes
From: Laurent Pinchart @ 2026-04-08 12:11 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, 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,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <ca31352b03689fa9902660be5cb4d0972ce04304.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:37:05PM +0200, Tommaso Merciai wrote:
> Add DU0, DU1, DSI nodes to RZ/RZG3E SoC DTSI.
>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> ---
> v5->v6:
> - Update ports numbering accordingly to the latest DT bindings.
>
> v4->v5:
> - Rename du0_out_dsi0 into du0_out_dsi.
> - Rename du1_out_dsi0 into du1_out_dsi.
> - Drop renesas,id entry from DU nodes.
>
> v3->v4:
> - No changes.
>
> v2->v3:
> - No changes.
>
> v1->v2:
> - Use single compatible string instead of multiple compatible strings
> for the two DU instances, leveraging a 'renesas,id' property to
> differentiate between DU0 and DU1.
> - Use vclk instead of vclk1 for DSI Node and set to the right position.
>
> arch/arm64/boot/dts/renesas/r9a09g047.dtsi | 120 +++++++++++++++++++++
> 1 file changed, 120 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> index f2fdaadd9d39..25d3a503a6cc 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> @@ -1585,6 +1585,126 @@ csi2cru: endpoint@0 {
> };
> };
>
> + dsi: dsi@16430000 {
> + compatible = "renesas,r9a09g047-mipi-dsi";
> + reg = <0 0x16430000 0 0x20000>;
> + interrupts = <GIC_SPI 874 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 875 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 876 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 877 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 878 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 879 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 880 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "seq0", "seq1", "vin1", "rcv",
> + "ferr", "ppi", "debug";
> + clocks = <&cpg CPG_MOD 0xec>, <&cpg CPG_MOD 0xe9>,
> + <&cpg CPG_MOD 0xe8>, <&cpg CPG_MOD 0xea>,
> + <&cpg CPG_MOD 0x190>, <&cpg CPG_MOD 0xeb>;
> + clock-names = "pllrefclk", "aclk", "pclk", "vclk",
> + "lpclk", "vclk2";
> + resets = <&cpg 0xd8>, <&cpg 0xd7>;
> + reset-names = "arst", "prst";
> + power-domains = <&cpg>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dsi_in0: endpoint {
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dsi_in1: endpoint {
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + dsi_out: endpoint {
> + };
> + };
> + };
> + };
> +
> + du0: display@16460000 {
> + compatible = "renesas,r9a09g047-du";
> + reg = <0 0x16460000 0 0x10000>;
> + interrupts = <GIC_SPI 882 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 0xed>,
> + <&cpg CPG_MOD 0xee>,
> + <&cpg CPG_MOD 0xef>;
> + clock-names = "aclk", "pclk", "vclk";
> + power-domains = <&cpg>;
> + resets = <&cpg 0xdc>;
I'm a bit concerned here. The same reset line is shared by the FCP, VSP
and DU. The FCP driver doesn't currently control it, but the VSP and DU
both assert and de-assert reset, without any coordination. Does it work
by chance ?
> + renesas,vsps = <&vspd0 0>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + du0_out_dsi: endpoint {
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + du0_out_lvds0: endpoint {
> + };
> + };
> +
> + port@3 {
> + reg = <3>;
> + du0_out_lvds1: endpoint {
> + };
> + };
> + };
> + };
> +
> + du1: display@16490000 {
> + compatible = "renesas,r9a09g047-du";
> + reg = <0 0x16490000 0 0x10000>;
> + interrupts = <GIC_SPI 922 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 0x1a8>,
> + <&cpg CPG_MOD 0x1a9>,
> + <&cpg CPG_MOD 0x1aa>;
> + clock-names = "aclk", "pclk", "vclk";
> + power-domains = <&cpg>;
> + resets = <&cpg 0x11e>;
> + renesas,vsps = <&vspd1 0>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + du1_out_dsi: endpoint {
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + du1_out_rgb: endpoint {
> + };
> + };
> +
> + port@3 {
> + reg = <3>;
> + du1_out_lvds1: endpoint {
> + };
> + };
> + };
> + };
> +
> fcpvd0: fcp@16470000 {
> compatible = "renesas,r9a09g047-fcpvd",
> "renesas,fcpv";
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
From: Mark Brown @ 2026-04-08 12:06 UTC (permalink / raw)
To: Biju
Cc: Fabrizio Castro, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju Das, linux-spi,
linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad, Krzysztof Kozlowski
In-Reply-To: <20260408085418.18770-2-biju.das.jz@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v2] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Fidelio Lawson @ 2026-04-08 11:57 UTC (permalink / raw)
To: Woojung Huh, UNGLinuxDriver, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Marek Vasut,
Maxime Chevallier
Cc: Woojung Huh, netdev, devicetree, linux-kernel, Fidelio Lawson
Implement the "Module 3: Equalizer fix for short cables" erratum from
Microchip document DS80000687C for KSZ87xx switches.
The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
where the PHY receiver equalizer may amplify high-amplitude signals
excessively, resulting in internal distortion and link establishment
failures.
KSZ87xx devices require a workaround for the Module 3 low-loss cable
condition, controlled through the switch TABLE_LINK_MD_V indirect
registers.
The affected registers are part of the switch address space and are not
directly accessible from the PHY driver. To keep the PHY-facing API
clean and avoid leaking switch-specific details, model this errata
control as vendor-specific Clause 22 PHY registers.
Two vendor-defined bits are introduced in PHY_REG_LOW_LOSS_CTRL,
and ksz8_r_phy() / ksz8_w_phy() translate accesses to these bits
into the appropriate indirect TABLE_LINK_MD_V accesses.
The control register defines the following modes:
bits [1:0]:
00 = workaround disabled
01 = workaround 1 (DSP EQ training adjustment, LinkMD reg 0x3c)
10 = workaround 2 (receiver LPF bandwidth, LinkMD reg 0x4c)
Workaround 1: Adjusts the DSP EQ training behavior via LinkMD register
0x3C. Widens and optimizes the DSP EQ compensation range,
and is expected to solve most short/low-loss cable issues.
Workaround 2: for the cases where Workaround 1 is not sufficient.
This one adjusts the receiver low-pass filter bandwidth, effectively
reducing the high-frequency component of the received signal
The register is accessible through standard PHY read/write operations
(e.g. phytool), without requiring any switch-specific userspace
interface. This allows robust link establishment on short or
low-loss cabling without requiring DTS properties and without
constraining hardware design choices.
The erratum affects the shared PHY analog front-end and therefore
applies globally to the switch.
Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
---
Hello,
This patch implements the “Module 3: Equalizer fix for short cables” erratum
described in Microchip document DS80000687C for KSZ87xx switches.
According to the erratum, the embedded PHY receiver in KSZ87xx switches is
tuned by default for long, high-loss Ethernet cables. When operating with
short or low-loss cables (for example CAT5e or CAT6), the PHY equalizer may
over-amplify the incoming signal, leading to internal distortion and link
establishment failures.
Microchip provides two workarounds, each requiring a write to a different
indirect PHY register access mechanism.
The workaround requires programming internal PHY/DSP registers located in the
LinkMD table, accessed through the KSZ8 indirect register mechanism. Since these
registers belong to the switch address space and are not directly accessible
from a standalone PHY driver, the erratum control is modeled as a vendor-specific
Clause 22 PHY register, virtualized by the KSZ8 DSA driver.
Reads and writes to this register are intercepted by ksz8_r_phy() /
ksz8_w_phy() and translated into the required TABLE_LINK_MD_V indirect accesses.
The erratum affects the shared PHY analog front-end and therefore applies
globally to the switch.
The register defines three modes:
- 0x0: workaround disabled
- 0x1: workaround 1 (DSP EQ training adjustment)
- 0x2: workaround 2 (receiver low-pass filter bandwidth reduction)
The register can be read and written from userspace via standard Clause 22 PHY
accesses (for example using phytool) on DSA user ports.
This series is based on Linux v7.0-rc1.
---
Changes in v2:
- Dropped the device tree approache based on review feedback
- Modeled the errata control as a vendor-specific Clause 22 PHY register
- Added KSZ87xx-specific guards and replaced magic values with named macros
- Rebased on Linux v7.0-rc1
- Link to v1: https://patch.msgid.link/20260326-ksz87xx_errata_low_loss_connections-v1-0-79a698f43626@exotec.com
---
drivers/net/dsa/microchip/ksz8.c | 33 +++++++++++++++++++++++++++++++++
drivers/net/dsa/microchip/ksz8_reg.h | 20 +++++++++++++++++++-
drivers/net/dsa/microchip/ksz_common.h | 3 +++
3 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/microchip/ksz8.c b/drivers/net/dsa/microchip/ksz8.c
index c354abdafc1b..d11da6e9ff54 100644
--- a/drivers/net/dsa/microchip/ksz8.c
+++ b/drivers/net/dsa/microchip/ksz8.c
@@ -1058,6 +1058,11 @@ int ksz8_r_phy(struct ksz_device *dev, u16 phy, u16 reg, u16 *val)
if (ret)
return ret;
+ break;
+ case PHY_REG_KSZ87XX_LOW_LOSS:
+ if (!ksz_is_ksz87xx(dev))
+ return -EOPNOTSUPP;
+ data = dev->low_loss_wa_mode;
break;
default:
processed = false;
@@ -1271,6 +1276,34 @@ int ksz8_w_phy(struct ksz_device *dev, u16 phy, u16 reg, u16 val)
if (ret)
return ret;
break;
+ case PHY_REG_KSZ87XX_LOW_LOSS:
+ if (!ksz_is_ksz87xx(dev))
+ return -EOPNOTSUPP;
+
+ switch (val & PHY_KSZ87XX_LOW_LOSS_MASK) {
+ case PHY_LOW_LOSS_ERRATA_DISABLED:
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_EQ_TRAIN,
+ KSZ87XX_EQ_TRAIN_DEFAULT);
+ if (!ret)
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD,
+ KSZ87XX_REG_PHY_LPF,
+ KSZ87XX_PHY_LPF_DEFAULT);
+ break;
+ case KSZ87XX_LOW_LOSS_WA_EQ:
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_EQ_TRAIN,
+ KSZ87XX_EQ_TRAIN_LOW_LOSS);
+ break;
+ case KSZ87XX_LOW_LOSS_WA_LPF:
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_PHY_LPF,
+ KSZ87XX_PHY_LPF_62MHZ);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (!ret)
+ dev->low_loss_wa_mode = val & PHY_KSZ87XX_LOW_LOSS_MASK;
+ return ret;
default:
break;
}
diff --git a/drivers/net/dsa/microchip/ksz8_reg.h b/drivers/net/dsa/microchip/ksz8_reg.h
index 332408567b47..cd1092aa0eaf 100644
--- a/drivers/net/dsa/microchip/ksz8_reg.h
+++ b/drivers/net/dsa/microchip/ksz8_reg.h
@@ -202,6 +202,10 @@
#define REG_PORT_3_STATUS_0 0x38
#define REG_PORT_4_STATUS_0 0x48
+/* KSZ87xx LinkMD registers (TABLE_LINK_MD_V) */
+#define KSZ87XX_REG_EQ_TRAIN 0x3C
+#define KSZ87XX_REG_PHY_LPF 0x4C
+
/* For KSZ8765. */
#define PORT_REMOTE_ASYM_PAUSE BIT(5)
#define PORT_REMOTE_SYM_PAUSE BIT(4)
@@ -342,7 +346,7 @@
#define TABLE_EEE (TABLE_EEE_V << TABLE_EXT_SELECT_S)
#define TABLE_ACL (TABLE_ACL_V << TABLE_EXT_SELECT_S)
#define TABLE_PME (TABLE_PME_V << TABLE_EXT_SELECT_S)
-#define TABLE_LINK_MD (TABLE_LINK_MD << TABLE_EXT_SELECT_S)
+#define TABLE_LINK_MD (TABLE_LINK_MD_V << TABLE_EXT_SELECT_S)
#define TABLE_READ BIT(4)
#define TABLE_SELECT_S 2
#define TABLE_STATIC_MAC_V 0
@@ -729,6 +733,20 @@
#define PHY_POWER_SAVING_ENABLE BIT(2)
#define PHY_REMOTE_LOOPBACK BIT(1)
+/* Equalizer low-loss workaround */
+/* bits [1:0]: 00 = disabled, 01 = workaround 1, 10 = workaround 2 */
+#define PHY_REG_KSZ87XX_LOW_LOSS 0x1C
+#define PHY_KSZ87XX_LOW_LOSS_MASK GENMASK(1, 0)
+
+#define PHY_LOW_LOSS_ERRATA_DISABLED 0
+#define KSZ87XX_LOW_LOSS_WA_EQ 1
+#define KSZ87XX_LOW_LOSS_WA_LPF 2
+
+#define KSZ87XX_EQ_TRAIN_DEFAULT 0x0A
+#define KSZ87XX_EQ_TRAIN_LOW_LOSS 0x15
+#define KSZ87XX_PHY_LPF_DEFAULT 0x00
+#define KSZ87XX_PHY_LPF_62MHZ 0x40
+
/* KSZ8463 specific registers. */
#define P1MBCR 0x4C
#define P1MBSR 0x4E
diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h
index 929aff4c55de..729996c7160c 100644
--- a/drivers/net/dsa/microchip/ksz_common.h
+++ b/drivers/net/dsa/microchip/ksz_common.h
@@ -219,6 +219,9 @@ struct ksz_device {
* the switch’s internal PHYs, bypassing the main SPI interface.
*/
struct mii_bus *parent_mdio_bus;
+
+ /* Equalizer low-loss workaround tunable */
+ u8 low_loss_wa_mode; /* bits [1:0]: 00 = disabled, 01 = workaround 1, 10 = workaround 2 */
};
/* List of supported models */
---
base-commit: 2d1373e4246da3b58e1df058374ed6b101804e07
change-id: 20260323-ksz87xx_errata_low_loss_connections-b65e76e2b403
Best regards,
--
Fidelio Lawson <fidelio.lawson@exotec.com>
^ permalink raw reply related
* [PATCH] ARM: dts: exynos: Add bluetooth support to manta
From: Lukas Timmermann @ 2026-04-08 11:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alim Akhtar
Cc: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
Lukas Timmermann, Alexandre Marquet
Enable the bcm4330-bt device for manta boards on serial0.
Also adds the necessary pin definitions and interrupt handling for
wakeup.
Signed-off-by: Lukas Timmermann <linux@timmermann.space>
Co-developed-by: Alexandre Marquet <tb@a-marquet.fr>
Signed-off-by: Alexandre Marquet <tb@a-marquet.fr>
---
This patch depends on previous patches which are
currently only found in linux-next.
See: https://lore.kernel.org/all/177214038655.341086.4114348823043257597.b4-ty@kernel.org/
---
arch/arm/boot/dts/samsung/exynos5250-manta.dts | 41 +++++++++++++++++++++++++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/samsung/exynos5250-manta.dts b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
index 24a27b342227..76d3657eb22f 100644
--- a/arch/arm/boot/dts/samsung/exynos5250-manta.dts
+++ b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
@@ -461,6 +461,13 @@ acc_int: acc-int-pins {
samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
};
+ bt_host_wakeup: bt-host-wakeup-pins {
+ samsung,pins = "gpx2-6";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
+ };
+
max77686_irq: max77686-irq-pins {
samsung,pins = "gpx0-2";
samsung,pin-function = <EXYNOS_PIN_FUNC_F>;
@@ -488,6 +495,20 @@ bh1721fvc_reset: bh1721fvc-reset-pins {
samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
};
+ bt_reg_on: bt-reg-on-pins {
+ samsung,pins = "gph0-0";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-con-pdn = <EXYNOS_PIN_PDN_PREV>;
+ samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ bt_wake: bt-wake-pins {
+ samsung,pins = "gph1-3";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-con-pdn = <EXYNOS_PIN_PDN_PREV>;
+ samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>;
+ };
+
msense_reset: msense-reset-pins {
samsung,pins = "gpg2-0";
samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
@@ -536,7 +557,25 @@ &sd1_cmd {
/* Bluetooth */
&serial_0 {
- status = "disabled";
+ pinctrl-0 = <&uart0_data &uart0_fctl>;
+ pinctrl-names = "default";
+
+ bluetooth {
+ compatible = "brcm,bcm4330-bt";
+
+ pinctrl-0 = <&bt_reg_on &bt_wake &bt_host_wakeup>;
+ pinctrl-names = "default";
+
+ shutdown-gpios = <&gph0 0 GPIO_ACTIVE_HIGH>;
+ device-wakeup-gpios = <&gph1 3 GPIO_ACTIVE_HIGH>;
+
+ interrupt-parent = <&gpx2>;
+ interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "host-wakeup";
+
+ clocks = <&max77686 MAX77686_CLK_PMIC>;
+ clock-names = "lpo";
+ };
};
/* GPS */
---
base-commit: e5f7e05a699f41275d6380c497293446034bc8af
change-id: 20260404-manta-bluetooth-836133028bb6
Best regards,
--
Lukas Timmermann <linux@timmermann.space>
^ permalink raw reply related
* Re: [PATCH v7 0/3] riscv: Use GCR.U timer device as clocksource
From: Aleksa Paunovic @ 2026-04-08 11:53 UTC (permalink / raw)
To: devnull+aleksa.paunovic.htecgroup.com@kernel.org
Cc: Aleksa Paunovic, alex@ghiti.fr, aou@eecs.berkeley.edu,
cfu@mips.com, conor+dt@kernel.org, conor.dooley@microchip.com,
daniel.lezcano@linaro.org, devicetree@vger.kernel.org,
Djordje Todorovic, jstultz@google.com, krzk+dt@kernel.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
palmer@dabbelt.com, paul.walmsley@sifive.com, pjw@kernel.org,
robh@kernel.org, sboyd@kernel.org, tglx@linutronix.de,
wangruikang@iscas.ac.cn
In-Reply-To: <20260311-riscv-time-mmio-v7-0-016845a0f808@htecgroup.com>
On 3/11/26 14:26, Aleksa Paunovic via B4 Relay wrote:
> This series adds bindings for the GCR.U timer device and corresponding
> driver support. Accessing the memory mapped shadow of the mtime register
> in the GCR.U region should be faster
> than trapping to M mode each time the timer needs to be read.
> The timer device does not implement any interrupts, therefore the
> timer-riscv clockevent implementation should suffice.
>
> We tested the patchset both on QEMU and the Boston board with the P8700 bitfile:
> - Coremark and timer kselftests on QEMU emulating an 8 core CPU
> - Coremark and timer kselftests on the Boston board with a single core CPU.
Gentle ping.
^ permalink raw reply
* Re: [PATCH 3/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Fidelio LAWSON @ 2026-04-08 11:50 UTC (permalink / raw)
To: Andrew Lunn
Cc: Woojung Huh, UNGLinuxDriver, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Maxime Chevallier,
netdev, devicetree, linux-kernel, Fidelio Lawson
In-Reply-To: <c235ee5c-6057-4c10-9960-9c5a3527bf22@lunn.ch>
On 4/4/26 16:45, Andrew Lunn wrote:
> On Fri, Apr 03, 2026 at 11:43:24AM +0200, Fidelio LAWSON wrote:
>> On 3/26/26 13:18, Andrew Lunn wrote:
>>>> + mutex_lock(&dev->alu_mutex);
>>>> +
>>>> + ret = ksz_write8(dev, regs[REG_IND_CTRL_0], 0xA0);
>>>> +
>>>> + if (!ret)
>>>> + ret = ksz_write8(dev, 0x6F, indir_reg);
>>>> +
>>>> + if (!ret)
>>>> + ret = ksz_write8(dev, regs[REG_IND_BYTE], indir_val);
>>>> +
>>>> + mutex_unlock(&dev->alu_mutex);
>>>
>>> What address space are these registers in? Normally workarounds for a
>>> PHY would be in the PHY driver. But that assumes the registers are
>>> accessible from the PHY driver.
>>>
>>> Andrew
>>
>> Hi Andrew,
>> These registers belong to the KSZ87xx switch address space, accessed through
>> the switch’s indirect access mechanism. In particular, the offsets used here
>> correspond to entries within the TABLE_LINK_MD_V indirect table of the
>> KSZ8-family switches.
>
> So this errata is for ksz87xx only?
>
> For this PHY, do all PHY register reads and writes go through
>
> https://elixir.bootlin.com/linux/v6.19.11/source/drivers/net/dsa/microchip/ksz8.c#L957
> ksz8_r_phy()
>
> and
>
> https://elixir.bootlin.com/linux/v6.19.11/source/drivers/net/dsa/microchip/ksz8.c#L1221
> ksz8_w_phy()?
>
> We already have some "interesting" things going on in these
> functions. PHY_REG_LINK_MD and PHY_REG_PHY_CTRL are not standard C22
> PHY registers. They take the values 0x1d and 0x1f. The 802.3 standard
> defines 0x10-0x1f as vendor specific, so this is O.K.
>
> So you could define 2 bits in say register 0x1c to indicate the errata
> mode. You can have a PHY tunable which does reads/writes to these two
> bits, and ksz8_w_phy/ksz8_r_phy which translates them to indirect
> register accesses?
>
> It is not even really violating the layering.
>
> Andrew
Hi Andrew,
Thanks a lot for the feedback, it was very helpful.
Yes, the erratum affects KSZ87xx devices only, and all accesses to the
embedded PHYs indeed go through ksz8_r_phy() / ksz8_w_phy(), as you
pointed out.
I followed your suggestion and reworked the implementation accordingly:
the errata selection is now modeled as a vendor‑specific Clause 22 PHY
register (0x1c), handled entirely in ksz8_r_phy() / ksz8_w_phy(), which
translate reads and writes into the appropriate indirect TABLE_LINK_MD_V
accesses. This keeps the PHY‑facing API clean without breaking the layering.
I’ve dropped the DT approach and adjusted the implementation based on
the review comments. I’m sending a v2 with these changes shortly.
Thanks again for the guidance.
Best regards,
Fidelio
^ permalink raw reply
* Re: [PATCH v8 1/7] dt-bindings: input: syna,rmi4: Document syna,rmi4-s3706b
From: David Heidelberg @ 2026-04-08 11:50 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Kaustabh Chakraborty, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Casey Connolly, linux-input, devicetree,
linux-kernel, phone-devel, Krzysztof Kozlowski
In-Reply-To: <adSMQXgbco8fvRLo@google.com>
On 07/04/2026 06:48, Dmitry Torokhov wrote:
> On Wed, Mar 25, 2026 at 12:33:23PM +0100, David Heidelberg wrote:
>> On 24/03/2026 20:42, Dmitry Torokhov wrote:
>>> On Tue, Mar 24, 2026 at 08:40:34PM +0100, David Heidelberg via B4 Relay wrote:
>>>> From: David Heidelberg <david@ixit.cz>
>>>>
>>>> Mostly irrelevant for authentic Synaptics touchscreens, but very important
>>>> for applying workarounds to cheap TS knockoffs.
>>>>
>>>> These knockoffs work well with the downstream driver, and since the user
>>>> has no way to distinguish them, later in this patch set, we introduce
>>>> workarounds to ensure they function as well as possible.
>>>>
>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>> Signed-off-by: David Heidelberg <david@ixit.cz>
>>>> ---
>>>> Documentation/devicetree/bindings/input/syna,rmi4.yaml | 11 ++++++++---
>>>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/input/syna,rmi4.yaml b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
>>>> index 8685ef4481f4a..fb4804ac3544d 100644
>>>> --- a/Documentation/devicetree/bindings/input/syna,rmi4.yaml
>>>> +++ b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
>>>> @@ -18,9 +18,14 @@ description: |
>>>> properties:
>>>> compatible:
>>>> - enum:
>>>> - - syna,rmi4-i2c
>>>> - - syna,rmi4-spi
>>>> + oneOf:
>>>> + - enum:
>>>> + - syna,rmi4-i2c
>>>> + - syna,rmi4-spi
>>>> + - items:
>>>> + - enum:
>>>> + - syna,rmi4-s3706b # OnePlus 6/6T
>>>
>>> I thought that all the workarounds will be keyed off this new
>>> compatible, but I do not see that. What am I missing?
>>
>> The compatible is used for sequence in the
>>
>> Input: synaptics-rmi4 - support fallback values for PDT descriptor bytes
>>
>> where it is used to provide values missing for OP6 (and possible others in
>> the future, when added).
>>
>> From my understanding the series, only two patches (1st and last) are
>> specific for the OP6, rest will likely benefit various TS not implementing
>> full Synaptics set. All measures apply only when touchscreen reports
>> something wrong.
>
> If the sensor does not implement RMI4 protocol properly it should not
> use rmi4 compatibility. I will not apply any patches that work around
> incomplete implementations unless they are triggered by a dedicated
> compatible.
Ok, good.
Can we agree on subset which is correct now?
I think that
[PATCH v8 4/7] Input: synaptics-rmi4 - f55: handle zero electrode count
[PATCH v8 6/7] Input: synaptics-rmi4 - read product ID on aftermarket touch ICs
could be reasonable to keep as is, except I would reword the 6/7, as reading
product ID isn't anything aftermarket specific.
Then I would send this subset to get in first and work on the rest, does it
sounds good to you?
David>
> Thanks.
>
--
David Heidelberg
^ permalink raw reply
* Re: [PATCH v6 19/21] arm64: dts: renesas: r9a09g047: Add vspd{0,1} nodes
From: Laurent Pinchart @ 2026-04-08 11:33 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, 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,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <46547aaff3cdb8ea6e17cf1fdec699d83a1cd71b.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:37:04PM +0200, Tommaso Merciai wrote:
> Add vspd{0,1} nodes to RZ/G3E SoC DTSI.
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> ---
> v5->v6:
> - No changes.
>
> v4->v5:
> - No changes.
>
> v3->v4:
> - No changes.
>
> v2->v3:
> - No changes.
>
> v1->v2:
> - Squashed vspd0 and vspd1 patches into a single patch.
> - Collected tags.
>
> arch/arm64/boot/dts/renesas/r9a09g047.dtsi | 28 ++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> index 3115ab4b050f..f2fdaadd9d39 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> @@ -1608,6 +1608,34 @@ fcpvd1: fcp@164a0000 {
> resets = <&cpg 0x11e>;
> power-domains = <&cpg>;
> };
> +
> + vspd0: vsp@16480000 {
> + compatible = "renesas,r9a09g047-vsp2",
> + "renesas,r9a07g044-vsp2";
> + reg = <0 0x16480000 0 0x10000>;
> + interrupts = <GIC_SPI 881 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 0xed>,
> + <&cpg CPG_MOD 0xee>,
> + <&cpg CPG_MOD 0xef>;
> + clock-names = "aclk", "pclk", "vclk";
> + resets = <&cpg 0xdc>;
> + power-domains = <&cpg>;
> + renesas,fcp = <&fcpvd0>;
> + };
> +
> + vspd1: vsp@164b0000 {
> + compatible = "renesas,r9a09g047-vsp2",
> + "renesas,r9a07g044-vsp2";
> + reg = <0 0x164b0000 0 0x10000>;
> + interrupts = <GIC_SPI 921 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 0x1a8>,
> + <&cpg CPG_MOD 0x1a9>,
> + <&cpg CPG_MOD 0x1aa>;
> + clock-names = "aclk", "pclk", "vclk";
> + resets = <&cpg 0x11e>;
> + power-domains = <&cpg>;
> + renesas,fcp = <&fcpvd1>;
> + };
This matches the documentation.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> };
>
> stmmac_axi_setup: stmmac-axi-config {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v6 18/21] arm64: dts: renesas: r9a09g047: Add fcpvd{0,1} nodes
From: Laurent Pinchart @ 2026-04-08 11:32 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, 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,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <1ba6a98ace4ad9525d054cbaa308d3aeeecfa22a.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:37:03PM +0200, Tommaso Merciai wrote:
> Add fcpvd{0,1} nodes to RZ/G3E SoC DTSI.
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> ---
> v5->v6:
> - No changes.
>
> v4->v5:
> - No changes.
>
> v3->v4:
> - No changes.
>
> v2->v3:
> - No changes.
>
> v1->v2:
> - Squashed fcpvd0 and fcpvd1 patches into a single patch.
> - Collected tags.
>
> arch/arm64/boot/dts/renesas/r9a09g047.dtsi | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> index 95a4e30a064d..3115ab4b050f 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> @@ -1584,6 +1584,30 @@ csi2cru: endpoint@0 {
> };
> };
> };
> +
> + fcpvd0: fcp@16470000 {
> + compatible = "renesas,r9a09g047-fcpvd",
> + "renesas,fcpv";
> + reg = <0 0x16470000 0 0x10000>;
> + clocks = <&cpg CPG_MOD 0xed>,
> + <&cpg CPG_MOD 0xee>,
> + <&cpg CPG_MOD 0xef>;
> + clock-names = "aclk", "pclk", "vclk";
> + resets = <&cpg 0xdc>;
> + power-domains = <&cpg>;
> + };
> +
> + fcpvd1: fcp@164a0000 {
> + compatible = "renesas,r9a09g047-fcpvd",
> + "renesas,fcpv";
> + reg = <0 0x164a0000 0 0x10000>;
> + clocks = <&cpg CPG_MOD 0x1a8>,
> + <&cpg CPG_MOD 0x1a9>,
> + <&cpg CPG_MOD 0x1aa>;
> + clock-names = "aclk", "pclk", "vclk";
> + resets = <&cpg 0x11e>;
> + power-domains = <&cpg>;
> + };
This matches the documentation.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> };
>
> stmmac_axi_setup: stmmac-axi-config {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [net-next v1 v1 4/5] net: stmmac: starfive: Add JHB100 SGMII interface
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260408084416.29753-1-minda.chen@starfivetech.com>
Add JHB100 compatible and SGMII support. JHB100 soc contains
2 SGMII interfaces and integrated with serdes PHY. SGMII with
split TX/RX MAC clock and need to set 2.5M/25M/125M TX/RX clock
rate in 10M/100M/1000M speed mode.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../ethernet/stmicro/stmmac/dwmac-starfive.c | 36 +++++++++++++++++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
index 16b955a6d77b..df7b2fc9989d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
@@ -26,6 +26,7 @@ struct starfive_dwmac_data {
struct starfive_dwmac {
struct device *dev;
const struct starfive_dwmac_data *data;
+ struct clk *sgmii_rx;
};
static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
@@ -36,6 +37,9 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
int phy_intf_sel;
int err;
+ if (plat_dat->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ return 0;
+
phy_intf_sel = stmmac_get_phy_intf_sel(plat_dat->phy_interface);
if (phy_intf_sel != PHY_INTF_SEL_RGMII &&
phy_intf_sel != PHY_INTF_SEL_RMII) {
@@ -68,6 +72,24 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
return 0;
}
+static int stmmac_starfive_sgmii_set_clk_rate(void *bsp_priv, struct clk *clk_tx_i,
+ phy_interface_t interface, int speed)
+{
+ struct starfive_dwmac *dwmac = (void *)bsp_priv;
+ long rate = rgmii_clock(speed);
+ int ret;
+
+ /* MAC clock rate the same as RGMII */
+ if (rate < 0)
+ return 0;
+
+ ret = clk_set_rate(clk_tx_i, rate);
+ if (ret)
+ return ret;
+
+ return clk_set_rate(dwmac->sgmii_rx, rate);
+}
+
static int starfive_dwmac_probe(struct platform_device *pdev)
{
struct plat_stmmacenet_data *plat_dat;
@@ -102,14 +124,23 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
return dev_err_probe(&pdev->dev, PTR_ERR(clk_gtx),
"error getting gtx clock\n");
+ dwmac->sgmii_rx = devm_clk_get_optional(&pdev->dev, "rx");
+ if (IS_ERR(dwmac->sgmii_rx))
+ return dev_err_probe(&pdev->dev, PTR_ERR(dwmac->sgmii_rx),
+ "error getting sgmii rx clock\n");
+
/* Generally, the rgmii_tx clock is provided by the internal clock,
* which needs to match the corresponding clock frequency according
* to different speeds. If the rgmii_tx clock is provided by the
* external rgmii_rxin, there is no need to configure the clock
* internally, because rgmii_rxin will be adaptively adjusted.
*/
- if (!device_property_read_bool(&pdev->dev, "starfive,tx-use-rgmii-clk"))
- plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
+ if (!device_property_read_bool(&pdev->dev, "starfive,tx-use-rgmii-clk")) {
+ if (plat_dat->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ plat_dat->set_clk_tx_rate = stmmac_starfive_sgmii_set_clk_rate;
+ else
+ plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
+ }
dwmac->dev = &pdev->dev;
plat_dat->flags |= STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP;
@@ -130,6 +161,7 @@ static const struct starfive_dwmac_data jh7100_data = {
static const struct of_device_id starfive_dwmac_match[] = {
{ .compatible = "starfive,jh7100-dwmac", .data = &jh7100_data },
{ .compatible = "starfive,jh7110-dwmac" },
+ { .compatible = "starfive,jhb100-dwmac" },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, starfive_dwmac_match);
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox