Message ID | 20190324032346.32394-1-olteanv@gmail.com |
---|---|
Headers | show |
Series | NXP SJA1105 DSA driver | expand |
On 3/23/19 8:23 PM, Vladimir Oltean wrote: > 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. Overall this is a very clean and impressive piece of work, especially given the constraints you have to work with, I will follow-up with comments in individual patches thanks Vladimir! > > Vladimir Oltean (13): > lib: Add support for generic packing operations > net: dsa: Store vlan_filtering as a property of dsa_port > net: dsa: Create a more convenient function for installing port VLANs > net: dsa: Call driver's setup callback after setting up its switchdev > notifier > net: dsa: Optional VLAN-based port separation for switches without > tagging > net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch > net: dsa: sja1105: Add support for FDB and MDB management > net: dsa: sja1105: Add support for VLAN operations > net: dsa: sja1105: Add support for ethtool port counters > net: dsa: sja1105: Add support for traffic through standalone ports > net: dsa: sja1105: Add support for Spanning Tree Protocol > Documentation: networking: dsa: Add details about NXP SJA1105 driver > dt-bindings: net: dsa: Add documentation for NXP SJA1105 driver > > .../devicetree/bindings/net/dsa/sja1105.txt | 123 ++ > Documentation/networking/dsa/sja1105.txt | 83 + > Documentation/packing.txt | 150 ++ > MAINTAINERS | 14 + > drivers/net/dsa/Kconfig | 2 + > drivers/net/dsa/Makefile | 1 + > drivers/net/dsa/sja1105/Kconfig | 17 + > drivers/net/dsa/sja1105/Makefile | 10 + > drivers/net/dsa/sja1105/sja1105.h | 148 ++ > drivers/net/dsa/sja1105/sja1105_clocking.c | 677 ++++++ > .../net/dsa/sja1105/sja1105_dynamic_config.c | 607 ++++++ > .../net/dsa/sja1105/sja1105_dynamic_config.h | 40 + > drivers/net/dsa/sja1105/sja1105_ethtool.c | 420 ++++ > drivers/net/dsa/sja1105/sja1105_main.c | 1580 ++++++++++++++ > drivers/net/dsa/sja1105/sja1105_spi.c | 667 ++++++ > .../net/dsa/sja1105/sja1105_static_config.c | 1810 +++++++++++++++++ > .../net/dsa/sja1105/sja1105_static_config.h | 500 +++++ > include/linux/dsa/sja1105.h | 52 + > include/linux/packing.h | 49 + > include/net/dsa.h | 6 + > lib/Makefile | 2 +- > lib/packing.c | 211 ++ > net/dsa/Kconfig | 12 + > net/dsa/Makefile | 2 + > net/dsa/dsa.c | 6 + > net/dsa/dsa2.c | 8 +- > net/dsa/dsa_priv.h | 15 + > net/dsa/port.c | 36 +- > net/dsa/slave.c | 16 +- > net/dsa/tag_8021q.c | 185 ++ > net/dsa/tag_sja1105.c | 142 ++ > 31 files changed, 7568 insertions(+), 23 deletions(-) > create mode 100644 Documentation/devicetree/bindings/net/dsa/sja1105.txt > create mode 100644 Documentation/networking/dsa/sja1105.txt > create mode 100644 Documentation/packing.txt > create mode 100644 drivers/net/dsa/sja1105/Kconfig > create mode 100644 drivers/net/dsa/sja1105/Makefile > create mode 100644 drivers/net/dsa/sja1105/sja1105.h > create mode 100644 drivers/net/dsa/sja1105/sja1105_clocking.c > create mode 100644 drivers/net/dsa/sja1105/sja1105_dynamic_config.c > create mode 100644 drivers/net/dsa/sja1105/sja1105_dynamic_config.h > create mode 100644 drivers/net/dsa/sja1105/sja1105_ethtool.c > create mode 100644 drivers/net/dsa/sja1105/sja1105_main.c > create mode 100644 drivers/net/dsa/sja1105/sja1105_spi.c > create mode 100644 drivers/net/dsa/sja1105/sja1105_static_config.c > create mode 100644 drivers/net/dsa/sja1105/sja1105_static_config.h > create mode 100644 include/linux/dsa/sja1105.h > create mode 100644 include/linux/packing.h > create mode 100644 lib/packing.c > create mode 100644 net/dsa/tag_8021q.c > create mode 100644 net/dsa/tag_sja1105.c >
Hi Vladmir, Vladimir Oltean <olteanv@gmail.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
On Tue, 26 Mar 2019 at 19:30, Vinicius Costa Gomes <vinicius.gomes@intel.com> wrote: > > Hi Vladmir, > > Vladimir Oltean <olteanv@gmail.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