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

From: Jacob Keller
Date: Tue Oct 01 2024 - 14:03:36 EST




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@xxxxxxxxx>