netdev - [net-next 0/2] net: dsa: realtek: Introduce realtek

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

Message-ID: <20231117235140.1178-1-luizluca@gmail.com>
Date: Fri, 17 Nov 2023 20:49:59 -0300
From: Luiz Angelo Daros de Luca <luizluca@...il.com>
To: netdev@...r.kernel.org
Cc: linus.walleij@...aro.org,
	alsi@...g-olufsen.dk,
	andrew@...n.ch,
	f.fainelli@...il.com,
	olteanv@...il.com,
	davem@...emloft.net,
	edumazet@...gle.com,
	kuba@...nel.org,
	pabeni@...hat.com,
	arinc.unal@...nc9.com
Subject: [net-next 0/2] net: dsa: realtek: Introduce realtek_common, load variants on demand 

The current driver comprises two interface modules (SMI and MDIO) and
two family/variant modules (RTL8365MB and RTL8366RB). While the
interface modules are independent and can be loaded only when necessary,
the symbols from variant modules are utilized by interface modules. This
requires loading all enabled variants simultaneously or disabling them
at build time. This approach, although simple, does not scale well,
particularly with the addition of more switch variants (e.g., RTL8366B),
resulting in loaded but unused modules.

This patch series refactors the Realtek DSA switch code by introducing a
common module shared by all existing interfaces (SMI or MDIO) and switch
variant modules (RTL8365MB and RTL8366RB). The common module primarily
contains parts of the probe code common to both interfaces, with the
possibility of incorporating more bits from variants in the future.

The relationship between interfaces and variant modules is also
modified. Variant modules now register themselves in realtek_common
using the compatible string as the key, which is also added as the
module alias. When an interface module probes a device, it utilizes the
matching string to both request the module, loading it if necessary, and
obtain the required variant reference.

Tested with a RTL8367S (RTL8365MB) using MDIO interface and a RTL8366RB
(RTL8366) with SMI interface.

Regards,

Luiz

--

Changelog:

RFC->v1
- Drop the reset-controller patches. It will be submitted in a different
  series.
- Renamed 'var' to 'variant'
- Used 'compatible' as MODULE_ALIAS; avoided static module names in
  macros
- Dropped tmp variable in realtek_variant_get()
- realtek_variant_get() now exclusively uses the compatible string
- Removed clk_delay, cmd_{read,write) from realtek_priv as they are
  already in realtek_variant
- Moved mdc/mdio from realtek_common_probe() to realtek_smi_probe()
- Moved module_realtek_variant() macro to realtek-common.h
- module_realtek_variant() now also generates MODULE_ALIAS()
- Avoided repeating error code with dev_err_probe()
- Removed unused realtek_variant.info
- Used realtek_common_(un)lock() in chip variant modules