[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+h21hpHBMWWyocg2ZmP-rFFDpFZBWWsAvEAK3MxEoBWxcsPSQ@mail.gmail.com>
Date: Sun, 10 Nov 2019 18:40:07 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Jakub Kicinski <jakub.kicinski@...ronome.com>,
"David S. Miller" <davem@...emloft.net>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Florian Fainelli <f.fainelli@...il.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 14/15] net: mscc: ocelot: split assignment of the
cpu port into a separate function
On Sun, 10 Nov 2019 at 18:32, Andrew Lunn <andrew@...n.ch> wrote:
>
> > +void ocelot_set_cpu_port(struct ocelot *ocelot, int cpu,
> > + enum ocelot_tag_prefix injection,
> > + enum ocelot_tag_prefix extraction)
> > +{
> > + /* Configure and enable the CPU port. */
> > + ocelot_write_rix(ocelot, 0, ANA_PGID_PGID, cpu);
> > + ocelot_write_rix(ocelot, BIT(cpu), ANA_PGID_PGID, PGID_CPU);
> > + ocelot_write_gix(ocelot, ANA_PORT_PORT_CFG_RECV_ENA |
> > + ANA_PORT_PORT_CFG_PORTID_VAL(cpu),
> > + ANA_PORT_PORT_CFG, cpu);
> > +
> > + /* If the CPU port is a physical port, set up the port in Node
> > + * Processor Interface (NPI) mode. This is the mode through which
> > + * frames can be injected from and extracted to an external CPU.
> > + * Only one port can be an NPI at the same time.
> > + */
> > + if (cpu < ocelot->num_phys_ports) {
> > + ocelot_write(ocelot, QSYS_EXT_CPU_CFG_EXT_CPUQ_MSK_M |
> > + QSYS_EXT_CPU_CFG_EXT_CPU_PORT(cpu),
> > + QSYS_EXT_CPU_CFG);
> > + }
>
> If a port is not a physical port, what is it? Is it actually an error
> if the CPU port is not physical? Should we be returning -EINVAL here,
> indicating the device tree is bad?
>
> Andrew
The Vitesse switches have a number of "physical" ports and a number of
"CPU" ports. By "port", one understands a target in the queuing
subsystem, with learning, flooding, forwarding, etc. The CPU ports
that are not physical don't have an 802.3 MAC. Then frame transfer
happens over DMA from its queues, PIO, etc (depending on SoC
integration). In the LS1028A SoC instantiation of the Felix switch
(which is an instantiation of the Ocelot core with less ports and
support for TSN), the CPU port _is_ physical (aka is a MAC connected
back-to-back to an ENETC DSA master), and that is what is being
understood by NPI mode.
Powered by blists - more mailing lists