| Message ID | 20201020034558.19438-2-chris.packham@alliedtelesis.co.nz (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: dsa: mv88e6xxx: serdes link without phy | expand |
On Tue, Oct 20, 2020 at 04:45:56PM +1300, Chris Packham wrote: > When a port is configured with 'managed = "in-band-status"' don't force > the link up, the switch MAC will detect the link status correctly. > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > Reviewed-by: Andrew Lunn <andrew@lunn.ch> I thought we had issues with the 88E6390 where the PCS does not update the MAC with its results. Isn't this going to break the 6390? Andrew?
On Tue, 20 Oct 2020 11:15:52 +0100 Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > On Tue, Oct 20, 2020 at 04:45:56PM +1300, Chris Packham wrote: > > When a port is configured with 'managed = "in-band-status"' don't force > > the link up, the switch MAC will detect the link status correctly. > > > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > > Reviewed-by: Andrew Lunn <andrew@lunn.ch> > > I thought we had issues with the 88E6390 where the PCS does not > update the MAC with its results. Isn't this going to break the > 6390? Andrew? > Russell, I tested this patch on Turris MOX with 6390 on port 9 (cpu port) which is configured in devicetree as 2500base-x, in-band-status, and it works... Or will this break on user ports?
On Tue, Oct 20, 2020 at 03:49:40PM +0200, Marek Behun wrote: > On Tue, 20 Oct 2020 11:15:52 +0100 > Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > > On Tue, Oct 20, 2020 at 04:45:56PM +1300, Chris Packham wrote: > > > When a port is configured with 'managed = "in-band-status"' don't force > > > the link up, the switch MAC will detect the link status correctly. > > > > > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > > > Reviewed-by: Andrew Lunn <andrew@lunn.ch> > > > > I thought we had issues with the 88E6390 where the PCS does not > > update the MAC with its results. Isn't this going to break the > > 6390? Andrew? > > > > Russell, I tested this patch on Turris MOX with 6390 on port 9 (cpu > port) which is configured in devicetree as 2500base-x, in-band-status, > and it works... > > Or will this break on user ports? User ports is what needs testing, ideally with an SFP. There used to be explicit code which when the SERDES reported link up, the MAC was configured in software with the correct speed etc. With the move to pcs APIs, it is less obvious how this works now, does it still software configure the MAC, or do we have the right magic so that the hardware updates itself. Andrew
On Tue, Oct 20, 2020 at 04:05:35PM +0200, Andrew Lunn wrote: > On Tue, Oct 20, 2020 at 03:49:40PM +0200, Marek Behun wrote: > > On Tue, 20 Oct 2020 11:15:52 +0100 > > Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > > > > On Tue, Oct 20, 2020 at 04:45:56PM +1300, Chris Packham wrote: > > > > When a port is configured with 'managed = "in-band-status"' don't force > > > > the link up, the switch MAC will detect the link status correctly. > > > > > > > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > > > > Reviewed-by: Andrew Lunn <andrew@lunn.ch> > > > > > > I thought we had issues with the 88E6390 where the PCS does not > > > update the MAC with its results. Isn't this going to break the > > > 6390? Andrew? > > > > > > > Russell, I tested this patch on Turris MOX with 6390 on port 9 (cpu > > port) which is configured in devicetree as 2500base-x, in-band-status, > > and it works... > > > > Or will this break on user ports? > > User ports is what needs testing, ideally with an SFP. > > There used to be explicit code which when the SERDES reported link up, > the MAC was configured in software with the correct speed etc. With > the move to pcs APIs, it is less obvious how this works now, does it > still software configure the MAC, or do we have the right magic so > that the hardware updates itself. It's still there. The speed/duplex etc are read from the serdes PHY via mv88e6390_serdes_pcs_get_state(). When the link comes up, we pass the negotiated link parameters read from there to the link_up() functions. For ports where mv88e6xxx_port_ppu_updates() returns false (no external PHY) we update the port's speed and duplex setting and (currently, before this patch) force the link up. That was the behaviour before I converted the code, the one that you referred to. I had assumed the code was correct, and _none_ of the speed, duplex, nor link state was propagated from the serdes PCS to the port on the 88E6390 - hence why the code you refer to existed.
On Tue, 20 Oct 2020 15:15:25 +0100 Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > On Tue, Oct 20, 2020 at 04:05:35PM +0200, Andrew Lunn wrote: > > On Tue, Oct 20, 2020 at 03:49:40PM +0200, Marek Behun wrote: > > > On Tue, 20 Oct 2020 11:15:52 +0100 > > > Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > > > > > > On Tue, Oct 20, 2020 at 04:45:56PM +1300, Chris Packham wrote: > > > > > When a port is configured with 'managed = "in-band-status"' don't force > > > > > the link up, the switch MAC will detect the link status correctly. > > > > > > > > > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > > > > > Reviewed-by: Andrew Lunn <andrew@lunn.ch> > > > > > > > > I thought we had issues with the 88E6390 where the PCS does not > > > > update the MAC with its results. Isn't this going to break the > > > > 6390? Andrew? > > > > > > > > > > Russell, I tested this patch on Turris MOX with 6390 on port 9 (cpu > > > port) which is configured in devicetree as 2500base-x, in-band-status, > > > and it works... > > > > > > Or will this break on user ports? > > > > User ports is what needs testing, ideally with an SFP. > > > > There used to be explicit code which when the SERDES reported link up, > > the MAC was configured in software with the correct speed etc. With > > the move to pcs APIs, it is less obvious how this works now, does it > > still software configure the MAC, or do we have the right magic so > > that the hardware updates itself. > > It's still there. The speed/duplex etc are read from the serdes PHY > via mv88e6390_serdes_pcs_get_state(). When the link comes up, we > pass the negotiated link parameters read from there to the link_up() > functions. For ports where mv88e6xxx_port_ppu_updates() returns false > (no external PHY) we update the port's speed and duplex setting and > (currently, before this patch) force the link up. > > That was the behaviour before I converted the code, the one that you > referred to. I had assumed the code was correct, and _none_ of the > speed, duplex, nor link state was propagated from the serdes PCS to > the port on the 88E6390 - hence why the code you refer to existed. > Russell, you are right. SFP on 88E6390 does not work with this patch applied. So this patch breaks 88E6390. Marek
> > It's still there. The speed/duplex etc are read from the serdes PHY > > via mv88e6390_serdes_pcs_get_state(). When the link comes up, we > > pass the negotiated link parameters read from there to the link_up() > > functions. For ports where mv88e6xxx_port_ppu_updates() returns false > > (no external PHY) we update the port's speed and duplex setting and > > (currently, before this patch) force the link up. > > > > That was the behaviour before I converted the code, the one that you > > referred to. I had assumed the code was correct, and _none_ of the > > speed, duplex, nor link state was propagated from the serdes PCS to > > the port on the 88E6390 - hence why the code you refer to existed. > > Chris Do you get an interrupt when the link goes up? Since there are no SERDES registers, there is no specific SERDES interrupt. But maybe the PHY interrupt in global 2 fires? If you can use that, you can then be more in line with the other implementations and not need this change. Andrew
On 21/10/20 3:58 am, Andrew Lunn wrote: >>> It's still there. The speed/duplex etc are read from the serdes PHY >>> via mv88e6390_serdes_pcs_get_state(). When the link comes up, we >>> pass the negotiated link parameters read from there to the link_up() >>> functions. For ports where mv88e6xxx_port_ppu_updates() returns false >>> (no external PHY) we update the port's speed and duplex setting and >>> (currently, before this patch) force the link up. >>> >>> That was the behaviour before I converted the code, the one that you >>> referred to. I had assumed the code was correct, and _none_ of the >>> speed, duplex, nor link state was propagated from the serdes PCS to >>> the port on the 88E6390 - hence why the code you refer to existed. >>> > Chris > > Do you get an interrupt when the link goes up? Since there are no > SERDES registers, there is no specific SERDES interrupt. But maybe the > PHY interrupt in global 2 fires? So far I've not needed to use interrupts from the 6097. It's connected on my hardware but never been tested. There are a couple of SERDES LinkInt bits in the Global2 interrupt source/mask register which look as though they should fire. > If you can use that, you can then be > more in line with the other implementations and not need this change. My particular problem was actually on the other end of the link (which is a 98dx160 that doesn't currently have a dsa driver). When the link was forced on the 6097 end it would only link up if the 6097 came up after the dx160. Are you saying there is a way of avoiding the call to mv88e6xxx_mac_link_up() if I have interrupts for the serdes ports?
On 21/10/20 3:51 am, Marek Behun wrote: > On Tue, 20 Oct 2020 15:15:25 +0100 > Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > >> On Tue, Oct 20, 2020 at 04:05:35PM +0200, Andrew Lunn wrote: >>> On Tue, Oct 20, 2020 at 03:49:40PM +0200, Marek Behun wrote: >>>> On Tue, 20 Oct 2020 11:15:52 +0100 >>>> Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: >>>> >>>>> On Tue, Oct 20, 2020 at 04:45:56PM +1300, Chris Packham wrote: >>>>>> When a port is configured with 'managed = "in-band-status"' don't force >>>>>> the link up, the switch MAC will detect the link status correctly. >>>>>> >>>>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> >>>>>> Reviewed-by: Andrew Lunn <andrew@lunn.ch> >>>>> I thought we had issues with the 88E6390 where the PCS does not >>>>> update the MAC with its results. Isn't this going to break the >>>>> 6390? Andrew? >>>>> >>>> Russell, I tested this patch on Turris MOX with 6390 on port 9 (cpu >>>> port) which is configured in devicetree as 2500base-x, in-band-status, >>>> and it works... >>>> >>>> Or will this break on user ports? >>> User ports is what needs testing, ideally with an SFP. >>> >>> There used to be explicit code which when the SERDES reported link up, >>> the MAC was configured in software with the correct speed etc. With >>> the move to pcs APIs, it is less obvious how this works now, does it >>> still software configure the MAC, or do we have the right magic so >>> that the hardware updates itself. >> It's still there. The speed/duplex etc are read from the serdes PHY >> via mv88e6390_serdes_pcs_get_state(). When the link comes up, we >> pass the negotiated link parameters read from there to the link_up() >> functions. For ports where mv88e6xxx_port_ppu_updates() returns false >> (no external PHY) we update the port's speed and duplex setting and >> (currently, before this patch) force the link up. >> >> That was the behaviour before I converted the code, the one that you >> referred to. I had assumed the code was correct, and _none_ of the >> speed, duplex, nor link state was propagated from the serdes PCS to >> the port on the 88E6390 - hence why the code you refer to existed. >> > Russell, you are right. > SFP on 88E6390 does not work with this patch applied. > So this patch breaks 88E6390. Thanks for testing. It sounds like maybe if I make mv88e6xxx_port_ppu_updates() return true for the 6097 in serdes mode I can avoid the forced link up without affecting the 6390.
Hi Chris > So far I've not needed to use interrupts from the 6097. It's connected > on my hardware but never been tested. The mv88e6xxx driver will also poll the interrupt bits, if the interrupt is not wired to a GPIO. > There are a couple of SERDES LinkInt bits in the Global2 interrupt > source/mask register which look as though they should fire. Sounds good. Maybe more 6352 code you can copy. > > If you can use that, you can then be more in line with the other > > implementations and not need this change. > My particular problem was actually on the other end of the link (which > is a 98dx160 that doesn't currently have a dsa driver). When the link > was forced on the 6097 end it would only link up if the 6097 came up > after the dx160. Are you saying there is a way of avoiding the call to > mv88e6xxx_mac_link_up() if I have interrupts for the serdes ports? If you have all the code in place, what should happen is that the PCS is powered up. It will try to establish a link with its peer. phylink will also call serdes_pcs_an_restart() function to kick off auto-neg on the PCS link. Once link is established, you should get an interrupt. The interrupt handler then calls dsa_port_phylink_mac_change() which tells phylink the PCS is now up. It will use the serdes_pcs_get_state() call to find out what the PCS pair have agreed on, and then configure the MAC with the same information, forcing it. Lets just hope you can do this, given the level of integration of the PCS and MAC, in that there are no real PCS registers you can play with. Andrew
On Tue, Oct 20, 2020 at 09:06:32PM +0000, Chris Packham wrote: > > On 21/10/20 3:51 am, Marek Behun wrote: > > On Tue, 20 Oct 2020 15:15:25 +0100 > > Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > > >> On Tue, Oct 20, 2020 at 04:05:35PM +0200, Andrew Lunn wrote: > >>> On Tue, Oct 20, 2020 at 03:49:40PM +0200, Marek Behun wrote: > >>>> On Tue, 20 Oct 2020 11:15:52 +0100 > >>>> Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > >>>> > >>>>> On Tue, Oct 20, 2020 at 04:45:56PM +1300, Chris Packham wrote: > >>>>>> When a port is configured with 'managed = "in-band-status"' don't force > >>>>>> the link up, the switch MAC will detect the link status correctly. > >>>>>> > >>>>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > >>>>>> Reviewed-by: Andrew Lunn <andrew@lunn.ch> > >>>>> I thought we had issues with the 88E6390 where the PCS does not > >>>>> update the MAC with its results. Isn't this going to break the > >>>>> 6390? Andrew? > >>>>> > >>>> Russell, I tested this patch on Turris MOX with 6390 on port 9 (cpu > >>>> port) which is configured in devicetree as 2500base-x, in-band-status, > >>>> and it works... > >>>> > >>>> Or will this break on user ports? > >>> User ports is what needs testing, ideally with an SFP. > >>> > >>> There used to be explicit code which when the SERDES reported link up, > >>> the MAC was configured in software with the correct speed etc. With > >>> the move to pcs APIs, it is less obvious how this works now, does it > >>> still software configure the MAC, or do we have the right magic so > >>> that the hardware updates itself. > >> It's still there. The speed/duplex etc are read from the serdes PHY > >> via mv88e6390_serdes_pcs_get_state(). When the link comes up, we > >> pass the negotiated link parameters read from there to the link_up() > >> functions. For ports where mv88e6xxx_port_ppu_updates() returns false > >> (no external PHY) we update the port's speed and duplex setting and > >> (currently, before this patch) force the link up. > >> > >> That was the behaviour before I converted the code, the one that you > >> referred to. I had assumed the code was correct, and _none_ of the > >> speed, duplex, nor link state was propagated from the serdes PCS to > >> the port on the 88E6390 - hence why the code you refer to existed. > >> > > Russell, you are right. > > SFP on 88E6390 does not work with this patch applied. > > So this patch breaks 88E6390. > Thanks for testing. It sounds like maybe if I make > mv88e6xxx_port_ppu_updates() return true for the 6097 in serdes mode I > can avoid the forced link up without affecting the 6390. Another option would be to make mv88e6xxx_mac_link_up() call a switch specific implementation function, which is probably way cleaner than introducing conditionals on the switch type in functions, and reflects the existing code structure.
On 21/10/20 10:18 am, Russell King - ARM Linux admin wrote: > On Tue, Oct 20, 2020 at 09:06:32PM +0000, Chris Packham wrote: >> On 21/10/20 3:51 am, Marek Behun wrote: >>> On Tue, 20 Oct 2020 15:15:25 +0100 >>> Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: >>> >>>> On Tue, Oct 20, 2020 at 04:05:35PM +0200, Andrew Lunn wrote: >>>>> On Tue, Oct 20, 2020 at 03:49:40PM +0200, Marek Behun wrote: >>>>>> On Tue, 20 Oct 2020 11:15:52 +0100 >>>>>> Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: >>>>>> >>>>>>> On Tue, Oct 20, 2020 at 04:45:56PM +1300, Chris Packham wrote: >>>>>>>> When a port is configured with 'managed = "in-band-status"' don't force >>>>>>>> the link up, the switch MAC will detect the link status correctly. >>>>>>>> >>>>>>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> >>>>>>>> Reviewed-by: Andrew Lunn <andrew@lunn.ch> >>>>>>> I thought we had issues with the 88E6390 where the PCS does not >>>>>>> update the MAC with its results. Isn't this going to break the >>>>>>> 6390? Andrew? >>>>>>> >>>>>> Russell, I tested this patch on Turris MOX with 6390 on port 9 (cpu >>>>>> port) which is configured in devicetree as 2500base-x, in-band-status, >>>>>> and it works... >>>>>> >>>>>> Or will this break on user ports? >>>>> User ports is what needs testing, ideally with an SFP. >>>>> >>>>> There used to be explicit code which when the SERDES reported link up, >>>>> the MAC was configured in software with the correct speed etc. With >>>>> the move to pcs APIs, it is less obvious how this works now, does it >>>>> still software configure the MAC, or do we have the right magic so >>>>> that the hardware updates itself. >>>> It's still there. The speed/duplex etc are read from the serdes PHY >>>> via mv88e6390_serdes_pcs_get_state(). When the link comes up, we >>>> pass the negotiated link parameters read from there to the link_up() >>>> functions. For ports where mv88e6xxx_port_ppu_updates() returns false >>>> (no external PHY) we update the port's speed and duplex setting and >>>> (currently, before this patch) force the link up. >>>> >>>> That was the behaviour before I converted the code, the one that you >>>> referred to. I had assumed the code was correct, and _none_ of the >>>> speed, duplex, nor link state was propagated from the serdes PCS to >>>> the port on the 88E6390 - hence why the code you refer to existed. >>>> >>> Russell, you are right. >>> SFP on 88E6390 does not work with this patch applied. >>> So this patch breaks 88E6390. >> Thanks for testing. It sounds like maybe if I make >> mv88e6xxx_port_ppu_updates() return true for the 6097 in serdes mode I >> can avoid the forced link up without affecting the 6390. > Another option would be to make mv88e6xxx_mac_link_up() call a > switch specific implementation function, which is probably way > cleaner than introducing conditionals on the switch type in > functions, and reflects the existing code structure. I've spent most of the day plumbing in the serdes interrupts. And while I have that working I think even with interrupts I still have the problem that on the 88E6097 and similar there is no separation of PCS from the MAC so I'd have to do something like this anyway. So I'll probably look at making the body of mv88e6xxx_mac_link_up a switch specific function.
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c index f0dbc05e30a4..1ef392ee52c5 100644 --- a/drivers/net/dsa/mv88e6xxx/chip.c +++ b/drivers/net/dsa/mv88e6xxx/chip.c @@ -767,8 +767,11 @@ static void mv88e6xxx_mac_link_up(struct dsa_switch *ds, int port, goto error; } - if (ops->port_set_link) - err = ops->port_set_link(chip, port, LINK_FORCED_UP); + if (ops->port_set_link) { + int link = mode == MLO_AN_INBAND ? LINK_UNFORCED : LINK_FORCED_UP; + + err = ops->port_set_link(chip, port, link); + } } error: mv88e6xxx_reg_unlock(chip);