netdev - Re: [PATCH 0/7] ethtool: add pretty dump for DSA mv88e6xxx drivers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181216125740.GB2063@slim.localdomain>
Date:   Sun, 16 Dec 2018 12:57:40 -0500
From:   Vivien Didelot <vivien.didelot@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     netdev@...r.kernel.org, Chris Healy <cphealy@...il.com>,
        "John W . Linville" <linville@...driver.com>, andrew@...n.ch
Subject: Re: [PATCH 0/7] ethtool: add pretty dump for DSA mv88e6xxx drivers

On Sat, 15 Dec 2018 09:28:41 -0800, Florian Fainelli <f.fainelli@...il.com> wrote:

> > The first patch adds the base support for "dsa" interfaces.
> > 
> > The second patch adds the boilerplate for the "mv88e6xxx" DSA driver,
> > all using 32 registers of 16 bits, the switch ID being available in
> > the port identification register 3. Support for other DSA drivers such
> > as "b53" or "ksz" can be added similarly later. Because the different
> > switches supported by mv88e6xxx have slightly different register layout,
> > we keep it simple and stupid by providing one dump function per switch.
> 
> This looks good to me, the only "concern" is that mv88e6xxx set
> regs->version = 0, while we could probably put the switch model in there
> directly which would avoid other drivers to have to put the chip ID in
> regs[3] since that may, or may not be convenient.

Note that the driver doesn't put the chip ID in regs[3], that is just
how Marvell registers are organized, chip ID are in port register 3
of all models.

> For instance the B53 devices are organized by page (0-255), and then by
> offsets (0-255 again). Within a page, there are registers that are
> really per-port and some that are global. Also, registers can be
> 8/16/32/48/64 bits (which is going to be interesting to support).

Thanks,
Vivien