net: phy: marvell: network working with generic PHY and not with marvell PHY

net: phy: marvell: network working with generic PHY and not with marvell PHY

[Corentin Labbe]

Hello

I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
By not working, I mean kernel started with ip=dhcp cannot get an IP.

Without CONFIG_MARVELL_PHY, the PHY is detected as generic:
Generic PHY gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
but with a 1Gbit link, network is now working.
I am able to get an IP via DHCP and iperf give:
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.04  sec   185 MBytes   154 Mbits/sec    2             sender
[  5]   0.00-10.09  sec   185 MBytes   154 Mbits/sec                  receiver
CPU Utilization: local/sender 77.8% (0.5%u/77.2%s), remote/receiver 13.3% (0.6%u/12.7%s)

ethtool confirms the gigabit link:
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Full 
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 1
	Transceiver: external
	Auto-negotiation: on
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: yes

With the marvell PHY, ethtool reports:
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Full 
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 1
	Transceiver: external
	Auto-negotiation: on
	MDI-X: Unknown
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: yes
Only change vs generic I saw is MDI-X and Port: values

Do you have any idea why the marvell PHY "break" the network ?

Regards

net: phy: marvell: network working with generic PHY and not with marvell PHY

[Corentin Labbe]

Hello

I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
By not working, I mean kernel started with ip=dhcp cannot get an IP.

Without CONFIG_MARVELL_PHY, the PHY is detected as generic:
Generic PHY gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
but with a 1Gbit link, network is now working.
I am able to get an IP via DHCP and iperf give:
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.04  sec   185 MBytes   154 Mbits/sec    2             sender
[  5]   0.00-10.09  sec   185 MBytes   154 Mbits/sec                  receiver
CPU Utilization: local/sender 77.8% (0.5%u/77.2%s), remote/receiver 13.3% (0.6%u/12.7%s)

ethtool confirms the gigabit link:
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Full 
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 1
	Transceiver: external
	Auto-negotiation: on
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: yes

With the marvell PHY, ethtool reports:
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Full 
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 1
	Transceiver: external
	Auto-negotiation: on
	MDI-X: Unknown
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: yes
Only change vs generic I saw is MDI-X and Port: values

Do you have any idea why the marvell PHY "break" the network ?

Regards

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Russell King (Oracle)]

On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> Hello
> 
> I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> By not working, I mean kernel started with ip=dhcp cannot get an IP.

How is the PHY connected to the host (which interface mode?) If it's
RGMII, it could be that the wrong RGMII interface mode is specified in
DT.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Russell King (Oracle)]

On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> Hello
> 
> I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> By not working, I mean kernel started with ip=dhcp cannot get an IP.

How is the PHY connected to the host (which interface mode?) If it's
RGMII, it could be that the wrong RGMII interface mode is specified in
DT.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Corentin Labbe]

Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > Hello
> > 
> > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> 
> How is the PHY connected to the host (which interface mode?) If it's
> RGMII, it could be that the wrong RGMII interface mode is specified in
> DT.
> 

The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
The only change to the mainline dtb is removing the max-speed.

Regards

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Corentin Labbe]

Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > Hello
> > 
> > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> 
> How is the PHY connected to the host (which interface mode?) If it's
> RGMII, it could be that the wrong RGMII interface mode is specified in
> DT.
> 

The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
The only change to the mainline dtb is removing the max-speed.

Regards

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Russell King (Oracle)]

On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > Hello
> > > 
> > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > 
> > How is the PHY connected to the host (which interface mode?) If it's
> > RGMII, it could be that the wrong RGMII interface mode is specified in
> > DT.
> > 
> 
> The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> The only change to the mainline dtb is removing the max-speed.

So, it's using "rgmii" with no delay configured at the PHY with the
speed limited to 100Mbps. You then remove the speed limitation and
it doesn't work at 1Gbps.

I think I've seen this on other platforms (imx6 + ar8035) when the
RGMII delay is not correctly configured - it will work at slower
speeds but not 1G.

The RGMII spec specifies that there will be a delay - and the delay can
be introduced by either the MAC, PHY or by PCB track routing. It sounds
to me like your boot environment configures the PHY to introduce the
necessary delay, but then, because the DT "rgmii" mode means "no delay
at the PHY" when you use the Marvell driver (which respects that), the
Marvell driver configures the PHY for no delay, resulting in a non-
working situation at 1G.

I would suggest checking how the boot environment configures the PHY,
and change the "rgmii" mode in DT to match. There is a description of
the four RGMII modes in Documentation/networking/phy.rst that may help
understand what each one means.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Russell King (Oracle)]

On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > Hello
> > > 
> > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > 
> > How is the PHY connected to the host (which interface mode?) If it's
> > RGMII, it could be that the wrong RGMII interface mode is specified in
> > DT.
> > 
> 
> The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> The only change to the mainline dtb is removing the max-speed.

So, it's using "rgmii" with no delay configured at the PHY with the
speed limited to 100Mbps. You then remove the speed limitation and
it doesn't work at 1Gbps.

I think I've seen this on other platforms (imx6 + ar8035) when the
RGMII delay is not correctly configured - it will work at slower
speeds but not 1G.

The RGMII spec specifies that there will be a delay - and the delay can
be introduced by either the MAC, PHY or by PCB track routing. It sounds
to me like your boot environment configures the PHY to introduce the
necessary delay, but then, because the DT "rgmii" mode means "no delay
at the PHY" when you use the Marvell driver (which respects that), the
Marvell driver configures the PHY for no delay, resulting in a non-
working situation at 1G.

I would suggest checking how the boot environment configures the PHY,
and change the "rgmii" mode in DT to match. There is a description of
the four RGMII modes in Documentation/networking/phy.rst that may help
understand what each one means.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Corentin Labbe]

Le Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) a écrit :
> On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> > Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > > Hello
> > > > 
> > > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > > 
> > > How is the PHY connected to the host (which interface mode?) If it's
> > > RGMII, it could be that the wrong RGMII interface mode is specified in
> > > DT.
> > > 
> > 
> > The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> > The only change to the mainline dtb is removing the max-speed.
> 
> So, it's using "rgmii" with no delay configured at the PHY with the
> speed limited to 100Mbps. You then remove the speed limitation and
> it doesn't work at 1Gbps.
> 
> I think I've seen this on other platforms (imx6 + ar8035) when the
> RGMII delay is not correctly configured - it will work at slower
> speeds but not 1G.
> 
> The RGMII spec specifies that there will be a delay - and the delay can
> be introduced by either the MAC, PHY or by PCB track routing. It sounds
> to me like your boot environment configures the PHY to introduce the
> necessary delay, but then, because the DT "rgmii" mode means "no delay
> at the PHY" when you use the Marvell driver (which respects that), the
> Marvell driver configures the PHY for no delay, resulting in a non-
> working situation at 1G.
> 
> I would suggest checking how the boot environment configures the PHY,
> and change the "rgmii" mode in DT to match. There is a description of
> the four RGMII modes in Documentation/networking/phy.rst that may help
> understand what each one means.
> 

So if I understand, the generic PHY does not touch delays and so values set by bootloader are kept.

The boot environment give no clue on how the PHY is set.
Only debug showed is:
PHY 0 Addr 1 Vendor ID: 0x01410e11
mii_write: phy_addr=0x1 reg_addr=0x4 value=0x5e1 
mii_write: phy_addr=0x1 reg_addr=0x9 value=0x300 
mii_write: phy_addr=0x1 reg_addr=0x0 value=0x1200 
mii_write: phy_addr=0x1 reg_addr=0x0 value=0x9200 
mii_write: phy_addr=0x1 reg_addr=0x0 value=0x1200

Does it is possible to dump PHY registers when using generic PHY and find delay values ?
For example ethtool -d eth0 ?

If not, my only choice is to bruteforce all delay values until it works.

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Corentin Labbe]

Le Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) a écrit :
> On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> > Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > > Hello
> > > > 
> > > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > > 
> > > How is the PHY connected to the host (which interface mode?) If it's
> > > RGMII, it could be that the wrong RGMII interface mode is specified in
> > > DT.
> > > 
> > 
> > The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> > The only change to the mainline dtb is removing the max-speed.
> 
> So, it's using "rgmii" with no delay configured at the PHY with the
> speed limited to 100Mbps. You then remove the speed limitation and
> it doesn't work at 1Gbps.
> 
> I think I've seen this on other platforms (imx6 + ar8035) when the
> RGMII delay is not correctly configured - it will work at slower
> speeds but not 1G.
> 
> The RGMII spec specifies that there will be a delay - and the delay can
> be introduced by either the MAC, PHY or by PCB track routing. It sounds
> to me like your boot environment configures the PHY to introduce the
> necessary delay, but then, because the DT "rgmii" mode means "no delay
> at the PHY" when you use the Marvell driver (which respects that), the
> Marvell driver configures the PHY for no delay, resulting in a non-
> working situation at 1G.
> 
> I would suggest checking how the boot environment configures the PHY,
> and change the "rgmii" mode in DT to match. There is a description of
> the four RGMII modes in Documentation/networking/phy.rst that may help
> understand what each one means.
> 

So if I understand, the generic PHY does not touch delays and so values set by bootloader are kept.

The boot environment give no clue on how the PHY is set.
Only debug showed is:
PHY 0 Addr 1 Vendor ID: 0x01410e11
mii_write: phy_addr=0x1 reg_addr=0x4 value=0x5e1 
mii_write: phy_addr=0x1 reg_addr=0x9 value=0x300 
mii_write: phy_addr=0x1 reg_addr=0x0 value=0x1200 
mii_write: phy_addr=0x1 reg_addr=0x0 value=0x9200 
mii_write: phy_addr=0x1 reg_addr=0x0 value=0x1200

Does it is possible to dump PHY registers when using generic PHY and find delay values ?
For example ethtool -d eth0 ?

If not, my only choice is to bruteforce all delay values until it works.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Russell King (Oracle)]

On Tue, Jan 04, 2022 at 01:09:13PM +0100, Corentin Labbe wrote:
> Le Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) a écrit :
> > On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> > > Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > > > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > > > Hello
> > > > > 
> > > > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > > > 
> > > > How is the PHY connected to the host (which interface mode?) If it's
> > > > RGMII, it could be that the wrong RGMII interface mode is specified in
> > > > DT.
> > > > 
> > > 
> > > The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> > > The only change to the mainline dtb is removing the max-speed.
> > 
> > So, it's using "rgmii" with no delay configured at the PHY with the
> > speed limited to 100Mbps. You then remove the speed limitation and
> > it doesn't work at 1Gbps.
> > 
> > I think I've seen this on other platforms (imx6 + ar8035) when the
> > RGMII delay is not correctly configured - it will work at slower
> > speeds but not 1G.
> > 
> > The RGMII spec specifies that there will be a delay - and the delay can
> > be introduced by either the MAC, PHY or by PCB track routing. It sounds
> > to me like your boot environment configures the PHY to introduce the
> > necessary delay, but then, because the DT "rgmii" mode means "no delay
> > at the PHY" when you use the Marvell driver (which respects that), the
> > Marvell driver configures the PHY for no delay, resulting in a non-
> > working situation at 1G.
> > 
> > I would suggest checking how the boot environment configures the PHY,
> > and change the "rgmii" mode in DT to match. There is a description of
> > the four RGMII modes in Documentation/networking/phy.rst that may help
> > understand what each one means.
> > 
> 
> So if I understand, the generic PHY does not touch delays and so values set by bootloader are kept.

Correct - the RGMII delays are not part of the standard 802.3 clause 22
register set, so the generic driver has no knowledge how to change
these.

> The boot environment give no clue on how the PHY is set.
> Only debug showed is:
> PHY 0 Addr 1 Vendor ID: 0x01410e11
> mii_write: phy_addr=0x1 reg_addr=0x4 value=0x5e1 
> mii_write: phy_addr=0x1 reg_addr=0x9 value=0x300 
> mii_write: phy_addr=0x1 reg_addr=0x0 value=0x1200 
> mii_write: phy_addr=0x1 reg_addr=0x0 value=0x9200 
> mii_write: phy_addr=0x1 reg_addr=0x0 value=0x1200

Hmm, it doesn't. The first two register writes set the advertisement.
The last three are just the PHY reset.

> Does it is possible to dump PHY registers when using generic PHY and
> find delay values ? For example ethtool -d eth0 ?

Even if that were possible, Marvell PHYs use a paged scheme to access
configuration registers, so merely reading the 32 registers would
probably not help. However, see my follow-up to my previous reply for
some further thoughts.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Russell King (Oracle)]

On Tue, Jan 04, 2022 at 01:09:13PM +0100, Corentin Labbe wrote:
> Le Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) a écrit :
> > On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> > > Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > > > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > > > Hello
> > > > > 
> > > > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > > > 
> > > > How is the PHY connected to the host (which interface mode?) If it's
> > > > RGMII, it could be that the wrong RGMII interface mode is specified in
> > > > DT.
> > > > 
> > > 
> > > The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> > > The only change to the mainline dtb is removing the max-speed.
> > 
> > So, it's using "rgmii" with no delay configured at the PHY with the
> > speed limited to 100Mbps. You then remove the speed limitation and
> > it doesn't work at 1Gbps.
> > 
> > I think I've seen this on other platforms (imx6 + ar8035) when the
> > RGMII delay is not correctly configured - it will work at slower
> > speeds but not 1G.
> > 
> > The RGMII spec specifies that there will be a delay - and the delay can
> > be introduced by either the MAC, PHY or by PCB track routing. It sounds
> > to me like your boot environment configures the PHY to introduce the
> > necessary delay, but then, because the DT "rgmii" mode means "no delay
> > at the PHY" when you use the Marvell driver (which respects that), the
> > Marvell driver configures the PHY for no delay, resulting in a non-
> > working situation at 1G.
> > 
> > I would suggest checking how the boot environment configures the PHY,
> > and change the "rgmii" mode in DT to match. There is a description of
> > the four RGMII modes in Documentation/networking/phy.rst that may help
> > understand what each one means.
> > 
> 
> So if I understand, the generic PHY does not touch delays and so values set by bootloader are kept.

Correct - the RGMII delays are not part of the standard 802.3 clause 22
register set, so the generic driver has no knowledge how to change
these.

> The boot environment give no clue on how the PHY is set.
> Only debug showed is:
> PHY 0 Addr 1 Vendor ID: 0x01410e11
> mii_write: phy_addr=0x1 reg_addr=0x4 value=0x5e1 
> mii_write: phy_addr=0x1 reg_addr=0x9 value=0x300 
> mii_write: phy_addr=0x1 reg_addr=0x0 value=0x1200 
> mii_write: phy_addr=0x1 reg_addr=0x0 value=0x9200 
> mii_write: phy_addr=0x1 reg_addr=0x0 value=0x1200

Hmm, it doesn't. The first two register writes set the advertisement.
The last three are just the PHY reset.

> Does it is possible to dump PHY registers when using generic PHY and
> find delay values ? For example ethtool -d eth0 ?

Even if that were possible, Marvell PHYs use a paged scheme to access
configuration registers, so merely reading the 32 registers would
probably not help. However, see my follow-up to my previous reply for
some further thoughts.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Russell King (Oracle)]

On Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) wrote:
> On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> > Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > > Hello
> > > > 
> > > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > > 
> > > How is the PHY connected to the host (which interface mode?) If it's
> > > RGMII, it could be that the wrong RGMII interface mode is specified in
> > > DT.
> > > 
> > 
> > The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> > The only change to the mainline dtb is removing the max-speed.
> 
> So, it's using "rgmii" with no delay configured at the PHY with the
> speed limited to 100Mbps. You then remove the speed limitation and
> it doesn't work at 1Gbps.
> 
> I think I've seen this on other platforms (imx6 + ar8035) when the
> RGMII delay is not correctly configured - it will work at slower
> speeds but not 1G.
> 
> The RGMII spec specifies that there will be a delay - and the delay can
> be introduced by either the MAC, PHY or by PCB track routing. It sounds
> to me like your boot environment configures the PHY to introduce the
> necessary delay, but then, because the DT "rgmii" mode means "no delay
> at the PHY" when you use the Marvell driver (which respects that), the
> Marvell driver configures the PHY for no delay, resulting in a non-
> working situation at 1G.
> 
> I would suggest checking how the boot environment configures the PHY,
> and change the "rgmii" mode in DT to match. There is a description of
> the four RGMII modes in Documentation/networking/phy.rst that may help
> understand what each one means.

Hmm. Sorry, I'm leading you stray. It looks like the 88E1118 code does
not program any delays depending on the interface mode, so changing that
will have no effect.

I suspect, looking at m88e1118_config_init(), that the write to register
0x15 in the MSCR page could be the problem.

0x15 is 21, which is MII_88E1121_PHY_MSCR_REG. In other Marvell PHYs,
bits 4 and 5 are the tx and rx delays, both of which are set. Looking
at m88e1121_config_aneg_rgmii_delays(), this would seem to indicate
that the PHY is being placed into rgmii-id mode.

Can you try changing:

	err = phy_write(phydev, 0x15, 0x1070);

to:

	err = phy_write(phydev, 0x15, 0x1040);

and see what happens? Maybe trying other combinations of bits 4 and 5
to find a working combination.

I think if we discover a setting there that works, we may have a problem,
since changing this could end up breaking some platforms. Looking at the
commit history...

2f495c398edc net/phy/marvell: Expose IDs and flags in a .h and add dns323 LEDs setup flag
605f196efbf8 phy: Add support for Marvell 88E1118 PHY

and the second is a less than helpful commit message...

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Russell King (Oracle)]

On Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) wrote:
> On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> > Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > > Hello
> > > > 
> > > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > > 
> > > How is the PHY connected to the host (which interface mode?) If it's
> > > RGMII, it could be that the wrong RGMII interface mode is specified in
> > > DT.
> > > 
> > 
> > The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> > The only change to the mainline dtb is removing the max-speed.
> 
> So, it's using "rgmii" with no delay configured at the PHY with the
> speed limited to 100Mbps. You then remove the speed limitation and
> it doesn't work at 1Gbps.
> 
> I think I've seen this on other platforms (imx6 + ar8035) when the
> RGMII delay is not correctly configured - it will work at slower
> speeds but not 1G.
> 
> The RGMII spec specifies that there will be a delay - and the delay can
> be introduced by either the MAC, PHY or by PCB track routing. It sounds
> to me like your boot environment configures the PHY to introduce the
> necessary delay, but then, because the DT "rgmii" mode means "no delay
> at the PHY" when you use the Marvell driver (which respects that), the
> Marvell driver configures the PHY for no delay, resulting in a non-
> working situation at 1G.
> 
> I would suggest checking how the boot environment configures the PHY,
> and change the "rgmii" mode in DT to match. There is a description of
> the four RGMII modes in Documentation/networking/phy.rst that may help
> understand what each one means.

Hmm. Sorry, I'm leading you stray. It looks like the 88E1118 code does
not program any delays depending on the interface mode, so changing that
will have no effect.

I suspect, looking at m88e1118_config_init(), that the write to register
0x15 in the MSCR page could be the problem.

0x15 is 21, which is MII_88E1121_PHY_MSCR_REG. In other Marvell PHYs,
bits 4 and 5 are the tx and rx delays, both of which are set. Looking
at m88e1121_config_aneg_rgmii_delays(), this would seem to indicate
that the PHY is being placed into rgmii-id mode.

Can you try changing:

	err = phy_write(phydev, 0x15, 0x1070);

to:

	err = phy_write(phydev, 0x15, 0x1040);

and see what happens? Maybe trying other combinations of bits 4 and 5
to find a working combination.

I think if we discover a setting there that works, we may have a problem,
since changing this could end up breaking some platforms. Looking at the
commit history...

2f495c398edc net/phy/marvell: Expose IDs and flags in a .h and add dns323 LEDs setup flag
605f196efbf8 phy: Add support for Marvell 88E1118 PHY

and the second is a less than helpful commit message...

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Corentin Labbe]

Le Tue, Jan 04, 2022 at 12:11:55PM +0000, Russell King (Oracle) a écrit :
> On Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) wrote:
> > On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> > > Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > > > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > > > Hello
> > > > > 
> > > > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > > > 
> > > > How is the PHY connected to the host (which interface mode?) If it's
> > > > RGMII, it could be that the wrong RGMII interface mode is specified in
> > > > DT.
> > > > 
> > > 
> > > The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> > > The only change to the mainline dtb is removing the max-speed.
> > 
> > So, it's using "rgmii" with no delay configured at the PHY with the
> > speed limited to 100Mbps. You then remove the speed limitation and
> > it doesn't work at 1Gbps.
> > 
> > I think I've seen this on other platforms (imx6 + ar8035) when the
> > RGMII delay is not correctly configured - it will work at slower
> > speeds but not 1G.
> > 
> > The RGMII spec specifies that there will be a delay - and the delay can
> > be introduced by either the MAC, PHY or by PCB track routing. It sounds
> > to me like your boot environment configures the PHY to introduce the
> > necessary delay, but then, because the DT "rgmii" mode means "no delay
> > at the PHY" when you use the Marvell driver (which respects that), the
> > Marvell driver configures the PHY for no delay, resulting in a non-
> > working situation at 1G.
> > 
> > I would suggest checking how the boot environment configures the PHY,
> > and change the "rgmii" mode in DT to match. There is a description of
> > the four RGMII modes in Documentation/networking/phy.rst that may help
> > understand what each one means.
> 
> Hmm. Sorry, I'm leading you stray. It looks like the 88E1118 code does
> not program any delays depending on the interface mode, so changing that
> will have no effect.
> 
> I suspect, looking at m88e1118_config_init(), that the write to register
> 0x15 in the MSCR page could be the problem.
> 
> 0x15 is 21, which is MII_88E1121_PHY_MSCR_REG. In other Marvell PHYs,
> bits 4 and 5 are the tx and rx delays, both of which are set. Looking
> at m88e1121_config_aneg_rgmii_delays(), this would seem to indicate
> that the PHY is being placed into rgmii-id mode.
> 
> Can you try changing:
> 
> 	err = phy_write(phydev, 0x15, 0x1070);
> 
> to:
> 
> 	err = phy_write(phydev, 0x15, 0x1040);
> 
> and see what happens? Maybe trying other combinations of bits 4 and 5
> to find a working combination.
> 

I tried more than all combinaisons (0x1010, 0x1020, 0x1030, 0x1040, 0x1050, 0x1060) without success.
A phy_read() just before the phy_write() give 0x1040.
I have also removed the phy_write() without success.

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Corentin Labbe]

Le Tue, Jan 04, 2022 at 12:11:55PM +0000, Russell King (Oracle) a écrit :
> On Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) wrote:
> > On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> > > Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > > > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > > > Hello
> > > > > 
> > > > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > > > 
> > > > How is the PHY connected to the host (which interface mode?) If it's
> > > > RGMII, it could be that the wrong RGMII interface mode is specified in
> > > > DT.
> > > > 
> > > 
> > > The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> > > The only change to the mainline dtb is removing the max-speed.
> > 
> > So, it's using "rgmii" with no delay configured at the PHY with the
> > speed limited to 100Mbps. You then remove the speed limitation and
> > it doesn't work at 1Gbps.
> > 
> > I think I've seen this on other platforms (imx6 + ar8035) when the
> > RGMII delay is not correctly configured - it will work at slower
> > speeds but not 1G.
> > 
> > The RGMII spec specifies that there will be a delay - and the delay can
> > be introduced by either the MAC, PHY or by PCB track routing. It sounds
> > to me like your boot environment configures the PHY to introduce the
> > necessary delay, but then, because the DT "rgmii" mode means "no delay
> > at the PHY" when you use the Marvell driver (which respects that), the
> > Marvell driver configures the PHY for no delay, resulting in a non-
> > working situation at 1G.
> > 
> > I would suggest checking how the boot environment configures the PHY,
> > and change the "rgmii" mode in DT to match. There is a description of
> > the four RGMII modes in Documentation/networking/phy.rst that may help
> > understand what each one means.
> 
> Hmm. Sorry, I'm leading you stray. It looks like the 88E1118 code does
> not program any delays depending on the interface mode, so changing that
> will have no effect.
> 
> I suspect, looking at m88e1118_config_init(), that the write to register
> 0x15 in the MSCR page could be the problem.
> 
> 0x15 is 21, which is MII_88E1121_PHY_MSCR_REG. In other Marvell PHYs,
> bits 4 and 5 are the tx and rx delays, both of which are set. Looking
> at m88e1121_config_aneg_rgmii_delays(), this would seem to indicate
> that the PHY is being placed into rgmii-id mode.
> 
> Can you try changing:
> 
> 	err = phy_write(phydev, 0x15, 0x1070);
> 
> to:
> 
> 	err = phy_write(phydev, 0x15, 0x1040);
> 
> and see what happens? Maybe trying other combinations of bits 4 and 5
> to find a working combination.
> 

I tried more than all combinaisons (0x1010, 0x1020, 0x1030, 0x1040, 0x1050, 0x1060) without success.
A phy_read() just before the phy_write() give 0x1040.
I have also removed the phy_write() without success.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Corentin Labbe]

Le Tue, Jan 04, 2022 at 12:11:55PM +0000, Russell King (Oracle) a écrit :
> On Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) wrote:
> > On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> > > Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > > > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > > > Hello
> > > > > 
> > > > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > > > 
> > > > How is the PHY connected to the host (which interface mode?) If it's
> > > > RGMII, it could be that the wrong RGMII interface mode is specified in
> > > > DT.
> > > > 
> > > 
> > > The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> > > The only change to the mainline dtb is removing the max-speed.
> > 
> > So, it's using "rgmii" with no delay configured at the PHY with the
> > speed limited to 100Mbps. You then remove the speed limitation and
> > it doesn't work at 1Gbps.
> > 
> > I think I've seen this on other platforms (imx6 + ar8035) when the
> > RGMII delay is not correctly configured - it will work at slower
> > speeds but not 1G.
> > 
> > The RGMII spec specifies that there will be a delay - and the delay can
> > be introduced by either the MAC, PHY or by PCB track routing. It sounds
> > to me like your boot environment configures the PHY to introduce the
> > necessary delay, but then, because the DT "rgmii" mode means "no delay
> > at the PHY" when you use the Marvell driver (which respects that), the
> > Marvell driver configures the PHY for no delay, resulting in a non-
> > working situation at 1G.
> > 
> > I would suggest checking how the boot environment configures the PHY,
> > and change the "rgmii" mode in DT to match. There is a description of
> > the four RGMII modes in Documentation/networking/phy.rst that may help
> > understand what each one means.
> 
> Hmm. Sorry, I'm leading you stray. It looks like the 88E1118 code does
> not program any delays depending on the interface mode, so changing that
> will have no effect.
> 
> I suspect, looking at m88e1118_config_init(), that the write to register
> 0x15 in the MSCR page could be the problem.
> 
> 0x15 is 21, which is MII_88E1121_PHY_MSCR_REG. In other Marvell PHYs,
> bits 4 and 5 are the tx and rx delays, both of which are set. Looking
> at m88e1121_config_aneg_rgmii_delays(), this would seem to indicate
> that the PHY is being placed into rgmii-id mode.
> 
> Can you try changing:
> 
> 	err = phy_write(phydev, 0x15, 0x1070);
> 
> to:
> 
> 	err = phy_write(phydev, 0x15, 0x1040);
> 
> and see what happens? Maybe trying other combinations of bits 4 and 5
> to find a working combination.
> 

Forget my other message, using 0x1040 lead to success.
My problem was that I tried rgmii-id which net/ethernet/cortina does not support on some code path. (everything test PHY_INTERFACE_MODE_RGMII only)
So I retry tests with original phy-mode = "rgmii".

So with the following changes everything is ok:
diff --git a/arch/arm/boot/dts/gemini-ssi1328.dts b/arch/arm/boot/dts/gemini-ssi1328.dts
index 113feb1c4922..7543d117a13a 100644
--- a/arch/arm/boot/dts/gemini-ssi1328.dts
+++ b/arch/arm/boot/dts/gemini-ssi1328.dts
@@ -40,10 +40,6 @@ mdio0: mdio {
                phy0: ethernet-phy@1 {
                        reg = <1>;
                        device_type = "ethernet-phy";
-                       /* We lack the knowledge of necessary GPIO to achieve
-                        * Gigabit
-                        */
-                       max-speed = <100>;
                };
                /* WAN ICPlus IP101A */
                phy1: ethernet-phy@2 {
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 4fcfca4e1702..af7fc9d8eaa7 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1233,7 +1233,7 @@ static int m88e1118_config_init(struct phy_device *phydev)
                return err;
 
        /* Enable 1000 Mbit */
-       err = phy_write(phydev, 0x15, 0x1070);
+       err = phy_write(phydev, 0x15, 0x1040);
        if (err < 0)
                return err;
 

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Corentin Labbe]

Le Tue, Jan 04, 2022 at 12:11:55PM +0000, Russell King (Oracle) a écrit :
> On Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) wrote:
> > On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> > > Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > > > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > > > Hello
> > > > > 
> > > > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > > > 
> > > > How is the PHY connected to the host (which interface mode?) If it's
> > > > RGMII, it could be that the wrong RGMII interface mode is specified in
> > > > DT.
> > > > 
> > > 
> > > The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> > > The only change to the mainline dtb is removing the max-speed.
> > 
> > So, it's using "rgmii" with no delay configured at the PHY with the
> > speed limited to 100Mbps. You then remove the speed limitation and
> > it doesn't work at 1Gbps.
> > 
> > I think I've seen this on other platforms (imx6 + ar8035) when the
> > RGMII delay is not correctly configured - it will work at slower
> > speeds but not 1G.
> > 
> > The RGMII spec specifies that there will be a delay - and the delay can
> > be introduced by either the MAC, PHY or by PCB track routing. It sounds
> > to me like your boot environment configures the PHY to introduce the
> > necessary delay, but then, because the DT "rgmii" mode means "no delay
> > at the PHY" when you use the Marvell driver (which respects that), the
> > Marvell driver configures the PHY for no delay, resulting in a non-
> > working situation at 1G.
> > 
> > I would suggest checking how the boot environment configures the PHY,
> > and change the "rgmii" mode in DT to match. There is a description of
> > the four RGMII modes in Documentation/networking/phy.rst that may help
> > understand what each one means.
> 
> Hmm. Sorry, I'm leading you stray. It looks like the 88E1118 code does
> not program any delays depending on the interface mode, so changing that
> will have no effect.
> 
> I suspect, looking at m88e1118_config_init(), that the write to register
> 0x15 in the MSCR page could be the problem.
> 
> 0x15 is 21, which is MII_88E1121_PHY_MSCR_REG. In other Marvell PHYs,
> bits 4 and 5 are the tx and rx delays, both of which are set. Looking
> at m88e1121_config_aneg_rgmii_delays(), this would seem to indicate
> that the PHY is being placed into rgmii-id mode.
> 
> Can you try changing:
> 
> 	err = phy_write(phydev, 0x15, 0x1070);
> 
> to:
> 
> 	err = phy_write(phydev, 0x15, 0x1040);
> 
> and see what happens? Maybe trying other combinations of bits 4 and 5
> to find a working combination.
> 

Forget my other message, using 0x1040 lead to success.
My problem was that I tried rgmii-id which net/ethernet/cortina does not support on some code path. (everything test PHY_INTERFACE_MODE_RGMII only)
So I retry tests with original phy-mode = "rgmii".

So with the following changes everything is ok:
diff --git a/arch/arm/boot/dts/gemini-ssi1328.dts b/arch/arm/boot/dts/gemini-ssi1328.dts
index 113feb1c4922..7543d117a13a 100644
--- a/arch/arm/boot/dts/gemini-ssi1328.dts
+++ b/arch/arm/boot/dts/gemini-ssi1328.dts
@@ -40,10 +40,6 @@ mdio0: mdio {
                phy0: ethernet-phy@1 {
                        reg = <1>;
                        device_type = "ethernet-phy";
-                       /* We lack the knowledge of necessary GPIO to achieve
-                        * Gigabit
-                        */
-                       max-speed = <100>;
                };
                /* WAN ICPlus IP101A */
                phy1: ethernet-phy@2 {
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 4fcfca4e1702..af7fc9d8eaa7 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1233,7 +1233,7 @@ static int m88e1118_config_init(struct phy_device *phydev)
                return err;
 
        /* Enable 1000 Mbit */
-       err = phy_write(phydev, 0x15, 0x1070);
+       err = phy_write(phydev, 0x15, 0x1040);
        if (err < 0)
                return err;
 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Russell King (Oracle)]

On Tue, Jan 04, 2022 at 03:11:46PM +0100, Corentin Labbe wrote:
> Le Tue, Jan 04, 2022 at 12:11:55PM +0000, Russell King (Oracle) a écrit :
> > On Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) wrote:
> > > On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> > > > Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > > > > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > > > > Hello
> > > > > > 
> > > > > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > > > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > > > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > > > > 
> > > > > How is the PHY connected to the host (which interface mode?) If it's
> > > > > RGMII, it could be that the wrong RGMII interface mode is specified in
> > > > > DT.
> > > > > 
> > > > 
> > > > The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> > > > The only change to the mainline dtb is removing the max-speed.
> > > 
> > > So, it's using "rgmii" with no delay configured at the PHY with the
> > > speed limited to 100Mbps. You then remove the speed limitation and
> > > it doesn't work at 1Gbps.
> > > 
> > > I think I've seen this on other platforms (imx6 + ar8035) when the
> > > RGMII delay is not correctly configured - it will work at slower
> > > speeds but not 1G.
> > > 
> > > The RGMII spec specifies that there will be a delay - and the delay can
> > > be introduced by either the MAC, PHY or by PCB track routing. It sounds
> > > to me like your boot environment configures the PHY to introduce the
> > > necessary delay, but then, because the DT "rgmii" mode means "no delay
> > > at the PHY" when you use the Marvell driver (which respects that), the
> > > Marvell driver configures the PHY for no delay, resulting in a non-
> > > working situation at 1G.
> > > 
> > > I would suggest checking how the boot environment configures the PHY,
> > > and change the "rgmii" mode in DT to match. There is a description of
> > > the four RGMII modes in Documentation/networking/phy.rst that may help
> > > understand what each one means.
> > 
> > Hmm. Sorry, I'm leading you stray. It looks like the 88E1118 code does
> > not program any delays depending on the interface mode, so changing that
> > will have no effect.
> > 
> > I suspect, looking at m88e1118_config_init(), that the write to register
> > 0x15 in the MSCR page could be the problem.
> > 
> > 0x15 is 21, which is MII_88E1121_PHY_MSCR_REG. In other Marvell PHYs,
> > bits 4 and 5 are the tx and rx delays, both of which are set. Looking
> > at m88e1121_config_aneg_rgmii_delays(), this would seem to indicate
> > that the PHY is being placed into rgmii-id mode.
> > 
> > Can you try changing:
> > 
> > 	err = phy_write(phydev, 0x15, 0x1070);
> > 
> > to:
> > 
> > 	err = phy_write(phydev, 0x15, 0x1040);
> > 
> > and see what happens? Maybe trying other combinations of bits 4 and 5
> > to find a working combination.
> > 
> 
> Forget my other message, using 0x1040 lead to success.
> My problem was that I tried rgmii-id which net/ethernet/cortina does not support on some code path. (everything test PHY_INTERFACE_MODE_RGMII only)
> So I retry tests with original phy-mode = "rgmii".
> 
> So with the following changes everything is ok:
> diff --git a/arch/arm/boot/dts/gemini-ssi1328.dts b/arch/arm/boot/dts/gemini-ssi1328.dts
> index 113feb1c4922..7543d117a13a 100644
> --- a/arch/arm/boot/dts/gemini-ssi1328.dts
> +++ b/arch/arm/boot/dts/gemini-ssi1328.dts
> @@ -40,10 +40,6 @@ mdio0: mdio {
>                 phy0: ethernet-phy@1 {
>                         reg = <1>;
>                         device_type = "ethernet-phy";
> -                       /* We lack the knowledge of necessary GPIO to achieve
> -                        * Gigabit
> -                        */
> -                       max-speed = <100>;
>                 };
>                 /* WAN ICPlus IP101A */
>                 phy1: ethernet-phy@2 {
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index 4fcfca4e1702..af7fc9d8eaa7 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -1233,7 +1233,7 @@ static int m88e1118_config_init(struct phy_device *phydev)
>                 return err;
>  
>         /* Enable 1000 Mbit */
> -       err = phy_write(phydev, 0x15, 0x1070);
> +       err = phy_write(phydev, 0x15, 0x1040);
>         if (err < 0)
>                 return err;
>  

Okay, so we have two things that need fixing:

1) We need m88e1118_config_init() to take note of the interface mode
if it's RGMII, and program MSCR appropriately.

2) We need drivers/net/ethernet/cortina/gemini.c to accept any RGMII
interface mode.

Here's an untested patch for both - I've also converted the MSCR write
to be more modern. Please let me know if this resolves your issue.
We then need to consider whether it breaks any existing platform.

diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
index 07add311f65d..c78b99a497df 100644
--- a/drivers/net/ethernet/cortina/gemini.c
+++ b/drivers/net/ethernet/cortina/gemini.c
@@ -305,21 +305,21 @@ static void gmac_speed_set(struct net_device *netdev)
 	switch (phydev->speed) {
 	case 1000:
 		status.bits.speed = GMAC_SPEED_1000;
-		if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
+		if (phy_interface_mode_is_rgmii(phydev->interface))
 			status.bits.mii_rmii = GMAC_PHY_RGMII_1000;
 		netdev_dbg(netdev, "connect %s to RGMII @ 1Gbit\n",
 			   phydev_name(phydev));
 		break;
 	case 100:
 		status.bits.speed = GMAC_SPEED_100;
-		if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
+		if (phy_interface_mode_is_rgmii(phydev->interface))
 			status.bits.mii_rmii = GMAC_PHY_RGMII_100_10;
 		netdev_dbg(netdev, "connect %s to RGMII @ 100 Mbit\n",
 			   phydev_name(phydev));
 		break;
 	case 10:
 		status.bits.speed = GMAC_SPEED_10;
-		if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
+		if (phy_interface_mode_is_rgmii(phydev->interface))
 			status.bits.mii_rmii = GMAC_PHY_RGMII_100_10;
 		netdev_dbg(netdev, "connect %s to RGMII @ 10 Mbit\n",
 			   phydev_name(phydev));
@@ -389,6 +389,9 @@ static int gmac_setup_phy(struct net_device *netdev)
 		status.bits.mii_rmii = GMAC_PHY_GMII;
 		break;
 	case PHY_INTERFACE_MODE_RGMII:
+	case PHY_INTERFACE_MODE_RGMII_ID:
+	case PHY_INTERFACE_MODE_RGMII_TXID:
+	case PHY_INTERFACE_MODE_RGMII_RXID:
 		netdev_dbg(netdev,
 			   "RGMII: set GMAC0 and GMAC1 to MII/RGMII mode\n");
 		status.bits.mii_rmii = GMAC_PHY_RGMII_100_10;
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 4fcfca4e1702..ccf142ce55d8 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1227,16 +1227,18 @@ static int m88e1118_config_init(struct phy_device *phydev)
 {
 	int err;
 
-	/* Change address */
-	err = marvell_set_page(phydev, MII_MARVELL_MSCR_PAGE);
-	if (err < 0)
-		return err;
-
 	/* Enable 1000 Mbit */
-	err = phy_write(phydev, 0x15, 0x1070);
+	err = phy_write_paged(phydev, MII_MARVELL_MSCR_PAGE,
+			      MII_88E1121_PHY_MSCR_REG, 0x1070);
 	if (err < 0)
 		return err;
 
+	if (phy_interface_is_rgmii(phydev)) {
+		err = m88e1121_config_aneg_rgmii_delays(phydev);
+		if (err < 0)
+			return err;
+	}
+
 	/* Change address */
 	err = marvell_set_page(phydev, MII_MARVELL_LED_PAGE);
 	if (err < 0)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Russell King (Oracle)]

On Tue, Jan 04, 2022 at 03:11:46PM +0100, Corentin Labbe wrote:
> Le Tue, Jan 04, 2022 at 12:11:55PM +0000, Russell King (Oracle) a écrit :
> > On Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) wrote:
> > > On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> > > > Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > > > > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > > > > Hello
> > > > > > 
> > > > > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > > > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > > > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > > > > 
> > > > > How is the PHY connected to the host (which interface mode?) If it's
> > > > > RGMII, it could be that the wrong RGMII interface mode is specified in
> > > > > DT.
> > > > > 
> > > > 
> > > > The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> > > > The only change to the mainline dtb is removing the max-speed.
> > > 
> > > So, it's using "rgmii" with no delay configured at the PHY with the
> > > speed limited to 100Mbps. You then remove the speed limitation and
> > > it doesn't work at 1Gbps.
> > > 
> > > I think I've seen this on other platforms (imx6 + ar8035) when the
> > > RGMII delay is not correctly configured - it will work at slower
> > > speeds but not 1G.
> > > 
> > > The RGMII spec specifies that there will be a delay - and the delay can
> > > be introduced by either the MAC, PHY or by PCB track routing. It sounds
> > > to me like your boot environment configures the PHY to introduce the
> > > necessary delay, but then, because the DT "rgmii" mode means "no delay
> > > at the PHY" when you use the Marvell driver (which respects that), the
> > > Marvell driver configures the PHY for no delay, resulting in a non-
> > > working situation at 1G.
> > > 
> > > I would suggest checking how the boot environment configures the PHY,
> > > and change the "rgmii" mode in DT to match. There is a description of
> > > the four RGMII modes in Documentation/networking/phy.rst that may help
> > > understand what each one means.
> > 
> > Hmm. Sorry, I'm leading you stray. It looks like the 88E1118 code does
> > not program any delays depending on the interface mode, so changing that
> > will have no effect.
> > 
> > I suspect, looking at m88e1118_config_init(), that the write to register
> > 0x15 in the MSCR page could be the problem.
> > 
> > 0x15 is 21, which is MII_88E1121_PHY_MSCR_REG. In other Marvell PHYs,
> > bits 4 and 5 are the tx and rx delays, both of which are set. Looking
> > at m88e1121_config_aneg_rgmii_delays(), this would seem to indicate
> > that the PHY is being placed into rgmii-id mode.
> > 
> > Can you try changing:
> > 
> > 	err = phy_write(phydev, 0x15, 0x1070);
> > 
> > to:
> > 
> > 	err = phy_write(phydev, 0x15, 0x1040);
> > 
> > and see what happens? Maybe trying other combinations of bits 4 and 5
> > to find a working combination.
> > 
> 
> Forget my other message, using 0x1040 lead to success.
> My problem was that I tried rgmii-id which net/ethernet/cortina does not support on some code path. (everything test PHY_INTERFACE_MODE_RGMII only)
> So I retry tests with original phy-mode = "rgmii".
> 
> So with the following changes everything is ok:
> diff --git a/arch/arm/boot/dts/gemini-ssi1328.dts b/arch/arm/boot/dts/gemini-ssi1328.dts
> index 113feb1c4922..7543d117a13a 100644
> --- a/arch/arm/boot/dts/gemini-ssi1328.dts
> +++ b/arch/arm/boot/dts/gemini-ssi1328.dts
> @@ -40,10 +40,6 @@ mdio0: mdio {
>                 phy0: ethernet-phy@1 {
>                         reg = <1>;
>                         device_type = "ethernet-phy";
> -                       /* We lack the knowledge of necessary GPIO to achieve
> -                        * Gigabit
> -                        */
> -                       max-speed = <100>;
>                 };
>                 /* WAN ICPlus IP101A */
>                 phy1: ethernet-phy@2 {
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index 4fcfca4e1702..af7fc9d8eaa7 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -1233,7 +1233,7 @@ static int m88e1118_config_init(struct phy_device *phydev)
>                 return err;
>  
>         /* Enable 1000 Mbit */
> -       err = phy_write(phydev, 0x15, 0x1070);
> +       err = phy_write(phydev, 0x15, 0x1040);
>         if (err < 0)
>                 return err;
>  

Okay, so we have two things that need fixing:

1) We need m88e1118_config_init() to take note of the interface mode
if it's RGMII, and program MSCR appropriately.

2) We need drivers/net/ethernet/cortina/gemini.c to accept any RGMII
interface mode.

Here's an untested patch for both - I've also converted the MSCR write
to be more modern. Please let me know if this resolves your issue.
We then need to consider whether it breaks any existing platform.

diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
index 07add311f65d..c78b99a497df 100644
--- a/drivers/net/ethernet/cortina/gemini.c
+++ b/drivers/net/ethernet/cortina/gemini.c
@@ -305,21 +305,21 @@ static void gmac_speed_set(struct net_device *netdev)
 	switch (phydev->speed) {
 	case 1000:
 		status.bits.speed = GMAC_SPEED_1000;
-		if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
+		if (phy_interface_mode_is_rgmii(phydev->interface))
 			status.bits.mii_rmii = GMAC_PHY_RGMII_1000;
 		netdev_dbg(netdev, "connect %s to RGMII @ 1Gbit\n",
 			   phydev_name(phydev));
 		break;
 	case 100:
 		status.bits.speed = GMAC_SPEED_100;
-		if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
+		if (phy_interface_mode_is_rgmii(phydev->interface))
 			status.bits.mii_rmii = GMAC_PHY_RGMII_100_10;
 		netdev_dbg(netdev, "connect %s to RGMII @ 100 Mbit\n",
 			   phydev_name(phydev));
 		break;
 	case 10:
 		status.bits.speed = GMAC_SPEED_10;
-		if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
+		if (phy_interface_mode_is_rgmii(phydev->interface))
 			status.bits.mii_rmii = GMAC_PHY_RGMII_100_10;
 		netdev_dbg(netdev, "connect %s to RGMII @ 10 Mbit\n",
 			   phydev_name(phydev));
@@ -389,6 +389,9 @@ static int gmac_setup_phy(struct net_device *netdev)
 		status.bits.mii_rmii = GMAC_PHY_GMII;
 		break;
 	case PHY_INTERFACE_MODE_RGMII:
+	case PHY_INTERFACE_MODE_RGMII_ID:
+	case PHY_INTERFACE_MODE_RGMII_TXID:
+	case PHY_INTERFACE_MODE_RGMII_RXID:
 		netdev_dbg(netdev,
 			   "RGMII: set GMAC0 and GMAC1 to MII/RGMII mode\n");
 		status.bits.mii_rmii = GMAC_PHY_RGMII_100_10;
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 4fcfca4e1702..ccf142ce55d8 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1227,16 +1227,18 @@ static int m88e1118_config_init(struct phy_device *phydev)
 {
 	int err;
 
-	/* Change address */
-	err = marvell_set_page(phydev, MII_MARVELL_MSCR_PAGE);
-	if (err < 0)
-		return err;
-
 	/* Enable 1000 Mbit */
-	err = phy_write(phydev, 0x15, 0x1070);
+	err = phy_write_paged(phydev, MII_MARVELL_MSCR_PAGE,
+			      MII_88E1121_PHY_MSCR_REG, 0x1070);
 	if (err < 0)
 		return err;
 
+	if (phy_interface_is_rgmii(phydev)) {
+		err = m88e1121_config_aneg_rgmii_delays(phydev);
+		if (err < 0)
+			return err;
+	}
+
 	/* Change address */
 	err = marvell_set_page(phydev, MII_MARVELL_LED_PAGE);
 	if (err < 0)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Andrew Lunn]

> @@ -1227,16 +1227,18 @@ static int m88e1118_config_init(struct phy_device *phydev)
>  {
>  	int err;
>  
> -	/* Change address */
> -	err = marvell_set_page(phydev, MII_MARVELL_MSCR_PAGE);
> -	if (err < 0)
> -		return err;
> -
>  	/* Enable 1000 Mbit */
> -	err = phy_write(phydev, 0x15, 0x1070);
> +	err = phy_write_paged(phydev, MII_MARVELL_MSCR_PAGE,
> +			      MII_88E1121_PHY_MSCR_REG, 0x1070);

Ah, yes, keeping this makes it more backwards compatible.

It would be nice to replace the 0x1070 with #defines.

We already have:

#define MII_88E1121_PHY_MSCR_RX_DELAY	BIT(5)
#define MII_88E1121_PHY_MSCR_TX_DELAY	BIT(4)
#define MII_88E1121_PHY_MSCR_DELAY_MASK	(BIT(5) | BIT(4))

Bits 6 is the MSB of the default MAC speed.
Bit 13 is the LSB of the default MAC speed. These two should default to 10b = 1000Mbps
Bit 12 is reserved, and should be written 1.

    Andrew

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Andrew Lunn]

> @@ -1227,16 +1227,18 @@ static int m88e1118_config_init(struct phy_device *phydev)
>  {
>  	int err;
>  
> -	/* Change address */
> -	err = marvell_set_page(phydev, MII_MARVELL_MSCR_PAGE);
> -	if (err < 0)
> -		return err;
> -
>  	/* Enable 1000 Mbit */
> -	err = phy_write(phydev, 0x15, 0x1070);
> +	err = phy_write_paged(phydev, MII_MARVELL_MSCR_PAGE,
> +			      MII_88E1121_PHY_MSCR_REG, 0x1070);

Ah, yes, keeping this makes it more backwards compatible.

It would be nice to replace the 0x1070 with #defines.

We already have:

#define MII_88E1121_PHY_MSCR_RX_DELAY	BIT(5)
#define MII_88E1121_PHY_MSCR_TX_DELAY	BIT(4)
#define MII_88E1121_PHY_MSCR_DELAY_MASK	(BIT(5) | BIT(4))

Bits 6 is the MSB of the default MAC speed.
Bit 13 is the LSB of the default MAC speed. These two should default to 10b = 1000Mbps
Bit 12 is reserved, and should be written 1.

    Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Russell King (Oracle)]

On Tue, Jan 04, 2022 at 03:46:19PM +0100, Andrew Lunn wrote:
> > @@ -1227,16 +1227,18 @@ static int m88e1118_config_init(struct phy_device *phydev)
> >  {
> >  	int err;
> >  
> > -	/* Change address */
> > -	err = marvell_set_page(phydev, MII_MARVELL_MSCR_PAGE);
> > -	if (err < 0)
> > -		return err;
> > -
> >  	/* Enable 1000 Mbit */
> > -	err = phy_write(phydev, 0x15, 0x1070);
> > +	err = phy_write_paged(phydev, MII_MARVELL_MSCR_PAGE,
> > +			      MII_88E1121_PHY_MSCR_REG, 0x1070);
> 
> Ah, yes, keeping this makes it more backwards compatible.
> 
> It would be nice to replace the 0x1070 with #defines.
> 
> We already have:
> 
> #define MII_88E1121_PHY_MSCR_RX_DELAY	BIT(5)
> #define MII_88E1121_PHY_MSCR_TX_DELAY	BIT(4)
> #define MII_88E1121_PHY_MSCR_DELAY_MASK	(BIT(5) | BIT(4))
> 
> Bits 6 is the MSB of the default MAC speed.
> Bit 13 is the LSB of the default MAC speed. These two should default to 10b = 1000Mbps
> Bit 12 is reserved, and should be written 1.

Hmm, seems odd that these speed bits match BMCR, and I'm not sure why
the default MAC speed would have any bearing on whether gigabit mode
is enabled. If they default to 10b, then the write should have no effect
unless boot firmware has changed them.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Russell King (Oracle)]

On Tue, Jan 04, 2022 at 03:46:19PM +0100, Andrew Lunn wrote:
> > @@ -1227,16 +1227,18 @@ static int m88e1118_config_init(struct phy_device *phydev)
> >  {
> >  	int err;
> >  
> > -	/* Change address */
> > -	err = marvell_set_page(phydev, MII_MARVELL_MSCR_PAGE);
> > -	if (err < 0)
> > -		return err;
> > -
> >  	/* Enable 1000 Mbit */
> > -	err = phy_write(phydev, 0x15, 0x1070);
> > +	err = phy_write_paged(phydev, MII_MARVELL_MSCR_PAGE,
> > +			      MII_88E1121_PHY_MSCR_REG, 0x1070);
> 
> Ah, yes, keeping this makes it more backwards compatible.
> 
> It would be nice to replace the 0x1070 with #defines.
> 
> We already have:
> 
> #define MII_88E1121_PHY_MSCR_RX_DELAY	BIT(5)
> #define MII_88E1121_PHY_MSCR_TX_DELAY	BIT(4)
> #define MII_88E1121_PHY_MSCR_DELAY_MASK	(BIT(5) | BIT(4))
> 
> Bits 6 is the MSB of the default MAC speed.
> Bit 13 is the LSB of the default MAC speed. These two should default to 10b = 1000Mbps
> Bit 12 is reserved, and should be written 1.

Hmm, seems odd that these speed bits match BMCR, and I'm not sure why
the default MAC speed would have any bearing on whether gigabit mode
is enabled. If they default to 10b, then the write should have no effect
unless boot firmware has changed them.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Andrew Lunn]

> > #define MII_88E1121_PHY_MSCR_RX_DELAY	BIT(5)
> > #define MII_88E1121_PHY_MSCR_TX_DELAY	BIT(4)
> > #define MII_88E1121_PHY_MSCR_DELAY_MASK	(BIT(5) | BIT(4))
> > 
> > Bits 6 is the MSB of the default MAC speed.
> > Bit 13 is the LSB of the default MAC speed. These two should default to 10b = 1000Mbps
> > Bit 12 is reserved, and should be written 1.
> 
> Hmm, seems odd that these speed bits match BMCR, and I'm not sure why
> the default MAC speed would have any bearing on whether gigabit mode
> is enabled. If they default to 10b, then the write should have no effect
> unless boot firmware has changed them.

There is a bit more, which is did not copy:

    Also, used for setting speed of MAC interface during MAC side
    loop-back. Requires that customer set both these bits and force
    speed using register 0 to the same speed.  MAC Interface Speed
    during Link down.

So i don't think they matter during normal operation.

   Andrew

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Andrew Lunn]

> > #define MII_88E1121_PHY_MSCR_RX_DELAY	BIT(5)
> > #define MII_88E1121_PHY_MSCR_TX_DELAY	BIT(4)
> > #define MII_88E1121_PHY_MSCR_DELAY_MASK	(BIT(5) | BIT(4))
> > 
> > Bits 6 is the MSB of the default MAC speed.
> > Bit 13 is the LSB of the default MAC speed. These two should default to 10b = 1000Mbps
> > Bit 12 is reserved, and should be written 1.
> 
> Hmm, seems odd that these speed bits match BMCR, and I'm not sure why
> the default MAC speed would have any bearing on whether gigabit mode
> is enabled. If they default to 10b, then the write should have no effect
> unless boot firmware has changed them.

There is a bit more, which is did not copy:

    Also, used for setting speed of MAC interface during MAC side
    loop-back. Requires that customer set both these bits and force
    speed using register 0 to the same speed.  MAC Interface Speed
    during Link down.

So i don't think they matter during normal operation.

   Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Corentin Labbe]

Le Tue, Jan 04, 2022 at 02:27:14PM +0000, Russell King (Oracle) a écrit :
> On Tue, Jan 04, 2022 at 03:11:46PM +0100, Corentin Labbe wrote:
> > Le Tue, Jan 04, 2022 at 12:11:55PM +0000, Russell King (Oracle) a écrit :
> > > On Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) wrote:
> > > > On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> > > > > Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > > > > > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > > > > > Hello
> > > > > > > 
> > > > > > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > > > > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > > > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > > > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > > > > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > > > > > 
> > > > > > How is the PHY connected to the host (which interface mode?) If it's
> > > > > > RGMII, it could be that the wrong RGMII interface mode is specified in
> > > > > > DT.
> > > > > > 
> > > > > 
> > > > > The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> > > > > The only change to the mainline dtb is removing the max-speed.
> > > > 
> > > > So, it's using "rgmii" with no delay configured at the PHY with the
> > > > speed limited to 100Mbps. You then remove the speed limitation and
> > > > it doesn't work at 1Gbps.
> > > > 
> > > > I think I've seen this on other platforms (imx6 + ar8035) when the
> > > > RGMII delay is not correctly configured - it will work at slower
> > > > speeds but not 1G.
> > > > 
> > > > The RGMII spec specifies that there will be a delay - and the delay can
> > > > be introduced by either the MAC, PHY or by PCB track routing. It sounds
> > > > to me like your boot environment configures the PHY to introduce the
> > > > necessary delay, but then, because the DT "rgmii" mode means "no delay
> > > > at the PHY" when you use the Marvell driver (which respects that), the
> > > > Marvell driver configures the PHY for no delay, resulting in a non-
> > > > working situation at 1G.
> > > > 
> > > > I would suggest checking how the boot environment configures the PHY,
> > > > and change the "rgmii" mode in DT to match. There is a description of
> > > > the four RGMII modes in Documentation/networking/phy.rst that may help
> > > > understand what each one means.
> > > 
> > > Hmm. Sorry, I'm leading you stray. It looks like the 88E1118 code does
> > > not program any delays depending on the interface mode, so changing that
> > > will have no effect.
> > > 
> > > I suspect, looking at m88e1118_config_init(), that the write to register
> > > 0x15 in the MSCR page could be the problem.
> > > 
> > > 0x15 is 21, which is MII_88E1121_PHY_MSCR_REG. In other Marvell PHYs,
> > > bits 4 and 5 are the tx and rx delays, both of which are set. Looking
> > > at m88e1121_config_aneg_rgmii_delays(), this would seem to indicate
> > > that the PHY is being placed into rgmii-id mode.
> > > 
> > > Can you try changing:
> > > 
> > > 	err = phy_write(phydev, 0x15, 0x1070);
> > > 
> > > to:
> > > 
> > > 	err = phy_write(phydev, 0x15, 0x1040);
> > > 
> > > and see what happens? Maybe trying other combinations of bits 4 and 5
> > > to find a working combination.
> > > 
> > 
> > Forget my other message, using 0x1040 lead to success.
> > My problem was that I tried rgmii-id which net/ethernet/cortina does not support on some code path. (everything test PHY_INTERFACE_MODE_RGMII only)
> > So I retry tests with original phy-mode = "rgmii".
> > 
> > So with the following changes everything is ok:
> > diff --git a/arch/arm/boot/dts/gemini-ssi1328.dts b/arch/arm/boot/dts/gemini-ssi1328.dts
> > index 113feb1c4922..7543d117a13a 100644
> > --- a/arch/arm/boot/dts/gemini-ssi1328.dts
> > +++ b/arch/arm/boot/dts/gemini-ssi1328.dts
> > @@ -40,10 +40,6 @@ mdio0: mdio {
> >                 phy0: ethernet-phy@1 {
> >                         reg = <1>;
> >                         device_type = "ethernet-phy";
> > -                       /* We lack the knowledge of necessary GPIO to achieve
> > -                        * Gigabit
> > -                        */
> > -                       max-speed = <100>;
> >                 };
> >                 /* WAN ICPlus IP101A */
> >                 phy1: ethernet-phy@2 {
> > diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> > index 4fcfca4e1702..af7fc9d8eaa7 100644
> > --- a/drivers/net/phy/marvell.c
> > +++ b/drivers/net/phy/marvell.c
> > @@ -1233,7 +1233,7 @@ static int m88e1118_config_init(struct phy_device *phydev)
> >                 return err;
> >  
> >         /* Enable 1000 Mbit */
> > -       err = phy_write(phydev, 0x15, 0x1070);
> > +       err = phy_write(phydev, 0x15, 0x1040);
> >         if (err < 0)
> >                 return err;
> >  
> 
> Okay, so we have two things that need fixing:
> 
> 1) We need m88e1118_config_init() to take note of the interface mode
> if it's RGMII, and program MSCR appropriately.
> 
> 2) We need drivers/net/ethernet/cortina/gemini.c to accept any RGMII
> interface mode.
> 
> Here's an untested patch for both - I've also converted the MSCR write
> to be more modern. Please let me know if this resolves your issue.
> We then need to consider whether it breaks any existing platform.

Patch works for me.
Furthermore, I have an other board with the same issue (but with a Realtek PHY).
But in that case, it was just a missing rgmii-id (and your ethernet/cortina/gemini change).

Tested-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Tested-on: gemini-ssi1328
Tested-on: gemini-ns2502

I wait for patch to be sent before sending DTB changes on my side.

Thanks for your help

> 
> diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
> index 07add311f65d..c78b99a497df 100644
> --- a/drivers/net/ethernet/cortina/gemini.c
> +++ b/drivers/net/ethernet/cortina/gemini.c
> @@ -305,21 +305,21 @@ static void gmac_speed_set(struct net_device *netdev)
>  	switch (phydev->speed) {
>  	case 1000:
>  		status.bits.speed = GMAC_SPEED_1000;
> -		if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
> +		if (phy_interface_mode_is_rgmii(phydev->interface))
>  			status.bits.mii_rmii = GMAC_PHY_RGMII_1000;
>  		netdev_dbg(netdev, "connect %s to RGMII @ 1Gbit\n",
>  			   phydev_name(phydev));
>  		break;
>  	case 100:
>  		status.bits.speed = GMAC_SPEED_100;
> -		if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
> +		if (phy_interface_mode_is_rgmii(phydev->interface))
>  			status.bits.mii_rmii = GMAC_PHY_RGMII_100_10;
>  		netdev_dbg(netdev, "connect %s to RGMII @ 100 Mbit\n",
>  			   phydev_name(phydev));
>  		break;
>  	case 10:
>  		status.bits.speed = GMAC_SPEED_10;
> -		if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
> +		if (phy_interface_mode_is_rgmii(phydev->interface))
>  			status.bits.mii_rmii = GMAC_PHY_RGMII_100_10;
>  		netdev_dbg(netdev, "connect %s to RGMII @ 10 Mbit\n",
>  			   phydev_name(phydev));
> @@ -389,6 +389,9 @@ static int gmac_setup_phy(struct net_device *netdev)
>  		status.bits.mii_rmii = GMAC_PHY_GMII;
>  		break;
>  	case PHY_INTERFACE_MODE_RGMII:
> +	case PHY_INTERFACE_MODE_RGMII_ID:
> +	case PHY_INTERFACE_MODE_RGMII_TXID:
> +	case PHY_INTERFACE_MODE_RGMII_RXID:
>  		netdev_dbg(netdev,
>  			   "RGMII: set GMAC0 and GMAC1 to MII/RGMII mode\n");
>  		status.bits.mii_rmii = GMAC_PHY_RGMII_100_10;
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index 4fcfca4e1702..ccf142ce55d8 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -1227,16 +1227,18 @@ static int m88e1118_config_init(struct phy_device *phydev)
>  {
>  	int err;
>  
> -	/* Change address */
> -	err = marvell_set_page(phydev, MII_MARVELL_MSCR_PAGE);
> -	if (err < 0)
> -		return err;
> -
>  	/* Enable 1000 Mbit */
> -	err = phy_write(phydev, 0x15, 0x1070);
> +	err = phy_write_paged(phydev, MII_MARVELL_MSCR_PAGE,
> +			      MII_88E1121_PHY_MSCR_REG, 0x1070);
>  	if (err < 0)
>  		return err;
>  
> +	if (phy_interface_is_rgmii(phydev)) {
> +		err = m88e1121_config_aneg_rgmii_delays(phydev);
> +		if (err < 0)
> +			return err;
> +	}
> +
>  	/* Change address */
>  	err = marvell_set_page(phydev, MII_MARVELL_LED_PAGE);
>  	if (err < 0)
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Corentin Labbe]

Le Tue, Jan 04, 2022 at 02:27:14PM +0000, Russell King (Oracle) a écrit :
> On Tue, Jan 04, 2022 at 03:11:46PM +0100, Corentin Labbe wrote:
> > Le Tue, Jan 04, 2022 at 12:11:55PM +0000, Russell King (Oracle) a écrit :
> > > On Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) wrote:
> > > > On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote:
> > > > > Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a écrit :
> > > > > > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote:
> > > > > > > Hello
> > > > > > > 
> > > > > > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with a Marvell 88E1118 as given by:
> > > > > > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
> > > > > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit
> > > > > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network.
> > > > > > > By not working, I mean kernel started with ip=dhcp cannot get an IP.
> > > > > > 
> > > > > > How is the PHY connected to the host (which interface mode?) If it's
> > > > > > RGMII, it could be that the wrong RGMII interface mode is specified in
> > > > > > DT.
> > > > > > 
> > > > > 
> > > > > The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts)
> > > > > The only change to the mainline dtb is removing the max-speed.
> > > > 
> > > > So, it's using "rgmii" with no delay configured at the PHY with the
> > > > speed limited to 100Mbps. You then remove the speed limitation and
> > > > it doesn't work at 1Gbps.
> > > > 
> > > > I think I've seen this on other platforms (imx6 + ar8035) when the
> > > > RGMII delay is not correctly configured - it will work at slower
> > > > speeds but not 1G.
> > > > 
> > > > The RGMII spec specifies that there will be a delay - and the delay can
> > > > be introduced by either the MAC, PHY or by PCB track routing. It sounds
> > > > to me like your boot environment configures the PHY to introduce the
> > > > necessary delay, but then, because the DT "rgmii" mode means "no delay
> > > > at the PHY" when you use the Marvell driver (which respects that), the
> > > > Marvell driver configures the PHY for no delay, resulting in a non-
> > > > working situation at 1G.
> > > > 
> > > > I would suggest checking how the boot environment configures the PHY,
> > > > and change the "rgmii" mode in DT to match. There is a description of
> > > > the four RGMII modes in Documentation/networking/phy.rst that may help
> > > > understand what each one means.
> > > 
> > > Hmm. Sorry, I'm leading you stray. It looks like the 88E1118 code does
> > > not program any delays depending on the interface mode, so changing that
> > > will have no effect.
> > > 
> > > I suspect, looking at m88e1118_config_init(), that the write to register
> > > 0x15 in the MSCR page could be the problem.
> > > 
> > > 0x15 is 21, which is MII_88E1121_PHY_MSCR_REG. In other Marvell PHYs,
> > > bits 4 and 5 are the tx and rx delays, both of which are set. Looking
> > > at m88e1121_config_aneg_rgmii_delays(), this would seem to indicate
> > > that the PHY is being placed into rgmii-id mode.
> > > 
> > > Can you try changing:
> > > 
> > > 	err = phy_write(phydev, 0x15, 0x1070);
> > > 
> > > to:
> > > 
> > > 	err = phy_write(phydev, 0x15, 0x1040);
> > > 
> > > and see what happens? Maybe trying other combinations of bits 4 and 5
> > > to find a working combination.
> > > 
> > 
> > Forget my other message, using 0x1040 lead to success.
> > My problem was that I tried rgmii-id which net/ethernet/cortina does not support on some code path. (everything test PHY_INTERFACE_MODE_RGMII only)
> > So I retry tests with original phy-mode = "rgmii".
> > 
> > So with the following changes everything is ok:
> > diff --git a/arch/arm/boot/dts/gemini-ssi1328.dts b/arch/arm/boot/dts/gemini-ssi1328.dts
> > index 113feb1c4922..7543d117a13a 100644
> > --- a/arch/arm/boot/dts/gemini-ssi1328.dts
> > +++ b/arch/arm/boot/dts/gemini-ssi1328.dts
> > @@ -40,10 +40,6 @@ mdio0: mdio {
> >                 phy0: ethernet-phy@1 {
> >                         reg = <1>;
> >                         device_type = "ethernet-phy";
> > -                       /* We lack the knowledge of necessary GPIO to achieve
> > -                        * Gigabit
> > -                        */
> > -                       max-speed = <100>;
> >                 };
> >                 /* WAN ICPlus IP101A */
> >                 phy1: ethernet-phy@2 {
> > diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> > index 4fcfca4e1702..af7fc9d8eaa7 100644
> > --- a/drivers/net/phy/marvell.c
> > +++ b/drivers/net/phy/marvell.c
> > @@ -1233,7 +1233,7 @@ static int m88e1118_config_init(struct phy_device *phydev)
> >                 return err;
> >  
> >         /* Enable 1000 Mbit */
> > -       err = phy_write(phydev, 0x15, 0x1070);
> > +       err = phy_write(phydev, 0x15, 0x1040);
> >         if (err < 0)
> >                 return err;
> >  
> 
> Okay, so we have two things that need fixing:
> 
> 1) We need m88e1118_config_init() to take note of the interface mode
> if it's RGMII, and program MSCR appropriately.
> 
> 2) We need drivers/net/ethernet/cortina/gemini.c to accept any RGMII
> interface mode.
> 
> Here's an untested patch for both - I've also converted the MSCR write
> to be more modern. Please let me know if this resolves your issue.
> We then need to consider whether it breaks any existing platform.

Patch works for me.
Furthermore, I have an other board with the same issue (but with a Realtek PHY).
But in that case, it was just a missing rgmii-id (and your ethernet/cortina/gemini change).

Tested-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Tested-on: gemini-ssi1328
Tested-on: gemini-ns2502

I wait for patch to be sent before sending DTB changes on my side.

Thanks for your help

> 
> diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
> index 07add311f65d..c78b99a497df 100644
> --- a/drivers/net/ethernet/cortina/gemini.c
> +++ b/drivers/net/ethernet/cortina/gemini.c
> @@ -305,21 +305,21 @@ static void gmac_speed_set(struct net_device *netdev)
>  	switch (phydev->speed) {
>  	case 1000:
>  		status.bits.speed = GMAC_SPEED_1000;
> -		if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
> +		if (phy_interface_mode_is_rgmii(phydev->interface))
>  			status.bits.mii_rmii = GMAC_PHY_RGMII_1000;
>  		netdev_dbg(netdev, "connect %s to RGMII @ 1Gbit\n",
>  			   phydev_name(phydev));
>  		break;
>  	case 100:
>  		status.bits.speed = GMAC_SPEED_100;
> -		if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
> +		if (phy_interface_mode_is_rgmii(phydev->interface))
>  			status.bits.mii_rmii = GMAC_PHY_RGMII_100_10;
>  		netdev_dbg(netdev, "connect %s to RGMII @ 100 Mbit\n",
>  			   phydev_name(phydev));
>  		break;
>  	case 10:
>  		status.bits.speed = GMAC_SPEED_10;
> -		if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
> +		if (phy_interface_mode_is_rgmii(phydev->interface))
>  			status.bits.mii_rmii = GMAC_PHY_RGMII_100_10;
>  		netdev_dbg(netdev, "connect %s to RGMII @ 10 Mbit\n",
>  			   phydev_name(phydev));
> @@ -389,6 +389,9 @@ static int gmac_setup_phy(struct net_device *netdev)
>  		status.bits.mii_rmii = GMAC_PHY_GMII;
>  		break;
>  	case PHY_INTERFACE_MODE_RGMII:
> +	case PHY_INTERFACE_MODE_RGMII_ID:
> +	case PHY_INTERFACE_MODE_RGMII_TXID:
> +	case PHY_INTERFACE_MODE_RGMII_RXID:
>  		netdev_dbg(netdev,
>  			   "RGMII: set GMAC0 and GMAC1 to MII/RGMII mode\n");
>  		status.bits.mii_rmii = GMAC_PHY_RGMII_100_10;
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index 4fcfca4e1702..ccf142ce55d8 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -1227,16 +1227,18 @@ static int m88e1118_config_init(struct phy_device *phydev)
>  {
>  	int err;
>  
> -	/* Change address */
> -	err = marvell_set_page(phydev, MII_MARVELL_MSCR_PAGE);
> -	if (err < 0)
> -		return err;
> -
>  	/* Enable 1000 Mbit */
> -	err = phy_write(phydev, 0x15, 0x1070);
> +	err = phy_write_paged(phydev, MII_MARVELL_MSCR_PAGE,
> +			      MII_88E1121_PHY_MSCR_REG, 0x1070);
>  	if (err < 0)
>  		return err;
>  
> +	if (phy_interface_is_rgmii(phydev)) {
> +		err = m88e1121_config_aneg_rgmii_delays(phydev);
> +		if (err < 0)
> +			return err;
> +	}
> +
>  	/* Change address */
>  	err = marvell_set_page(phydev, MII_MARVELL_LED_PAGE);
>  	if (err < 0)
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Andrew Lunn]

> Forget my other message, using 0x1040 lead to success.

O.K. this is going to be messy :-(

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 4fcfca4e1702..4bc7a44f613a 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1227,15 +1227,11 @@ static int m88e1118_config_init(struct phy_device *phydev)
 {
        int err;
 
-       /* Change address */
-       err = marvell_set_page(phydev, MII_MARVELL_MSCR_PAGE);
-       if (err < 0)
-               return err;
-
-       /* Enable 1000 Mbit */
-       err = phy_write(phydev, 0x15, 0x1070);
-       if (err < 0)
-               return err;
+       if (phy_interface_is_rgmii(phydev)) {
+               err = m88e1121_config_aneg_rgmii_delays(phydev);
+               if (err < 0)
+                       return err;
+       }
 
        /* Change address */
        err = marvell_set_page(phydev, MII_MARVELL_LED_PAGE);


will make the PHY driver respect the delays passed to it. But as
Russell already said, it is likely to break with boards which have
"rgmii" in their DT, which is currently being ignored and rgmii-id
programmed into hardware.

We have been here before, with another PHY driver. We decided to make
the change anyway, and fix broken DT when they were reported. It
caused some pain, but in the end, we avoided having odd DT properties
like:

       phy-mode = 'we-really-do-want-rgmii'

There is one more instance of phy_write(phydev, 0x15, 0x1070) for the
m88e1149. I suggest we leave that one alone, until we have a board
which actually requires it.

One thing i would like to understand is where is the delay actually
getting added? If you need the PHY to not add the delay, it is either
the MAC or the PCB. Can you look at the MAC driver and see if it has
any such configuration registers.

       Andrew

Re: net: phy: marvell: network working with generic PHY and not with marvell PHY

[Andrew Lunn]

> Forget my other message, using 0x1040 lead to success.

O.K. this is going to be messy :-(

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 4fcfca4e1702..4bc7a44f613a 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1227,15 +1227,11 @@ static int m88e1118_config_init(struct phy_device *phydev)
 {
        int err;
 
-       /* Change address */
-       err = marvell_set_page(phydev, MII_MARVELL_MSCR_PAGE);
-       if (err < 0)
-               return err;
-
-       /* Enable 1000 Mbit */
-       err = phy_write(phydev, 0x15, 0x1070);
-       if (err < 0)
-               return err;
+       if (phy_interface_is_rgmii(phydev)) {
+               err = m88e1121_config_aneg_rgmii_delays(phydev);
+               if (err < 0)
+                       return err;
+       }
 
        /* Change address */
        err = marvell_set_page(phydev, MII_MARVELL_LED_PAGE);


will make the PHY driver respect the delays passed to it. But as
Russell already said, it is likely to break with boards which have
"rgmii" in their DT, which is currently being ignored and rgmii-id
programmed into hardware.

We have been here before, with another PHY driver. We decided to make
the change anyway, and fix broken DT when they were reported. It
caused some pain, but in the end, we avoided having odd DT properties
like:

       phy-mode = 'we-really-do-want-rgmii'

There is one more instance of phy_write(phydev, 0x15, 0x1070) for the
m88e1149. I suggest we leave that one alone, until we have a board
which actually requires it.

One thing i would like to understand is where is the delay actually
getting added? If you need the PHY to not add the delay, it is either
the MAC or the PCB. Can you look at the MAC driver and see if it has
any such configuration registers.

       Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel