On Thu, Jun 4, 2020 at 6:51 AM Pavel Machek <pavel@xxxxxx> wrote: > > On Tue 2020-06-02 15:44:32, Rob Herring wrote: > > On Tue, Jun 2, 2020 at 2:04 PM Pavel Machek <pavel@xxxxxx> wrote: > > > > > > On Wed 2020-05-27 08:35:06, Rob Herring wrote: > > > > On Wed, May 27, 2020 at 7:39 AM Pavel Machek <pavel@xxxxxx> 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. What!? If the binding patch with the header comes first, how would bisect build the driver change without the header? > Patches are supposed to be correct on their own. If your repository > filtering can not handle that, you need to fix that... I'm just asking you to follow the process that *everyone* else is following and works. It's not really about the repository filtering. That doesn't care. A binding ABI is defined by the schema and any defines it has. That is the logical unit that stands on its own. Rob
