Re: [REGRESSION?] sensors and fancontrol not seeing armada_thermal on 3.12-rc series

[Guenter Roeck <linux@roeck-us.net>]

On Mon, Oct 21, 2013 at 09:17:39AM +0200, Jean Delvare wrote:
> Hi Arnaud,
> 
> On Sun, 20 Oct 2013 20:10:41 +0200, Arnaud Ebalard wrote:
> > With 3.12-rc series, sysfs support for thermal susbsytem (and/or hwmon
> > one) was modified in such a way that sensors utility (current 3.3.4
> > version with 3.3.4 version of libsensors from lm-sensors package on
> > Debian unstable) does not see the temperature sensor anymore on armada
> > 370 platforms (not tested on others). Additionally, the changes break
> > existing configurations of fancontrol utility, which prevents the 
> > fan to be regulated correctly w/o recreating an /etc/fancontrol w/
> > pwmconfig.
> > 
> > Here is what I have on my Armada 370-based system on a 3.11.5:
> > 
> > # sensors
> > g762-i2c-0-3e
> > Adapter: mv64xxx_i2c adapter
> > fan1:        2457 RPM  (div = 1)
> > 
> > armada_thermal-virtual-0
> > Adapter: Virtual device
> > temp1:        +45.7°C  
> > 
> > And what I get on 3.12-rc6:
> > 
> > # sensors
> > g762-i2c-0-3e
> > Adapter: mv64xxx_i2c adapter
> > fan1:        1350 RPM  (div = 1)
> > 
> > 
> > Monitoring what sensors does w/ strace, I started looking at the changes
> > to /sys/class/hwmon/hwmon1/:
> > 
> > On 3.11.5:
> > 
> > # find /sys/class/hwmon/hwmon1/
> > /sys/class/hwmon/hwmon1/
> > /sys/class/hwmon/hwmon1/name
> > /sys/class/hwmon/hwmon1/subsystem
> > /sys/class/hwmon/hwmon1/uevent
> > /sys/class/hwmon/hwmon1/temp1_input
> > 
> > On 3.12-rc6:
> > 
> > # find /sys/class/hwmon/hwmon1/
> > /sys/class/hwmon/hwmon1/
> > /sys/class/hwmon/hwmon1/name
> > /sys/class/hwmon/hwmon1/device
> > /sys/class/hwmon/hwmon1/subsystem
> > /sys/class/hwmon/hwmon1/uevent
> > /sys/class/hwmon/hwmon1/temp1_input
> > 
> > # find /sys/class/hwmon/hwmon1/device/
> > /sys/class/hwmon/hwmon1/device/
> > /sys/class/hwmon/hwmon1/device/temp
> > /sys/class/hwmon/hwmon1/device/type
> > /sys/class/hwmon/hwmon1/device/hwmon1
> > /sys/class/hwmon/hwmon1/device/hwmon1/name
> > /sys/class/hwmon/hwmon1/device/hwmon1/device
> > /sys/class/hwmon/hwmon1/device/hwmon1/subsystem
> > /sys/class/hwmon/hwmon1/device/hwmon1/uevent
> > /sys/class/hwmon/hwmon1/device/hwmon1/temp1_input
> > /sys/class/hwmon/hwmon1/device/subsystem
> > /sys/class/hwmon/hwmon1/device/policy
> > /sys/class/hwmon/hwmon1/device/uevent
> > /sys/class/hwmon/hwmon1/device/passive
> 
> Can you please share the full output of "strace sensors"? This will
> help me understand which exact code paths are taken in libsensors.
> 
> > Is that expected? As for sensors, it *seems* to be bothered to find a
> > device/ folder in /sys/class/hwmon/hwmon1/ w/o no name entry in it.
> 
> It should be able to cope with this just fine. The radeon driver does
> exactly this and libsensors has no problem with it. 
> 
Hi Jean,

I think it is more likely that the problem is related to parsing the 'subsystem'
link. If I understand the code in lib/sysfs.c correctly, it doesn't recognize
'thermal' (which I think is the subsystem name, but I may be wrong) and ignores
the device as unknown.

Question is if we can come up with some more generic code to handle that case.
Define SENSORS_BUS_TYPE_OTHER and treat it similar to virtual, maybe ?
But then there can be more than one of those, so you would need some means
for enumerating bus and chip numbers, so I don't know if that is feasible.

Guenter