1. Patchew
  2. linux
  3. [PATCH v3 0/2] ARM: add support for pcb8385
  4. View patch

[PATCH v3 2/2] ARM: dts: Add support for pcb8385

Horatiu Vultur posted 2 patches 5 days, 13 hours ago
There is a newer version of this series
[PATCH v3 2/2] ARM: dts: Add support for pcb8385
Posted by Horatiu Vultur 5 days, 13 hours ago 
Add basic support for pcb8385 [1]. It is a modular board which allows
to add different daughter cards on which there are different PHYs.
This adds support for UART, LEDs and I2C.

[1] https://www.microchip.com/en-us/development-tool/ev83e85a

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
---
 arch/arm/boot/dts/microchip/Makefile          |   3 +-
 .../boot/dts/microchip/lan966x-pcb8385.dts    | 133 ++++++++++++++++++
 2 files changed, 135 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/microchip/lan966x-pcb8385.dts

diff --git a/arch/arm/boot/dts/microchip/Makefile b/arch/arm/boot/dts/microchip/Makefile
index 79cd38fdc7dab..08986c24a4700 100644
--- a/arch/arm/boot/dts/microchip/Makefile
+++ b/arch/arm/boot/dts/microchip/Makefile
@@ -102,4 +102,5 @@ dtb-$(CONFIG_SOC_LAN966) += \
 	lan966x-kontron-kswitch-d10-mmt-8g.dtb \
 	lan966x-pcb8290.dtb \
 	lan966x-pcb8291.dtb \
-	lan966x-pcb8309.dtb
+	lan966x-pcb8309.dtb \
+	lan966x-pcb8385.dtb
diff --git a/arch/arm/boot/dts/microchip/lan966x-pcb8385.dts b/arch/arm/boot/dts/microchip/lan966x-pcb8385.dts
new file mode 100644
index 0000000000000..a7ac7854cdaf0
--- /dev/null
+++ b/arch/arm/boot/dts/microchip/lan966x-pcb8385.dts
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * lan966x-pcb8385.dts - Device Tree file for PCB8385
+ */
+/dts-v1/;
+
+#include "lan966x.dtsi"
+#include "dt-bindings/phy/phy-lan966x-serdes.h"
+
+/ {
+	model = "Microchip EVB - LAN9668";
+	compatible = "microchip,lan9668-pcb8385", "microchip,lan9668", "microchip,lan966";
+
+	aliases {
+		serial0 = &usart3;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio-restart {
+		compatible = "gpio-restart";
+		gpios = <&gpio 59 GPIO_ACTIVE_LOW>;
+		open-source;
+		priority = <200>;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led-p1-green {
+			label = "cu0:green";
+			gpios = <&sgpio_out 2 0 GPIO_ACTIVE_LOW>;
+			default-state = "off";
+		};
+
+		led-p1-yellow {
+			label = "cu0:yellow";
+			gpios = <&sgpio_out 2 1 GPIO_ACTIVE_LOW>;
+			default-state = "off";
+		};
+
+		led-p2-green {
+			label = "cu1:green";
+			gpios = <&sgpio_out 3 0 GPIO_ACTIVE_LOW>;
+			default-state = "off";
+		};
+
+		led-p2-yellow {
+			label = "cu1:yellow";
+			gpios = <&sgpio_out 3 1 GPIO_ACTIVE_LOW>;
+			default-state = "off";
+		};
+	};
+};
+
+&aes {
+	status = "disabled"; /* Reserved by secure OS */
+};
+
+&flx0 {
+	atmel,flexcom-mode = <ATMEL_FLEXCOM_MODE_TWI>;
+	status = "okay";
+
+	i2c0: i2c@600 {
+		pinctrl-0 = <&fc0_b_pins>;
+		pinctrl-names = "default";
+		dmas = <0>, <0>;
+		i2c-analog-filter;
+		i2c-digital-filter;
+		i2c-digital-filter-width-ns = <35>;
+		i2c-sda-hold-time-ns = <1500>;
+		status = "okay";
+
+		eeprom@54 {
+			compatible = "atmel,24c01";
+			reg = <0x54>;
+			status = "okay";
+		};
+
+		eeprom@55 {
+			compatible = "atmel,24c01";
+			reg = <0x55>;
+			status = "okay";
+		};
+	};
+};
+
+&flx3 {
+	atmel,flexcom-mode = <ATMEL_FLEXCOM_MODE_USART>;
+	status = "okay";
+
+	usart3: serial@200 {
+		pinctrl-0 = <&fc3_b_pins>;
+		pinctrl-names = "default";
+		status = "okay";
+	};
+};
+
+&gpio {
+	fc0_b_pins: fc0-b-pins {
+		/* SCL, SDA */
+		pins = "GPIO_25", "GPIO_26";
+		function = "fc0_b";
+	};
+
+	fc3_b_pins: fc3-b-pins {
+		/* RX, TX */
+		pins = "GPIO_52", "GPIO_53";
+		function = "fc3_b";
+	};
+
+	sgpio_a_pins: sgpio-a-pins {
+		/* SCK, D0, D1, LD */
+		pins = "GPIO_32", "GPIO_33", "GPIO_34", "GPIO_35";
+		function = "sgpio_a";
+	};
+};
+
+&sgpio {
+	pinctrl-0 = <&sgpio_a_pins>;
+	pinctrl-names = "default";
+	microchip,sgpio-port-ranges = <0 3>;
+	status = "okay";
+
+	gpio@0 {
+		ngpios = <64>;
+	};
+	gpio@1 {
+		ngpios = <64>;
+	};
+};
-- 
2.34.1
Re: [PATCH v3 2/2] ARM: dts: Add support for pcb8385
Posted by Krzysztof Kozlowski 5 days, 13 hours ago 
On 26/11/2025 11:01, Horatiu Vultur wrote:
> Add basic support for pcb8385 [1]. It is a modular board which allows
> to add different daughter cards on which there are different PHYs.
> This adds support for UART, LEDs and I2C.
> 
> [1] https://www.microchip.com/en-us/development-tool/ev83e85a
> 
> Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
> ---
>  arch/arm/boot/dts/microchip/Makefile          |   3 +-
>  .../boot/dts/microchip/lan966x-pcb8385.dts    | 133 ++++++++++++++++++
>  2 files changed, 135 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/microchip/lan966x-pcb8385.dts
> 
> diff --git a/arch/arm/boot/dts/microchip/Makefile b/arch/arm/boot/dts/microchip/Makefile
> index 79cd38fdc7dab..08986c24a4700 100644
> --- a/arch/arm/boot/dts/microchip/Makefile
> +++ b/arch/arm/boot/dts/microchip/Makefile
> @@ -102,4 +102,5 @@ dtb-$(CONFIG_SOC_LAN966) += \
>  	lan966x-kontron-kswitch-d10-mmt-8g.dtb \
>  	lan966x-pcb8290.dtb \
>  	lan966x-pcb8291.dtb \
> -	lan966x-pcb8309.dtb
> +	lan966x-pcb8309.dtb \
> +	lan966x-pcb8385.dtb
> diff --git a/arch/arm/boot/dts/microchip/lan966x-pcb8385.dts b/arch/arm/boot/dts/microchip/lan966x-pcb8385.dts
> new file mode 100644
> index 0000000000000..a7ac7854cdaf0
> --- /dev/null
> +++ b/arch/arm/boot/dts/microchip/lan966x-pcb8385.dts
> @@ -0,0 +1,133 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * lan966x-pcb8385.dts - Device Tree file for PCB8385
> + */
> +/dts-v1/;
> +
> +#include "lan966x.dtsi"
> +#include "dt-bindings/phy/phy-lan966x-serdes.h"
> +
> +/ {
> +	model = "Microchip EVB - LAN9668";
> +	compatible = "microchip,lan9668-pcb8385", "microchip,lan9668", "microchip,lan966";
> +
> +	aliases {
> +		serial0 = &usart3;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	gpio-restart {
> +		compatible = "gpio-restart";
> +		gpios = <&gpio 59 GPIO_ACTIVE_LOW>;
> +		open-source;
> +		priority = <200>;
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		led-p1-green {
> +			label = "cu0:green";
> +			gpios = <&sgpio_out 2 0 GPIO_ACTIVE_LOW>;
> +			default-state = "off";
> +		};
> +
> +		led-p1-yellow {
> +			label = "cu0:yellow";
> +			gpios = <&sgpio_out 2 1 GPIO_ACTIVE_LOW>;
> +			default-state = "off";
> +		};
> +
> +		led-p2-green {
> +			label = "cu1:green";
> +			gpios = <&sgpio_out 3 0 GPIO_ACTIVE_LOW>;
> +			default-state = "off";
> +		};
> +
> +		led-p2-yellow {
> +			label = "cu1:yellow";
> +			gpios = <&sgpio_out 3 1 GPIO_ACTIVE_LOW>;
> +			default-state = "off";
> +		};
> +	};
> +};
> +
> +&aes {
> +	status = "disabled"; /* Reserved by secure OS */
> +};
> +
> +&flx0 {
> +	atmel,flexcom-mode = <ATMEL_FLEXCOM_MODE_TWI>;
> +	status = "okay";
> +
> +	i2c0: i2c@600 {

You added a label, so this feels like a new node, but then you miss
compatible and status feels redundant.

If this is override, you should rather override by labels/phandles in
the first place. Even when overriding by full node path, you should not
add custom labels - they belong to the base SoC.

> +		pinctrl-0 = <&fc0_b_pins>;
> +		pinctrl-names = "default";
> +		dmas = <0>, <0>;
> +		i2c-analog-filter;
> +		i2c-digital-filter;
> +		i2c-digital-filter-width-ns = <35>;
> +		i2c-sda-hold-time-ns = <1500>;
> +		status = "okay";

> +
> +		eeprom@54 {
> +			compatible = "atmel,24c01";
> +			reg = <0x54>;
> +			status = "okay";

Why? Was it disabled anywhere?

> +		};
> +
> +		eeprom@55 {
> +			compatible = "atmel,24c01";
> +			reg = <0x55>;
> +			status = "okay";
> +		};
> +	};
> +};
> +



Best regards,
Krzysztof
Re: [PATCH v3 2/2] ARM: dts: Add support for pcb8385
Posted by Horatiu Vultur 4 days, 14 hours ago 
The 11/26/2025 11:24, Krzysztof Kozlowski wrote:
> 

Hi Krzysztof,

> > +
> > +&flx0 {
> > +     atmel,flexcom-mode = <ATMEL_FLEXCOM_MODE_TWI>;
> > +     status = "okay";
> > +
> > +     i2c0: i2c@600 {
> 
> You added a label, so this feels like a new node, but then you miss
> compatible and status feels redundant.

Ah.. OK. I didn't want to add a new node.

> 
> If this is override, you should rather override by labels/phandles in
> the first place. Even when overriding by full node path, you should not
> add custom labels - they belong to the base SoC.

I can remove the label.
So, when I want to override or extend with new properties I should
labels?

> 
> > +             pinctrl-0 = <&fc0_b_pins>;
> > +             pinctrl-names = "default";
> > +             dmas = <0>, <0>;
> > +             i2c-analog-filter;
> > +             i2c-digital-filter;
> > +             i2c-digital-filter-width-ns = <35>;
> > +             i2c-sda-hold-time-ns = <1500>;
> > +             status = "okay";
> 
> > +
> > +             eeprom@54 {
> > +                     compatible = "atmel,24c01";
> > +                     reg = <0x54>;
> > +                     status = "okay";
> 
> Why? Was it disabled anywhere?

It wasn't disabled anywhere. I will remove this.

> 
> > +             };
> > +
> > +             eeprom@55 {
> > +                     compatible = "atmel,24c01";
> > +                     reg = <0x55>;
> > +                     status = "okay";
> > +             };
> > +     };
> > +};
> > +
> 
> 
> 
> Best regards,
> Krzysztof

-- 
/Horatiu
Re: [PATCH v3 2/2] ARM: dts: Add support for pcb8385
Posted by Krzysztof Kozlowski 3 days, 14 hours ago 
On 27/11/2025 10:24, Horatiu Vultur wrote:
> The 11/26/2025 11:24, Krzysztof Kozlowski wrote:
>>
> 
> Hi Krzysztof,
> 
>>> +
>>> +&flx0 {
>>> +     atmel,flexcom-mode = <ATMEL_FLEXCOM_MODE_TWI>;
>>> +     status = "okay";
>>> +
>>> +     i2c0: i2c@600 {
>>
>> You added a label, so this feels like a new node, but then you miss
>> compatible and status feels redundant.
> 
> Ah.. OK. I didn't want to add a new node.
> 
>>
>> If this is override, you should rather override by labels/phandles in
>> the first place. Even when overriding by full node path, you should not
>> add custom labels - they belong to the base SoC.
> 
> I can remove the label.
> So, when I want to override or extend with new properties I should
> labels?


Yes, child of serial engine should still be extended by label/phandle,
unless this SoC subsystem has different rule.

Best regards,
Krzysztof
Re: [PATCH v3 2/2] ARM: dts: Add support for pcb8385
Posted by Horatiu Vultur 3 days, 10 hours ago 
The 11/28/2025 10:08, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 27/11/2025 10:24, Horatiu Vultur wrote:
> > The 11/26/2025 11:24, Krzysztof Kozlowski wrote:
> >>
> >
> > Hi Krzysztof,
> >
> >>> +
> >>> +&flx0 {
> >>> +     atmel,flexcom-mode = <ATMEL_FLEXCOM_MODE_TWI>;
> >>> +     status = "okay";
> >>> +
> >>> +     i2c0: i2c@600 {
> >>
> >> You added a label, so this feels like a new node, but then you miss
> >> compatible and status feels redundant.
> >
> > Ah.. OK. I didn't want to add a new node.
> >
> >>
> >> If this is override, you should rather override by labels/phandles in
> >> the first place. Even when overriding by full node path, you should not
> >> add custom labels - they belong to the base SoC.
> >
> > I can remove the label.
> > So, when I want to override or extend with new properties I should
> > labels?
> 
> 
> Yes, child of serial engine should still be extended by label/phandle,
> unless this SoC subsystem has different rule.

What do you mean by "child of serial engine"?

> 
> Best regards,
> Krzysztof

-- 
/Horatiu
Re: [PATCH v3 2/2] ARM: dts: Add support for pcb8385
Posted by Krzysztof Kozlowski 2 days, 14 hours ago 
On 28/11/2025 14:04, Horatiu Vultur wrote:
> The 11/28/2025 10:08, Krzysztof Kozlowski wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> On 27/11/2025 10:24, Horatiu Vultur wrote:
>>> The 11/26/2025 11:24, Krzysztof Kozlowski wrote:
>>>>
>>>
>>> Hi Krzysztof,
>>>
>>>>> +
>>>>> +&flx0 {
>>>>> +     atmel,flexcom-mode = <ATMEL_FLEXCOM_MODE_TWI>;
>>>>> +     status = "okay";
>>>>> +
>>>>> +     i2c0: i2c@600 {
>>>>
>>>> You added a label, so this feels like a new node, but then you miss
>>>> compatible and status feels redundant.
>>>
>>> Ah.. OK. I didn't want to add a new node.
>>>
>>>>
>>>> If this is override, you should rather override by labels/phandles in
>>>> the first place. Even when overriding by full node path, you should not
>>>> add custom labels - they belong to the base SoC.
>>>
>>> I can remove the label.
>>> So, when I want to override or extend with new properties I should
>>> labels?
>>
>>
>> Yes, child of serial engine should still be extended by label/phandle,
>> unless this SoC subsystem has different rule.
> 
> What do you mean by "child of serial engine"?

flx is your serial engine, no? It's child is i2c or whatever other
interface.


Best regards,
Krzysztof

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.