From: linux@roeck-us•net (Guenter Roeck)
To: linux-arm-kernel@lists•infradead.org
Subject: [REGRESSION?] sensors and fancontrol not seeing armada_thermal on 3.12-rc series
Date: Mon, 21 Oct 2013 08:16:16 -0700 [thread overview]
Message-ID: <20131021151616.GA17598@roeck-us.net> (raw)
In-Reply-To: <20131021091739.739142e8@endymion.delvare>
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
next prev parent reply other threads:[~2013-10-21 15:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-20 18:10 [REGRESSION?] sensors and fancontrol not seeing armada_thermal on 3.12-rc series Arnaud Ebalard
2013-10-20 19:23 ` Guenter Roeck
2013-10-21 2:28 ` Zhang Rui
2013-10-21 5:19 ` Guenter Roeck
2013-10-21 18:49 ` Arnaud Ebalard
2013-10-21 7:17 ` Jean Delvare
2013-10-21 15:16 ` Guenter Roeck [this message]
2013-10-22 12:04 ` Jean Delvare
2013-10-21 18:14 ` Arnaud Ebalard
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=20131021151616.GA17598@roeck-us.net \
--to=linux@roeck-us$(echo .)net \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox