netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Angelo Daros de Luca <luizluca@gmail.com>
To: netdev@vger.kernel.org
Cc: linus.walleij@linaro.org, alsi@bang-olufsen.dk, andrew@lunn.ch,
	vivien.didelot@gmail.com, f.fainelli@gmail.com,
	olteanv@gmail.com, davem@davemloft.net, kuba@kernel.org,
	pabeni@redhat.com, robh+dt@kernel.org, krzk+dt@kernel.org,
	arinc.unal@arinc9.com
Subject: [RFC net-next 0/5] refactor realtek switches and add reset controller
Date: Sat, 11 Nov 2023 18:51:03 -0300	[thread overview]
Message-ID: <20231111215647.4966-1-luizluca@gmail.com> (raw)

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



             reply	other threads:[~2023-11-11 21:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-11 21:51 Luiz Angelo Daros de Luca [this message]
2023-11-11 21:51 ` [RFC net-next 1/5] dt-bindings: net: dsa: realtek: reset-gpios is not required Luiz Angelo Daros de Luca
2023-11-12  7:37   ` Krzysztof Kozlowski
2023-11-13 20:30     ` Luiz Angelo Daros de Luca
2023-11-13  8:31   ` Linus Walleij
2023-11-14 12:23   ` Alvin Šipraga
2023-11-11 21:51 ` [RFC net-next 2/5] dt-bindings: net: dsa: realtek: add reset controller Luiz Angelo Daros de Luca
2023-11-13  8:31   ` Linus Walleij
2023-11-14 12:23   ` Alvin Šipraga
2023-11-16 16:25   ` Rob Herring
2023-11-11 21:51 ` [RFC net-next 3/5] net: dsa: realtek: create realtek-common Luiz Angelo Daros de Luca
2023-11-12  7:39   ` Krzysztof Kozlowski
2023-11-13  8:35   ` Linus Walleij
2023-11-13 20:41     ` Luiz Angelo Daros de Luca
2023-11-13 22:01       ` Alvin Šipraga
2023-11-14 11:43   ` Alvin Šipraga
2023-11-17 23:04     ` Luiz Angelo Daros de Luca
2023-11-11 21:51 ` [RFC net-next 4/5] net: dsa: realtek: load switch variants on demand Luiz Angelo Daros de Luca
2023-11-14 12:17   ` Alvin Šipraga
2023-11-17 21:14     ` Luiz Angelo Daros de Luca
2023-11-11 21:51 ` [RFC net-next 5/5] net: dsa: realtek: support reset controller Luiz Angelo Daros de Luca

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231111215647.4966-1-luizluca@gmail.com \
    --to=luizluca@gmail.com \
    --cc=alsi@bang-olufsen.dk \
    --cc=andrew@lunn.ch \
    --cc=arinc.unal@arinc9.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).