public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Cc: "Alvin Šipraga" <ALSI@bang-olufsen.dk>,
	"Krzysztof Kozlowski" <krzk@kernel.org>,
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"andrew@lunn.ch" <andrew@lunn.ch>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"edumazet@google.com" <edumazet@google.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"arinc.unal@arinc9.com" <arinc.unal@arinc9.com>
Subject: Re: [net-next 2/2] net: dsa: realtek: load switch variants on demand
Date: Thu, 7 Dec 2023 19:02:01 +0200	[thread overview]
Message-ID: <20231207170201.xq3it75hqqd6qnzj@skbuf> (raw)
In-Reply-To: <CAJq09z4ZdB9L7ksuN0b+N-LCv+zOvM+5Q9iWXccGN3w54EN1_Q@mail.gmail.com>

On Mon, Nov 27, 2023 at 07:24:16PM -0300, Luiz Angelo Daros de Luca wrote:
> I'm not sure if getting/putting a module is a problem or if I can
> request it when missing. I would like some options on that specific
> topic from the experts. It seems to happen in many places, even in DSA
> tag code.
> 
> I wouldn't say it will invariably require both interface modules to be
> loaded. The dynamic load would be much simpler if variants request the
> interface module as we only have two (at most 3 with a future
> realtek-spi) modules. We would just need to call a
> realtek_interface_get() and realtek_interface_put() on each respective
> probe. The module names will be well-known with no issues with
> module_alias.
> 
> Thanks for your help, Alvin. I'll wait for a couple of more days for
> others to manifest.

I'm not an expert on this topic either, but Alvin's suggestion makes
sense to have the switch variant drivers be both platform and MDIO
device drivers, and call symbols exported by the interface drivers as
needed.

If you are able to make the variant driver depend on just the interface
driver in use based on some request_module() calls, I don't think that
will be a problem with Krzysztof either, since he just said to not
duplicate the MODULE_DEVICE_TABLE() functionality.

I think it's down to prototyping something and seeing what are the pros
and cons.

  reply	other threads:[~2023-12-07 17:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-17 23:49 [net-next 0/2] net: dsa: realtek: Introduce realtek_common, load variants on demand Luiz Angelo Daros de Luca
2023-11-17 23:50 ` [net-next 1/2] net: dsa: realtek: create realtek-common Luiz Angelo Daros de Luca
2023-11-19 12:13   ` Vladimir Oltean
2023-11-19 12:20   ` Vladimir Oltean
2023-11-17 23:50 ` [net-next 2/2] net: dsa: realtek: load switch variants on demand Luiz Angelo Daros de Luca
2023-11-19 12:19   ` Vladimir Oltean
2023-11-20  9:20   ` Krzysztof Kozlowski
2023-11-20 13:48     ` Vladimir Oltean
2023-11-20 14:07       ` Krzysztof Kozlowski
2023-11-21 14:40         ` Luiz Angelo Daros de Luca
2023-11-21 22:15           ` Krzysztof Kozlowski
2023-11-21 22:35             ` Krzysztof Kozlowski
2023-11-22 22:44               ` Luiz Angelo Daros de Luca
2023-11-23  2:05                 ` Alvin Šipraga
2023-11-27 22:24                   ` Luiz Angelo Daros de Luca
2023-12-07 17:02                     ` Vladimir Oltean [this message]
2023-12-07 20:22                       ` Luiz Angelo Daros de Luca
2023-12-07 17:19                     ` Vladimir Oltean
2023-12-07 19:50                       ` Luiz Angelo Daros de Luca
2023-12-07 22:31                         ` Vladimir Oltean
2023-12-08  2:46                           ` Luiz Angelo Daros de Luca
2023-12-11 18:01                             ` Vladimir Oltean
2023-11-25  7:10   ` Dan Carpenter
2023-11-17 23:57 ` [net-next 0/2] net: dsa: realtek: Introduce realtek_common, load " Luiz Angelo Daros de Luca
2023-11-18  0:44   ` Jakub Kicinski

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=20231207170201.xq3it75hqqd6qnzj@skbuf \
    --to=olteanv@gmail.com \
    --cc=ALSI@bang-olufsen.dk \
    --cc=andrew@lunn.ch \
    --cc=arinc.unal@arinc9.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=krzk@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=luizluca@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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