Re: [PATCH net-next] net: dsa: felix: provide own phylink MAC operations

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Mon, Apr 15, 2024 at 07:01:50PM +0300, Vladimir Oltean wrote:
> On Mon, Apr 15, 2024 at 04:24:45PM +0100, Russell King (Oracle) wrote:
> > Looking at these three, isn't there good reason to merge the allocation
> > and initialisation of struct dsa_switch together in all three drivers?
> > All three are basically doing the same thing:
> > 
> > felix_vsc9959.c:
> >         ds->dev = &pdev->dev;
> >         ds->num_ports = felix->info->num_ports;
> >         ds->num_tx_queues = felix->info->num_tx_queues;
> >         ds->ops = &felix_switch_ops;
> >         ds->priv = ocelot;
> >         felix->ds = ds;
> > 
> > ocelot_ext.c:
> >         ds->dev = dev;
> >         ds->num_ports = felix->info->num_ports;
> >         ds->num_tx_queues = felix->info->num_tx_queues;
> >         ds->ops = &felix_switch_ops;
> >         ds->priv = ocelot;
> >         felix->ds = ds;
> > 
> > seville_vsc9953.c:
> >         ds->dev = &pdev->dev;
> >         ds->num_ports = felix->info->num_ports;
> >         ds->ops = &felix_switch_ops;
> >         ds->priv = ocelot;
> >         felix->ds = ds;
> 
> Yes, there is :)
> 
> If dev_set_drvdata() were to be used instead of platform_set_drvdata()/
> pci_set_drvdata(), there's room for even more common code.
> 
> > Also, I note that felix->info->num_tx_queues on seville_vsc9953.c
> > is set to OCELOT_NUM_TC, which is defined to be 8, and is the same
> > value for ocelot_ext and felix_vsc9959. Presumably this unintentionally
> > missing from seville_vsc9953.c... because why initialise a private
> > struct member to a non-zero value and then not use it.
> > 
> > An alternative would be to initialise .num_tx_queues in seville_vsc9953.c
> > to zero.
> 
> It makes me wonder why felix->info->num_tx_queues even exists...
> 
> It was introduced by commit de143c0e274b ("net: dsa: felix: Configure
> Time-Aware Scheduler via taprio offload") at a time when vsc9959
> (LS1028A) was the only switch supported by the driver. It seems
> unnecessary.
> 
> 8 traffic classes, and 1 queue per traffic class, is a common
> architectural feature of all switches in the family. So they could all
> just set OCELOT_NUM_TC in the common allocation function and be fine
> (and remove felix->info->num_tx_queues).
> 
> When num_tx_queues=0, this is implicitly converted to 1 by dsa_user_create(),
> and this is good enough for basic operation for a switch port. The tc
> qdisc offload layer works with netdev TX queues, so for QoS offload we
> need to pretend we have multiple TX queues. The VSC9953, like ocelot_ext,
> doesn't export QoS offload, so it doesn't really matter. But we can
> definitely set num_tx_queues=8 for all switches.
> 
> > If we had common code doing this initialisation, then it wouldn't be
> > missed... and neither would have _this_ addition of the phylink MAC
> > ops missed the other two drivers - so I think that's something which
> > should be done as a matter of course - and thus there will be no need
> > to export these two data structures, just an initialisation (and
> > destruction) function. I don't think we would even need the destruction
> > function if we used devm_kzalloc().
> > 
> > Good idea?
> 
> Looking again at the driver, I see it's not very consistent in its use of
> devres... It is used elsewhere, including in felix_pci_probe() itself:
> devm_request_threaded_irq().
> 
> Yes, I think the use of devres here would be an improvement.
> 
> Note that felix_pci_probe() will still have to call pci_disable_device()
> on the error teardown path.
> 
> For even more consistency, it would be great if the error teardown
> labels were called after what they do, rather than after the path that
> triggered them. Example:
> - goto err_pci_enable -> goto out
> - goto err_alloc_felix -> goto out_pci_disable

Sounds like there's an opportunity to beneficially clean this driver
up before I make this change, so I'll hold off this patch until that's
happened. I probably don't have the spare cycles for that.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!