linux-kernel - Re: [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings documention

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: <20200604125111.GA7222@duo.ucw.cz>
Date:   Thu, 4 Jun 2020 14:51:11 +0200
From:   Pavel Machek <pavel@....cz>
To:     Rob Herring <robh@...nel.org>
Cc:     Dan Murphy <dmurphy@...com>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        devicetree@...r.kernel.org,
        Linux LED Subsystem <linux-leds@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings
 documention

On Tue 2020-06-02 15:44:32, Rob Herring wrote:
> On Tue, Jun 2, 2020 at 2:04 PM Pavel Machek <pavel@....cz> wrote:
> >
> > On Wed 2020-05-27 08:35:06, Rob Herring wrote:
> > > On Wed, May 27, 2020 at 7:39 AM Pavel Machek <pavel@....cz> wrote:
> > > >
> > > > Hi!
> > > >
> > > > Thanks for reviews!
> > > >
> > > > > > +additionalProperties: false
> > > > > > +...
> > > > > > diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
> > > > >
> > > > > This isn't a binding file. Belongs in another patch.
> > > >
> > > > These constants are directly related to the binding. It makes sense to
> > > > go in one patch...
> > >
> > > Yes, the header does go in this patch, but kernel subsystem files do not.
> > >
> > > Part of the reason for separating is we generate a DT only repository
> > > which filters out all the kernel code. Ideally this is just filtering
> > > out commits and the commit messages still make sens
> >
> > Well, but the patch can't be split like that. Otherwise we risk null
> > pointer dereferences when one part is applied but not the second one.
> 
> There's no risk because you are supposed to apply both patches. I
> don't apply binding patches that are a part of a series like this.

Yes, this is always guaranteed to happen, because "git bisect"
understand patch series. Oh, wait.

Patches are supposed to be correct on their own. If your repository
filtering can not handle that, you need to fix that...

-- 
(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" (196 bytes)