netdev - Re: [PATCH net-next 10/12] net: dsa: vitesse: move vsc73xx driver to a separate folder

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: <20191113084722.GI3572@piout.net>
Date:   Wed, 13 Nov 2019 09:47:22 +0100
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     "Allan W. Nielsen" <allan.nielsen@...rochip.com>
Cc:     Vladimir Oltean <olteanv@...il.com>, Andrew Lunn <andrew@...n.ch>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        "David S. Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Joergen Andreasen <joergen.andreasen@...rochip.com>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        netdev <netdev@...r.kernel.org>,
        Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH net-next 10/12] net: dsa: vitesse: move vsc73xx driver to
 a separate folder

On 13/11/2019 08:38:22+0100, Allan W. Nielsen wrote:
> > > > The way I see an Ocelot DSA driver, it would be done a la mv88e6xxx,
> > > > aka a single struct dsa_switch_ops registered for the entire family,
> > > > and function pointers where the implementation differs. You're not
> > > > proposing that here, but rather that each switch driver works in
> > > > parallel with each other, and they all call into the Ocelot core. That
> > > > would produce a lot more boilerplate, I think.
> > > > And if the DSA driver for Ocelot ends up supporting more than 1
> > > > device, its name should better not contain "vsc9959" since that's
> > > > rather specific.
> > > A vsc7511/12 will not share code with felix/vsc9959. I do not expect any other
> > > IP/chip will be register compatible with vsc9959.
> > I don't exactly understand this comment. Register-incompatible in a
> > logical sense, or in a layout sense? Judging from the attachment in
> > chapter 6 of the VSC7511 datasheet [1], at least the basic
> > functionality appears to be almost the same. And for the rest, there's
> > regmap magic.
> My point is that vsc7511 has more in commen with vsc7514 than it has with
> felix/vsc9959.
> 
> vsc7511 will use the same regmaps as those in vsc7514 (with different helper
> functions as it will be accessing the reguster via SPI).
> 

regmap will properly abstract the underlying bus, this was the whole
point of using it.


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com