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

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

Date:   Sun, 16 Jul 2017 13:53:04 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Pavel Machek <pavel@....cz>
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

On Wed 05 Jul 20:18 PDT 2017, Pavel Machek wrote:

> 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.


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?

Regards,
Bjorn