linux-kernel - Re: [PATCH v3] staging: iio: light: Replace symbolic permissions as per coding style

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] [day] [month] [year] [list]

Date:   Sun, 21 May 2017 11:55:01 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Brian Masney <masneyb@...tation.org>
Cc:     surenderpolsani@...il.com, knaack.h@....de, lars@...afoo.de,
        pmeerw@...erw.net, gregkh@...uxfoundation.org,
        gregor.boirie@...rot.com, singhalsimran0@...il.com,
        maitysanchayan@...il.com, eraretuya@...il.com,
        linux-iio@...r.kernel.org, devel@...verdev.osuosl.org,
        linux-kernel@...r.kernel.org, Jon Brenner <Jon.Brenner@....com>
Subject: Re: [PATCH v3] staging: iio: light: Replace symbolic permissions as
 per coding style

On 20/05/17 19:36, Brian Masney wrote:
> On Sat, May 20, 2017 at 06:55:02PM +0100, Jonathan Cameron wrote:
>> On 19/05/17 10:37, surenderpolsani@...il.com wrote:
>>> From: Surender Polsani <surenderpolsani@...il.com>
>>>
>>> Fixed the following checkpatch.pl warnings:
>>> octal permissions are more preferable than symbolic permissions
>>>
>>> Replaced DEVICE_ATTR family macros with DEVICE_ATTR_RW family
>>> as suggested by Greg K-H. Changed attributes and function
>>> names where ever required to satisfy internal macro definitions
>>> like __ATTR__RW().
>>>
>>> Signed-off-by: Surender Polsani <surenderpolsani@...il.com>
>> Nicely presented patch, but it runs into the fact that some of these
>> shouldn't exist as hand rolled attrs in the first place.
>>
>> Some of theses should be handled through the various info_mask and
>> event_info_mask bitmaps + read_raw etc.
>>
>> This would be a much less mechanical change however...
>>
>> See inline and I'll try and pick out which ones.
>>
>> Brian is working on this driver as well at the moment so there may
>> well be some clashes.
>>
>> Perhaps you two could confer on who will target what?  Saves
>> everyone time to work together!
> 
> You can apply this if you'd like. I just got 7 different hardware
> samples from Jon this week that are supported by this driver. I haven't
> gotten far yet with coding since I'm currently working on getting
> them all setup so that it will be easy for me to test my upcoming
> driver changes.
> 
> For my first patch series, I'm planning to migrate the driver to use
> IIO channels, cleaning up the I2C calls, and runtime power management
> support. Hopefully I'll have this to you for next weekend.
> 
I've applied this patch (with a lot of fuzz as the driver had changed
under it).

Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to see what we messed up.

Jonathan
> Brian
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>