Re: [net-next 8/9] ixgbe: add interface to export thermal data

2012/1/5 Skidmore, Donald C [off-list ref]:

quoted

-----Original Message-----
From: Ben Hutchings [mailto:bhutchings@solarflare.com]
Sent: Thursday, January 05, 2012 10:36 AM
To: Skidmore, Donald C
Cc: Michal Miroslaw; Kirsher, Jeffrey T; davem@davemloft.net;
netdev@vger.kernel.org; gospo@redhat.com; sassmann@redhat.com;
Waskiewicz Jr, Peter P
Subject: RE: [net-next 8/9] ixgbe: add interface to export thermal data

On Thu, 2012-01-05 at 17:53 +0000, Skidmore, Donald C wrote:

quoted

quoted

-----Original Message-----
From: Michał Mirosław [mailto:mirqus@gmail.com]
Sent: Friday, December 23, 2011 9:59 AM
To: Kirsher, Jeffrey T
Cc: davem@davemloft.net; Skidmore, Donald C; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com; Waskiewicz Jr, Peter P
Subject: Re: [net-next 8/9] ixgbe: add interface to export thermal

data

quoted

quoted

2011/12/23 Jeff Kirsher [off-list ref]:

quoted

From: Don Skidmore <redacted>

Some of our adapters have thermal data available, this patch

exports

quoted

quoted

this

quoted

data via a read-only sysfs interface.

Just curious: can't this use the hwmon subsystem to be consistent

with

quoted

quoted

other system monitoring devices?

Best Regards,
Michał Mirosław

Sorry about the slow response, first vacation then I hadn't heard of
hwmon and wanted to look into it a bit.  I can see why you mentioned
it as it looks to be close to what I'm trying to do here.  However I
don't think it quite matches.  I'll list my thoughts below:

- We are trying to export a large set of data that our customers are
requesting.  The thermals were just the first patch and the other data
items wouldn't really fit well in the hwmon (i.e. FW version,
secondary MAC address).

Nevertheless, there is a specific way that the thermal information
should be exposed.

quoted

- Didn't seem like we had much data to offer hwmon anyway just sensor
temp, caution threshold, maxop threshold and location of sensor.  All
the other data (which you haven't seen yet so couldn't have known :)
wasn't related.
- The thermal data we do have is defined in our FW and could change
(number of sensors) based on that FW.  I wasn't sure whether that
would be an issue for hwmon.

I have the same issue with the current Solarflare controllers, as the
driver has no static information about specific boards.  It is possible
to generate hwmon attributes dynamically though I've not yet got round
to completing my implementation of this.  (Since firmware is also
responsible for thermal shutdown, handling any of this stuff in the
driver has been a low priority.)

quoted

- I went with sysfs based on a conversation with Peter Waskiewicz.  He
mentioned that there was discussion on how to export generic data at
netconf and sysfs was brought up as the best choice.

Sensors are also exposed through sysfs, but following a specific naming
convention and using a separate hwmon device.

(Oddly, though, the sensor attributes are must be attached to the hwmon
device's parent - which will be your PCI device.  So you may not need to
make many changes.)

Ben.

Hey Ben,

Thanks for all the clarifications.  I think I have a better idea what would be required from an hwmon interface.

My one real concern with this implementation is that the ixgbe driver will now have a dependency on hwmon.  The customers that are requesting this data aren't interested in using hwmon and would most likely just grab the thermal information (which is a small portion of the data they are asking for us to export) directly from sysfs.  Originally they wanted the FW to export the data directly, when this was found to be impossible the driver became the fall back option.

I do see your point on this being a defined way to expose thermals and I want to do this the correct way.  It just seems to put a lot of overhead on the driver (dependence on hwmon) for 4 fields that the user of this data won't even be using hwmon to look at.  I guess I would feel better if we had more data to provide hwmon then its support would seem more useful.

Drivers outside of drivers/hwmon just select HWMON in Kconfig. This
adds a 3kB .c file to the kernel build for the first one that needs
it.

Best Regards,
Michał Mirosław