[PATCH 2/2] dsa: mv88e6131: support fixed PHYs

Statically setup the PCS Control on the MAC to match the fixed PHY.

Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
---
 drivers/net/dsa/mv88e6131.c | 43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
index eadb27c..d2b2fcf 100644
--- a/drivers/net/dsa/mv88e6131.c
+++ b/drivers/net/dsa/mv88e6131.c

@@ -337,6 +337,48 @@ mv88e6131_phy_write(struct dsa_switch *ds,
 	return mv88e6xxx_phy_write_ppu(ds, addr, regnum, val);
 }
 
+static void mv88e6131_adjust_link(struct dsa_switch *ds, int port,
+				  struct phy_device *phy)
+{
+	u16 pcs_ctrl;
+
+	/* PPU will configure MACs with physical PHYs */
+	if (!fixed_phy_get_status(phy))
+		return;
+
+	pcs_ctrl = mv88e6xxx_reg_read(ds, REG_PORT(port), 1);
+
+	/* clear all forced settings */
+	pcs_ctrl &= ~0xff;
+	pcs_ctrl |= BIT(2) | BIT(4) | BIT(6);
+
+	switch (phy->speed) {
+	case 10:
+		break;
+	case 100:
+		pcs_ctrl |= BIT(0);
+		break;
+	case 1000:
+		pcs_ctrl |= BIT(1);
+		break;
+
+	default:
+		netdev_err(ds->ports[port], "unsupported speed: %d\n", phy->speed);
+	}
+
+	if (phy->duplex)
+		pcs_ctrl |= BIT(3);
+
+	if (phy->link)
+		pcs_ctrl |= BIT(5);
+
+	if (phy->pause)
+		pcs_ctrl |= BIT(7);
+
+	mv88e6xxx_reg_write(ds, REG_PORT(port), 1, pcs_ctrl);
+	return;
+}
+
 static struct mv88e6xxx_hw_stat mv88e6131_hw_stats[] = {
 	{ "in_good_octets", 8, 0x00, },
 	{ "in_bad_octets", 4, 0x02, },

@@ -398,6 +440,7 @@ struct dsa_switch_driver mv88e6131_switch_driver = {
 	.set_addr		= mv88e6xxx_set_addr_direct,
 	.phy_read		= mv88e6131_phy_read,
 	.phy_write		= mv88e6131_phy_write,
+	.adjust_link		= mv88e6131_adjust_link,
 	.poll_link		= mv88e6xxx_poll_link,
 	.get_strings		= mv88e6131_get_strings,
 	.get_ethtool_stats	= mv88e6131_get_ethtool_stats,

-- 
1.8.4.357.g8d83871.dirty

2015-02-12 6:13 GMT-08:00 Tobias Waldekranz [off-list ref]:

Statically setup the PCS Control on the MAC to match the fixed PHY.

bcm_sf2 supports both fixed PHYs and regular PHYs, yet we do not need
to get access to the fixed PHY status from the adjust_link callback
because you could implement a separate fixed_link_update callback for
that purpose.

Did not that work for you?

33 more quoted lines

-- 
Florian

From: Tobias Waldekranz <tobias@waldekranz.com>
Date: Thu, 12 Feb 2015 15:13:17 +0100

Statically setup the PCS Control on the MAC to match the fixed PHY.

Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>

 ...

I kind of agree with Florian that you probably don't need this.

And furthermore, this fixed_phy_get_status() interface you created
isn't even used for what it's designed for.

As coded, fixed_phy_get_status() returns the link status structure,
but here you are only interested in whether a phy is fixed or not
because you're simply making a boolean test upon whether you were
given a non-NULL fixed phy status or not.

On Thu, Feb 12, 2015 at 08:13:28AM -0800, Florian Fainelli wrote:

2015-02-12 6:13 GMT-08:00 Tobias Waldekranz [off-list ref]:

quoted

Statically setup the PCS Control on the MAC to match the fixed PHY.

bcm_sf2 supports both fixed PHYs and regular PHYs, yet we do not need
to get access to the fixed PHY status from the adjust_link callback
because you could implement a separate fixed_link_update callback for
that purpose.

Did not that work for you?

That was my first approach and it worked fine. The only issue I saw
was that the callback was continously called at each poll cycle even
though the link state had not changed.

So then I implemented the same check for updates that was in the
regular adjust_link callback. But before I submitted that version of
the patch I looked att the sf2 code, and it seemed as though this code
uses the callback to update the phy status based on the chip state and
not the other way around. Did I misunderstand the code?

Not wanting to break your code, I went with this approach instead. But
if you're fine with it, I'm more than happy to go with that version.

-- 
Thanks
 - wkz

2015-02-21 2:30 GMT-08:00 Tobias Waldekranz [off-list ref]:

On Thu, Feb 12, 2015 at 08:13:28AM -0800, Florian Fainelli wrote:

quoted

2015-02-12 6:13 GMT-08:00 Tobias Waldekranz [off-list ref]:

quoted

Statically setup the PCS Control on the MAC to match the fixed PHY.

bcm_sf2 supports both fixed PHYs and regular PHYs, yet we do not need
to get access to the fixed PHY status from the adjust_link callback
because you could implement a separate fixed_link_update callback for
that purpose.

Did not that work for you?

That was my first approach and it worked fine. The only issue I saw
was that the callback was continously called at each poll cycle even
though the link state had not changed.

Right, we poll using this callback fairly often. Just like the PHY
libraries adjust_link, drivers are responsible for implementing
"caching" and avoiding the callback to be invoked too frequently.

So then I implemented the same check for updates that was in the
regular adjust_link callback. But before I submitted that version of
the patch I looked att the sf2 code, and it seemed as though this code
uses the callback to update the phy status based on the chip state and
not the other way around. Did I misunderstand the code?

It is a two step process:

- fixed_link_update updates the fixed PHY's status member to reflect
the HW changes (link change mostly), updates the PHY device
speed/duplex/pause parameters

- adjust_link reads the PHY device speed/duplex/pause and applies
these to the HW registers

Not wanting to break your code, I went with this approach instead. But
if you're fine with it, I'm more than happy to go with that version.

I think it is a little cleaner since the adjust_link callback does not
need to know what kind of PHY device it is dealing with, while the
fixed_link_update() one only takes care of fixed PHYs.

Thanks
-- 
Florian

On Sat, Feb 21, 2015 at 10:56:25AM -0800, Florian Fainelli wrote:

2015-02-21 2:30 GMT-08:00 Tobias Waldekranz [off-list ref]:

quoted

On Thu, Feb 12, 2015 at 08:13:28AM -0800, Florian Fainelli wrote:

quoted

2015-02-12 6:13 GMT-08:00 Tobias Waldekranz [off-list ref]:

quoted

Statically setup the PCS Control on the MAC to match the fixed PHY.

bcm_sf2 supports both fixed PHYs and regular PHYs, yet we do not need
to get access to the fixed PHY status from the adjust_link callback
because you could implement a separate fixed_link_update callback for
that purpose.

Did not that work for you?

That was my first approach and it worked fine. The only issue I saw
was that the callback was continously called at each poll cycle even
though the link state had not changed.

Right, we poll using this callback fairly often. Just like the PHY
libraries adjust_link, drivers are responsible for implementing
"caching" and avoiding the callback to be invoked too frequently.

quoted

So then I implemented the same check for updates that was in the
regular adjust_link callback. But before I submitted that version of
the patch I looked att the sf2 code, and it seemed as though this code
uses the callback to update the phy status based on the chip state and
not the other way around. Did I misunderstand the code?

It is a two step process:

- fixed_link_update updates the fixed PHY's status member to reflect
the HW changes (link change mostly), updates the PHY device
speed/duplex/pause parameters

- adjust_link reads the PHY device speed/duplex/pause and applies
these to the HW registers

Right, in my case I just need to do an initial config according to the
fixed settings which are read from the device-tree.

In the case where there is a real PHY attached to the switch, an
internal machine will poll the PHY and setup the MAC accordingly. So
HW will take care of step 2 for me.

quoted

Not wanting to break your code, I went with this approach instead. But
if you're fine with it, I'm more than happy to go with that version.

I think it is a little cleaner since the adjust_link callback does not
need to know what kind of PHY device it is dealing with, while the
fixed_link_update() one only takes care of fixed PHYs.

In my case I do need to know, since I want the switch's phy polling
unit to do the work when possible. Maybe I should just rethink the
whole thing and do the setup at probe-time using some other method.

I will get back to you with a better solution :)

Thanks
-- 
Florian

-- 
Thanks
 - wkz

On 23/02/15 03:13, Tobias Waldekranz wrote:

On Sat, Feb 21, 2015 at 10:56:25AM -0800, Florian Fainelli wrote:

quoted

2015-02-21 2:30 GMT-08:00 Tobias Waldekranz [off-list ref]:

quoted

On Thu, Feb 12, 2015 at 08:13:28AM -0800, Florian Fainelli wrote:

quoted

2015-02-12 6:13 GMT-08:00 Tobias Waldekranz [off-list ref]:

quoted

Statically setup the PCS Control on the MAC to match the fixed PHY.

bcm_sf2 supports both fixed PHYs and regular PHYs, yet we do not need
to get access to the fixed PHY status from the adjust_link callback
because you could implement a separate fixed_link_update callback for
that purpose.

Did not that work for you?

That was my first approach and it worked fine. The only issue I saw
was that the callback was continously called at each poll cycle even
though the link state had not changed.

Right, we poll using this callback fairly often. Just like the PHY
libraries adjust_link, drivers are responsible for implementing
"caching" and avoiding the callback to be invoked too frequently.

quoted

So then I implemented the same check for updates that was in the
regular adjust_link callback. But before I submitted that version of
the patch I looked att the sf2 code, and it seemed as though this code
uses the callback to update the phy status based on the chip state and
not the other way around. Did I misunderstand the code?

It is a two step process:

- fixed_link_update updates the fixed PHY's status member to reflect
the HW changes (link change mostly), updates the PHY device
speed/duplex/pause parameters

- adjust_link reads the PHY device speed/duplex/pause and applies
these to the HW registers

Right, in my case I just need to do an initial config according to the
fixed settings which are read from the device-tree.

4 more quoted lines

Even if this is not a real PHY device, but e.g: a MAC-to-MAC type of
connection? Does the PHY PPU rely on being able to issue MDIO accesses?

quoted

quoted

Not wanting to break your code, I went with this approach instead. But
if you're fine with it, I'm more than happy to go with that version.

I think it is a little cleaner since the adjust_link callback does not
need to know what kind of PHY device it is dealing with, while the
fixed_link_update() one only takes care of fixed PHYs.

In my case I do need to know, since I want the switch's phy polling
unit to do the work when possible. Maybe I should just rethink the
whole thing and do the setup at probe-time using some other method.

You could do that, but it might be a little cumbersome, something
simpler could be just to have an initialization flag that ensures that
both of these callbacks run for at least once, and then do nothing?

I will get back to you with a better solution :)

quoted

Thanks
-- 
Florian

-- 
Florian