[net-next,0/7] add support for VSC8584 and VSC8574 Microsemi quad-port PHYs

Both PHYs are 4-port PHY that are 10/100/1000BASE-T, 100BASE-FX, 1000BASE-X
and triple-speed copper SFP capable, can communicate with the MAC via
SGMII, QSGMII or 1000BASE-X, supports downshifting and can set the blinking
pattern of each of its 4 LEDs, supports SyncE as well as HP Auto-MDIX
detection.

VSC8574 supports WOL and VSC8584 supports hardware offloading of MACsec.

This patch series add support for 10/100/1000BASE-T, SGMII/QSGMII link with
the MAC, downshifting, HP Auto-MDIX detection and blinking pattern for
their 4 LEDs.

They have also an internal Intel 8051 microcontroller whose firmware needs
to be patched when the PHY is reset. If the 8051's firmware has the
expected CRC, its patching can be skipped. The microcontroller can be
accessed from any port of the PHY, though the CRC function can only be done
through the PHY that is the base PHY of the package (internal address 0)
due to a limitation of the firmware.

The GPIO register bank is a set of registers that are common to all PHYs in
the package. So any modification in any register of this bank affects all
PHYs of the package.

If the PHYs haven't been reset before booting the Linux kernel and were
configured to use interrupts for e.g. link status updates, it is required
to clear the interrupts mask register of all PHYs before being able to use
interrupts with any PHY. The first PHY of the package that will be init
will take care of clearing all PHYs interrupts mask registers. Thus, we
need to keep track of the init sequence in the package, if it's already
been done or if it's to be done.

Most of the init sequence of a PHY of the package is common to all PHYs in
the package, thus we use the SMI broadcast feature which enables us to
propagate a write in one register of one PHY to all PHYs in the package.

We also introduce a new development board called PCB120 which exists in
variants for VSC8584 and VSC8574 (and that's the only difference to the
best of my knowledge).

I suggest patches 1 to 4 go through net tree and patches 5 to 7 go through
MIPS tree. Patches going through net tree and those going through MIPS tree
do not depend on one another.

This patch series depends on two patch series though:
"mscc: ocelot: add support for SerDes muxing configuration"
(https://lore.kernel.org/lkml/cover.ff40d591b548a6da31716e6e600f11a303e0e643.1536912834.git-series.quentin.schulz@bootlin.com/)
"Various improvements to Microsemi PHY driver"
(https://lore.kernel.org/lkml/cover.616d15610d44a0e3d463acd8119859f243163ad2.1536913944.git-series.quentin.schulz@bootlin.com/)
specifically patch 2/5 which defines constants that are used in this patch
series.

Thanks,
Quentin

Quentin Schulz (7):
  dt-bindings: net: vsc8531: add two additional LED modes for VSC8584
  net: phy: mscc: add support for VSC8584 PHY
  net: phy: mscc: split config_init in two functions for VSC8584
  net: phy: mscc: add support for VSC8574 PHY
  MIPS: mscc: ocelot: add GPIO4 pinmuxing DT node
  MIPS: mscc: add DT for Ocelot PCB120
  MIPS: mscc: add PCB120 to the ocelot fitImage

 arch/mips/boot/dts/mscc/Makefile            |    2 +-
 arch/mips/boot/dts/mscc/ocelot.dtsi         |    5 +-
 arch/mips/boot/dts/mscc/ocelot_pcb120.dts   |  100 ++-
 arch/mips/generic/Kconfig                   |    6 +-
 arch/mips/generic/Platform                  |    2 +-
 arch/mips/generic/board-ocelot.its.S        |   40 +-
 arch/mips/generic/board-ocelot_pcb123.its.S |   23 +-
 drivers/net/phy/mscc.c                      | 1019 ++++++++++++++++++++-
 include/dt-bindings/net/mscc-phy-vsc8531.h  |    2 +-
 9 files changed, 1171 insertions(+), 28 deletions(-)
 create mode 100644 arch/mips/boot/dts/mscc/ocelot_pcb120.dts
 create mode 100644 arch/mips/generic/board-ocelot.its.S
 delete mode 100644 arch/mips/generic/board-ocelot_pcb123.its.S

base-commit: d9cca8eef36bb8918c9ed28574b79b7674fd36f6

Just as a drive-by comment this seems vaguely related to the Vitesse
DSA switch I merged in drivers/net/dsa/vitesse-vsc73xx.c
The VSC* product name handily gives away the origin in Vitesse's
product line.

The VSC73xx also have the 8051 CPU and internal RAM, but are
accessed (typically) over SPI, and AFAICT this thing is talking over
MDIO.

The Vitesse 73xx however also supports a WAN port and VLANs
which makes it significantly different, falling into switch class I
guess.

These VSC85*4's does have an SPI interface as well, according
to the data sheet but I assume your target boards don't even
connect it?

When it comes to 8051 code we have quite a lot of this in the kernel
these days, I suspect the 8051 snippets in this code could be
disassembled and put into linux-firmware in source form, but
that is maybe a bit overly ambitious. We have done that for a few
USB to serial controllers using the EzUSB 8051 though:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/keyspan_pda
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/usbdux

These can rebuild their firmware using the as31 assembler.
https://github.com/nitsky/as31

Yours,
Linus Walleij

Hi Linus,

I'm Allan, working for Microchip, who acquired Microsemi, who acquired Vitesse.

Alexandre pointed me to your comments on the VSC7384 switch done by Vitesse ~15
years ago. BTW: the chip is not being sold any more, and is unlikely to turn up
in new products.

I managed to find the complete datasheet of this device, and convincing people
that it can be "opened-up" meaning that it is available without any NDA or
similar. It is a 1.2mb/200 page pdf, it is not avialable at any web page (that I
know of), but if you are interested in having it then I can send it in a mail to
you.

The 09/20/2018 14:38, Linus Walleij wrote:
> Just as a drive-by comment this seems vaguely related to the Vitesse
> DSA switch I merged in drivers/net/dsa/vitesse-vsc73xx.c
> The VSC* product name handily gives away the origin in Vitesse's
> product line.
> 
> The VSC73xx also have the 8051 CPU and internal RAM, but are
> accessed (typically) over SPI, and AFAICT this thing is talking over
> MDIO.
> 
> The Vitesse 73xx however also supports a WAN port and VLANs
> which makes it significantly different, falling into switch class I
> guess.
That is right, here are the list of feature from page 1 in the datasheet.

Features:
- 12 Gigabit Ethernet ports with nonblocking wire- speed performance
- IEEE802.1Q-in-Q nested VLAN support
- Tri-speed (10/100/1000 Mbps) RGMII interfaces
- Full duplex flow control (IEEE802.3x) and half duplex back pressure
- Support for both wire-speed automatic learning, and CPU-based learning
- Flexible link aggregation compliant with IEEE802.3ad
- 208 kB on-chip frame buffer
- Spanning Tree Protocol support (IEEE802.1D)
- Jumbo frame support
- Multiple Spanning Tree support (IEEE802.1s)
- Programmable classifier for QoS (Layer 4/Multimedia) into four classes of
  service
- Port-based Access Control (IEEE802.1X)
- IGMP, GARP, GMRP, and GVRP support
- 8192 MAC addresses and 4,096 VLAN support (IEEE802.1Q)
- Cost effective 4-pin serial CPU interface
- Per-port shaping, policing, and Broadcast and Multicast Storm Control
- Selection between on-chip 8051 CPU, or off-chip 8-bit or 16-bit CPU for SNMP
  and Web-based management

/Allan

On Thu, Oct 11, 2018 at 8:18 AM Allan W. Nielsen
<allan.nielsen@microchip.com> wrote:

> I'm Allan, working for Microchip, who acquired Microsemi, who acquired Vitesse.

Thanks Allan, it's nice to have vendors involved :)

> Alexandre pointed me to your comments on the VSC7384 switch done by Vitesse ~15
> years ago. BTW: the chip is not being sold any more, and is unlikely to turn up
> in new products.

Yeah, it's just us enthusiasts who maintain the old chips. It's nice, because
since they don't have very shiny new features, it is often a bliss to add
proper kernel support these days since the subsystems improved and
they become very good proofs of concept.

> I managed to find the complete datasheet of this device, and convincing people
> that it can be "opened-up" meaning that it is available without any NDA or
> similar. It is a 1.2mb/200 page pdf, it is not avialable at any web page (that I
> know of), but if you are interested in having it then I can send it in a mail to
> you.

I'd be delighted to have a look! I hope my mailbox survives that, otherise
sharing it on Google drive works fine.

Yours,
Linus Walleij