On 16/06/2025 09:10, Krzysztof Kozlowski wrote:
On 16/06/2025 08:51, Michal Simek wrote:One more thought: That was from submitter point of view. But from
Hi,
On 6/16/25 08:41, Krzysztof Kozlowski wrote:
On 13/06/2025 13:26, Michal Simek wrote:
Based on discussion at
https://lore.kernel.org/lkml/20241002-revivable-crummy-f780adec538c@spud/
Actually this shouldn't be only targetting GPIO but also for example
xlnx,xps-timebase-wdt-1.00.a but I would like to check it first on gpio
before starting to check other bindings.
IIUC, patch #1 is a prerequisite, so you need to squash them. Otherwise
dt_binding_check is not bisectable and we want it to be bisectable.
No issue with squash if necessary. I sent it as series to be applied together
which won't break bisectability of tree and no new error is going to be reported.
You did not say anything about dependencies and merging strategy, to
this would go via different trees. Sending something in one patchset
does not mean that there is a dependency.
No offense but I don't think I can agree with this. The main purpose of patchset
is to show sequence how things should go one after each other and series should
go via single tree.
Go through all patchsets on DT list touching different subsystems. You
will find only 1% of patchsets having above expectation implied (when
not explicitly stated).
Really. 99% of patchsets on DT list targeting different subsytems, have
opposite, so implied rule they go INDEPENDENTLY to separate subsystems.
And above (so implied rule of splitting things) is even documented in DT
submitting patches.
maintainers point of view, EVERY MONTH there is around one patchset on
DT list which has implied merging like you described (but not explicitly
stated) and MAINTAINERS pick them up independently causing breaks, so
some or many MAINTAINERS also have such reasoning as I said.
They will pick up individual bits from patchset unless told otherwise.