[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ftr9fsqw.fsf@intel.com>
Date: Tue, 26 Mar 2019 10:30:31 -0700
From: Vinicius Costa Gomes <vinicius.gomes@...el.com>
To: Vladimir Oltean <olteanv@...il.com>, davem@...emloft.net,
netdev@...r.kernel.org
Cc: f.fainelli@...il.com, andrew@...n.ch, vivien.didelot@...il.com,
linus.walleij@...aro.org, Vladimir Oltean <olteanv@...il.com>
Subject: Re: [RFC PATCH net-next 00/13] NXP SJA1105 DSA driver
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
Powered by blists - more mailing lists