linux-kernel - Re: [PATCH 0/3] ARM: davinci: ohci-da8xx: model the vbus GPIO as a fixed regulator

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1903281036290.1291-100000@iolanthe.rowland.org>
Date:   Thu, 28 Mar 2019 10:38:02 -0400 (EDT)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Bartosz Golaszewski <brgl@...ev.pl>
cc:     Sekhar Nori <nsekhar@...com>, Kevin Hilman <khilman@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        <linux-usb@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH 0/3] ARM: davinci: ohci-da8xx: model the vbus GPIO as a
 fixed regulator

On Thu, 28 Mar 2019, Bartosz Golaszewski wrote:

> czw., 28 mar 2019 o 15:11 Alan Stern <stern@...land.harvard.edu> napisał(a):
> >
> > On Thu, 28 Mar 2019, Sekhar Nori wrote:
> >
> > > >> Can you document why the current solution is not optimal? Is it to make
> > > >> future device-tree conversion for these boards easier? Or?
> > > >>
> > > >
> > > > It's sub-optimal from the HW modeling in SW PoV - it is in fact a
> > > > regulator enabled/disabled by a GPIO. Also: it's code duplication as
> > > > currently we check if the vbus GPIO exists and then use it or check if
> > > > the regulator exists and use this as the second choice. The third
> > > > patch actually shrinks the driver.
> > >
> > > I see now that the driver supports controlling the VBUS gpio as
> > > regulator already. Something I should have caught in review last time
> > > around.
> > >
> > > I agree this patch is an improvement. Lets see what Alan feels.
> >
> > I'm not an expert on this stuff, but the patch looks reasonable.
> > However, I do wish that in the devm_request_threaded_irq() call, the
> > indentation of the continuation lines was left unchanged.
> >
> 
> I don't think it's possible - the function name is longer and the
> first line exceeds the 80 characters limit. I can put all the
> parameters below the function name if you prefer that?

Which line the arguments go on doesn't matter.  But increasing the 
amount of indentation, like the patch did, makes the whole thing less 
readable, IMO.  It makes everything end up crammed against the right 
margin.

Alan Stern