netdev - Re: [PATCH net-next 14/15] net: mscc: ocelot: split assignment of the cpu port into a separate function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+h21hrsoUmCag15NNxnhKOvhZkiPvX94Zs+21F5pwQj+5kjmg@mail.gmail.com>
Date:   Sun, 10 Nov 2019 18:50:40 +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:40, Vladimir Oltean <olteanv@...il.com> wrote:
>
> 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.

If this is still confusing, take for example Ocelot
(http://ww1.microchip.com/downloads/en/DeviceDoc/VMDS-10491.pdf). The
physical ports are 0-9, and the CPU ports are 10 and 11. So the ocelot
driver was hardcoding the CPU port to 10, which is the first port
outside the num_phys_ports range.

I don't expect any caller to specify an invalid CPU port, so returning
-EINVAL would just be overhead here. Neither of the 2 entry points of
this function (one in mainline, one as a currently downstream patch)
can. The Ocelot SoC driver (ocelot_board.c) always sets port #10 as
CPU port, which is legit, and the Felix driver always sets one of the
physical ports as CPU port, which again is legit.