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

Message-ID: <20170520183635.GA4124@200591939db7>
Date:   Sat, 20 May 2017 14:36:35 -0400
From:   Brian Masney <masneyb@...tation.org>
To:     Jonathan Cameron <jic23@...nel.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 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.

Brian