Re: [PATCH net v3] net: ethernet: ti: am65-cpsw: Fix devlink port register sequence

[Siddharth Vadapalli <s-vadapalli@ti.com>]

Hello Paolo,

On 07/07/22 13:00, Paolo Abeni wrote:
> On Wed, 2022-07-06 at 12:32 +0530, Siddharth Vadapalli wrote:
>> Renaming interfaces using udevd depends on the interface being registered
>> before its netdev is registered. Otherwise, udevd reads an empty
>> phys_port_name value, resulting in the interface not being renamed.
>>
>> Fix this by registering the interface before registering its netdev
>> by invoking am65_cpsw_nuss_register_devlink() before invoking
>> register_netdev() for the interface.
>>
>> Move the function call to devlink_port_type_eth_set(), invoking it after
>> register_netdev() is invoked, to ensure that netlink notification for the
>> port state change is generated after the netdev is completely initialized.
>>
>> Fixes: 58356eb31d60 ("net: ti: am65-cpsw-nuss: Add devlink support")
>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>> ---
>> Changelog:
>> v2 -> v3:
>> 1. Add error handling to unregister devlink.
>>
>> v1-> v2:
>> 1. Add Fixes tag in commit message.
>> 2. Update patch subject to include "net".
>> 3. Invoke devlink_port_type_eth_set() after register_netdev() is called.
>> 4. Update commit message describing the cause for moving the call to
>>    devlink_port_type_eth_set().
>>
>> v2: https://lore.kernel.org/r/20220704073040.7542-1-s-vadapalli@ti.com/
>> v1: https://lore.kernel.org/r/20220623044337.6179-1-s-vadapalli@ti.com/
>>
>>  drivers/net/ethernet/ti/am65-cpsw-nuss.c | 17 ++++++++++-------
>>  1 file changed, 10 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
>> index fb92d4c1547d..f4a6b590a1e3 100644
>> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
>> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
>> @@ -2467,7 +2467,6 @@ static int am65_cpsw_nuss_register_devlink(struct am65_cpsw_common *common)
>>  				port->port_id, ret);
>>  			goto dl_port_unreg;
>>  		}
>> -		devlink_port_type_eth_set(dl_port, port->ndev);
>>  	}
>>  	devlink_register(common->devlink);
>>  	return ret;
>> @@ -2511,6 +2510,7 @@ static void am65_cpsw_unregister_devlink(struct am65_cpsw_common *common)
>>  static int am65_cpsw_nuss_register_ndevs(struct am65_cpsw_common *common)
>>  {
>>  	struct device *dev = common->dev;
>> +	struct devlink_port *dl_port;
>>  	struct am65_cpsw_port *port;
>>  	int ret = 0, i;
>>  
>> @@ -2527,6 +2527,10 @@ static int am65_cpsw_nuss_register_ndevs(struct am65_cpsw_common *common)
>>  		return ret;
>>  	}
>>  
>> +	ret = am65_cpsw_nuss_register_devlink(common);
>> +	if (ret)
>> +		return ret;
>> +
>>  	for (i = 0; i < common->port_num; i++) {
>>  		port = &common->ports[i];
>>  
>> @@ -2539,25 +2543,24 @@ static int am65_cpsw_nuss_register_ndevs(struct am65_cpsw_common *common)
>>  				i, ret);
>>  			goto err_cleanup_ndev;
>>  		}
>> +
>> +		dl_port = &port->devlink_port;
>> +		devlink_port_type_eth_set(dl_port, port->ndev);
>>  	}
>>  
>>  	ret = am65_cpsw_register_notifiers(common);
>>  	if (ret)
>>  		goto err_cleanup_ndev;
>>  
>> -	ret = am65_cpsw_nuss_register_devlink(common);
>> -	if (ret)
>> -		goto clean_unregister_notifiers;
>> -
>>  	/* can't auto unregister ndev using devm_add_action() due to
>>  	 * devres release sequence in DD core for DMA
>>  	 */
>>  
>>  	return 0;
>> -clean_unregister_notifiers:
>> -	am65_cpsw_unregister_notifiers(common);
>> +
>>  err_cleanup_ndev:
>>  	am65_cpsw_nuss_cleanup_ndev(common);
>> +	am65_cpsw_unregister_devlink(common);
> 
> It looks strange that there is no error path leading to
> am65_cpsw_unregister_devlink() only.
> 
> Why we don't need to call it when/if devm_request_irq() fails? 

am65_cpsw_nuss_register_devlink() is invoked after devm_request_irq() and
devm_request_irq()'s associated error handling.

> 
> Not strictly related to this patch, but it looks like there is another
> suspect cleanup point: if a 'register_netdev()' call fails, the cleanup
> code will still call unregister_netdev() on the relevant device and the
> later ones, hitting a WARN_ON(1) in unregister_netdevice_many().

Thank you for pointing it out. I will look at it and address it in a separate
cleanup patch.

Regards,
Siddharth.