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:	Sun, 10 Jul 2016 17:56:27 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Jonathan Cameron <jic23@...nel.org>,
	Jean Delvare <jdelvare@...e.com>
Cc:	Zhang Rui <rui.zhang@...el.com>,
	Eduardo Valentin <edubezval@...il.com>,
	linux-pm@...r.kernel.org, linux-iio@...r.kernel.org,
	linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] hwmon: New hwmon registration API

Hi Jonathan,

On 07/10/2016 09:00 AM, Jonathan Cameron wrote:
> On 26/06/16 04:26, Guenter Roeck wrote:
>> Up to now, each hwmon driver has to implement its own sysfs attributes.
>> This requires a lot of template code, and distracts from the driver's
>> core function to read and write chip registers.
>>
>> To be able to reduce driver complexity, move sensor attribute handling
>> and thermal zone registration into the hwmon core. By using the new API,
>> driver size is typically reduced by 20-50% depending on driver complexity
>> and the number of sysfs attributes supported.
>>
>> The first patch of the series introduces the API as well as support
>> for temperature sensors. Subsequent patches introduce support for
>> voltage, current, power, energy, humidity, and fan speed sensors.
>>
>> The series was tested by converting several drivers (lm75, lm90, tmp102,
>> tmp421, ltc4245) to the new API. Testing was done with with real chips
>> as well as with the hwmon driver module test code available at
>> https://github.com/groeck/module-tests.
> Some cool stuff hiding in there :)
>
> I've only reviewed 1 and 7 and the intermediate ones are really either
> correct or they aren't and they look fine to me.
>
Thanks a lot for your feedback - it is reassuring that it looks sane to you.

>
> So what's next? (beyond presumably a lot of driver conversions).
>
Next steps will be to address your comments, re-test, submit a new series,
add to -next after v4.8-rc1 is out, submit the conversions I have done
and add to -next. Then, obviously, only accept new drivers using the
new API.

Not sure if there is anything else we can or want to do do at this time.
Do you have anything in mind ?

Thanks,
Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ