linux-kernel - Re: [PATCH v2 0/3] Qualcomm Light Pulse Generator

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:   Sun, 16 Jul 2017 23:15:42 +0200
From:   Pavel Machek <pavel@....cz>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     Richard Purdie <rpurdie@...ys.net>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        linux-kernel@...r.kernel.org, linux-leds@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        devicetree@...r.kernel.org, Fenglin Wu <fenglinw@...eaurora.org>
Subject: Re: [PATCH v2 0/3] Qualcomm Light Pulse Generator

Hi!

> > > > >   DT: leds: Add Qualcomm Light Pulse Generator binding
> > > > 
> > > > This one should be first.
> > > > 
> > > 
> > > Okay, no problems.
> > > 
> > > > And I guess I'd prefer the driver to go in first, before the generic
> > > > pattern interface.
> > > > 
> > > 
> > > The driver won't compile without the additions to the header file. Would
> > > you like the rest of the driver to go in first, then the generic
> > > interface and finally the pattern part of the driver?
> > > 
> > > Large portions of the driver doesn't make sense without the pattern
> > > part, so I think I would prefer it to go in as one patch.
> > 
> > Can we get minimum driver without the pattern parts?
> 
> It's possible to do, but I must admit I find it slightly contrived.
> 
> The overall design of different parts of the driver does relate to how I
> decided to structure and implement the pattern support, so this would
> mean that the driver we merge has a conceptual dependency on a
> out-of-tree part.

Ok... but I guess that's something we can live with?

> May I ask about the reasoning for your request? Is it just to not leave
> the driver hanging while we conclude the discussion on the pattern
> interface?

Yes; it would be good to have driver in the tree. OTOH new userland
interface is a "big" decission, and we'll have to support the
interface "forever" once it is merged.

Actually even complete driver (but w/o the userland interface) would
be acceptable. Drivers we can fix. Userland interfaces... not so.

Best regards,
   	       	       	      	   	    		      Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)