On 25/08/2022 18:31, Robert Marko wrote: > On Thu, Aug 25, 2022 at 5:29 PM Guenter Roeck <linux@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxx> >>>> >>>> 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@xxxxxxxxxxxxxx/ ? The datasheet says it is a "PSE Controller" so looks similar to the problem solved above... Best regards, Krzysztof
