Re: hwmon driver with misc interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/10/2018 07:54 PM, Benjamin Herrenschmidt wrote:
On Wed, 2018-07-11 at 09:26 +1000, Benjamin Herrenschmidt wrote:
On Tue, 2018-07-10 at 13:44 -0700, Guenter Roeck wrote:
Yes, I think that would be more appropriate.

This still won't work, since then we wouldn't have those attributes
available in the P8 version of the driver (which has no fsi-occ driver). In
addition, how would the poll response data get from the hwmon driver to the
fsi-occ driver? Yet another interface? Seems awkward.

How about debugfs? We don't really mind where the attributes are, just that
the data is exposed somewhere...


You are essentially confirming that using sysfs attributes would not be
appropriate. I have no problems with using debugfs; you have a free ride
there.

I disagree.

If the attributes are used for the normal operation of the system then
they should be in sysfs.

A system should be able to function normally without debugfs mounted.

Those attributes are about monitoring proper operations of the OCC
right ? Or are there other things here ? I don't see any reason why
those couldn't hang off the device sysfs node...

Eddie: If Guenter really strongly objects to that handful of attributes

Please keep in mind that you are not making a string case for those attributes,
whatever they are. Saying that debugfs may be a solution isn't really a strong
case; it is exactly the opposite.

I am pushing back because I have seen too many "I want to have this
attribute because the HW supports it. I have no clue what to use it
for, I just want it". I'll want to see something better than that.

Guenter

being in the hwmon device itself, then we have two alternatives we can
consider:

   - Not upstream P8 :-)

   - Use a similar 2-level driver for P8/i2c, which additionally
provides the ability to create a p8 variant of /dev/occ if needed.

I don't like the way the P8 backend works today anyway. It basically
uses i2c to do SCOMs which will race/clash with anything else in the
system trying to do the same.

We should ideally have a pure "SCOM" driver providing a P8 /dev/scom
and lay on top of that a platform device for OCC like we do with
sbefifo.

That said, I'm also not too fussed about leaving P8 behind as legacy
and not upstreaming it.

Cheers,
Ben.

Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux