netdev - Re: [PATCH net-next 2/2] net: dsa: microchip: add KSZ8 change_tag

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: <CAHvy4ApydUb273oJRLLyfBKTNU1YHMBp261uRXJnLO05Hd0XKQ@mail.gmail.com>
Date: Mon, 19 Aug 2024 14:05:26 +0200
From: Pieter <vtpieter@...il.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Woojung Huh <woojung.huh@...rochip.com>, UNGLinuxDriver@...rochip.com, 
	Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Russell King <linux@...linux.org.uk>, Pieter Van Trappen <pieter.van.trappen@...n.ch>, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 2/2] net: dsa: microchip: add KSZ8
 change_tag_protocol support

Hi Vladimir,

> Hi Pieter,
>
> > - DSA_TAG_PROTO_NONE
> >
> > When disabled, this can be used as a workaround for the 'Common
> > pitfalls using DSA setups' [1] to use the conduit network interface as
> > a regular one, admittedly forgoing most DSA functionality and using
> > the device as an unmanaged switch whilst allowing control
> > operations (ethtool, PHY management, WoL).
>
> Concretely, what is it that you wish to accomplish? I see you chose to
> ignore my previous NACK due to the lack of a strong justification for
> disabling the tagging protocol.
> https://lore.kernel.org/netdev/20240801134401.h24ikzuoiakwg4i4@skbuf/

Sorry I definitely did not try to ignore your previous NACK but here the
motivation and solution are both different, which is why I did not consider
it a patch iteration of the previous one.

Previously I could not use DSA because of the macb driver limitation, now
fixed (max_mtu increase, submitted here). Once I got that working, I notice
that full DSA was not a compatible use case for my board because of
requiring the conduit interface to behave as a regular ethernet interface.
So it's really the unmanaged switch case, which I though I motivated well in
the patch description here (PHY library, ethtool and switch WoL management).

The solution is now the one you proposed earlier.

> > Implementing the new software-defined DSA tagging protocol tag_8021q
> > [2] for these devices seems overkill for this use case at the time
> > being.
>
> I think there's a misunderstanding about tag_8021q. It does not disable
> the tagging protocol. But rather, it helps you implement a tagging
> protocol when the hardware does not want to cooperate. So I don't see
> how it would have helped you in your goal (whatever that is), and why
> mention it.

Right I understand, indeed a misunderstanding. Will remove this part.

> tag_8021q exists because it is my goal for DSA_TAG_PROTO_NONE to
> eventually disappear. The trend is for drivers to be converted from
> DSA_TAG_PROTO_NONE to something else (like DSA_TAG_PROTO_VSC73XX_8021Q),
> not the other way around. It's a strong usability concern to not be able
> to ping through the port net devices.
>
> At the very least we need consensus among the current DSA maintainers
> that accepting 'none' as an alternative tagging protocol is acceptable.

This of course I understand as well.

Cheers, Pieter