Re: [RFC PATCH vN net-next 2/2] net: mscc: ocelot: add support for VSC75XX SPI control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > This function seems out of place. Why would SPI access change what the
> > ports are capable of doing? Please split this up into more
> > patches. Keep the focus of this patch as being adding SPI support.
> 
> What is going on is that this is just the way in which the drivers are
> structured. Colin is not really "adding SPI support" to any of the
> existing DSA switches that are supported (VSC9953, VSC9959) as much as
> "adding support for a new switch which happens to be controlled over
> SPI" (VSC7512).
> The layering is as follows:
> - drivers/net/dsa/ocelot/felix_vsc7512_spi.c: deals with the most
>   hardware specific SoC support. The regmap is defined here, so are the
>   port capabilities.
> - drivers/net/dsa/ocelot/felix.c: common integration with DSA
> - drivers/net/ethernet/mscc/ocelot*.c: the SoC-independent hardware
>   support.

Hi Vladimir

I took a quick look at the data sheet. It says in section 2.1.5
Management:

  External access to registers through PCIe, SPI, MIIM, or through an
  Ethernet port with inline Microsemi’s Versatile Register Access
  Protocol (VRAP)

So maybe the basic 7512 support should be separate from how you access
the registers, so that somebody can later add MMIO or MDIO support?

    Andrew

P.S.

I did not know about VRAP. Marvell has something similar. It would be
nice to put together some shared generic code to support
this. Statistics would really benefit from it.



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux