linux-kernel - Re: [net-next PATCH v18 0/8] net: dsa: Add Airoha AN8855 support

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: <20250917101031.drg3qairsrinucbl@skbuf>
Date: Wed, 17 Sep 2025 13:10:31 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Lee Jones <lee@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	Simon Horman <horms@...nel.org>,
	"Chester A. Unal" <chester.a.unal@...nc9.com>,
	Daniel Golle <daniel@...rotopia.org>,
	DENG Qingfang <dqfext@...il.com>,
	Sean Wang <sean.wang@...iatek.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [net-next PATCH v18 0/8] net: dsa: Add Airoha AN8855 support

On Wed, Sep 17, 2025 at 11:40:36AM +0200, Christian Marangi wrote:
> On Wed, Sep 17, 2025 at 12:28:07PM +0300, Vladimir Oltean wrote:
> > On Mon, Sep 15, 2025 at 12:45:36PM +0200, Christian Marangi wrote:
> > > It's conceptually similar to mediatek switch but register and bits
> > > are different. And there is massive list of register for the PCS
> > > configuration.
> > > Saddly for that part we have absolutely NO documentation currently.
> > 
> > Please add in the next revision a more convincing argument for not
> > reusing the mt7530 driver control flow. Regmap fields can abstract a
> > lot, and the driver can select a completely different phylink_pcs for
> > different hardware.
> > 
> > I don't see in the short change log included here any mentions related
> > to the mt7530, but I'm not going to search the mailing lists since Nov
> > 2024 for any previous discussions about this...
> 
> Ok will add additional info.
> 
> But In short the FDB and VLAN part are very different. The FDB logic to
> dump entry add and remove is entirely different.
> 
> And the mt7530 itself is full of unrelated function (specific to the
> first revision of the mt7530 switch) so I have to move lots of code
> around.
> 
> If asked I can do it but I have to also introduce lots of extra change.

Ok, it would be good if you could point to an ack from mt7530 people
that they're ok with this choice and motivation.

> > Do you know why it won't receive PTP over IP? It seems strange, given it
> > receives other IP multicast (even unregistered). Is it a hardware or a
> > software drop? What port counters increment? Does it drop PTP over IP
> > only on local termination, or does it also fail to forward it? What
> > about the packet makes the switch drop it?
> > 
> 
> From what they said there isn't any support for 1588v2 (PTP) on the Switch other
> than L2 (that I think they simply forward)
> 
> I can ask more info on the topic, will also check what counters
> increment.

"Don't support PTP over IP" can mean a lot of different things, but I
don't expect "let's drop it" to be expected behaviour. Being a
PTP-unaware switch (which doesn't timestamp event packets and doesn't
participate in the protocol) is an entirely adequate and basic use case,
and we aren't even requesting the switch anything other than to receive
these packets during the selftest (no timestamping). But it doesn't seem
to work, which is bizarre. We don't even know if the problem is specific
to PTP or is more widespread. Maybe it has to do with the UDP ports 319
and 320, maybe with the particular IP multicast groups...