From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f179.google.com ([209.85.128.179]:38285 "EHLO mail-wr0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751719AbeCXHpx (ORCPT ); Sat, 24 Mar 2018 03:45:53 -0400 Received: by mail-wr0-f179.google.com with SMTP id m13so844639wrj.5 for ; Sat, 24 Mar 2018 00:45:53 -0700 (PDT) Date: Sat, 24 Mar 2018 08:45:51 +0100 From: Jiri Pirko To: Andrew Lunn Cc: netdev@vger.kernel.org, davem@davemloft.net, idosch@mellanox.com, jakub.kicinski@netronome.com, mlxsw@mellanox.com, vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com, michael.chan@broadcom.com, ganeshgr@chelsio.com, saeedm@mellanox.com, simon.horman@netronome.com, pieter.jansenvanvuuren@netronome.com, john.hurley@netronome.com, dirk.vandermerwe@netronome.com, alexander.h.duyck@intel.com, ogerlitz@mellanox.com, dsahern@gmail.com, vijaya.guvva@cavium.com, satananda.burla@cavium.com, raghu.vatsavayi@cavium.com, felix.manlunas@cavium.com, gospo@broadcom.com, sathya.perla@broadcom.com, vasundhara-v.volam@broadcom.com, tariqt@mellanox.com, eranbe@mellanox.com, jeffrey.t.kirsher@intel.com Subject: Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation Message-ID: <20180324074551.GD1891@nanopsycho> References: <20180322105522.8186-1-jiri@resnulli.us> <20180323134357.GG5145@lunn.ch> <20180323145935.GC2125@nanopsycho> <20180323152412.GC24361@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180323152412.GC24361@lunn.ch> Sender: netdev-owner@vger.kernel.org List-ID: Fri, Mar 23, 2018 at 04:24:12PM CET, andrew@lunn.ch wrote: >On Fri, Mar 23, 2018 at 03:59:35PM +0100, Jiri Pirko wrote: >> Fri, Mar 23, 2018 at 02:43:57PM CET, andrew@lunn.ch wrote: >> >> I tested this for mlxsw and nfp. I have no way to test this on DSA hw, >> >> I would really appretiate DSA guys to test this. >> > >> >Hi Jiri >> > >> >With the missing break added, i get: >> > >> >root@zii-devel-b:~# ./iproute2/devlink/devlink port >> >mdio_bus/0.1:00/0: type eth netdev lan0 flavour physical number 0 >> >mdio_bus/0.1:00/1: type eth netdev lan1 flavour physical number 1 >> >mdio_bus/0.1:00/2: type eth netdev lan2 flavour physical number 2 >> >mdio_bus/0.1:00/3: type notset >> >mdio_bus/0.1:00/4: type notset >> >mdio_bus/0.1:00/5: type notset flavour dsa number 5 >> >mdio_bus/0.1:00/6: type notset flavour cpu number 6 >> >mdio_bus/0.2:00/0: type eth netdev lan3 flavour physical number 0 >> >mdio_bus/0.2:00/1: type eth netdev lan4 flavour physical number 1 >> >mdio_bus/0.2:00/2: type eth netdev lan5 flavour physical number 2 >> >mdio_bus/0.2:00/3: type notset >> >mdio_bus/0.2:00/4: type notset >> >mdio_bus/0.2:00/5: type notset flavour dsa number 5 >> >mdio_bus/0.2:00/6: type notset flavour dsa number 6 >> >mdio_bus/0.4:00/0: type eth netdev lan6 flavour physical number 0 >> >mdio_bus/0.4:00/1: type eth netdev lan7 flavour physical number 1 >> >mdio_bus/0.4:00/2: type eth netdev lan8 flavour physical number 2 >> >mdio_bus/0.4:00/3: type eth netdev optical3 flavour physical number 3 >> >mdio_bus/0.4:00/4: type eth netdev optical4 flavour physical number 4 >> >mdio_bus/0.4:00/5: type notset >> >mdio_bus/0.4:00/6: type notset >> >mdio_bus/0.4:00/7: type notset >> >mdio_bus/0.4:00/8: type notset >> >mdio_bus/0.4:00/9: type notset flavour dsa number 9 > >> That is basically front panel number for physical ports. > >You cannot make that assumption. As you can see here, we have 3 ports >with the number 0. > >Look at clearfog, armada-388-clearfog.dts. port 0=lan5, port 1=lan4 >port 2=lan3, port 3=lan2, port 4=lan1, port 5=cpu, port 6=lan6. > >The hardware and mechanical engineer is free to wire switch ports to >the front panel however they want. That is why we put the netdev name >in device tree. Got it. Hmm, so I think that the port number can be made optional and when it is present, it would be used to generate phys_port_name. If not, perhaps devlink port index could be used instead. So iiuc, you don't really need phys_port_name in dsa, as it provides misleading names, right? Why is it implemented then? > > Andrew