netdev - Re: [PATCH net-next v3 7/8] net: dsa: lantiq_gswip: store switch API version in priv

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] [day] [month] [year] [list]

Message-ID: <8eb20dee-162f-47ea-8596-be71a3aa653b@lunn.ch>
Date: Thu, 21 Aug 2025 16:15:32 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Hauke Mehrtens <hauke@...ke-m.de>, Vladimir Oltean <olteanv@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Russell King <linux@...linux.org.uk>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, Andreas Schirm <andreas.schirm@...mens.com>,
	Lukas Stockmann <lukas.stockmann@...mens.com>,
	Alexander Sverdlin <alexander.sverdlin@...mens.com>,
	Peter Christen <peter.christen@...mens.com>,
	Avinash Jayaraman <ajayaraman@...linear.com>,
	Bing tao Xu <bxu@...linear.com>, Liang Xu <lxu@...linear.com>,
	Juraj Povazanec <jpovazanec@...linear.com>,
	"Fanni (Fang-Yi) Chan" <fchan@...linear.com>,
	"Benny (Ying-Tsan) Weng" <yweng@...linear.com>,
	"Livia M. Rosu" <lrosu@...linear.com>,
	John Crispin <john@...ozen.org>
Subject: Re: [PATCH net-next v3 7/8] net: dsa: lantiq_gswip: store switch API
 version in priv

> The (anyway public) datasheets I have access to don't describe the VERSION
> register at all. In the existing precompiler macros, however, you can see
> that most-significant and least-significant byte are swapped. REV is
> more significant than MOD:
> 
> #define GSWIP_VERSION                   0x013
> #define  GSWIP_VERSION_REV_SHIFT        0
> #define  GSWIP_VERSION_REV_MASK         GENMASK(7, 0)
> #define  GSWIP_VERSION_MOD_SHIFT        8
> #define  GSWIP_VERSION_MOD_MASK         GENMASK(15, 8)
> #define   GSWIP_VERSION_2_0             0x100
> #define   GSWIP_VERSION_2_1             0x021
> #define   GSWIP_VERSION_2_2             0x122
> #define   GSWIP_VERSION_2_2_ETC         0x022
> 
> Now I'd like to add
> #define   GSWIP_VERSION_2_3             0x023
> 
> and then have a simple way to make features available starting from a
> GSWIP_VERSION. Now in order for GSWIP_VERSION_2_3 to be greater than
> GSWIP_VERSION_2_2, and GSWIP_VERSION_2_1 to be greater than
> GSWIP_VERSION_2_0, the bytes need to be swapped.
> 
> I don't think the vendor even considered any specific order of the two
> bytes but just defines them as separate 8-bit fields, considering it a
> 16-bit unsigned integer is my interpretation which came from the need for
> comparability.

It would be good to put some of this into the commit message and
comments in the code. That the hardware has the 'major/minor' version
bytes in the wrong order preventing numerical comparisons. To make it
obvious, rather than use swap16(), maybe actually extract the major
and minor, and then construct the version in the form you want?

    Andrew