linux-kernel - Re: [lm-sensors] [PATCH 12/22] hwmon: WM831x PMIC hardware monitoring driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090727204614.GA4386@sirena.org.uk>
Date:	Mon, 27 Jul 2009 21:46:14 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	Samuel Ortiz <sameo@...ux.intel.com>, linux-kernel@...r.kernel.org,
	lm-sensors@...sensors.org
Subject: Re: [lm-sensors] [PATCH 12/22] hwmon: WM831x PMIC hardware
 monitoring  driver

On Mon, Jul 27, 2009 at 09:44:19PM +0200, Jean Delvare wrote:
> On Mon, 27 Jul 2009 14:46:02 +0100, Mark Brown wrote:

> > +Temperatures are sampled by a 12 bit ADC.  Chip and battery temperatures
> > +are available.  The chip temperature is calculated as:

> > +	Degrees celsius = (512.8 - data) / 1.0983

> The driver code says 512.18.

The code is correct, will update.

> >  obj-$(CONFIG_SENSORS_W83L786NG)	+= w83l786ng.o
> > +obj-$(CONFIG_SENSORS_WM831X)	+= wm831x-hwmon.o

> FWIW, I tend to dislike "x" for digits in driver names. What if a

Neither naming convention is entirely satisfactory; whatever is chosen
will cause hassle or confusion or some point.  It's one of those things
where I do find myself wishing for code names.

> Additionally it is inconsistent with the naming of the WM8350 driver
> below.

Yes, the WM8350 drivers (well, most of it) predate the WM8351 and
WM8352.

> > +	/* The conversion depends on the battery, leave to userspace */
> > +	return sprintf(buf, "%d\n", ret);
> > +}

> This is a problem. You are not supposed to return raw register values through
> the sysfs interface. Returning the voltage reading at the chip's pin is
> OK because you still return a voltage value. But a raw register value is
> not something the user should see. I agree that technically speaking, a
> good sensors.conf configuration file would work it out, but
> conceptually this is wrong.

Hrm, OK.  There's a potential small loss of accuracy from converting to
a voltage since the voltages are reported as milivolts but it is just a
simple multiplier.

> Can you say more about these batteries and how temperature measurement
> is different between them? If you can export a voltage reading to
> userspace than that would be OK (as I recall, we have at least one
> driver doing that already.)

Not really; it's intended to be a NTC thermistor but the driver is
rather at the mercy of the battery and any other external components
that the board has added.  I'll convert to reporting as a voltage for
consistency with the ABI.

> > +#define WM831X_NAMED_VOLTAGE(id, name) \
> > +	static SENSOR_DEVICE_ATTR(in##id##_input, S_IRUGO, show_voltage,\
> > +				  NULL, name);		\
> 
> I guess you could just call WM831X_VOLTAGE(id, name).

That clashes with the unnamed voltage above.  I could also call them
_NAMED and _UNNAMED, I suppose.

I've fixed all your other issues, will repost tomorrow.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/