[PATCH net-next 4/4] net: stmmac: Move MAC caps init to phylink MAC caps getter

Serge Semin fancer.lancer at gmail.com
Tue Apr 16 04:38:28 PDT 2024


Hi Romain

On Tue, Apr 16, 2024 at 09:56:32AM +0200, Romain Gantois wrote:
> Hi Serge,
> 
> On Fri, 12 Apr 2024, Serge Semin wrote:
> 
> > +static unsigned long stmmac_mac_get_caps(struct phylink_config *config,
> > +					 phy_interface_t interface)
> > +{
> > +	struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));
> > +
> > +	/* Get the MAC-specific capabilities */
> > +	stmmac_mac_phylink_get_caps(priv);
> 
> This is a bit of a nitpick, but the terminology is quite confusing between 
> stmmac_mac_phylink_get_caps() and stmmac_mac_get_caps().

Right, the naming turns to be ambiguous "a bit".)

> Ideally, we could just 
> get rid of the whole stmmac_do_void_callback() complexity and just call 
> phylink_get_caps() directly.

No, this isn't a good solution. The local coding convention implies
using the macro-functions implemented to execute the callbacks. We
can't use the macros everywhere but in this place.

> In the meantime, maybe renaming this to 
> stmmac_mac_core_get_caps() would be acceptable?

The name was selected to align with the rest of the PHYLINK callbacks:

static const struct phylink_mac_ops stmmac_phylink_mac_ops = {
        .mac_get_caps = stmmac_mac_get_caps,
        .mac_select_pcs = stmmac_mac_select_pcs,
        .mac_config = stmmac_mac_config,
        .mac_link_down = stmmac_mac_link_down,
        .mac_link_up = stmmac_mac_link_up,
};

So I don't think that changing it to something different would be a
good alternative. What could be a better option is to rename the
stmmac_ops::phylink_get_caps() callback and
stmmac_mac_phylink_get_caps() macro-function to something like:

stmmac_ops::link_update_caps()
stmmac_mac_link_update_caps()

especially seeing the callback no longer sets the phylink MAC
capabilities directly. What do you think?

-Serge(y)

> 
> Please let me know what you think.
> 
> Thanks,
> 
> -- 
> Romain Gantois, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com



More information about the linux-arm-kernel mailing list