linux-kernel - Re: [PATCH v3 net-next 05/10] net: dsa: microchip: add DSA support for microchip lan937x

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20210802121550.gqgbipqdvp5x76ii@skbuf>
Date:   Mon, 2 Aug 2021 15:15:50 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Prasanna Vengateshan <prasanna.vengateshan@...rochip.com>
Cc:     andrew@...n.ch, netdev@...r.kernel.org, robh+dt@...nel.org,
        UNGLinuxDriver@...rochip.com, Woojung.Huh@...rochip.com,
        hkallweit1@...il.com, linux@...linux.org.uk, davem@...emloft.net,
        kuba@...nel.org, linux-kernel@...r.kernel.org,
        vivien.didelot@...il.com, f.fainelli@...il.com,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v3 net-next 05/10] net: dsa: microchip: add DSA support
 for microchip lan937x

On Mon, Aug 02, 2021 at 04:15:08PM +0530, Prasanna Vengateshan wrote:
> On Sat, 2021-07-31 at 18:04 +0300, Vladimir Oltean wrote:
> > > +void lan937x_mac_config(struct ksz_device *dev, int port,
> > > +                     phy_interface_t interface)
> > > +{
> > > +     u8 data8;
> > > +
> > > +     lan937x_pread8(dev, port, REG_PORT_XMII_CTRL_1, &data8);
> > > +
> > > +     /* clear MII selection & set it based on interface later */
> > > +     data8 &= ~PORT_MII_SEL_M;
> > > +
> > > +     /* configure MAC based on interface */
> > > +     switch (interface) {
> > > +     case PHY_INTERFACE_MODE_MII:
> > > +             lan937x_config_gbit(dev, false, &data8);
> > > +             data8 |= PORT_MII_SEL;
> > > +             break;
> > > +     case PHY_INTERFACE_MODE_RMII:
> > > +             lan937x_config_gbit(dev, false, &data8);
> > > +             data8 |= PORT_RMII_SEL;
> > > +             break;
> > > +     case PHY_INTERFACE_MODE_RGMII:
> > > +     case PHY_INTERFACE_MODE_RGMII_ID:
> > > +     case PHY_INTERFACE_MODE_RGMII_TXID:
> > > +     case PHY_INTERFACE_MODE_RGMII_RXID:
> > > +             lan937x_config_gbit(dev, true, &data8);
> > > +             data8 |= PORT_RGMII_SEL;
> > > +
> > > +             /* Add RGMII internal delay for cpu port*/
> > > +             if (dsa_is_cpu_port(dev->ds, port)) {
> >
> > Why only for the CPU port? I would like Andrew/Florian to have a look
> > here, I guess the assumption is that if the port has a phy-handle, the
> > RGMII delays should be dealt with by the PHY, but the logic seems to be
> > "is a CPU port <=> has a phy-handle / isn't a CPU port <=> doesn't have
> > a phy-handle"? What if it's a fixed-link port connected to a downstream
> > switch, for which this one is a DSA master?
>
> Thanks for reviewing the patches. My earlier proposal here was to check if there
> is no phydev (dp->slave->phydev) or if PHY is genphy, then apply RGMII delays
> assuming delays should be dealt with the phy driver if available. What do you
> think of that?

I don't know what to suggest, this is a bit of a minefield.
A while ago and in a different thread, Russell King said that
PHY_INTERFACE_MODE_RGMII_TXID means that the MAC should behave as if it
is connected to a PHY which has applied RGMII delays in the TX direction,
regardless of whether it is in fixed-link or not. So if the MAC was to
add any internal delays in PHY_INTERFACE_MODE_RGMII_TXID mode, those
would have to be RX delays, because the phy-mode specifies what was
already added and nothing more.
However, that is yet another problem. "what is already added" does not
mean "what more needs to be added". The fact that internal delays were
added in the TX direction doesn't necessarily mean that they still need
to be added in the RX direction. If you have a PHY which can only delay
the clock that it drives (the RX clock), and this is connected to a MAC
that cannot add any delays of its own, then you would end up adding PCB
traces on the board in the TX direction. But if you specify the phy-mode
as "rgmii-rxid", the MAC driver would complain that it can't add delays
in the TX direction (under the assumption that these are needed to work),
and if you specify the phy-mode as "rgmii-id", the PHY driver would
complain that it can't add delays in the TX direction.
So you'd have a system that works from a hardware PoV, but you wouldn't
have any way to describe it to Linux, which sucks.

I think the only way to do things correctly today and have a way to
describe any possible hardware setup is to parse the explicit
rx-internal-delay-ps and tx-internal-delay-ps properties in the MAC
driver, as defined in Documentation/bindings/net/ethernet-controller.yaml.
Then only let the MAC add the internal delays if the device tree has
added those properties, leave nothing down to assumptions.