netdev - Re: [PATCH net-next v4 1/2] net: dsa: microchip: ksz8: Make flow control, speed, and duplex on CPU port configurable

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: <20230520151708.24duenxufth4xsh5@skbuf>
Date: Sat, 20 May 2023 18:17:08 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Woojung Huh <woojung.huh@...rochip.com>, Andrew Lunn <andrew@...n.ch>,
	Arun Ramadoss <arun.ramadoss@...rochip.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Simon Horman <simon.horman@...igine.com>,
	"Russell King (Oracle)" <linux@...linux.org.uk>,
	linux-kernel@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
	Paolo Abeni <pabeni@...hat.com>, kernel@...gutronix.de,
	netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
	UNGLinuxDriver@...rochip.com,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next v4 1/2] net: dsa: microchip: ksz8: Make flow
 control, speed, and duplex on CPU port configurable

On Sat, May 20, 2023 at 07:03:17AM +0200, Oleksij Rempel wrote:
> On Fri, May 19, 2023 at 11:34:49PM +0300, Vladimir Oltean wrote:
> > On Fri, May 19, 2023 at 08:50:15PM +0200, Oleksij Rempel wrote:
> > > Thank you for your feedback. I see your point. 
> > > 
> > > We need to remember that the KSZ switch series has different types of
> > > ports. Specifically, for the KSZ8 series, there's a unique port. This
> > > port is unique because it's the only one that can be configured with
> > > global registers, and it is only one supports tail tagging. This special
> > > port is already referenced in the driver by "dev->cpu_port", so I continued
> > > using it in my patch.
> > 
> > Ok, I understand, so for the KSZ8 family, the assumption about which
> > port will use tail tagging is baked into the hardware.
> > 
> > > It is important to note that while this port has an xMII interface, it
> > > is not the only port that could have an xMII interface. Therefore, using
> > > "dev->info->internal_phy" may not be the best way to identify this port,
> > > because there can be ports that are not global/cpu, have an xMII
> > > interface, but don't have an internal PHY.
> > 
> > Right, but since we're talking about phylink, the goal is to identify
> > the xMII ports, not the CPU ports... This is a particularly denatured
> > case because the xMII port is global and is also the CPU port.
> 
> I see. Do you have any suggestions for a better or more suitable
> implementation? I'm open to ideas.

Trying to answer here for both questions. In the RFC/RFT patch set I had
posted, I introduced the concept of "wacky" registers, which are registers
which should be per port (and are accessed as per-port by the driver),
but because there is a single such port in the switch, the hardware
design degenerated into moving them in the global area. Nonetheless,
treating the xMII global registers as per-port makes it possible for the
common driver to share more code between KSZ8 and others.

If you look at ksz9477_phylink_mac_link_up() - renamed to just
ksz_phylink_mac_link_up() in my patch set - hard enough, you can see
that it makes an attempt to generalize the "link up" procedure for all
switch families, via these regs and fields. At the end of that regfield
series, I theoretically converted KSZ8765/KSZ8794/KSZ8795 to reuse
ksz9477_phylink_mac_link_up(). Theoretically because no one commented
on whether the result still worked.

I think that regfields and that KSZ_WACKY_REG_FIELD_8() are an avenue
worth exploring here.