netdev - Re: [PATCH net-next v4 6/6] net: tn40xx: add PHYLIB support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240508.221851.1563324062182870165.fujita.tomonori@gmail.com>
Date: Wed, 08 May 2024 22:18:51 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: andrew@...n.ch
Cc: fujita.tomonori@...il.com, netdev@...r.kernel.org, kuba@...nel.org,
 jiri@...nulli.us, horms@...nel.org
Subject: Re: [PATCH net-next v4 6/6] net: tn40xx: add PHYLIB support

Hi,

On Wed, 8 May 2024 14:21:29 +0200
Andrew Lunn <andrew@...n.ch> wrote:

>> --- a/drivers/net/ethernet/tehuti/tn40.c
>> +++ b/drivers/net/ethernet/tehuti/tn40.c
>> @@ -7,6 +7,7 @@
>>  #include <linux/if_vlan.h>
>>  #include <linux/netdevice.h>
>>  #include <linux/pci.h>
>> +#include <linux/phylink.h>
>>  
>>  #include "tn40.h"
>>  
>> @@ -1185,21 +1186,25 @@ static void tn40_link_changed(struct tn40_priv *priv)
>>  	u32 link = tn40_read_reg(priv,
>>  				 TN40_REG_MAC_LNK_STAT) & TN40_MAC_LINK_STAT;
>>  	if (!link) {
>> -		if (netif_carrier_ok(priv->ndev) && priv->link)
>> +		if (netif_carrier_ok(priv->ndev) && priv->link) {
>>  			netif_stop_queue(priv->ndev);
>> +			phylink_mac_change(priv->phylink, false);
>> +		}
> 
> What exactly does link_changed mean?
> 
> The normal use case for calling phylink_mac_change() is that you have
> received an interrupt from something like the PCS, or the PHY. The MAC
> driver itself cannot fully evaluate if the link is up because there
> can be multiple parts in that decision. Is the SFP reporting LOS? Does

The original driver receives an interrupt from an PHY (or something),
then reads the register (TN40_REG_MAC_LNK_STAT) to evaluate the state
of the link; doesn't use information from the PHY.


> the PCS SERDES have sync, etc. So all you do is forward the interrupt
> to phylink. phylink will then look at everything it knows about and
> decide the state of the link, and maybe call one of the callbacks
> indicating the link is now up/down.

What function should be used to forward an interrupt to phylink?
equivalent to phy_mac_interrupt() in phylib.


>>  		priv->link = 0;
>>  		if (priv->link_loop_cnt++ > TN40_LINK_LOOP_MAX) {
>>  			/* MAC reset */
>>  			tn40_set_link_speed(priv, 0);
>> +			tn40_set_link_speed(priv, priv->speed);
>>  			priv->link_loop_cnt = 0;
> 
> This should move into the link_down callback.

I'll try phylink callbacks to see if they would work. 


>> -	if (!netif_carrier_ok(priv->ndev) && !link)
>> +	if (!netif_carrier_ok(priv->ndev) && !link) {
>>  		netif_wake_queue(priv->ndev);
> 
> and this should be in the link_up callback.
>> +static void tn40_link_up(struct phylink_config *config, struct phy_device *phy,
>> +			 unsigned int mode, phy_interface_t interface,
>> +			 int speed, int duplex, bool tx_pause, bool rx_pause)
>> +{
>> +	struct tn40_priv *priv = container_of(config, struct tn40_priv,
>> +					      phylink_config);
>> +
>> +	priv->speed = speed;
> 
> This is where you should take any actions needed to make the MAC send
> packets, at the correct rate.
> 
>> +}
>> +
>> +static void tn40_link_down(struct phylink_config *config, unsigned int mode,
>> +			   phy_interface_t interface)
>> +{
> 
> And here you should stop the MAC sending packets.
> 
>> +}
> 
>> +
>> +static void tn40_mac_config(struct phylink_config *config, unsigned int mode,
>> +			    const struct phylink_link_state *state)
>> +{
> 
> I know at the moment you only support 10G. When you add support for
> 1G, this is where you will need to configure the MAC to swap between
> the different modes. phylink will tell you which mode to use,
> 10GBaseX, 1000BaseX, SGMII, etc. You might want to move the existing
> code for 10GBaseX here.

Yeah.

The original driver configures the MAC for 10G with QT2025 PHY so I'm
not sure things would work well. I'll experiment once I get 1G SFP.


> For the next version, please also Cc: Russell King, the phylink
> Maintainer.

Sure, I'll do in v6.