| Message ID | 20220213003702.2440875-1-tobias@waldekranz.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net-next] net: dsa: mv88e6xxx: Fix validation of built-in PHYs on 6095/6097 | expand |
Hi, Thanks for spotting this. Some comments below. On Sun, Feb 13, 2022 at 01:37:01AM +0100, Tobias Waldekranz wrote: > +static void mv88e6095_phylink_get_caps(struct mv88e6xxx_chip *chip, int port, > + struct phylink_config *config) > +{ > + u8 cmode = chip->ports[port].cmode; > + > + config->mac_capabilities = MAC_SYM_PAUSE | MAC_10 | MAC_100; > + > + if (mv88e6xxx_phy_is_internal(chip->ds, port)) { > + if (cmode == MV88E6185_PORT_STS_CMODE_PHY) > + __set_bit(PHY_INTERFACE_MODE_MII, > + config->supported_interfaces); Hmm. First, note that with mv88e6xxx_get_caps(), you'll end up with both MII and GMII here. GMII is necessary as that's the phylib default if no one specifies anything different in the firmware description. I assume you've noticed a problem because you specify MII for the internal ports in firmware? I'm wondering what the point of checking the cmode here is - if the port is internal, won't this switch always have cmode == PHY?
On Sun, Feb 13, 2022 at 12:58, "Russell King (Oracle)" <linux@armlinux.org.uk> wrote: > Hi, > > Thanks for spotting this. Some comments below. > > On Sun, Feb 13, 2022 at 01:37:01AM +0100, Tobias Waldekranz wrote: >> +static void mv88e6095_phylink_get_caps(struct mv88e6xxx_chip *chip, int port, >> + struct phylink_config *config) >> +{ >> + u8 cmode = chip->ports[port].cmode; >> + >> + config->mac_capabilities = MAC_SYM_PAUSE | MAC_10 | MAC_100; >> + >> + if (mv88e6xxx_phy_is_internal(chip->ds, port)) { >> + if (cmode == MV88E6185_PORT_STS_CMODE_PHY) >> + __set_bit(PHY_INTERFACE_MODE_MII, >> + config->supported_interfaces); > > Hmm. First, note that with mv88e6xxx_get_caps(), you'll end up with both > MII and GMII here. GMII is necessary as that's the phylib default if no I did notice that. > one specifies anything different in the firmware description. I assume > you've noticed a problem because you specify MII for the internal ports > in firmware? Precisely. > I'm wondering what the point of checking the cmode here is - if the port > is internal, won't this switch always have cmode == PHY? For all intents and purposes: I think so. It is just that the functional spec. also lists cmode == 4 == disabled (PHYDetect == 0) for the internal ports. So I figured that there might be some way of strapping ports as disabled that I had never come across. Do you think we should drop it?
On Sun, Feb 13, 2022 at 04:32:51PM +0100, Tobias Waldekranz wrote: > On Sun, Feb 13, 2022 at 12:58, "Russell King (Oracle)" <linux@armlinux.org.uk> wrote: > > I'm wondering what the point of checking the cmode here is - if the port > > is internal, won't this switch always have cmode == PHY? > > For all intents and purposes: I think so. It is just that the functional > spec. also lists cmode == 4 == disabled (PHYDetect == 0) for the > internal ports. So I figured that there might be some way of strapping > ports as disabled that I had never come across. I don't think there is a way to pinstrap the internal ports. As far as I can see, the only way would be for software to program PHY Detect to zero. If we wanted a port to be disabled, then describing it in firmware as being enabled would be a bug. If it isn't described in firmware, the DSA code won't even consider looking at the port. > Do you think we should drop it? I think so. Thanks.
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c index 85527fe4fcc8..622b3b4ed513 100644 --- a/drivers/net/dsa/mv88e6xxx/chip.c +++ b/drivers/net/dsa/mv88e6xxx/chip.c @@ -580,6 +580,27 @@ static const u8 mv88e6185_phy_interface_modes[] = { [MV88E6185_PORT_STS_CMODE_PHY] = PHY_INTERFACE_MODE_SGMII, }; +static void mv88e6095_phylink_get_caps(struct mv88e6xxx_chip *chip, int port, + struct phylink_config *config) +{ + u8 cmode = chip->ports[port].cmode; + + config->mac_capabilities = MAC_SYM_PAUSE | MAC_10 | MAC_100; + + if (mv88e6xxx_phy_is_internal(chip->ds, port)) { + if (cmode == MV88E6185_PORT_STS_CMODE_PHY) + __set_bit(PHY_INTERFACE_MODE_MII, + config->supported_interfaces); + } else { + if (cmode < ARRAY_SIZE(mv88e6185_phy_interface_modes) && + mv88e6185_phy_interface_modes[cmode]) + __set_bit(mv88e6185_phy_interface_modes[cmode], + config->supported_interfaces); + + config->mac_capabilities |= MAC_1000FD; + } +} + static void mv88e6185_phylink_get_caps(struct mv88e6xxx_chip *chip, int port, struct phylink_config *config) { @@ -3803,7 +3824,7 @@ static const struct mv88e6xxx_ops mv88e6095_ops = { .reset = mv88e6185_g1_reset, .vtu_getnext = mv88e6185_g1_vtu_getnext, .vtu_loadpurge = mv88e6185_g1_vtu_loadpurge, - .phylink_get_caps = mv88e6185_phylink_get_caps, + .phylink_get_caps = mv88e6095_phylink_get_caps, .set_max_frame_size = mv88e6185_g1_set_max_frame_size, }; @@ -3850,7 +3871,7 @@ static const struct mv88e6xxx_ops mv88e6097_ops = { .rmu_disable = mv88e6085_g1_rmu_disable, .vtu_getnext = mv88e6352_g1_vtu_getnext, .vtu_loadpurge = mv88e6352_g1_vtu_loadpurge, - .phylink_get_caps = mv88e6185_phylink_get_caps, + .phylink_get_caps = mv88e6095_phylink_get_caps, .set_max_frame_size = mv88e6185_g1_set_max_frame_size, };
These chips have 8 built-in FE PHYs and 3 SERDES interfaces that can run at 1G. With the blamed commit, the built-in PHYs could no longer be connected to, using an MII PHY interface mode. Create a separate .phylink_get_caps callback for these chips, which takes the FE/GE split into consideration. Fixes: 2ee84cfefb1e ("net: dsa: mv88e6xxx: convert to phylink_generic_validate()") Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> --- drivers/net/dsa/mv88e6xxx/chip.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-)