Avoid having to define a PHY for every physical port when PHY addresses
are fixed, but port index != PHY address.
Signed-off-by: Matthias Schiffer <[email protected]>
---
include/net/dsa.h | 1 +
net/dsa/slave.c | 10 ++++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index aeb411e77b9a..8216f3687799 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -391,6 +391,7 @@ struct dsa_switch_ops {
int (*setup)(struct dsa_switch *ds);
void (*teardown)(struct dsa_switch *ds);
+ int (*get_phy_address)(struct dsa_switch *ds, int port);
u32 (*get_phy_flags)(struct dsa_switch *ds, int port);
/*
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 8ced165a7908..1c78f8cae9e9 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1546,7 +1546,7 @@ static int dsa_slave_phy_setup(struct net_device *slave_dev)
struct dsa_switch *ds = dp->ds;
phy_interface_t mode;
u32 phy_flags = 0;
- int ret;
+ int addr, ret;
ret = of_get_phy_mode(port_dn, &mode);
if (ret)
@@ -1578,7 +1578,13 @@ static int dsa_slave_phy_setup(struct net_device *slave_dev)
/* We could not connect to a designated PHY or SFP, so try to
* use the switch internal MDIO bus instead
*/
- ret = dsa_slave_phy_connect(slave_dev, dp->index);
+
+ if (ds->ops->get_phy_address)
+ addr = ds->ops->get_phy_address(ds, dp->index);
+ else
+ addr = dp->index;
+
+ ret = dsa_slave_phy_connect(slave_dev, addr);
if (ret) {
netdev_err(slave_dev,
"failed to connect to port %d: %d\n",
--
2.17.1
Avoid the need to specify a PHY for each physical port in the device tree
when phy_base_addr is not 0 (6250 and 6341 families).
This change should be backwards-compatible with existing device trees,
as it only adds sensible defaults where explicit definitions were
required before.
Signed-off-by: Matthias Schiffer <[email protected]>
---
drivers/net/dsa/mv88e6xxx/chip.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 221593261e8f..228c1b085b66 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -5379,6 +5379,13 @@ static enum dsa_tag_protocol mv88e6xxx_get_tag_protocol(struct dsa_switch *ds,
return chip->info->tag_protocol;
}
+static int mv88e6xxx_get_phy_address(struct dsa_switch *ds, int port)
+{
+ struct mv88e6xxx_chip *chip = ds->priv;
+
+ return chip->phy_base_addr + port;
+}
+
static int mv88e6xxx_port_mdb_prepare(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_mdb *mdb)
{
@@ -5509,6 +5516,7 @@ static const struct dsa_switch_ops mv88e6xxx_switch_ops = {
.get_tag_protocol = mv88e6xxx_get_tag_protocol,
.setup = mv88e6xxx_setup,
.teardown = mv88e6xxx_teardown,
+ .get_phy_address = mv88e6xxx_get_phy_address,
.phylink_validate = mv88e6xxx_validate,
.phylink_mac_link_state = mv88e6xxx_serdes_pcs_get_state,
.phylink_mac_config = mv88e6xxx_mac_config,
--
2.17.1
On 3/30/2020 6:53 AM, Matthias Schiffer wrote:
> Avoid having to define a PHY for every physical port when PHY addresses
> are fixed, but port index != PHY address.
>
> Signed-off-by: Matthias Schiffer <[email protected]>
You could do this much more elegantly by doing this with Device Tree and
specifying the built-in PHYs to be hanging off the switch's internal
MDIO bus and specifying the port to PHY address mapping, you would only
patch #4 then.
--
Florian
On Mon, 2020-03-30 at 20:04 -0700, Florian Fainelli wrote:
>
> On 3/30/2020 6:53 AM, Matthias Schiffer wrote:
> > Avoid having to define a PHY for every physical port when PHY
> > addresses
> > are fixed, but port index != PHY address.
> >
> > Signed-off-by: Matthias Schiffer <[email protected]
> > >
>
> You could do this much more elegantly by doing this with Device Tree
> and
> specifying the built-in PHYs to be hanging off the switch's internal
> MDIO bus and specifying the port to PHY address mapping, you would
> only
> patch #4 then.
This does work indeed, but it seems we have different ideas on
elegance.
I'm not happy about the fact that an implementor needs to study the
switch manual in great detail to find out about things like the PHY
address offsets when the driver could just to the right thing by
default. Requiring this only for some switch configurations, while
others work fine with the defaults, doesn't make this any less
confusing (I'd even argue that it would be better if there weren't any
default PHY and IRQ mappings for the switch ports, but I also
understand that this can't easily be removed at this point...)
In particular when PHY IRQ support is desired (not implemented on the
PHY driver side for this switch yet; not sure if my current project
will require it), indices are easy to get wrong - which might not be
noticed as long as there is no PHY driver with IRQ support for the port
PHYs, potentially breaking existing Device Trees with future kernel
updates. For this reason, I think at least patch #2 should be
considered even if #1 and #3 are rejected.
Kind regards,
Matthias
On Tue, 2020-03-31 at 11:09 +0200, Matthias Schiffer wrote:
> On Mon, 2020-03-30 at 20:04 -0700, Florian Fainelli wrote:
> >
> > On 3/30/2020 6:53 AM, Matthias Schiffer wrote:
> > > Avoid having to define a PHY for every physical port when PHY
> > > addresses
> > > are fixed, but port index != PHY address.
> > >
> > > Signed-off-by: Matthias Schiffer <
> > > [email protected]
> > > >
> >
> > You could do this much more elegantly by doing this with Device
> > Tree
> > and
> > specifying the built-in PHYs to be hanging off the switch's
> > internal
> > MDIO bus and specifying the port to PHY address mapping, you would
> > only
> > patch #4 then.
>
> This does work indeed, but it seems we have different ideas on
> elegance.
>
> I'm not happy about the fact that an implementor needs to study the
> switch manual in great detail to find out about things like the PHY
> address offsets when the driver could just to the right thing by
> default. Requiring this only for some switch configurations, while
> others work fine with the defaults, doesn't make this any less
> confusing (I'd even argue that it would be better if there weren't
> any
> default PHY and IRQ mappings for the switch ports, but I also
> understand that this can't easily be removed at this point...)
>
> In particular when PHY IRQ support is desired (not implemented on the
> PHY driver side for this switch yet; not sure if my current project
> will require it), indices are easy to get wrong - which might not be
> noticed as long as there is no PHY driver with IRQ support for the
> port
> PHYs, potentially breaking existing Device Trees with future kernel
> updates. For this reason, I think at least patch #2 should be
> considered even if #1 and #3 are rejected.
>
> Kind regards,
> Matthias
net-next is open again, and I'd like to come to a conclusion regarding
this patch series before I resend it (or parts of it).
It is my impression that a detailed configuration in the Device Tree is
most useful when the driver that it configures is very generic, so
different values are useful in practice.
The mv88e6xxx driver is not generic in this sense: It already lists
every single piece of supported hardware, often using completely
different code for different chips - which is already not configurable
in the Device Tree (and being able to wouldn't make much sense IMO).
Having the additional pieces of sane defaults in the driver that are
introduced by the patches 1..3 of this series avoids mistakes in the DT
configuration, for settings that never need to be modified for a given
switch model supported by mv88e6xxx.
Kind regards,
Matthias