mbox series

[RFC,net-next,0/5] refactor realtek switches and add reset controller

Message ID 20231111215647.4966-1-luizluca@gmail.com (mailing list archive)
Headers show
Series refactor realtek switches and add reset controller | expand

Message

Luiz Angelo Daros de Luca Nov. 11, 2023, 9:51 p.m. UTC
This patch series might be a bit too hefty, and I'm thinking of splitting it into two series. It all began as a patch to add reset-controller as a way to reset the switch, but the duplicated code for both sparked a discussion about a shared code base, which led to what you get here. This driver will be used in some devices with tight resources, both in storage and RAM.

The current driver has two interface modules (SMI and MDIO) and two family/variant modules (RTL8365MB and RTL8366RB). The interface modules are independent and can be loaded only when necessary. But, they refer to symbols from both variant modules, which means they have to be loaded together or disabled at build time. It's a simple approach but doesn't scale well over time, especially if you add more switch variants (like RTL8366B). Also, it's unlikely there'll ever be a device using switches from different families simultaneously. The variant modules are much larger than the interface modules, so it makes sense to load only the needed code.

The first part involves reworking the Realtek DSA switch code. It introduces a common module shared by all existing interfaces (SMI or MDIO) and switch family modules (RTL8365MB and RTL8366RB). This module will mainly have parts of the probe code common to both interfaces, but more bits from variants might move over in the future. This common module is also a way for variant modules to register themselves for interface modules. The idea came from how DSA requests tag modules at runtime when necessary.

The second part is about the original reset controller code, along with the first two binding patches. It'll only affect the new common module.

This series was tested with RTL8366RB using SMI and RTL8367S (rtl8365mb) with MDIO. Both seemed to work as expected.

Checkpatch is flagging some long function declarations (realtek_common_probe and realtek_variant_get). I checked existing kernel code and noticed differe

Regards,

Luiz