mbox series

[net-next,v2,0/2] net: ethernet: mediatek: support custom GMAC label

Message ID 20210419154659.44096-1-ilya.lipnitskiy@gmail.com
Headers show
Series net: ethernet: mediatek: support custom GMAC label | expand

Message

Ilya Lipnitskiy April 19, 2021, 3:46 p.m. UTC
Add support for specifying GMAC label via DTS. Useful when it is desired
to use a master DSA interface name that is different from the "eth%d"
pattern.

v2:
  - Use alloc_netdev instead of alloc_etherdev followed by rename

Ilya Lipnitskiy (2):
  dt-bindings: net: mediatek: add optional GMAC labels
  net: ethernet: mediatek: support custom GMAC label

 Documentation/devicetree/bindings/net/mediatek-net.txt | 6 ++++++
 drivers/net/ethernet/mediatek/mtk_eth_soc.c            | 6 ++++--
 2 files changed, 10 insertions(+), 2 deletions(-)

Comments

Andrew Lunn April 20, 2021, 1:22 a.m. UTC | #1
On Mon, Apr 19, 2021 at 08:46:59AM -0700, Ilya Lipnitskiy wrote:
> The MAC device name can now be set within DTS file instead of always
> being "ethX". This is helpful for DSA to clearly label the DSA master
> device and distinguish it from DSA slave ports.
> 
> For example, some devices, such as the Ubiquiti EdgeRouter X, may have
> ports labeled ethX. Labeling the master GMAC with a different prefix
> than DSA ports helps with clarity.
> 
> Suggested-by: René van Dorst <opensource@vdorst.com>
> Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew
Ilya Lipnitskiy April 20, 2021, 7:57 p.m. UTC | #2
On Tue, Apr 20, 2021 at 12:51 PM Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Apr 19, 2021 at 08:46:59AM -0700, Ilya Lipnitskiy wrote:
> > The MAC device name can now be set within DTS file instead of always
> > being "ethX". This is helpful for DSA to clearly label the DSA master
> > device and distinguish it from DSA slave ports.
> >
> > For example, some devices, such as the Ubiquiti EdgeRouter X, may have
> > ports labeled ethX. Labeling the master GMAC with a different prefix
> > than DSA ports helps with clarity.
> >
> > Suggested-by: René van Dorst <opensource@vdorst.com>
> > Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
> > ---
> >  drivers/net/ethernet/mediatek/mtk_eth_soc.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > index 6b00c12c6c43..df3cda63a8c5 100644
> > --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > @@ -2845,6 +2845,7 @@ static const struct net_device_ops mtk_netdev_ops = {
> >
> >  static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
> >  {
> > +     const char *label = of_get_property(np, "label", NULL);
> >       const __be32 *_id = of_get_property(np, "reg", NULL);
> >       phy_interface_t phy_mode;
> >       struct phylink *phylink;
> > @@ -2867,9 +2868,10 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
> >               return -EINVAL;
> >       }
> >
> > -     eth->netdev[id] = alloc_etherdev(sizeof(*mac));
> > +     eth->netdev[id] = alloc_netdev(sizeof(*mac), label ? label : "eth%d",
> > +                                    NET_NAME_UNKNOWN, ether_setup);
>
> 'label' is generally supposed to correspond to the sticker for the
> device connector for a human to id. I can't really tell if that's the
> case here. I don't see how 'gmacX' vs. 'ethX' maps to DSA master vs.
> slave.
The ports on devices such as Ubiquiti ER-X are named eth0 through
eth4, all of them DSA slaves. The gmac (DSA master) is hard-coded to
eth0 without this change.
>
> I don't think this should be handled within a specific driver either. If
> we're going to have a way to name things, then fix it in
> alloc_etherdev().
>
> It can also be argued that device naming for userspace is a userspace
> (udev) problem.
Yeah, that is a valid argument. We can drop this changeset if the
agreement is that it doesn't belong in the specific driver or the
kernel-space at all.
Some discussion (and device picture) here if you are interested:
https://github.com/openwrt/openwrt/pull/3971

Ilya
Frank Wunderlich April 21, 2021, 2:04 p.m. UTC | #3
Hi,

for dsa slave-ports there is already a property "label", but not for master/cpu-ports

https://elixir.bootlin.com/linux/v5.12-rc8/source/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts#L163

handled here:

https://elixir.bootlin.com/linux/v5.12-rc8/source/net/dsa/dsa2.c#L1113

@ilya maybe you can rename slave-ports instead of master-port without code change?

i also prefer a more generic way to name interfaces in dts, not only in the mtk-driver, but the udev-approach is a way too, but this needs to be configured on each system manually...a preset by kernel/dts will be nice (at least to distinguish master/cpu- and user-ports).

regards Frank
Rob Herring (Arm) April 21, 2021, 4:12 p.m. UTC | #4
On Wed, Apr 21, 2021 at 9:05 AM Frank Wunderlich
<frank-w@public-files.de> wrote:
>
> Hi,
>
> for dsa slave-ports there is already a property "label", but not for master/cpu-ports

Is that because slave ports are external and master are not? If so,
that makes sense.

> https://elixir.bootlin.com/linux/v5.12-rc8/source/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts#L163
>
> handled here:
>
> https://elixir.bootlin.com/linux/v5.12-rc8/source/net/dsa/dsa2.c#L1113
>
> @ilya maybe you can rename slave-ports instead of master-port without code change?
>
> i also prefer a more generic way to name interfaces in dts, not only in the mtk-driver, but the udev-approach is a way too, but this needs to be configured on each system manually...a preset by kernel/dts will be nice (at least to distinguish master/cpu- and user-ports).


Seems like it could be possible to want to distinguish port types for
reasons other than just what to name the device. Better to describe
that difference in DT and then base the device name off of that.

If you just want fixed numbering, then 'aliases' node is generally how
that is done (either because it sneaks in or fatigue from arguing
fixed /dev nodes are an anti-feature). There's already 'ethernetN'
which u-boot uses, but the kernel so far does not.

Rob