| Message ID | 20210830155250.4029923-1-vladimir.oltean@nxp.com |
|---|---|
| Headers | show |
| Series | Let phylink manage in-band AN for the PHY | expand |
Can we postpone this after this merge window please, so I've got time to properly review this. Thanks. On Mon, Aug 30, 2021 at 06:52:45PM +0300, Vladimir Oltean wrote: > This small series creates a configuration knob for PHY drivers which use > serial MII-side interfaces and support clause 37 in-band auto-negotiation > there. > > Changes in v2: > Incorporated feedback from Russell, which was to consider PHYs on SFP > modules too, and unify phylink's detection of PHYs with broken in-band > autoneg with the newly introduced PHY driver methods. > https://patchwork.kernel.org/project/netdevbpf/cover/20210212172341.3489046-1-olteanv@gmail.com/ > > This change set is only superficially tested, hence the RFC tag. It does > what I need on the NXP boards with on-board PHYs that I have, and also > seems to behave the same as before when I use a 1G SGMII SFP module with > the Marvell 88E1111 PHY (the only thing I have). I do not have the > ability to test the Methode DM7052 SFP module for the bcm84881.c driver > change, since I don't have that. > > Posting the patch series mostly to figure out whether I understood the > change request correctly. > > Vladimir Oltean (5): > net: phylink: pass the phy argument to phylink_sfp_config > net: phylink: introduce a generic method for querying PHY in-band > autoneg capability > net: phy: bcm84881: move the in-band capability check where it belongs > net: phylink: explicitly configure in-band autoneg for PHYs that > support it > net: phy: mscc: configure in-band auto-negotiation for VSC8514 > > drivers/net/phy/bcm84881.c | 10 ++++ > drivers/net/phy/mscc/mscc.h | 2 + > drivers/net/phy/mscc/mscc_main.c | 20 +++++++ > drivers/net/phy/phy.c | 25 +++++++++ > drivers/net/phy/phylink.c | 93 +++++++++++++++++++++++++------- > include/linux/phy.h | 24 +++++++++ > 6 files changed, 154 insertions(+), 20 deletions(-) > > -- > 2.25.1 > >
On Mon, Aug 30, 2021 at 09:36:23PM +0300, Vladimir Oltean wrote: > On Mon, Aug 30, 2021 at 07:30:15PM +0100, Russell King (Oracle) wrote: > > Can we postpone this after this merge window please, so I've got time > > to properly review this. Thanks. > > Please review at your discretion, I've no intention to post a v3 right > now, and to the best of my knowledge, RFC's are not even considered for > direct inclusion in the git tree. Hello Russell, can you please review these patches if possible? I would like to repost them soon.
Am 2021-09-16 15:09, schrieb Vladimir Oltean: > On Mon, Aug 30, 2021 at 09:36:23PM +0300, Vladimir Oltean wrote: >> On Mon, Aug 30, 2021 at 07:30:15PM +0100, Russell King (Oracle) wrote: >> > Can we postpone this after this merge window please, so I've got time >> > to properly review this. Thanks. >> >> Please review at your discretion, I've no intention to post a v3 right >> now, and to the best of my knowledge, RFC's are not even considered >> for >> direct inclusion in the git tree. > > Hello Russell, can you please review these patches if possible? I > would like to repost them soon. I planned to test this on my board with the AR8031 (and add support there), but it seems I won't find time before my vacation, unfortunately. -michael
On Thu, Sep 16, 2021 at 03:51:28PM +0200, Michael Walle wrote: > Am 2021-09-16 15:09, schrieb Vladimir Oltean: > > On Mon, Aug 30, 2021 at 09:36:23PM +0300, Vladimir Oltean wrote: > > > On Mon, Aug 30, 2021 at 07:30:15PM +0100, Russell King (Oracle) wrote: > > > > Can we postpone this after this merge window please, so I've got time > > > > to properly review this. Thanks. > > > > > > Please review at your discretion, I've no intention to post a v3 right > > > now, and to the best of my knowledge, RFC's are not even considered > > > for > > > direct inclusion in the git tree. > > > > Hello Russell, can you please review these patches if possible? I > > would like to repost them soon. > > I planned to test this on my board with the AR8031 (and add support there), > but it seems I won't find time before my vacation, unfortunately. Oh, but there isn't any "support" to be added I though, your conclusion last time seemed to be that it only supported in-band autoneg ON? I was going to add a patch to implement .validate_inband_aneg for the at803x driver to mark that fact too, I just didn't do it in the RFC. That should also fix the ENETC ports on the LS1028A-RDB which were migrated to phylink while they didn't have the 'managed = "in-band-status"' OF property, and enable new kernels to still work with the old DT blob. Or were you thinking of something else?
Am 2021-09-16 15:54, schrieb Vladimir Oltean: > On Thu, Sep 16, 2021 at 03:51:28PM +0200, Michael Walle wrote: >> Am 2021-09-16 15:09, schrieb Vladimir Oltean: >> > On Mon, Aug 30, 2021 at 09:36:23PM +0300, Vladimir Oltean wrote: >> > > On Mon, Aug 30, 2021 at 07:30:15PM +0100, Russell King (Oracle) wrote: >> > > > Can we postpone this after this merge window please, so I've got time >> > > > to properly review this. Thanks. >> > > >> > > Please review at your discretion, I've no intention to post a v3 right >> > > now, and to the best of my knowledge, RFC's are not even considered >> > > for >> > > direct inclusion in the git tree. >> > >> > Hello Russell, can you please review these patches if possible? I >> > would like to repost them soon. >> >> I planned to test this on my board with the AR8031 (and add support >> there), >> but it seems I won't find time before my vacation, unfortunately. > > Oh, but there isn't any "support" to be added I though, your conclusion > last time seemed to be that it only supported in-band autoneg ON? > I was going to add a patch to implement .validate_inband_aneg for the > at803x driver to mark that fact too, I just didn't do it in the RFC. > That should also fix the ENETC ports on the LS1028A-RDB which were > migrated to phylink while they didn't have the 'managed = > "in-band-status"' > OF property, and enable new kernels to still work with the old DT blob. > Or were you thinking of something else? No, but I won't find time to test it within the next.. uhm, 30minutes until I call it a day ;) -michael
On Thu, Sep 16, 2021 at 04:05:20PM +0200, Michael Walle wrote: > Am 2021-09-16 15:54, schrieb Vladimir Oltean: > > On Thu, Sep 16, 2021 at 03:51:28PM +0200, Michael Walle wrote: > > > Am 2021-09-16 15:09, schrieb Vladimir Oltean: > > > > On Mon, Aug 30, 2021 at 09:36:23PM +0300, Vladimir Oltean wrote: > > > > > On Mon, Aug 30, 2021 at 07:30:15PM +0100, Russell King (Oracle) wrote: > > > > > > Can we postpone this after this merge window please, so I've got time > > > > > > to properly review this. Thanks. > > > > > > > > > > Please review at your discretion, I've no intention to post a v3 right > > > > > now, and to the best of my knowledge, RFC's are not even considered > > > > > for > > > > > direct inclusion in the git tree. > > > > > > > > Hello Russell, can you please review these patches if possible? I > > > > would like to repost them soon. > > > > > > I planned to test this on my board with the AR8031 (and add support > > > there), > > > but it seems I won't find time before my vacation, unfortunately. > > > > Oh, but there isn't any "support" to be added I though, your conclusion > > last time seemed to be that it only supported in-band autoneg ON? > > I was going to add a patch to implement .validate_inband_aneg for the > > at803x driver to mark that fact too, I just didn't do it in the RFC. > > That should also fix the ENETC ports on the LS1028A-RDB which were > > migrated to phylink while they didn't have the 'managed = > > "in-band-status"' > > OF property, and enable new kernels to still work with the old DT blob. > > Or were you thinking of something else? > > No, but I won't find time to test it within the next.. uhm, 30minutes > until I call it a day ;) Ok, if that is all, I can make sure on the NXP LS1028A-RDB that the Atheros PHYs are always presented to phylink drivers as MLO_AN_INBAND, never MLO_AN_PHY, and make sure that the enetc driver works in that configuration regardless of device tree description.
This small series creates a configuration knob for PHY drivers which use serial MII-side interfaces and support clause 37 in-band auto-negotiation there. Changes in v2: Incorporated feedback from Russell, which was to consider PHYs on SFP modules too, and unify phylink's detection of PHYs with broken in-band autoneg with the newly introduced PHY driver methods. https://patchwork.kernel.org/project/netdevbpf/cover/20210212172341.3489046-1-olteanv@gmail.com/ This change set is only superficially tested, hence the RFC tag. It does what I need on the NXP boards with on-board PHYs that I have, and also seems to behave the same as before when I use a 1G SGMII SFP module with the Marvell 88E1111 PHY (the only thing I have). I do not have the ability to test the Methode DM7052 SFP module for the bcm84881.c driver change, since I don't have that. Posting the patch series mostly to figure out whether I understood the change request correctly. Vladimir Oltean (5): net: phylink: pass the phy argument to phylink_sfp_config net: phylink: introduce a generic method for querying PHY in-band autoneg capability net: phy: bcm84881: move the in-band capability check where it belongs net: phylink: explicitly configure in-band autoneg for PHYs that support it net: phy: mscc: configure in-band auto-negotiation for VSC8514 drivers/net/phy/bcm84881.c | 10 ++++ drivers/net/phy/mscc/mscc.h | 2 + drivers/net/phy/mscc/mscc_main.c | 20 +++++++ drivers/net/phy/phy.c | 25 +++++++++ drivers/net/phy/phylink.c | 93 +++++++++++++++++++++++++------- include/linux/phy.h | 24 +++++++++ 6 files changed, 154 insertions(+), 20 deletions(-)