linux-kernel - Re: [RFC PATCH v2 3/4] hwmon: adc128d818: Trivial code style fixup

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:   Thu, 29 Dec 2016 16:55:52 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Alexander Koch <mail@...xanderkoch.net>
Cc:     linux-kernel@...r.kernel.org, linux-hwmon@...r.kernel.org,
        devicetree@...r.kernel.org, robh+dt@...nel.org,
        mark.rutland@....com, jdelvare@...e.com, trivial@...nel.org
Subject: Re: [RFC PATCH v2 3/4] hwmon: adc128d818: Trivial code style fixup

On 12/29/2016 12:30 PM, Alexander Koch wrote:
> On 12/29/2016 08:46 PM, Guenter Roeck wrote:
>> On Thu, Dec 29, 2016 at 07:22:12PM +0100, Alexander Koch wrote:
>>> On 12/26/2016 11:47 AM, Guenter Roeck wrote:
>>>> On 12/23/2016 02:12 PM, Alexander Koch wrote:
>>>>> Replace sysfs symbolic file permissions, e.g. 'S_IRUGO', by octal
>>>>> permissions. This fixes checkpatch.pl warnings.
>>>>>
>>>>> Signed-off-by: Alexander Koch <mail@...xanderkoch.net>
>>>> Please do not bother with those warnings and ignore checkpatch.
>>>> We are in the process of doing an automated conversion.
>>> Okay, so I shall create v3 of the patchset, without these changes. I've
>>> found a typo in the 4th patch so I thought about going v3 anyways.
>>>
>>> I've tested operation modes 1-3 on real hardware today and found no
>>> issues so far, so I hope v3 will have good chances of getting accepted.
>>>
>> Pretty much. One request, though: If there is no configuration data
>> from DT, I would like the driver to read the mode from the chip - if for
>> nothing else, this will let me test all modes, but it also supports the
>> case where the chip is configured by BIOS/ROMMON.
>
> Aye, will add this as new fourth patch then. I assume the chip reset in
> adc128_init_client() clears the chip mode as well, so I will read it in
> the operation mode block in adc128_probe().
>
> Just out of interest: how does this help you test the modes? Do you
> configure the chip externally and test it on a platform without
> devicetree support?
>

I use the i2c test driver in the kernel and a module test script, on x86.
See https://github.com/groeck/module-tests. That only works if the driver
does not overwrite the register values on probe.

Not really sure if resetting the chip during probe is such a good idea
in the first place. It is quite unusual.

Guenter