[PATCH v3 0/3] net: dsa: mv88e6xxx: serdes link without phy

[PATCH v3 0/3] net: dsa: mv88e6xxx: serdes link without phy

[Chris Packham]

This small series gets my hardware into a working state. The key points are to
make sure we don't force the link and that we ask the MAC for the link status.
I also have updated my dts to say `phy-mode = "1000base-x";` and `managed =
"in-band-status";`

I've included patch #3 in this series but I don't have anything to test it on.
It's just a guess based on the datasheets. I'd suggest applying patch 1 & 2
and leaving 3 for the mailing list archives.

Chris Packham (3):
  net: dsa: mv88e6xxx: Don't force link when using in-band-status
  net: dsa: mv88e6xxx: Support serdes ports on MV88E6097/6095/6185
  net: dsa: mv88e6xxx: Support serdes ports on MV88E6123/6131

 drivers/net/dsa/mv88e6xxx/chip.c   |  26 ++++++-
 drivers/net/dsa/mv88e6xxx/serdes.c | 106 +++++++++++++++++++++++++++++
 drivers/net/dsa/mv88e6xxx/serdes.h |   9 +++
 3 files changed, 139 insertions(+), 2 deletions(-)

-- 
2.28.0

[PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status

[Chris Packham]

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>
---
Changes in v3:
- None
Changes in v2:
- Add review from Andrew

 drivers/net/dsa/mv88e6xxx/chip.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

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);
-- 
2.28.0

Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status

[Russell King - ARM Linux admin]

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?

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

Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status

[Marek Behun]

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?

Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status

[Andrew Lunn]

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

Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status

[Russell King - ARM Linux admin]

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.

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

Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status

[Marek Behun]

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

Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status

[Andrew Lunn]

> > 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

Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status

[Chris Packham]

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?

Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status

[Andrew Lunn]

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

Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status

[Chris Packham]

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.

Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status

[Russell King - ARM Linux admin]

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.

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

Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status

[Chris Packham]

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.

[PATCH v3 2/3] net: dsa: mv88e6xxx: Support serdes ports on MV88E6097/6095/6185

[Chris Packham]

Implement serdes_power, serdes_get_lane and serdes_pcs_get_state ops for
the MV88E6097/6095/6185 so that ports 8 & 9 can be supported as serdes
ports and directly connected to other network interfaces or to SFPs
without a PHY.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
Changes in v3:
- Add comment to mv88e6185_serdes_get_lane
- Add review from Andrew
Changes in v2:
- expand support to cover 6095 and 6185
- move serdes related code to serdes.c

 drivers/net/dsa/mv88e6xxx/chip.c   |  9 +++++
 drivers/net/dsa/mv88e6xxx/serdes.c | 62 ++++++++++++++++++++++++++++++
 drivers/net/dsa/mv88e6xxx/serdes.h |  5 +++
 3 files changed, 76 insertions(+)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 1ef392ee52c5..62d4d7b5d9ac 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3496,6 +3496,9 @@ static const struct mv88e6xxx_ops mv88e6095_ops = {
 	.stats_get_strings = mv88e6095_stats_get_strings,
 	.stats_get_stats = mv88e6095_stats_get_stats,
 	.mgmt_rsvd2cpu = mv88e6185_g2_mgmt_rsvd2cpu,
+	.serdes_power = mv88e6185_serdes_power,
+	.serdes_get_lane = mv88e6185_serdes_get_lane,
+	.serdes_pcs_get_state = mv88e6185_serdes_pcs_get_state,
 	.ppu_enable = mv88e6185_g1_ppu_enable,
 	.ppu_disable = mv88e6185_g1_ppu_disable,
 	.reset = mv88e6185_g1_reset,
@@ -3534,6 +3537,9 @@ static const struct mv88e6xxx_ops mv88e6097_ops = {
 	.set_egress_port = mv88e6095_g1_set_egress_port,
 	.watchdog_ops = &mv88e6097_watchdog_ops,
 	.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
+	.serdes_power = mv88e6185_serdes_power,
+	.serdes_get_lane = mv88e6185_serdes_get_lane,
+	.serdes_pcs_get_state = mv88e6185_serdes_pcs_get_state,
 	.pot_clear = mv88e6xxx_g2_pot_clear,
 	.reset = mv88e6352_g1_reset,
 	.rmu_disable = mv88e6085_g1_rmu_disable,
@@ -3958,6 +3964,9 @@ static const struct mv88e6xxx_ops mv88e6185_ops = {
 	.set_egress_port = mv88e6095_g1_set_egress_port,
 	.watchdog_ops = &mv88e6097_watchdog_ops,
 	.mgmt_rsvd2cpu = mv88e6185_g2_mgmt_rsvd2cpu,
+	.serdes_power = mv88e6185_serdes_power,
+	.serdes_get_lane = mv88e6185_serdes_get_lane,
+	.serdes_pcs_get_state = mv88e6185_serdes_pcs_get_state,
 	.set_cascade_port = mv88e6185_g1_set_cascade_port,
 	.ppu_enable = mv88e6185_g1_ppu_enable,
 	.ppu_disable = mv88e6185_g1_ppu_disable,
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c b/drivers/net/dsa/mv88e6xxx/serdes.c
index 9c07b4f3d345..d4f40a739b17 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.c
+++ b/drivers/net/dsa/mv88e6xxx/serdes.c
@@ -428,6 +428,68 @@ u8 mv88e6341_serdes_get_lane(struct mv88e6xxx_chip *chip, int port)
 	return lane;
 }
 
+int mv88e6185_serdes_power(struct mv88e6xxx_chip *chip, int port, u8 lane,
+			   bool up)
+{
+	/* The serdes power can't be controlled on this switch chip but we need
+	 * to supply this function to avoid returning -EOPNOTSUPP in
+	 * mv88e6xxx_serdes_power_up/mv88e6xxx_serdes_power_down
+	 */
+	return 0;
+}
+
+u8 mv88e6185_serdes_get_lane(struct mv88e6xxx_chip *chip, int port)
+{
+	/* There are no configurable serdes lanes on this switch chip but we
+	 * need to return non-zero so that callers of
+	 * mv88e6xxx_serdes_get_lane() know this is a serdes port.
+	 */
+	switch (chip->ports[port].cmode) {
+	case MV88E6185_PORT_STS_CMODE_SERDES:
+	case MV88E6185_PORT_STS_CMODE_1000BASE_X:
+		return 0xff;
+	default:
+		return 0;
+	}
+}
+
+int mv88e6185_serdes_pcs_get_state(struct mv88e6xxx_chip *chip, int port,
+				   u8 lane, struct phylink_link_state *state)
+{
+	int err;
+	u16 status;
+
+	err = mv88e6xxx_port_read(chip, port, MV88E6XXX_PORT_STS, &status);
+	if (err)
+		return err;
+
+	state->link = !!(status & MV88E6XXX_PORT_STS_LINK);
+
+	if (state->link) {
+		state->duplex = status & MV88E6XXX_PORT_STS_DUPLEX ? DUPLEX_FULL : DUPLEX_HALF;
+
+		switch (status &  MV88E6XXX_PORT_STS_SPEED_MASK) {
+		case MV88E6XXX_PORT_STS_SPEED_1000:
+			state->speed = SPEED_1000;
+			break;
+		case MV88E6XXX_PORT_STS_SPEED_100:
+			state->speed = SPEED_100;
+			break;
+		case MV88E6XXX_PORT_STS_SPEED_10:
+			state->speed = SPEED_10;
+			break;
+		default:
+			dev_err(chip->dev, "invalid PHY speed\n");
+			return -EINVAL;
+		}
+	} else {
+		state->duplex = DUPLEX_UNKNOWN;
+		state->speed = SPEED_UNKNOWN;
+	}
+
+	return 0;
+}
+
 u8 mv88e6390_serdes_get_lane(struct mv88e6xxx_chip *chip, int port)
 {
 	u8 cmode = chip->ports[port].cmode;
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.h b/drivers/net/dsa/mv88e6xxx/serdes.h
index 14315f26228a..c24ec4122c9e 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.h
+++ b/drivers/net/dsa/mv88e6xxx/serdes.h
@@ -73,6 +73,7 @@
 #define MV88E6390_PG_CONTROL		0xf010
 #define MV88E6390_PG_CONTROL_ENABLE_PC		BIT(0)
 
+u8 mv88e6185_serdes_get_lane(struct mv88e6xxx_chip *chip, int port);
 u8 mv88e6341_serdes_get_lane(struct mv88e6xxx_chip *chip, int port);
 u8 mv88e6352_serdes_get_lane(struct mv88e6xxx_chip *chip, int port);
 u8 mv88e6390_serdes_get_lane(struct mv88e6xxx_chip *chip, int port);
@@ -85,6 +86,8 @@ int mv88e6390_serdes_pcs_config(struct mv88e6xxx_chip *chip, int port,
 				u8 lane, unsigned int mode,
 				phy_interface_t interface,
 				const unsigned long *advertise);
+int mv88e6185_serdes_pcs_get_state(struct mv88e6xxx_chip *chip, int port,
+				   u8 lane, struct phylink_link_state *state);
 int mv88e6352_serdes_pcs_get_state(struct mv88e6xxx_chip *chip, int port,
 				   u8 lane, struct phylink_link_state *state);
 int mv88e6390_serdes_pcs_get_state(struct mv88e6xxx_chip *chip, int port,
@@ -101,6 +104,8 @@ unsigned int mv88e6352_serdes_irq_mapping(struct mv88e6xxx_chip *chip,
 					  int port);
 unsigned int mv88e6390_serdes_irq_mapping(struct mv88e6xxx_chip *chip,
 					  int port);
+int mv88e6185_serdes_power(struct mv88e6xxx_chip *chip, int port, u8 lane,
+			   bool up);
 int mv88e6352_serdes_power(struct mv88e6xxx_chip *chip, int port, u8 lane,
 			   bool on);
 int mv88e6390_serdes_power(struct mv88e6xxx_chip *chip, int port, u8 lane,
-- 
2.28.0

[PATCH v3 3/3] net: dsa: mv88e6xxx: Support serdes ports on MV88E6123/6131

[Chris Packham]

Implement serdes_power, serdes_get_lane and serdes_pcs_get_state ops for
the MV88E6123 so that the ports without a built-in PHY supported as
serdes ports and directly connected to other network interfaces or to
SFPs. Also implement serdes_get_regs_len and serdes_get_regs to aid
future debugging.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---

This is untested (apart from compilation) it assumes the SERDES "phy"
address corresponds to the port number but I'm not confident that is a
valid assumption.

Changes in v3:
- None
Changes in v2:
- new

 drivers/net/dsa/mv88e6xxx/chip.c   | 10 +++++++
 drivers/net/dsa/mv88e6xxx/serdes.c | 44 ++++++++++++++++++++++++++++++
 drivers/net/dsa/mv88e6xxx/serdes.h |  4 +++
 3 files changed, 58 insertions(+)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 62d4d7b5d9ac..5344fc84b03e 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3574,6 +3574,11 @@ static const struct mv88e6xxx_ops mv88e6123_ops = {
 	.set_egress_port = mv88e6095_g1_set_egress_port,
 	.watchdog_ops = &mv88e6097_watchdog_ops,
 	.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
+	.serdes_power = mv88e6123_serdes_power,
+	.serdes_get_lane = mv88e6185_serdes_get_lane,
+	.serdes_pcs_get_state = mv88e6185_serdes_pcs_get_state,
+	.serdes_get_regs_len = mv88e6123_serdes_get_regs_len,
+	.serdes_get_regs = mv88e6123_serdes_get_regs,
 	.pot_clear = mv88e6xxx_g2_pot_clear,
 	.reset = mv88e6352_g1_reset,
 	.atu_get_hash = mv88e6165_g1_atu_get_hash,
@@ -3613,6 +3618,11 @@ static const struct mv88e6xxx_ops mv88e6131_ops = {
 	.set_egress_port = mv88e6095_g1_set_egress_port,
 	.watchdog_ops = &mv88e6097_watchdog_ops,
 	.mgmt_rsvd2cpu = mv88e6185_g2_mgmt_rsvd2cpu,
+	.serdes_power = mv88e6123_serdes_power,
+	.serdes_get_lane = mv88e6185_serdes_get_lane,
+	.serdes_pcs_get_state = mv88e6185_serdes_pcs_get_state,
+	.serdes_get_regs_len = mv88e6123_serdes_get_regs_len,
+	.serdes_get_regs = mv88e6123_serdes_get_regs,
 	.ppu_enable = mv88e6185_g1_ppu_enable,
 	.set_cascade_port = mv88e6185_g1_set_cascade_port,
 	.ppu_disable = mv88e6185_g1_ppu_disable,
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c b/drivers/net/dsa/mv88e6xxx/serdes.c
index d4f40a739b17..eb89debbf576 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.c
+++ b/drivers/net/dsa/mv88e6xxx/serdes.c
@@ -428,6 +428,50 @@ u8 mv88e6341_serdes_get_lane(struct mv88e6xxx_chip *chip, int port)
 	return lane;
 }
 
+int mv88e6123_serdes_power(struct mv88e6xxx_chip *chip, int port, u8 lane,
+			   bool up)
+{
+	u16 val, new_val;
+	int err;
+
+	err = mv88e6xxx_phy_read(chip, port, MII_BMCR, &val);
+	if (err)
+		return err;
+
+	if (up)
+		new_val = val & ~BMCR_PDOWN;
+	else
+		new_val = val | BMCR_PDOWN;
+
+	if (val != new_val)
+		err = mv88e6xxx_phy_write(chip, port, MII_BMCR, val);
+
+	return err;
+}
+
+int mv88e6123_serdes_get_regs_len(struct mv88e6xxx_chip *chip, int port)
+{
+	if (mv88e6xxx_serdes_get_lane(chip, port) == 0)
+		return 0;
+
+	return 26 * sizeof(u16);
+}
+
+void mv88e6123_serdes_get_regs(struct mv88e6xxx_chip *chip, int port, void *_p)
+{
+	u16 *p = _p;
+	u16 reg;
+	int i;
+
+	if (mv88e6xxx_serdes_get_lane(chip, port) == 0)
+		return;
+
+	for (i = 0; i < 26; i++) {
+		mv88e6xxx_phy_read(chip, port, i, &reg);
+		p[i] = reg;
+	}
+}
+
 int mv88e6185_serdes_power(struct mv88e6xxx_chip *chip, int port, u8 lane,
 			   bool up)
 {
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.h b/drivers/net/dsa/mv88e6xxx/serdes.h
index c24ec4122c9e..b573139928c4 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.h
+++ b/drivers/net/dsa/mv88e6xxx/serdes.h
@@ -104,6 +104,8 @@ unsigned int mv88e6352_serdes_irq_mapping(struct mv88e6xxx_chip *chip,
 					  int port);
 unsigned int mv88e6390_serdes_irq_mapping(struct mv88e6xxx_chip *chip,
 					  int port);
+int mv88e6123_serdes_power(struct mv88e6xxx_chip *chip, int port, u8 lane,
+			   bool up);
 int mv88e6185_serdes_power(struct mv88e6xxx_chip *chip, int port, u8 lane,
 			   bool up);
 int mv88e6352_serdes_power(struct mv88e6xxx_chip *chip, int port, u8 lane,
@@ -129,6 +131,8 @@ int mv88e6390_serdes_get_strings(struct mv88e6xxx_chip *chip,
 int mv88e6390_serdes_get_stats(struct mv88e6xxx_chip *chip, int port,
 			       uint64_t *data);
 
+int mv88e6123_serdes_get_regs_len(struct mv88e6xxx_chip *chip, int port);
+void mv88e6123_serdes_get_regs(struct mv88e6xxx_chip *chip, int port, void *_p);
 int mv88e6352_serdes_get_regs_len(struct mv88e6xxx_chip *chip, int port);
 void mv88e6352_serdes_get_regs(struct mv88e6xxx_chip *chip, int port, void *_p);
 int mv88e6390_serdes_get_regs_len(struct mv88e6xxx_chip *chip, int port);
-- 
2.28.0

Re: [PATCH v3 3/3] net: dsa: mv88e6xxx: Support serdes ports on MV88E6123/6131

[Russell King - ARM Linux admin]

On Tue, Oct 20, 2020 at 04:45:58PM +1300, Chris Packham wrote:
> +void mv88e6123_serdes_get_regs(struct mv88e6xxx_chip *chip, int port, void *_p)
> +{
> +	u16 *p = _p;
> +	u16 reg;
> +	int i;
> +
> +	if (mv88e6xxx_serdes_get_lane(chip, port) == 0)
> +		return;
> +
> +	for (i = 0; i < 26; i++) {
> +		mv88e6xxx_phy_read(chip, port, i, &reg);

Shouldn't this deal with a failed read in some way, rather than just
assigning the last or possibly uninitialised value to p[i] ?

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

Re: [PATCH v3 3/3] net: dsa: mv88e6xxx: Support serdes ports on MV88E6123/6131

[Chris Packham]

On 20/10/20 11:18 pm, Russell King - ARM Linux admin wrote:
> On Tue, Oct 20, 2020 at 04:45:58PM +1300, Chris Packham wrote:
>> +void mv88e6123_serdes_get_regs(struct mv88e6xxx_chip *chip, int port, void *_p)
>> +{
>> +	u16 *p = _p;
>> +	u16 reg;
>> +	int i;
>> +
>> +	if (mv88e6xxx_serdes_get_lane(chip, port) == 0)
>> +		return;
>> +
>> +	for (i = 0; i < 26; i++) {
>> +		mv88e6xxx_phy_read(chip, port, i, &reg);
> Shouldn't this deal with a failed read in some way, rather than just
> assigning the last or possibly uninitialised value to p[i] ?

mv88e6390_serdes_get_regs() and mv88e6352_serdes_get_regs() also ignore 
the error. The generic mv88e6xxx_get_regs() memsets p[] to 0xff so if 
the serdes_get_regs functions just left it alone we'd return 0xffff 
which is probably better than repeating the last value although it's 
still ambiguous because 0xffff is a valid value for plenty of these 
registers.

Since it looks like I need to come up with an alternative to patch #1 
I'll concentrate on that but making the serdes_get_regs() a little more 
error tolerant is a cleanup I can easily tack on onto this series.

Re: [PATCH v3 3/3] net: dsa: mv88e6xxx: Support serdes ports on MV88E6123/6131

[Russell King - ARM Linux admin]

On Tue, Oct 20, 2020 at 09:24:04PM +0000, Chris Packham wrote:
> 
> On 20/10/20 11:18 pm, Russell King - ARM Linux admin wrote:
> > On Tue, Oct 20, 2020 at 04:45:58PM +1300, Chris Packham wrote:
> >> +void mv88e6123_serdes_get_regs(struct mv88e6xxx_chip *chip, int port, void *_p)
> >> +{
> >> +	u16 *p = _p;
> >> +	u16 reg;
> >> +	int i;
> >> +
> >> +	if (mv88e6xxx_serdes_get_lane(chip, port) == 0)
> >> +		return;
> >> +
> >> +	for (i = 0; i < 26; i++) {
> >> +		mv88e6xxx_phy_read(chip, port, i, &reg);
> > Shouldn't this deal with a failed read in some way, rather than just
> > assigning the last or possibly uninitialised value to p[i] ?
> 
> mv88e6390_serdes_get_regs() and mv88e6352_serdes_get_regs() also ignore 
> the error. The generic mv88e6xxx_get_regs() memsets p[] to 0xff so if 
> the serdes_get_regs functions just left it alone we'd return 0xffff 
> which is probably better than repeating the last value although it's 
> still ambiguous because 0xffff is a valid value for plenty of these 
> registers.
> 
> Since it looks like I need to come up with an alternative to patch #1 
> I'll concentrate on that but making the serdes_get_regs() a little more 
> error tolerant is a cleanup I can easily tack on onto this series.

Yep, it looks like they all suffer the same problem. Interestingly,
mv88e6xxx_get_regs() does handle the error by avoiding writing the
register entry (so it gets left as 0xffff.)

Incidentally, that's also the value you'll get when reading from a
PHY that doesn't respond, since the MDIO data line is pulled high
when undriven.

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