| Message ID | 20230127142621.1761278-5-yoshihiro.shimoda.uh@renesas.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
| Series | net: ethernet: renesas: rswitch: Modify initialization for SERDES and PHY | expand |
On Fri, Jan 27, 2023 at 11:26:21PM +0900, Yoshihiro Shimoda wrote: > Some Ethernet PHYs (like marvell10g) will decide the host interface > mode by the media-side speed. So, the rswitch driver needs to > initialize one of the Ethernet SERDES (r8a779f0-eth-serdes) ports > after linked the Ethernet PHY up. The r8a779f0-eth-serdes driver has > .init() for initializing all ports and .power_on() for initializing > each port. So, add phy_power_{on,off} calling for it. So how does this work? 88x3310 can change it's MAC facing interface according to the speed negotiated on the media side, or it can use rate adaption mode, but if it's not a MACSEC device, the MAC must pace its transmission rate to that of the media side link. The former requires one to reconfigure the interface mode in mac_config(), which I don't see happening in this patch set. The latter requires some kind of configuration in mac_link_up() which I also don't see happening in this patch set. So, I doubt this works properly. Also, I can't see any sign of any working DT configuration for this switch to even be able to review a use case - all there is in net-next is the basic description of the rswitch in a .dtsi and no users. It may be helpful if there was some visibility of its use, and why phylink is being used in this driver - because right now with phylink's MAC methods stubbed out in the way they are, and even after this patch set, I see little point to this driver using phylink. Moreover, looking at the binding document, you don't even support SFPs or fixed link, which are really the two reasons to use phylink over phylib. Also, phylink only really makes sense if the methods in its _ops structures actually do something useful, because without that there can be no dynamic configuration of the system to suit what is connected.
Hi Russell, > From: Russell King, Sent: Saturday, January 28, 2023 12:18 AM > > On Fri, Jan 27, 2023 at 11:26:21PM +0900, Yoshihiro Shimoda wrote: > > Some Ethernet PHYs (like marvell10g) will decide the host interface > > mode by the media-side speed. So, the rswitch driver needs to > > initialize one of the Ethernet SERDES (r8a779f0-eth-serdes) ports > > after linked the Ethernet PHY up. The r8a779f0-eth-serdes driver has > > .init() for initializing all ports and .power_on() for initializing > > each port. So, add phy_power_{on,off} calling for it. > > So how does this work? This hardware has MDIO interfaces, and the MDIO can communicate the Ethernet PHY without the Ethernet SERDES initialization. And, the Ethernet PHY can be initialized, and media-side of the PHY works. So, this works. > 88x3310 can change it's MAC facing interface according to the speed > negotiated on the media side, or it can use rate adaption mode, but > if it's not a MACSEC device, the MAC must pace its transmission > rate to that of the media side link. My platform has 88x2110 so that it's not a MACSEC device. > The former requires one to reconfigure the interface mode in > mac_config(), which I don't see happening in this patch set. You're correct. This patch set doesn't have such reconfiguration because this driver doesn't support such a feature (for now). However, this driver has configured the interface mode when driver is probing. > The latter requires some kind of configuration in mac_link_up() > which I also don't see happening in this patch set. You're correct. This patch set doesn't have such configuration in mac_link_up() because this hardware cannot change speed at runtime (for now). However, this driver has configured the speed when driver is probing. > So, I doubt this works properly. > > Also, I can't see any sign of any working DT configuration for this > switch to even be able to review a use case - all there is in net-next > is the basic description of the rswitch in a .dtsi and no users. It > may be helpful if there was some visibility of its use, and why > phylink is being used in this driver - because right now with phylink's > MAC methods stubbed out in the way they are, and even after this patch > set, I see little point to this driver using phylink. In the latest net-next, r8a779f0-spider.dts is a user. In r8a779f0-spider-ether.dtsi: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/arch/arm64/boot/dts/renesas/r8a779f0-spider-ethernet.dtsi#n41 In r8a779f0-spider.dts: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/arch/arm64/boot/dts/renesas/r8a779f0-spider.dts#n10 > Moreover, looking at the binding document, you don't even support SFPs > or fixed link, which are really the two reasons to use phylink over > phylib. You're correct. This hardware doesn't support SFPs or fixed link. I sent a patch at the first, I had used phylib and had added a new function for setting the phy_dev->host_interfaces [1]. And then, Marek suggested that I should use phylink instead of phylib. That's why this driver is using phylink even if this doesn't support SFPs and fixed link. [1] https://lore.kernel.org/netdev/20221019124100.41c9bbaf@dellmb/ > Also, phylink only really makes sense if the methods in its _ops > structures actually do something useful, because without that there > can be no dynamic configuration of the system to suit what is > connected. I think so. This rswitch doesn't need dynamic configuration, but Marvell 88x2110 on my platform needs dynamic configuration. That's why this driver uses phylink. Best regards, Yoshihiro Shimoda
On Mon, Jan 30, 2023 at 05:52:15AM +0000, Yoshihiro Shimoda wrote: > Hi Russell, > > > From: Russell King, Sent: Saturday, January 28, 2023 12:18 AM > > > > On Fri, Jan 27, 2023 at 11:26:21PM +0900, Yoshihiro Shimoda wrote: > > > Some Ethernet PHYs (like marvell10g) will decide the host interface > > > mode by the media-side speed. So, the rswitch driver needs to > > > initialize one of the Ethernet SERDES (r8a779f0-eth-serdes) ports > > > after linked the Ethernet PHY up. The r8a779f0-eth-serdes driver has > > > .init() for initializing all ports and .power_on() for initializing > > > each port. So, add phy_power_{on,off} calling for it. > > > > So how does this work? > > This hardware has MDIO interfaces, and the MDIO can communicate the Ethernet > PHY without the Ethernet SERDES initialization. And, the Ethernet PHY can be > initialized, and media-side of the PHY works. So, this works. Ethernet PHYs can generally be communicated with irrespective of the serdes state, so that isn't the concern. What I'm trying to grasp is your decision making behind putting the serdes phy power control in the link_up/link_down functions, when doing so is fundamentally problematical if in-band mode is ever supported - and in-band mode has to be supported for things like fibre connections to work. > > 88x3310 can change it's MAC facing interface according to the speed > > negotiated on the media side, or it can use rate adaption mode, but > > if it's not a MACSEC device, the MAC must pace its transmission > > rate to that of the media side link. > > My platform has 88x2110 so that it's not a MACSEC device. ... which supports USXGMII, 10GBaseR, 5GBaseR, 2500BaseX and SGMII, possibly with rate adaption, and if it's not a MACSEC device, that rate adaption will likely require the MAC side to pace its transmission to the media speed. > > The former requires one to reconfigure the interface mode in > > mac_config(), which I don't see happening in this patch set. > > You're correct. This patch set doesn't have such reconfiguration > because this driver doesn't support such a feature (for now). Is this planned? When are we likely to see this code? > > The latter requires some kind of configuration in mac_link_up() > > which I also don't see happening in this patch set. > > You're correct. This patch set doesn't have such configuration > in mac_link_up() because this hardware cannot change speed at > runtime (for now). the hardware can't even change between the various SGMII speeds? What kind of utterly crippled hardware implementation is this? You make it sound like the hardware designers don't have a clue what they're doing. > > So, I doubt this works properly. > > > > Also, I can't see any sign of any working DT configuration for this > > switch to even be able to review a use case - all there is in net-next > > is the basic description of the rswitch in a .dtsi and no users. It > > may be helpful if there was some visibility of its use, and why > > phylink is being used in this driver - because right now with phylink's > > MAC methods stubbed out in the way they are, and even after this patch > > set, I see little point to this driver using phylink. > > In the latest net-next, r8a779f0-spider.dts is a user. > > In r8a779f0-spider-ether.dtsi: > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/arch/arm64/boot/dts/renesas/r8a779f0-spider-ethernet.dtsi#n41 > > In r8a779f0-spider.dts: > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/arch/arm64/boot/dts/renesas/r8a779f0-spider.dts#n10 So these configure the ports with PHYs on to use SGMII mode. No mention of any speed, yet you say that's configured at probe time? Do you just set them to 1G, and hope that the media side link negotiates to 1G speeds? That doesn't sound like a good idea to me. > > Moreover, looking at the binding document, you don't even support SFPs > > or fixed link, which are really the two reasons to use phylink over > > phylib. > > You're correct. This hardware doesn't support SFPs or fixed link. > > I sent a patch at the first, I had used phylib and had added a new function > for setting the phy_dev->host_interfaces [1]. And then, Marek suggested > that I should use phylink instead of phylib. That's why this driver > is using phylink even if this doesn't support SFPs and fixed link. > `> [1] > https://lore.kernel.org/netdev/20221019124100.41c9bbaf@dellmb/ [Adding Marek to the Cc] I'm afraid I don't agree with Marek given the state of this driver. His assertion is "there's an API for doing this" which is demonstrably false. If his assertion were true, then you wouldn't need to add the code to phylink to set phydev->host_interfaces for on-board PHYs. I'm not particularly happy about adding that to phylink, and now that I read your current rather poor implementation of phylink, I'm even less happy about it. > > Also, phylink only really makes sense if the methods in its _ops > > structures actually do something useful, because without that there > > can be no dynamic configuration of the system to suit what is > > connected. > > I think so. This rswitch doesn't need dynamic configuration, > but Marvell 88x2110 on my platform needs dynamic configuration. > That's why this driver uses phylink. Given that you use the 88x2110, and you've set the phy-mode to SGMII, it should support 10M, 100M and 1G speeds on the media side. Please test - and if not, I think the code which supports that should at the very least be part of this patch set - so we begin to see a proper implementation in the mac_* ops. The reason for this is I utterly detest shoddy users of phylink, and I will ask people not to use phylink if they aren't prepared to implement it properly - because shoddy phylink users add greatly to my maintenance workload. Thanks.
On Mon, 30 Jan 2023 12:15:33 +0000 "Russell King (Oracle)" <linux@armlinux.org.uk> wrote: > On Mon, Jan 30, 2023 at 05:52:15AM +0000, Yoshihiro Shimoda wrote: > > Hi Russell, > > > > > From: Russell King, Sent: Saturday, January 28, 2023 12:18 AM > > > > > > On Fri, Jan 27, 2023 at 11:26:21PM +0900, Yoshihiro Shimoda wrote: > > > > Some Ethernet PHYs (like marvell10g) will decide the host interface > > > > mode by the media-side speed. So, the rswitch driver needs to > > > > initialize one of the Ethernet SERDES (r8a779f0-eth-serdes) ports > > > > after linked the Ethernet PHY up. The r8a779f0-eth-serdes driver has > > > > .init() for initializing all ports and .power_on() for initializing > > > > each port. So, add phy_power_{on,off} calling for it. > > > > > > So how does this work? > > > > This hardware has MDIO interfaces, and the MDIO can communicate the Ethernet > > PHY without the Ethernet SERDES initialization. And, the Ethernet PHY can be > > initialized, and media-side of the PHY works. So, this works. > > Ethernet PHYs can generally be communicated with irrespective of the > serdes state, so that isn't the concern. > > What I'm trying to grasp is your decision making behind putting the > serdes phy power control in the link_up/link_down functions, when > doing so is fundamentally problematical if in-band mode is ever > supported - and in-band mode has to be supported for things like > fibre connections to work. > > > > 88x3310 can change it's MAC facing interface according to the speed > > > negotiated on the media side, or it can use rate adaption mode, but > > > if it's not a MACSEC device, the MAC must pace its transmission > > > rate to that of the media side link. > > > > My platform has 88x2110 so that it's not a MACSEC device. > > ... which supports USXGMII, 10GBaseR, 5GBaseR, 2500BaseX and SGMII, > possibly with rate adaption, and if it's not a MACSEC device, that > rate adaption will likely require the MAC side to pace its > transmission to the media speed. > > > > The former requires one to reconfigure the interface mode in > > > mac_config(), which I don't see happening in this patch set. > > > > You're correct. This patch set doesn't have such reconfiguration > > because this driver doesn't support such a feature (for now). > > Is this planned? When are we likely to see this code? > > > > The latter requires some kind of configuration in mac_link_up() > > > which I also don't see happening in this patch set. > > > > You're correct. This patch set doesn't have such configuration > > in mac_link_up() because this hardware cannot change speed at > > runtime (for now). > > the hardware can't even change between the various SGMII speeds? What > kind of utterly crippled hardware implementation is this? You make it > sound like the hardware designers don't have a clue what they're doing. > > > > So, I doubt this works properly. > > > > > > Also, I can't see any sign of any working DT configuration for this > > > switch to even be able to review a use case - all there is in net-next > > > is the basic description of the rswitch in a .dtsi and no users. It > > > may be helpful if there was some visibility of its use, and why > > > phylink is being used in this driver - because right now with phylink's > > > MAC methods stubbed out in the way they are, and even after this patch > > > set, I see little point to this driver using phylink. > > > > In the latest net-next, r8a779f0-spider.dts is a user. > > > > In r8a779f0-spider-ether.dtsi: > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/arch/arm64/boot/dts/renesas/r8a779f0-spider-ethernet.dtsi#n41 > > > > In r8a779f0-spider.dts: > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/arch/arm64/boot/dts/renesas/r8a779f0-spider.dts#n10 > > So these configure the ports with PHYs on to use SGMII mode. No mention > of any speed, yet you say that's configured at probe time? Do you just > set them to 1G, and hope that the media side link negotiates to 1G > speeds? > > That doesn't sound like a good idea to me. > > > > Moreover, looking at the binding document, you don't even support SFPs > > > or fixed link, which are really the two reasons to use phylink over > > > phylib. > > > > You're correct. This hardware doesn't support SFPs or fixed link. > > > > I sent a patch at the first, I had used phylib and had added a new function > > for setting the phy_dev->host_interfaces [1]. And then, Marek suggested > > that I should use phylink instead of phylib. That's why this driver > > is using phylink even if this doesn't support SFPs and fixed link. > > > `> [1] > > https://lore.kernel.org/netdev/20221019124100.41c9bbaf@dellmb/ > > [Adding Marek to the Cc] > > I'm afraid I don't agree with Marek given the state of this driver. > His assertion is "there's an API for doing this" which is demonstrably > false. If his assertion were true, then you wouldn't need to add the > code to phylink to set phydev->host_interfaces for on-board PHYs. > > I'm not particularly happy about adding that to phylink, and now that > I read your current rather poor implementation of phylink, I'm even > less happy about it. OK, it seems that I had a invalid expectation that the author wants to implement the driver fully, for future possible devices that use rswitch with SFP cage. If this is not the case, I guess we just have to end up with another phylib initialization function... Blegh. But rswitch already uses phylink, so should Yoshihiro convert it whole back to phylib? (I am not sure how much phylink API is used, maybe it can stay that way and the new phylib function as proposed in Yoshihiro's previous proposal can just be added.) Marek
On Mon, Jan 30, 2023 at 05:30:48PM +0100, Marek Behún wrote: > But rswitch already uses phylink, so should Yoshihiro convert it whole > back to phylib? (I am not sure how much phylink API is used, maybe it > can stay that way and the new phylib function as proposed in Yoshihiro's > previous proposal can just be added.) In terms of "how much phylink API is used"... well, all the phylink ops functions are currently entirely empty. So, phylink in this case is just being nothing more than a shim between the driver and the corresponding phylib functions.
On Mon, 30 Jan 2023 16:48:02 +0000 "Russell King (Oracle)" <linux@armlinux.org.uk> wrote: > On Mon, Jan 30, 2023 at 05:30:48PM +0100, Marek Behún wrote: > > But rswitch already uses phylink, so should Yoshihiro convert it whole > > back to phylib? (I am not sure how much phylink API is used, maybe it > > can stay that way and the new phylib function as proposed in Yoshihiro's > > previous proposal can just be added.) > > In terms of "how much phylink API is used"... well, all the phylink > ops functions are currently entirely empty. So, phylink in this case > is just being nothing more than a shim between the driver and the > corresponding phylib functions. > Yoshihiro, sorry for this. If not for my complaints, your proposal could already be merged (maybe). Anyway, I think the best solution would be to implement phylink properly, even for cases that are not relevant for your board*, but this would take a non-trivial amount of time, so I will understand if you want to stick with phylib. * Altough you don't use fixed-link or SFP on your board, I think it should be possible to test it somehow if you implemented it... For example, I have tested fixed-link between SOC and switch SerDes by configuring it in device-tree on both sides. Marek
Hi Russell, > From: Russell King, Sent: Monday, January 30, 2023 9:16 PM > > On Mon, Jan 30, 2023 at 05:52:15AM +0000, Yoshihiro Shimoda wrote: > > Hi Russell, > > > > > From: Russell King, Sent: Saturday, January 28, 2023 12:18 AM > > > > > > On Fri, Jan 27, 2023 at 11:26:21PM +0900, Yoshihiro Shimoda wrote: > > > > Some Ethernet PHYs (like marvell10g) will decide the host interface > > > > mode by the media-side speed. So, the rswitch driver needs to > > > > initialize one of the Ethernet SERDES (r8a779f0-eth-serdes) ports > > > > after linked the Ethernet PHY up. The r8a779f0-eth-serdes driver has > > > > .init() for initializing all ports and .power_on() for initializing > > > > each port. So, add phy_power_{on,off} calling for it. > > > > > > So how does this work? > > > > This hardware has MDIO interfaces, and the MDIO can communicate the Ethernet > > PHY without the Ethernet SERDES initialization. And, the Ethernet PHY can be > > initialized, and media-side of the PHY works. So, this works. > > Ethernet PHYs can generally be communicated with irrespective of the > serdes state, so that isn't the concern. > > What I'm trying to grasp is your decision making behind putting the > serdes phy power control in the link_up/link_down functions, when > doing so is fundamentally problematical if in-band mode is ever > supported - and in-band mode has to be supported for things like > fibre connections to work. I understood it. > > > 88x3310 can change it's MAC facing interface according to the speed > > > negotiated on the media side, or it can use rate adaption mode, but > > > if it's not a MACSEC device, the MAC must pace its transmission > > > rate to that of the media side link. > > > > My platform has 88x2110 so that it's not a MACSEC device. > > ... which supports USXGMII, 10GBaseR, 5GBaseR, 2500BaseX and SGMII, > possibly with rate adaption, and if it's not a MACSEC device, that > rate adaption will likely require the MAC side to pace its > transmission to the media speed. I understood it. > > > The former requires one to reconfigure the interface mode in > > > mac_config(), which I don't see happening in this patch set. > > > > You're correct. This patch set doesn't have such reconfiguration > > because this driver doesn't support such a feature (for now). > > Is this planned? When are we likely to see this code? I'm afraid, but this is not planned. > > > The latter requires some kind of configuration in mac_link_up() > > > which I also don't see happening in this patch set. > > > > You're correct. This patch set doesn't have such configuration > > in mac_link_up() because this hardware cannot change speed at > > runtime (for now). > > the hardware can't even change between the various SGMII speeds? Unfortunately, it's true. But, I'm sorry for my unclear explanation. This is related to a hardware restriction which cannot changed an internal mode if it enters "operation" mode once... But, I heard that this restriction will be fixed on a new SoC revision. > What > kind of utterly crippled hardware implementation is this? You make it > sound like the hardware designers don't have a clue what they're doing. > > > > So, I doubt this works properly. > > > > > > Also, I can't see any sign of any working DT configuration for this > > > switch to even be able to review a use case - all there is in net-next > > > is the basic description of the rswitch in a .dtsi and no users. It > > > may be helpful if there was some visibility of its use, and why > > > phylink is being used in this driver - because right now with phylink's > > > MAC methods stubbed out in the way they are, and even after this patch > > > set, I see little point to this driver using phylink. > > > > In the latest net-next, r8a779f0-spider.dts is a user. > > > > In r8a779f0-spider-ether.dtsi: > > > <snip the URL> > > > > In r8a779f0-spider.dts: > > <snip the URL> > > So these configure the ports with PHYs on to use SGMII mode. No mention > of any speed, yet you say that's configured at probe time? Do you just > set them to 1G, and hope that the media side link negotiates to 1G > speeds? You're correct. > That doesn't sound like a good idea to me. I agreed. So, I will fix it somehow... > > > Moreover, looking at the binding document, you don't even support SFPs > > > or fixed link, which are really the two reasons to use phylink over > > > phylib. > > > > You're correct. This hardware doesn't support SFPs or fixed link. > > > > I sent a patch at the first, I had used phylib and had added a new function > > for setting the phy_dev->host_interfaces [1]. And then, Marek suggested > > that I should use phylink instead of phylib. That's why this driver > > is using phylink even if this doesn't support SFPs and fixed link. > > > `> [1] > > <snip the URL> > > [Adding Marek to the Cc] > > I'm afraid I don't agree with Marek given the state of this driver. > His assertion is "there's an API for doing this" which is demonstrably > false. If his assertion were true, then you wouldn't need to add the > code to phylink to set phydev->host_interfaces for on-board PHYs. > > I'm not particularly happy about adding that to phylink, and now that > I read your current rather poor implementation of phylink, I'm even > less happy about it. I understood it. > > > Also, phylink only really makes sense if the methods in its _ops > > > structures actually do something useful, because without that there > > > can be no dynamic configuration of the system to suit what is > > > connected. > > > > I think so. This rswitch doesn't need dynamic configuration, > > but Marvell 88x2110 on my platform needs dynamic configuration. > > That's why this driver uses phylink. > > Given that you use the 88x2110, and you've set the phy-mode to > SGMII, it should support 10M, 100M and 1G speeds on the media > side. Please test - and if not, I think the code which supports > that should at the very least be part of this patch set - so we > begin to see a proper implementation in the mac_* ops. I got it. > The reason for this is I utterly detest shoddy users of phylink, and > I will ask people not to use phylink if they aren't prepared to > implement it properly - because shoddy phylink users add greatly to > my maintenance workload. I understood it. I don't want to add your maintenance workload by my patch. Best regards, Yoshihiro Shimoda
Hi Marek, > From: Marek Behún, Sent: Tuesday, January 31, 2023 1:59 AM > > On Mon, 30 Jan 2023 16:48:02 +0000 > "Russell King (Oracle)" <linux@armlinux.org.uk> wrote: > > > On Mon, Jan 30, 2023 at 05:30:48PM +0100, Marek Behún wrote: > > > But rswitch already uses phylink, so should Yoshihiro convert it whole > > > back to phylib? (I am not sure how much phylink API is used, maybe it > > > can stay that way and the new phylib function as proposed in Yoshihiro's > > > previous proposal can just be added.) > > > > In terms of "how much phylink API is used"... well, all the phylink > > ops functions are currently entirely empty. So, phylink in this case > > is just being nothing more than a shim between the driver and the > > corresponding phylib functions. > > > > Yoshihiro, sorry for this. No warries! > If not for my complaints, your proposal could > already be merged (maybe). Anyway, I think the best solution would be > to implement phylink properly, even for cases that are not relevant for > your board*, but this would take a non-trivial amount of time, so > I will understand if you want to stick with phylib. > > * Altough you don't use fixed-link or SFP on your board, I think it > should be possible to test it somehow if you implemented it... > For example, I have tested fixed-link between SOC and switch SerDes > by configuring it in device-tree on both sides. Thank you very much for your comments! For now I'm intending to use phylib instead, because I'm thinking that I cannot implement the in-band mode of phylink on my board. # As you mentioned, fixed-link can be implemented, I guess. Best regards, Yoshihiro Shimoda > Marek
diff --git a/drivers/net/ethernet/renesas/rswitch.c b/drivers/net/ethernet/renesas/rswitch.c index b9addbc29ef9..7bdfcb5270c0 100644 --- a/drivers/net/ethernet/renesas/rswitch.c +++ b/drivers/net/ethernet/renesas/rswitch.c @@ -1143,12 +1143,20 @@ static void rswitch_mac_config(struct phylink_config *config, unsigned int mode, const struct phylink_link_state *state) { + struct net_device *ndev = to_net_dev(config->dev); + + if (mode == MLO_AN_INBAND) + netdev_err(ndev, "Link up/down will not work because in-band mode\n"); } static void rswitch_mac_link_down(struct phylink_config *config, unsigned int mode, phy_interface_t interface) { + struct net_device *ndev = to_net_dev(config->dev); + struct rswitch_device *rdev = netdev_priv(ndev); + + phy_power_off(rdev->serdes); } static void rswitch_mac_link_up(struct phylink_config *config, @@ -1156,7 +1164,11 @@ static void rswitch_mac_link_up(struct phylink_config *config, phy_interface_t interface, int speed, int duplex, bool tx_pause, bool rx_pause) { + struct net_device *ndev = to_net_dev(config->dev); + struct rswitch_device *rdev = netdev_priv(ndev); + /* Current hardware cannot change speed at runtime */ + phy_power_on(rdev->serdes); } static const struct phylink_mac_ops rswitch_phylink_ops = {
Some Ethernet PHYs (like marvell10g) will decide the host interface mode by the media-side speed. So, the rswitch driver needs to initialize one of the Ethernet SERDES (r8a779f0-eth-serdes) ports after linked the Ethernet PHY up. The r8a779f0-eth-serdes driver has .init() for initializing all ports and .power_on() for initializing each port. So, add phy_power_{on,off} calling for it. Notes that in-band mode will not work because the initialization is not completed. So, output error message if in-band mode. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> --- drivers/net/ethernet/renesas/rswitch.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)