lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180323152412.GC24361@lunn.ch>
Date:   Fri, 23 Mar 2018 16:24:12 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, idosch@...lanox.com,
        jakub.kicinski@...ronome.com, mlxsw@...lanox.com,
        vivien.didelot@...oirfairelinux.com, f.fainelli@...il.com,
        michael.chan@...adcom.com, ganeshgr@...lsio.com,
        saeedm@...lanox.com, simon.horman@...ronome.com,
        pieter.jansenvanvuuren@...ronome.com, john.hurley@...ronome.com,
        dirk.vandermerwe@...ronome.com, alexander.h.duyck@...el.com,
        ogerlitz@...lanox.com, dsahern@...il.com, vijaya.guvva@...ium.com,
        satananda.burla@...ium.com, raghu.vatsavayi@...ium.com,
        felix.manlunas@...ium.com, gospo@...adcom.com,
        sathya.perla@...adcom.com, vasundhara-v.volam@...adcom.com,
        tariqt@...lanox.com, eranbe@...lanox.com,
        jeffrey.t.kirsher@...el.com
Subject: Re: [patch net-next RFC 00/12] devlink: introduce port flavours and
 common phys_port_name generation

On Fri, Mar 23, 2018 at 03:59:35PM +0100, Jiri Pirko wrote:
> Fri, Mar 23, 2018 at 02:43:57PM CET, andrew@...n.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@...-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.

    Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ