[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200814122744.GF17795@plvision.eu>
Date: Fri, 14 Aug 2020 15:27:44 +0300
From: Vadym Kochan <vadym.kochan@...ision.eu>
To: Jonathan McDowell <noodles@...th.li>
Cc: "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Jiri Pirko <jiri@...lanox.com>,
Ido Schimmel <idosch@...lanox.com>,
Andrew Lunn <andrew@...n.ch>,
Oleksandr Mazur <oleksandr.mazur@...ision.eu>,
Serhiy Boiko <serhiy.boiko@...ision.eu>,
Serhiy Pshyk <serhiy.pshyk@...ision.eu>,
Volodymyr Mytnyk <volodymyr.mytnyk@...ision.eu>,
Taras Chornyi <taras.chornyi@...ision.eu>,
Andrii Savka <andrii.savka@...ision.eu>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Andy Shevchenko <andy.shevchenko@...il.com>,
Mickey Rachamim <mickeyr@...vell.com>
Subject: Re: [net-next v4 1/6] net: marvell: prestera: Add driver for
Prestera family ASIC devices
On Fri, Aug 14, 2020 at 01:05:36PM +0100, Jonathan McDowell wrote:
> On Fri, Aug 14, 2020 at 11:20:54AM +0300, Vadym Kochan wrote:
> > On Thu, Aug 13, 2020 at 09:03:22AM +0100, Jonathan McDowell wrote:
> > > On Mon, Jul 27, 2020 at 03:22:37PM +0300, Vadym Kochan wrote:
> > > > Marvell Prestera 98DX326x integrates up to 24 ports of 1GbE with 8
> > > > ports of 10GbE uplinks or 2 ports of 40Gbps stacking for a largely
> > > > wireless SMB deployment.
> > > >
> > > > The current implementation supports only boards designed for the Marvell
> > > > Switchdev solution and requires special firmware.
> > > >
> > > > The core Prestera switching logic is implemented in prestera_main.c,
> > > > there is an intermediate hw layer between core logic and firmware. It is
> > > > implemented in prestera_hw.c, the purpose of it is to encapsulate hw
> > > > related logic, in future there is a plan to support more devices with
> > > > different HW related configurations.
> > >
> > > The Prestera range covers a lot of different silicon. 98DX326x appears
> > > to be AlleyCat3; does this driver definitely support all previous
> > > revisions too? I've started looking at some 98DX4122 (BobCat+) hardware
> > > and while some of the register mappings seem to match up it looks like
> > > the DSA tagging has some extra information at least.
> > >
> > > Worth making it clear exactly what this driver is expected to support,
> > > and possibly fix up the naming/device tree compatibles as a result.
> > >
> > Regarding "naming/device tree compatibles", do you mean to add
> > compatible matching for particular ASIC and also for common ?
> >
> > Currently
> >
> > compatible = "marvell,prestera"
> >
> > is used as default, so may be
> >
> > you mean to support few matching including particular silicon too, like ?
> >
> >
> > compatible = "marvell,prestera"
> > compatible = "marvell,prestera-ac3x"
> >
> > Would you please give an example ?
>
> AFAICT "Prestera" is the general name for the Marvell
> enterprise/data-centre silicon, comparable to the "LinkStreet"
> designation for their lower end switching. The mv88e* drivers do not
> mention LinkStreet in their compatible strings at all, choosing instead
> to refer to chip IDs (I see mv88e6085, mv88e6190 + mv88e6250).
>
> I do not have enough familiarity with the Prestera range to be able to
> tell what commonality there is between the different versions (it
> appears you need an NDA to get hold of the programming references), but
> even just looking at your driver and the vendor code for the BobCat it
> seems that AlleyCat3 uses an extended DSA header format, and requires a
> firmware with message based access, in comparison to the BobCat which
> uses register poking.
>
> Based on that I'd recommend not using the bare "marvell,prestera"
> compatible string, but instead something more specific.
> "marvell,prestera-ac3x" seems like a suitable choice, assuming that's
> how these chips are named/generally referred to.
>
> Also I'd expand your Kconfig information to actually include "Marvell
> Prestera 98DX326x" as that's the only supported chip range at present.
>
Yes, Prestera covers more range of devices. But it is planning to cover
other devices too, and currently there is no device-specific DTS
properties which are used in this version, but only the generic one -
since only the MAC address node.
I mean that if there will be other Prestera devices supported then it
will require to extend the DTS matching string in the driver just to
support the same generic DTS properties for new device.
Anyway I will rise and discuss this question.
Thanks,
Powered by blists - more mailing lists