Message-ID: <CA+h21hrPAhF9=KHLH2S-+1krg4qB55yYCw4_eo+TVL3BKwrsuw@mail.gmail.com>
Date:   Tue, 26 Mar 2019 20:07:27 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Vinicius Costa Gomes <vinicius.gomes@...el.com>
Cc:     davem@...emloft.net, netdev <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>, vivien.didelot@...il.com,
        Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [RFC PATCH net-next 00/13] NXP SJA1105 DSA driver

On Tue, 26 Mar 2019 at 19:30, Vinicius Costa Gomes
<vinicius.gomes@...el.com> wrote:
>
> Hi Vladmir,
>
> Vladimir Oltean <olteanv@...il.com> writes:
>
> > This patchset adds a DSA driver for the SPI-managed NXP SJA1105 driver.
> > Due to the hardware's unfriendliness, most of its state needs to be
> > shadowed in kernel memory by the driver. To support this and keep a
> > decent amount of cleanliness in the code, a new generic API for
> > converting between CPU-accessible ("unpacked") structures and
> > hardware-accessible ("packed") structures is proposed and used.
> >
> > Then several small modifications are done to the DSA core, like changing
> > the order of two calls during initialization, or permitting driver
> > access to the dp->vlan_filtering property.
> >
> > These small modifications are done for the greater goal of adding
> > support for 802.1Q pseudo-switch tagging. The limitations of this type
> > of tagging are discussed in the commit that adds it, and in the code
> > comments.
> >
> > The SJA1105 driver then proceeds to extend this 8021q switch tagging
> > protocol while adding its own (tag_sja1105). This is done because
> > SJA1105 needs SPI intervention during transmission of link-local
> > traffic, which cannot be done from the xmit handler but requires a
> > deferred worker thread.
> >
> > The driver is GPL-2.0 licensed. The source code files which are licensed
> > as BSD-3-Clause are hardware support files and derivative of the
> > userspace NXP sja1105-tool program, which is BSD-3-Clause licensed.
> >
> > TODO items:
> > * Add full support for the P/Q/R/S series. The patches were mostly
> >   tested on a first-generation T device.
> > * Add timestamping support and PTP clock manipulation.
> > * Figure out what the current state of tc-taprio hw offload is, and
> >   attempt to configure the switch's time-aware scheduler using that.
>
> At this point, there's no support for hw offloading in taprio. I am
> planning on sending an RFC suggesting a interface soon (this week, I
> hope). That RFC should at least be useful to get this conversation
> started.
>
> By the way, Is there a publicly available datasheet I can take a look?
>
>
> Cheers,
> --
> Vinicius


Hi Vinicius,

I knew you'd appear at some point since I mentioned tc-taprio offload :)
The documentation for the 1st generation SJA1105 switches is at
https://www.nxp.com/docs/en/user-guide/UM10944.pdf (for the 2nd
generation it is not publicly available, but for the most part it's
the same IP).
It's not a perfect match with 802.1Qbv and there are some (perhaps
workable) limitations, but it does offer the concept of scheduled
transmission (8 gated traffic classes per port) based on a PTP clock.
Do send your RFC and feel free to ignore the SJA1105 implementation
for now, since it would probably only cause endless confusion anyway.
:)
I myself am a bit conflicted about how traffic would be scheduled
in-band with the hardware Qbv window (PHC time domain) but that is
more a question about software architecture rather than hardware
details, so I'm really eager to see your proposal.

Thanks!
-Vladimir

Powered by blists - more mailing lists