[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