From: "Köry Maincent" <kory.maincent@bootlin.com>
To: Mark Brown <broonie@kernel.org>
Cc: Oleksij Rempel <o.rempel@pengutronix.de>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
Luis Chamberlain <mcgrof@kernel.org>,
Russ Weight <russ.weight@linux.dev>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, devicetree@vger.kernel.org,
Dent Project <dentproject@linuxfoundation.org>,
Liam Girdwood <lgirdwood@gmail.com>
Subject: Re: [PATCH net-next v2 8/8] net: pse-pd: Add PD692x0 PSE controller driver
Date: Thu, 21 Dec 2023 18:19:55 +0100 [thread overview]
Message-ID: <20231221181955.422e676e@kmaincent-XPS-13-7390> (raw)
In-Reply-To: <501f671d-4e03-490b-a9d6-e1f39bb99115@sirena.org.uk>
On Thu, 21 Dec 2023 16:20:10 +0000
Mark Brown <broonie@kernel.org> wrote:
> On Thu, Dec 21, 2023 at 05:10:00PM +0100, Köry Maincent wrote:
> > Mark Brown <broonie@kernel.org> wrote:
> > > On Thu, Dec 21, 2023 at 04:36:10PM +0100, Köry Maincent wrote:
> > > > Mark Brown <broonie@kernel.org> wrote:
>
> > > > > OK... I mean, if they're not using the regulator framework I'm not
> > > > > sure it has much impact - there are plenty of internal regulators in
> > > > > devices already so it wouldn't be *too* unusual other than the fact
> > > > > that AFAICT this is somewhat split between devices within the
> > > > > subsystem? Neither of the messages was super clear.
>
> > > > PSE Power Interface (which is kind of the RJ45 in PSE world) have
> > > > similar functionalities as regulators. We wondered if registering a
> > > > regulator for each PSE PI (RJ45 ports) is a good idea. The point is
> > > > that the PSE controller driver will be its own regulator consumer.
> > > > I can't find any example in Linux with such a case of a driver being a
> > > > provider and a consumer of its own regulator. This idea of a regulator
> > > > biting its own tail seems weird to me. Maybe it is better to implement
> > > > the PSE functionalities even if they are like the regulator
> > > > functionalities.
>
> > > Is it at all plausible that a system (perhaps an embedded one) might use
> > > something other than PSE?
>
> > Do you mean to supply power to a RJ45 port?
>
> Whatever it is that PSE does.
>
> > This can be done with a simple regulator. In that case we use the
> > pse_regulator driver which is a regulator consumer.
> > I don't know about other cases. Oleksij do you?
>
> In that case it sounds like you need the split to allow people to
> substitute in a non-PSE supply, and everything ought to be doing the
> consumer thing?
In case of non-PSE supply we would indeed have a wrapper like this
pse_regulator driver.
My question was about PSE:
A PSE may indeed need a regulator to work properly. In that case the PSE is
indeed a consumer.
The PSE may also power one or several RJ45 ports. The power capabilities of each
port have some capabilities like regulators (enable/disable, power limit,
current and voltage status ...) and capabilities specific to PoE (class, type
...).
These capabilities are modified by ethtool which will call ops within the PSE
driver.
As the power capabilities for each ports are kind of similar to regulator
capabilities we wonder if it is a good idea to register regulator for each ports
of a PSE to avoid rewriting the wheel.
So we will have PSE drivers which are regulators consumer for the chip,
regulator providers for all its ports and regulator consumers also for all its
ports. Is it clearer? Would that sound ok for you?
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2023-12-21 17:19 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-01 17:10 [PATCH net-next v2 0/8] net: Add support for Power over Ethernet (PoE) Kory Maincent
2023-12-01 17:10 ` [PATCH net-next v2 1/8] net: pse-pd: Rectify and adapt the naming of admin_cotrol member of struct pse_control_config Kory Maincent
2023-12-03 18:19 ` Andrew Lunn
2023-12-04 12:19 ` Oleksij Rempel
2023-12-01 17:10 ` [PATCH net-next v2 2/8] ethtool: Expand Ethernet Power Equipment with c33 (PoE) alongside PoDL Kory Maincent
2023-12-03 18:27 ` Andrew Lunn
2023-12-04 12:27 ` Oleksij Rempel
2023-12-06 2:45 ` Bagas Sanjaya
2023-12-06 8:35 ` Köry Maincent
2023-12-06 4:23 ` kernel test robot
2023-12-01 17:10 ` [PATCH net-next v2 3/8] net: pse-pd: Introduce PSE types enumeration Kory Maincent
2023-12-03 18:31 ` Andrew Lunn
2023-12-04 12:43 ` Oleksij Rempel
2023-12-03 18:38 ` Andrew Lunn
2023-12-04 14:00 ` Köry Maincent
2023-12-04 12:51 ` Oleksij Rempel
2023-12-04 13:55 ` Köry Maincent
2023-12-01 17:10 ` [PATCH net-next v2 4/8] net: ethtool: pse-pd: Expand pse commands with the PSE PoE interface Kory Maincent
2023-12-03 18:45 ` Andrew Lunn
2023-12-04 15:28 ` Köry Maincent
2023-12-04 15:29 ` Oleksij Rempel
2023-12-06 4:18 ` Bagas Sanjaya
2023-12-01 17:10 ` [PATCH net-next v2 5/8] netlink: specs: Modify pse attribute prefix Kory Maincent
2023-12-01 17:10 ` [PATCH net-next v2 6/8] netlink: specs: Expand the pse netlink command with PoE interface Kory Maincent
2023-12-01 17:10 ` [PATCH net-next v2 7/8] dt-bindings: net: pse-pd: Add bindings for PD692x0 PSE controller Kory Maincent
2023-12-04 23:08 ` Oleksij Rempel
2023-12-05 6:36 ` Oleksij Rempel
2023-12-05 10:15 ` Köry Maincent
2023-12-05 13:31 ` Köry Maincent
2023-12-05 14:21 ` Oleksij Rempel
2023-12-05 15:23 ` Köry Maincent
2023-12-08 9:06 ` Köry Maincent
2023-12-05 12:54 ` Mark Brown
2023-12-01 17:10 ` [PATCH net-next v2 8/8] net: pse-pd: Add PD692x0 PSE controller driver Kory Maincent
2023-12-03 19:34 ` Andrew Lunn
2024-01-16 9:49 ` Köry Maincent
2024-01-16 13:18 ` Andrew Lunn
2024-01-16 14:12 ` Köry Maincent
2023-12-03 21:11 ` Christophe JAILLET
2023-12-04 22:16 ` Köry Maincent
2023-12-05 18:01 ` Christophe JAILLET
2023-12-06 8:41 ` Köry Maincent
2023-12-04 22:59 ` Oleksij Rempel
2023-12-05 6:45 ` Oleksij Rempel
2023-12-05 12:55 ` Mark Brown
2023-12-05 14:02 ` Oleksij Rempel
2023-12-05 15:57 ` Mark Brown
2023-12-21 15:36 ` Köry Maincent
2023-12-21 15:43 ` Mark Brown
2023-12-21 16:10 ` Köry Maincent
2023-12-21 16:20 ` Mark Brown
2023-12-21 17:19 ` Köry Maincent [this message]
2023-12-21 17:34 ` Mark Brown
2023-12-21 17:42 ` Oleksij Rempel
2023-12-21 18:05 ` Mark Brown
2023-12-22 7:54 ` Oleksij Rempel
2023-12-05 21:35 ` kernel test robot
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=20231221181955.422e676e@kmaincent-XPS-13-7390 \
--to=kory.maincent@bootlin.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=dentproject@linuxfoundation.org \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=russ.weight@linux.dev \
--cc=thomas.petazzoni@bootlin.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).