From: Guenter Roeck <linux@roeck-us.net>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: "Robert Marko" <robert.marko@sartura.hr>,
"Andreas Böhler" <dev@aboehler.at>,
"Luka Perkov" <luka.perkov@sartura.hr>,
"Jean Delvare" <jdelvare@suse.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/2] Documentation: devicetree: update bindings for tps23861
Date: Fri, 26 Aug 2022 05:19:54 -0700 [thread overview]
Message-ID: <20220826121954.GB2897306@roeck-us.net> (raw)
In-Reply-To: <9d25d239-8d40-e639-c5e5-a308bc41d22f@linaro.org>
On Fri, Aug 26, 2022 at 09:56:29AM +0300, Krzysztof Kozlowski wrote:
> On 25/08/2022 18:31, Robert Marko wrote:
> > On Thu, Aug 25, 2022 at 5:29 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >>
> >> On Thu, Aug 25, 2022 at 05:07:45PM +0200, Robert Marko wrote:
> >>> On Thu, Aug 25, 2022 at 5:02 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >>>>
> >>>> On Thu, Aug 25, 2022 at 04:37:36PM +0200, Andreas Böhler wrote:
> >>>>> The tps23861 driver does not initialize the chip and relies on it being
> >>>>> in auto-mode by default. On some devices, these controllers default to
> >>>>> OFF-Mode and hence cannot be used at all.
> >>>>>
> >>>>> This brings minimal support for initializing the controller in a user-
> >>>>> defined mode.
> >>>>>
> >>>>> Signed-off-by: Andreas Böhler <dev@aboehler.at>
> >>>>
> >>>> nack for the series, sorry. The suggested properties are not hardware
> >>>> monitoring but phy properties. There should be a separate phy driver
> >>>> to manage those.
> >>>>
> >>>> Also, as mentioned, the hwmon 'enable' attribute is abused to control
> >>>> port functionality and should be removed.
> >>>
> >>> Hi Guenter,
> >>> Are you referring to an ethernet PHY driver or the generic PHY framework?
> >>>
> >>
> >> Could be both, though ethernet phy sounds about right for me.
> >> I don't know where/how similar chips are handled. hwmon is most definitey
> >> the wrong place.
> >
> > Hi,
> >
> > Well, that is the thing, this is definitively not an ethernet PHY nor
> > a PHY of any other kind.
> > I dont see where it would fit if not hwmon, there is no more specific
> > subsystem in the
> > kernel.
>
> It's not hwmon. The device has monitoring capabilities, but it's only
> one piece and calling something hwmon just because can provide sensor
> data is like calling a plane a car, because it has wheels.
>
> Maybe this is similar to these series:
> https://lore.kernel.org/linux-devicetree/20220825130211.3730461-1-o.rempel@pengutronix.de/
> ?
>
> The datasheet says it is a "PSE Controller" so looks similar to the
> problem solved above...
Excellent find. That infrastructure is exactly what the driver for this chip
needs to tie into. I would suggest to get in touch with the author of that
series - it is quite likely that they are working on adding support for one
or more real PSE chips.
The only open question is if the hwmon driver should be retained as a
separate driver or be implemented as part of the PSE networking driver.
I am open to both.
Thanks,
Guenter
next prev parent reply other threads:[~2022-08-26 12:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-25 14:37 [PATCH v3 1/2] Documentation: devicetree: update bindings for tps23861 Andreas Böhler
2022-08-25 14:37 ` [PATCH v3 2/2] hwmon: tps23861: add support for initializing the chip Andreas Böhler
2022-08-25 14:49 ` [PATCH v3 1/2] Documentation: devicetree: update bindings for tps23861 Krzysztof Kozlowski
2022-08-25 15:02 ` Guenter Roeck
2022-08-25 15:07 ` Robert Marko
2022-08-25 15:29 ` Guenter Roeck
2022-08-25 15:31 ` Robert Marko
2022-08-26 6:56 ` Krzysztof Kozlowski
2022-08-26 12:19 ` Guenter Roeck [this message]
2022-08-25 18:51 ` Rob Herring
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=20220826121954.GB2897306@roeck-us.net \
--to=linux@roeck-us.net \
--cc=dev@aboehler.at \
--cc=devicetree@vger.kernel.org \
--cc=jdelvare@suse.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luka.perkov@sartura.hr \
--cc=robert.marko@sartura.hr \
--cc=robh+dt@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.