From: Andrew Lunn <andrew@lunn.ch>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Florian Fainelli <f.fainelli@gmail.com>,
Lee Jones <lee@kernel.org>,
Colin Foster <colin.foster@in-advantage.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: Advice on MFD-style probing of DSA switch SoCs
Date: Thu, 22 Dec 2022 17:36:22 +0100 [thread overview]
Message-ID: <Y6SHhiMx4V9tyJuG@lunn.ch> (raw)
In-Reply-To: <20221222161806.mhqsr2ot64v34al2@skbuf>
> > Maybe the media subsystem has some pointers how to do this. It also
> > has complex devices made up from lots of sub devices.
>
> You mean something like struct v4l2_subdev_ops? This seems like the
> precise definition of what I'd like to avoid: a predefined set of
> subfunctions decided by the DSA core.
>
> Or maybe something else? To be honest, I don't know much about the media
> subsystem. This is what I saw.
Russell King put in some infrastructure where a media 'glue' driver
has a list of other drivers which need to probe and register there
resources with the kernel before it then becomes active and glues all
the parts together. I just know it exists, i've never used it, so i've
no idea if it could be useful or not.
What i'm really trying to say is that we should look outside of netdev
and see if similar problems have been solved somewhere else and all
that is needed is some code copying.
Andrew
next prev parent reply other threads:[~2022-12-22 16:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-22 13:48 Advice on MFD-style probing of DSA switch SoCs Vladimir Oltean
2022-12-22 14:34 ` Andrew Lunn
2022-12-22 16:18 ` Vladimir Oltean
2022-12-22 16:36 ` Andrew Lunn [this message]
2022-12-23 8:44 ` Krzysztof Kozlowski
2022-12-23 13:44 ` Vladimir Oltean
2023-02-07 6:49 ` Saravana Kannan
2023-02-11 1:27 ` Vladimir Oltean
2023-02-11 15:50 ` Andrew Lunn
2023-02-11 21:36 ` Vladimir Oltean
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=Y6SHhiMx4V9tyJuG@lunn.ch \
--to=andrew@lunn.ch \
--cc=alexandre.belloni@bootlin.com \
--cc=colin.foster@in-advantage.com \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=vladimir.oltean@nxp.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