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:   Tue, 21 Mar 2017 06:35:41 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Peter Hüwe <PeterHuewe@....de>
Cc:     linux-hwmon@...r.kernel.org, Jean Delvare <jdelvare@...e.com>,
        linux-kernel@...r.kernel.org
Subject: Re: Conversion of w83627ehf to hwmon_device_register_with_info ?

On 03/21/2017 03:46 AM, Peter Hüwe wrote:
> Hi
>
> On Friday 03 March 2017 03:56:01 Guenter Roeck wrote:
>> Hi Peter,
>>
>> On 03/02/2017 04:33 PM, Peter Hüwe wrote:
>>> Hi,
>>>
>>> is anybody else working on the conversion of the w83627ehf to the new
>>> hwmon_device_register_with_info interface?
>>
>> I don't think so.
>>
>>> Otherwise I will probably update the driver to this interface within the
>>> next days - but since it's a lot of work I wanted to check for
>>> duplication first.
>>
>> Go ahead.
>
> So I'm close to have to conversion done,
> the current diff stat is about
> 647 insertions(+), 787 deletions(-)
> for the whole conversion.
>
> Should I try to break it down into smaller chunks for easier review?
>
> Although this would mean to convert stuff from A to B and then from B to C -
> otherwise the intermediate steps would be not fully functional.
> (since the sysfs nodes partially would exist under hwmon1/ and partially under
> hwmon1/device/ (as they currently are)).
>
> or just submit it?
>

Just submit it. I don't really think a conversion like this can be split up
cleanly.

> It saves about 20k in compiled size, so the savings from reduced boilerplate
> are huge. (and I think it's more readable)
>
>> I would suggest to drop nct6775/nct6776 support to simplify the
>> code when you do that. Maybe as separate commit, though.
> Hehe - I'm testing on a nct6776 :)
> I'll look into it once the first conversion has been accepted.
>

Wondering - why don't you use the nct6775 driver ?

Thanks,
Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ