linux-kernel - Re: [PATCH net-next 00/15] net: sparx5: prepare for lan969x switch driver

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: <4e89dd84-eadc-4cae-8892-c33688cc051f@intel.com>
Date: Tue, 1 Oct 2024 11:03:10 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Daniel Machon <daniel.machon@...rochip.com>, "David S. Miller"
	<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Lars Povlsen
	<lars.povlsen@...rochip.com>, Steen Hegelund <Steen.Hegelund@...rochip.com>,
	<horatiu.vultur@...rochip.com>, <jensemil.schulzostergaard@...rochip.com>,
	<UNGLinuxDriver@...rochip.com>, Richard Cochran <richardcochran@...il.com>,
	<horms@...nel.org>, <justinstitt@...gle.com>, <gal@...dia.com>,
	<aakash.r.menon@...il.com>
CC: <netdev@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 00/15] net: sparx5: prepare for lan969x switch
 driver



On 10/1/2024 6:50 AM, Daniel Machon wrote:
> == Description:
> 
> This series is the first of a multi-part series, that prepares and adds
> support for the new lan969x switch driver.
> 
> The upstreaming efforts is split into multiple series (might change a
> bit as we go along):
> 
>     1) Prepare the Sparx5 driver for lan969x (this series)
>     2) Add support lan969x (same basic features as Sparx5 provides +
>        RGMII, excl.  FDMA and VCAP)
>     3) Add support for lan969x FDMA
>     4) Add support for lan969x VCAP
> 
> == Lan969x in short:
> 
> The lan969x Ethernet switch family [1] provides a rich set of
> switching features and port configurations (up to 30 ports) from 10Mbps
> to 10Gbps, with support for RGMII, SGMII, QSGMII, USGMII, and USXGMII,
> ideal for industrial & process automation infrastructure applications,
> transport, grid automation, power substation automation, and ring &
> intra-ring topologies. The LAN969x family is hardware and software
> compatible and scalable supporting 46Gbps to 102Gbps switch bandwidths.
> 
> == Preparing Sparx5 for lan969x:
> 
> The lan969x switch chip reuses many of the IP's of the Sparx5 switch
> chip, therefore it has been decided to add support through the existing
> Sparx5 driver, in order to avoid a bunch of duplicate code. However, in
> order to reuse the Sparx5 switch driver, we have to introduce some
> mechanisms to handle the chip differences that are there.  These
> mechanisms are:
> 
>     - Platform match data to contain all the differences that needs to
>       be handled (constants, ops etc.)
> 
>     - Register macro indirection layer so that we can reuse the existing
>       register macros.
> 
>     - Function for branching out on platform type where required.
> 
> In some places we ops out functions and in other places we branch on the
> chip type. Exactly when we choose one over the other, is an estimate in
> each case.
> 
> After this series is applied, the Sparx5 driver will be prepared for
> lan969x and still function exactly as before.
> 
> == Patch breakdown:
> 
> Patch #1     adds private match data
> 
> Patch #2     adds register macro indirection layer
> 
> Patch #3-#5  does some preparation work
> 
> Patch #6-#8  adds chip constants and updates the code to use them
> 
> Patch #9-#14 adds and uses ops for handling functions differently on the
>              two platforms.
> 
> Patch #15    adds and uses a macro for branching out on the chip type
> 
> [1] https://www.microchip.com/en-us/product/lan9698
> 

The series seems ok to me. I'm not personally a fan of the implicit
local variables used by macros. I do not know how common that is, or
what others on the list feel about this.

For everything else:

Reviewed-by: Jacob Keller <jacob.e.keller@...el.com>