Date:   Tue, 12 Nov 2019 02:53:26 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        "David S. Miller" <davem@...emloft.net>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Joergen Andreasen <joergen.andreasen@...rochip.com>,
        "Allan W. Nielsen" <allan.nielsen@...rochip.com>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        netdev <netdev@...r.kernel.org>,
        Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH net-next 15/15] net: mscc: ocelot: don't hardcode the
 number of the CPU port

On Sun, 10 Nov 2019 at 22:54, Florian Fainelli <f.fainelli@...il.com> wrote:
>
>
>
> On 11/10/2019 9:33 AM, Vladimir Oltean wrote:
> > On Sun, 10 Nov 2019 at 19:12, Andrew Lunn <andrew@...n.ch> wrote:
> >>
> >> On Sun, Nov 10, 2019 at 07:00:33PM +0200, Vladimir Oltean wrote:
> >>> On Sun, 10 Nov 2019 at 18:50, Andrew Lunn <andrew@...n.ch> wrote:
> >>>>
> >>>> On Sat, Nov 09, 2019 at 03:03:01PM +0200, Vladimir Oltean wrote:
> >>>>> From: Vladimir Oltean <vladimir.oltean@....com>
> >>>>>
> >>>>> VSC7514 is a 10-port switch with 2 extra "CPU ports" (targets in the
> >>>>> queuing subsystem for terminating traffic locally).
> >>>>
> >>>> So maybe that answers my last question.
> >>>>
> >>>>> There are 2 issues with hardcoding the CPU port as #10:
> >>>>> - It is not clear which snippets of the code are configuring something
> >>>>>   for one of the CPU ports, and which snippets are just doing something
> >>>>>   related to the number of physical ports.
> >>>>> - Actually any physical port can act as a CPU port connected to an
> >>>>>   external CPU (in addition to the local CPU). This is called NPI mode
> >>>>>   (Node Processor Interface) and is the way that the 6-port VSC9959
> >>>>>   (Felix) switch is integrated inside NXP LS1028A (the "local management
> >>>>>   CPU" functionality is not used there).
> >>>>
> >>>> So i'm having trouble reading this and spotting the difference between
> >>>> the DSA concept of a CPU port and the two extra "CPU ports". Maybe
> >>>> using the concept of virtual ports would help?
> >>>>
> >>>> Are the physical ports number 0-9, and so port #10 is the first extra
> >>>> "CPU port", aka a virtual port? And so that would not work for DSA,
> >>>> where you need a physical port.
> >>>>
> >>>>       Andrew
> >>>
> >>> Right. See my other answer which links to Ocelot documentation.
> >>
> >> Yes, i'm getting the picture now.
> >>
> >> The basic problem is that in the Linux kernel CPU port has a specific
> >> meaning, and it is clashing with the meaning used in the datasheet. So
> >> maybe in the driver, we need to refer to these two ports as 'local
> >> ports'?
> >>
> >
> > Hmm, I don't know. Both types of CPU ports lead to management CPUs,
> > but to different types of them. I understand the clash with the DSA
> > meaning, but even if I rename it I would have to provide an
> > explanation relative to the datasheet definitions (and I already
> > explain that the NPI mode is the DSA type of CPU port). I'm not sure
> > there is a net gain.
>
> Maybe we need to agree on renaming DSA's CPU port to "mgmt_port" or
> something that indicates that there is in-band signaling to help support
> the function of managing the switch, incidentally Broadcom switches call
> their ports In-Band Management Port (IMP) which is clearer IMHO.
> --
> Florian

In the hardware conceptions that I float in, a "management port" has
the connotation of "exclusively management" (link-local multicast plus
user-defined trapping rules). While I completely understand that this
model is something that doesn't help the Linux abstraction at all, it
is something that apparently enough people in NXP have thought of as
being a good idea since they actually put it in practice in designs.
Just something to keep in mind.

Andrew, is the Z80 embedded CPU able to run Linux? If not, then from
what perspective are you saying you're going to call it "the z80 port"
instead of "CPU port", and why would you add support for it?
The current ocelot driver runs on the little CPU and doesn't support
external management, and the downstream felix driver runs on the big
CPU and doesn't support "local" I/O (DMA, PIO), so there are both at
the extremes. I don't know of any kernel driver that sets up the
switch for a remote DSA master, but I'd be curious to see what is the
terminology there.

But otherwise, I don't know whether there's anything really actionable
here. What the ocelot driver calls a CPU port is always a "port
towards the CPU running Linux and managing the switch", so the CPU
port is always local by definition, no matter whether the CPU is
connected over DMA or over Ethernet (aka NPI mode or not).

Thanks,
-Vladimir

Powered by blists - more mailing lists