Message-ID: <20210507084757.eau5camvi26ub2i3@skbuf>
Date:   Fri, 7 May 2021 11:47:57 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Colin Foster <colin.foster@...advantage.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        "supporter:OCELOT ETHERNET SWITCH DRIVER" 
        <UNGLinuxDriver@...rochip.com>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:OCELOT ETHERNET SWITCH DRIVER" <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH vN net-next 2/2] net: mscc: ocelot: add support for
 VSC75XX SPI control

On Thu, May 06, 2021 at 11:34:18AM -0700, Colin Foster wrote:
> Vladimir, Thank you very much for the feedback. I appreciate your time
> and your patience when dealing with my many blunders. This is a large
> learning experience for me.

You haven't seen mine...

> On Thu, May 06, 2021 at 01:22:04PM +0300, Vladimir Oltean wrote:
> > On Mon, May 03, 2021 at 10:11:27PM -0700, Colin Foster wrote:
> > > Add support for control for VSC75XX chips over SPI control. Starting with the
> > > VSC9959 code, this will utilize a spi bus instead of PCIe or memory-mapped IO to
> > > control the chip.
> > > 
> > > Signed-off-by: Colin Foster <colin.foster@...advantage.com>
> > > ---
> > >  arch/arm/boot/dts/rpi-vsc7512-spi-overlay.dts |  124 ++
> > >  drivers/net/dsa/ocelot/Kconfig                |   11 +
> > >  drivers/net/dsa/ocelot/Makefile               |    5 +
> > >  drivers/net/dsa/ocelot/felix_vsc7512_spi.c    | 1214 +++++++++++++++++
> > >  include/soc/mscc/ocelot.h                     |   15 +
> > >  5 files changed, 1369 insertions(+)
> > >  create mode 100644 arch/arm/boot/dts/rpi-vsc7512-spi-overlay.dts
> > >  create mode 100644 drivers/net/dsa/ocelot/felix_vsc7512_spi.c
> > > 
> > > diff --git a/drivers/net/dsa/ocelot/Kconfig b/drivers/net/dsa/ocelot/Kconfig
> > > index 932b6b6fe817..2db147ce9fe7 100644
> > > --- a/drivers/net/dsa/ocelot/Kconfig
> > > +++ b/drivers/net/dsa/ocelot/Kconfig
> > > @@ -14,6 +14,17 @@ config NET_DSA_MSCC_FELIX
> > >  	  This driver supports the VSC9959 (Felix) switch, which is embedded as
> > >  	  a PCIe function of the NXP LS1028A ENETC RCiEP.
> > >  
> > > +config NET_DSA_MSCC_FELIX_SPI
> > > +	tristate "Ocelot / Felix Ethernet SPI switch support"
> > > +	depends on NET_DSA && SPI
> > > +	depends on NET_VENDOR_MICROSEMI
> > > +	select MSCC_OCELOT_SWITCH_LIB
> > > +	select NET_DSA_TAG_OCELOT_8021Q
> > > +	select NET_DSA_TAG_OCELOT
> > > +	select PCS_LYNX
> > 
> > You most probably don't need to select PCS_LYNX (that's an NXP thing).
> > For that reason, you might want to call your module NET_DSA_MSCC_OCELOT_SPI.
> > The "felix" name is just the name of the common DSA driver and of the
> > VSC9959 chip. VSC7512 is probably called Ocelot-1 according to Microchip
> > marketing.
> 
> Thank you. I couldn't find where "Felix" and "Seville" actually came
> from. My next RFC submission will include these changes.

felix = code name for the VSC9959 from NXP LS1028A, derivative of Ocelot-1
seville = code name for the VSC9953 from NXP T1040, derivative of Serval-1

The common DSA driver layer is called felix because felix was the first
switch it supported. But since probing is now handled individually and
the PCIe probing of felix is done in a different driver compared to the
platform device probing of seville, you can name your VSC7512 driver in
any way you feel appropriate.

> > I'm surprised that the reset procedure for VSC7512 is different than
> > what is implemented in ocelot_reset() for VSC7514.
> 
> I will look more into this and repair as needed. I'm also considering
> the ability to use a GPIO as an external reset, which might negate any
> reset procedure the MIPS would be doing.

I think some memories need to be initialized too, not sure if you can
achieve that with a reset pin only.

> > You must be working on an old kernel or something. There's also a
> > watermark decode function which you can reuse from ocelot (ocelot_wm_dec).
> 
> Yes, my proof-of-concept was from a 5.10 kernel. I brought it up to
> mainline before submitting the patch and must have missed this. Per the
> documentation, I'll base my next submission entirely on the latest 5.12
> release.

What you actually mean when you set the patch subject prefix to
"PATCH net-next" is that your patches can be applied to the current
master branch of this tree, not on any release tree:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/

The official kernel tag v5.12 has just been released, and kernel v5.13
entered release candidate status (starting with rc1 and ending with rc7
or rc8, depending on how many fixes it gets). The development process
happens simultaneously with the release candidates for the official
v5.13 release, but new development is done for v5.14 only (that's why it
is called "next"). When Linus decides that the v5.13 release candidates
are mature enough to print the v5.13 final release tag, development for
v5.14 stops too, the maintainers stop accepting development patches for
a little while, everybody prepares a pull request, there is a "memory
barrier" until the official v5.14 rc1 is released which contains all
pull requests with new features from the maintainers' development trees,
and then these "next" trees reopen for development that will be included
in v5.15.

This is a bit oversimplified, but hopefully it should give you an idea
why sometimes you are told to rebase on a different tree, or why you
can't send patches right now, etc.

> > > +static int felix_spi_remove(struct spi_device *pdev)
> > > +{
> > > +	struct felix *felix;
> > > +
> > > +	felix = spi_get_drvdata(pdev);
> > > +
> > > +	return 0;
> > > +}
> > 
> > You got bored of writing code here? :)
> 
> A bad habit of mine. I'm trying to test the code as I'm writing it.
> Communication doesn't work, so I can't get past probe. I'm excited for
> the day I can see this memory leak in action.
> 
> I'll repair this for RFC V2, regardless of whether I can test it.

By testing, you mean this?

echo spiN.M > /sys/bus/spi/drivers/vsc7512/unbind
echo spiN.M > /sys/bus/spi/drivers/vsc7512/bind

(where of course, N is the bus number and M is the chip select)

Powered by blists - more mailing lists