| Message ID | 20250608211452.72920-13-linux@fw-web.de |
|---|---|
| State | New |
| Headers | show |
| Series | further mt7988 devicetree work | expand |
> +&gmac1 { > + phy-mode = "internal"; > + phy-connection-type = "internal"; ethernet-controller.yaml says: phy-connection-type: description: Specifies interface type between the Ethernet device and a physical layer (PHY) device. enum: # There is not a standard bus between the MAC and the PHY, # something proprietary is being used to embed the PHY in the # MAC. - internal - mii - gmii ... phy-mode: $ref: "#/properties/phy-connection-type" so phy-mode and phy-connection-type are the same thing. > + /* SFP2 cage (LAN) */ > + sfp2: sfp2 { > + compatible = "sff,sfp"; > + i2c-bus = <&i2c_sfp2>; > + los-gpios = <&pio 2 GPIO_ACTIVE_HIGH>; > + mod-def0-gpios = <&pio 83 GPIO_ACTIVE_LOW>; > + tx-disable-gpios = <&pio 0 GPIO_ACTIVE_HIGH>; > + tx-fault-gpios = <&pio 1 GPIO_ACTIVE_HIGH>; > + rate-select0-gpios = <&pio 3 GPIO_ACTIVE_LOW>; > + maximum-power-milliwatt = <3000>; sff,sfp.yaml says: maximum-power-milliwatt: minimum: 1000 default: 1000 description: Maximum module power consumption Specifies the maximum power consumption allowable by a module in the slot, in milli-Watts. Presently, modules can be up to 1W, 1.5W or 2W. I've no idea what will happen when the SFP core sees 3000. Is the comment out of date? Andrew
Hi Andrew > Gesendet: Sonntag, 8. Juni 2025 um 23:31 > Von: "Andrew Lunn" <andrew@lunn.ch> > Betreff: Re: [PATCH v3 12/13] arm64: dts: mediatek: mt7988a-bpi-r4: add sfp cages and link to gmac > > > +&gmac1 { > > + phy-mode = "internal"; > > + phy-connection-type = "internal"; > > ethernet-controller.yaml says: > > phy-connection-type: > description: > Specifies interface type between the Ethernet device and a physical > layer (PHY) device. > enum: > # There is not a standard bus between the MAC and the PHY, > # something proprietary is being used to embed the PHY in the > # MAC. > - internal > - mii > - gmii > ... > > phy-mode: > $ref: "#/properties/phy-connection-type" > > > so phy-mode and phy-connection-type are the same thing. phy-connection-type seems not needed, tested without it and 2.5G phy works without this property in the 2g5 dts. > > + /* SFP2 cage (LAN) */ > > + sfp2: sfp2 { > > + compatible = "sff,sfp"; > > + i2c-bus = <&i2c_sfp2>; > > + los-gpios = <&pio 2 GPIO_ACTIVE_HIGH>; > > + mod-def0-gpios = <&pio 83 GPIO_ACTIVE_LOW>; > > + tx-disable-gpios = <&pio 0 GPIO_ACTIVE_HIGH>; > > + tx-fault-gpios = <&pio 1 GPIO_ACTIVE_HIGH>; > > + rate-select0-gpios = <&pio 3 GPIO_ACTIVE_LOW>; > > + maximum-power-milliwatt = <3000>; > > sff,sfp.yaml says: > > maximum-power-milliwatt: > minimum: 1000 > default: 1000 > description: > Maximum module power consumption Specifies the maximum power consumption > allowable by a module in the slot, in milli-Watts. Presently, modules can > be up to 1W, 1.5W or 2W. > > I've no idea what will happen when the SFP core sees 3000. Is the > comment out of date? at least sfp-core has no issue with the setting root@bpi-r4-phy-8G:~# dmesg | grep sfp [ 1.269437] sfp sfp1: Host maximum power 3.0W [ 1.613749] sfp sfp1: module CISCO-FINISAR FTLX8571D3BCL-C2 rev A sn S2209167650 dc 220916 imho some modules require more than 2W (some gpon/xpon and 10G copper ethernet). > Andrew > regards Frank
> > sff,sfp.yaml says: > > > > maximum-power-milliwatt: > > minimum: 1000 > > default: 1000 > > description: > > Maximum module power consumption Specifies the maximum power consumption > > allowable by a module in the slot, in milli-Watts. Presently, modules can > > be up to 1W, 1.5W or 2W. > > > > I've no idea what will happen when the SFP core sees 3000. Is the > > comment out of date? > > at least sfp-core has no issue with the setting > > root@bpi-r4-phy-8G:~# dmesg | grep sfp > [ 1.269437] sfp sfp1: Host maximum power 3.0W > [ 1.613749] sfp sfp1: module CISCO-FINISAR FTLX8571D3BCL-C2 rev A sn S2209167650 dc 220916 > > imho some modules require more than 2W (some gpon/xpon and 10G copper ethernet). Looking at the code: static int sfp_module_parse_power(struct sfp *sfp) { u32 power_mW = 1000; bool supports_a2; if (sfp->id.ext.sff8472_compliance >= SFP_SFF8472_COMPLIANCE_REV10_2 && sfp->id.ext.options & cpu_to_be16(SFP_OPTIONS_POWER_DECL)) power_mW = 1500; /* Added in Rev 11.9, but there is no compliance code for this */ if (sfp->id.ext.sff8472_compliance >= SFP_SFF8472_COMPLIANCE_REV11_4 && sfp->id.ext.options & cpu_to_be16(SFP_OPTIONS_HIGH_POWER_LEVEL)) power_mW = 2000; How does your module indicate it needs 3000 mW? Does this bit of code need extending to read additional bits? Andrew
Am 10. Juni 2025 14:58:44 MESZ schrieb Andrew Lunn <andrew@lunn.ch>: >> > sff,sfp.yaml says: >> > >> > maximum-power-milliwatt: >> > minimum: 1000 >> > default: 1000 >> > description: >> > Maximum module power consumption Specifies the maximum power consumption >> > allowable by a module in the slot, in milli-Watts. Presently, modules can >> > be up to 1W, 1.5W or 2W. >> > >> > I've no idea what will happen when the SFP core sees 3000. Is the >> > comment out of date? >> >> at least sfp-core has no issue with the setting >> >> root@bpi-r4-phy-8G:~# dmesg | grep sfp >> [ 1.269437] sfp sfp1: Host maximum power 3.0W >> [ 1.613749] sfp sfp1: module CISCO-FINISAR FTLX8571D3BCL-C2 rev A sn S2209167650 dc 220916 >> >> imho some modules require more than 2W (some gpon/xpon and 10G copper ethernet). > >Looking at the code: > >static int sfp_module_parse_power(struct sfp *sfp) >{ > u32 power_mW = 1000; > bool supports_a2; > > if (sfp->id.ext.sff8472_compliance >= SFP_SFF8472_COMPLIANCE_REV10_2 && > sfp->id.ext.options & cpu_to_be16(SFP_OPTIONS_POWER_DECL)) > power_mW = 1500; > /* Added in Rev 11.9, but there is no compliance code for this */ > if (sfp->id.ext.sff8472_compliance >= SFP_SFF8472_COMPLIANCE_REV11_4 && > sfp->id.ext.options & cpu_to_be16(SFP_OPTIONS_HIGH_POWER_LEVEL)) > power_mW = 2000; > >How does your module indicate it needs 3000 mW? Does this bit of code >need extending to read additional bits? Message says "host maximum power",not that sfp needs the 3w. > Andrew regards Frank
Il 08/06/25 23:14, Frank Wunderlich ha scritto: > From: Frank Wunderlich <frank-w@public-files.de> > > Add SFP cages to Bananapi-R4 board. The 2.5g phy variant only contains the > wan-SFP, so add this to common dtsi and the lan-sfp only to the dual-SFP > variant. > > Signed-off-by: Daniel Golle <daniel@makrotopia.org> > Signed-off-by: Frank Wunderlich <frank-w@public-files.de> > --- > v3: > - enable mac with 2.5g phy on r4 phy variant because driver is now mainline > --- > .../mediatek/mt7988a-bananapi-bpi-r4-2g5.dts | 12 ++++++++++++ > .../dts/mediatek/mt7988a-bananapi-bpi-r4.dts | 18 ++++++++++++++++++ > .../dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi | 18 ++++++++++++++++++ > 3 files changed, 48 insertions(+) > > diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-2g5.dts b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-2g5.dts > index 53de9c113f60..e63e17ae35a0 100644 > --- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-2g5.dts > +++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-2g5.dts > @@ -9,3 +9,15 @@ / { > model = "Banana Pi BPI-R4 (1x SFP+, 1x 2.5GbE)"; > chassis-type = "embedded"; > }; > + > +&gmac1 { phy = ... phy-c..onnection-type phy-m...ode > + phy-mode = "internal"; > + phy-connection-type = "internal"; > + phy = <&int_2p5g_phy>; > + status = "okay"; > +}; > + > +&int_2p5g_phy { > + pinctrl-names = "i2p5gbe-led"; > + pinctrl-0 = <&i2p5gbe_led0_pins>; pinctrl-names pinctrl-0 > +}; > diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dts b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dts > index 36bd1ef2efab..3136dc4ba4cc 100644 > --- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dts > +++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dts > @@ -8,6 +8,24 @@ / { > compatible = "bananapi,bpi-r4", "mediatek,mt7988a"; > model = "Banana Pi BPI-R4 (2x SFP+)"; > chassis-type = "embedded"; > + > + /* SFP2 cage (LAN) */ > + sfp2: sfp2 { > + compatible = "sff,sfp"; > + i2c-bus = <&i2c_sfp2>; maximum-power-milliwatt here (blank line) ...then gpios > + los-gpios = <&pio 2 GPIO_ACTIVE_HIGH>; > + mod-def0-gpios = <&pio 83 GPIO_ACTIVE_LOW>; (r)ate-select0-gpios before (t)x-disable.... > + tx-disable-gpios = <&pio 0 GPIO_ACTIVE_HIGH>; > + tx-fault-gpios = <&pio 1 GPIO_ACTIVE_HIGH>; > + rate-select0-gpios = <&pio 3 GPIO_ACTIVE_LOW>; > + maximum-power-milliwatt = <3000>; > + }; > +}; > + > +&gmac1 { managed phy-mode sfp > + sfp = <&sfp2>; > + managed = "in-band-status"; > + phy-mode = "usxgmii"; > }; > > &pca9545 { > diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi > index 20073eb4d1bd..d8b9cd794ee3 100644 > --- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi > +++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi > @@ -63,6 +63,18 @@ reg_3p3v: regulator-3p3v { > regulator-boot-on; > regulator-always-on; > }; > + > + /* SFP1 cage (WAN) */ > + sfp1: sfp1 { > + compatible = "sff,sfp"; > + i2c-bus = <&i2c_sfp1>; (same comments from sfp2) > + los-gpios = <&pio 54 GPIO_ACTIVE_HIGH>; > + mod-def0-gpios = <&pio 82 GPIO_ACTIVE_LOW>; > + tx-disable-gpios = <&pio 70 GPIO_ACTIVE_HIGH>; > + tx-fault-gpios = <&pio 69 GPIO_ACTIVE_HIGH>; > + rate-select0-gpios = <&pio 21 GPIO_ACTIVE_LOW>; > + maximum-power-milliwatt = <3000>; > + }; > }; > > &cci { > @@ -133,6 +145,12 @@ map-cpu-active-low { > }; > }; > > +&gmac2 { (same comments from gmac1) > + sfp = <&sfp1>; > + managed = "in-band-status"; > + phy-mode = "usxgmii"; > +}; > + > &i2c0 { > pinctrl-names = "default"; > pinctrl-0 = <&i2c0_pins>; Cheers, Angelo
Hi > Gesendet: Mittwoch, 11. Juni 2025 um 11:33 > Von: "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com> > Betreff: Re: [PATCH v3 12/13] arm64: dts: mediatek: mt7988a-bpi-r4: add sfp cages and link to gmac > > Il 08/06/25 23:14, Frank Wunderlich ha scritto: > > From: Frank Wunderlich <frank-w@public-files.de> > > > > Add SFP cages to Bananapi-R4 board. The 2.5g phy variant only contains the > > wan-SFP, so add this to common dtsi and the lan-sfp only to the dual-SFP > > variant. > > > > Signed-off-by: Daniel Golle <daniel@makrotopia.org> > > Signed-off-by: Frank Wunderlich <frank-w@public-files.de> > > --- > > v3: > > - enable mac with 2.5g phy on r4 phy variant because driver is now mainline > > --- > > .../mediatek/mt7988a-bananapi-bpi-r4-2g5.dts | 12 ++++++++++++ > > .../dts/mediatek/mt7988a-bananapi-bpi-r4.dts | 18 ++++++++++++++++++ > > .../dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi | 18 ++++++++++++++++++ > > 3 files changed, 48 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-2g5.dts b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-2g5.dts > > index 53de9c113f60..e63e17ae35a0 100644 > > --- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-2g5.dts > > +++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-2g5.dts > > @@ -9,3 +9,15 @@ / { > > model = "Banana Pi BPI-R4 (1x SFP+, 1x 2.5GbE)"; > > chassis-type = "embedded"; > > }; > > + > > +&gmac1 { > > phy = ... > phy-c..onnection-type > phy-m...ode phy-connection-type is dropped in next version due to comment from andrew, but i order alphabetically > > + phy-mode = "internal"; > > + phy-connection-type = "internal"; > > + phy = <&int_2p5g_phy>; > > + status = "okay"; > > +}; > > + > > +&int_2p5g_phy { > > + pinctrl-names = "i2p5gbe-led"; > > + pinctrl-0 = <&i2p5gbe_led0_pins>; > > pinctrl-names > pinctrl-0 what the difference? i don't see it :( the others i change in v4 regards Frank
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-2g5.dts b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-2g5.dts index 53de9c113f60..e63e17ae35a0 100644 --- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-2g5.dts +++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-2g5.dts @@ -9,3 +9,15 @@ / { model = "Banana Pi BPI-R4 (1x SFP+, 1x 2.5GbE)"; chassis-type = "embedded"; }; + +&gmac1 { + phy-mode = "internal"; + phy-connection-type = "internal"; + phy = <&int_2p5g_phy>; + status = "okay"; +}; + +&int_2p5g_phy { + pinctrl-names = "i2p5gbe-led"; + pinctrl-0 = <&i2p5gbe_led0_pins>; +}; diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dts b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dts index 36bd1ef2efab..3136dc4ba4cc 100644 --- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dts +++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dts @@ -8,6 +8,24 @@ / { compatible = "bananapi,bpi-r4", "mediatek,mt7988a"; model = "Banana Pi BPI-R4 (2x SFP+)"; chassis-type = "embedded"; + + /* SFP2 cage (LAN) */ + sfp2: sfp2 { + compatible = "sff,sfp"; + i2c-bus = <&i2c_sfp2>; + los-gpios = <&pio 2 GPIO_ACTIVE_HIGH>; + mod-def0-gpios = <&pio 83 GPIO_ACTIVE_LOW>; + tx-disable-gpios = <&pio 0 GPIO_ACTIVE_HIGH>; + tx-fault-gpios = <&pio 1 GPIO_ACTIVE_HIGH>; + rate-select0-gpios = <&pio 3 GPIO_ACTIVE_LOW>; + maximum-power-milliwatt = <3000>; + }; +}; + +&gmac1 { + sfp = <&sfp2>; + managed = "in-band-status"; + phy-mode = "usxgmii"; }; &pca9545 { diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi index 20073eb4d1bd..d8b9cd794ee3 100644 --- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi @@ -63,6 +63,18 @@ reg_3p3v: regulator-3p3v { regulator-boot-on; regulator-always-on; }; + + /* SFP1 cage (WAN) */ + sfp1: sfp1 { + compatible = "sff,sfp"; + i2c-bus = <&i2c_sfp1>; + los-gpios = <&pio 54 GPIO_ACTIVE_HIGH>; + mod-def0-gpios = <&pio 82 GPIO_ACTIVE_LOW>; + tx-disable-gpios = <&pio 70 GPIO_ACTIVE_HIGH>; + tx-fault-gpios = <&pio 69 GPIO_ACTIVE_HIGH>; + rate-select0-gpios = <&pio 21 GPIO_ACTIVE_LOW>; + maximum-power-milliwatt = <3000>; + }; }; &cci { @@ -133,6 +145,12 @@ map-cpu-active-low { }; }; +&gmac2 { + sfp = <&sfp1>; + managed = "in-band-status"; + phy-mode = "usxgmii"; +}; + &i2c0 { pinctrl-names = "default"; pinctrl-0 = <&i2c0_pins>;