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]
Date:	Wed, 7 Jan 2015 08:16:38 -0800
From:	Guenter Roeck <linux@...ck-us.net>
To:	Bartosz Golaszewski <bgolaszewski@...libre.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Benoit Cousson <bcousson@...libre.com>,
	Patrick Titiano <ptitiano@...libre.com>,
	LM Sensors <lm-sensors@...sensors.org>
Subject: Re: [PATCH] hwmon: ina2xx: allow to change the averaging rate at
 run-time

On Wed, Jan 07, 2015 at 04:41:35PM +0100, Bartosz Golaszewski wrote:
> 2015-01-07 14:22 GMT+01:00 Guenter Roeck <linux@...ck-us.net>:
> > I think I know what to do here. Can you look into the ina209 driver ?
> > It uses update_interval and calculates the number of samples to use from it.
> > The ina226 datasheet suggests that we can do the same, combined with the
> > conversion time configuration. We would have to use the default conversion
> > time of 1.1ms for that to make sense, but that is what it is today,
> > so it would be ok. This way we are in line with the ABI and can still
> > configure the number of averages.
> >
> 
> Just to make sure I understood you correctly: I should add
> update_interval attribute instead of avg_rate, accept the desired
> interval (as time) instead of the number of averages and - already
> having the conversion time hardcoded to 1.1 ms - calculate the
> averaging rate? Isn't this an overkill for what we're trying to
> implement? I know it's for the sake of staying uniform with already
> existing interface of ina209 but on the other hand these devices
> aren't quite the same.
> 
INA219 uses the same mechanism and timing as used by INA209. This way
it is easily possible to extend the driver to support the attribute
for every chip. But overall this uses the existing ABI (update_interval
is part of the hwmon ABI) instead of creating a new driver specific
attribute. Yes, that is quite important.

The additional "overhead" is just to use different numbers and a
different attribute name, so I don't really understand your concern.

Guenter
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ