linux-kernel - Re: [PATCH v2 2/2] dt-bindings: gpio: gpio-xilinx: Mark clocks as required property

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]

Message-ID: <8c5ac938-6e58-4ff3-bc0c-d639b0c9ac14@kernel.org>
Date: Mon, 16 Jun 2025 09:13:29 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Michal Simek <michal.simek@....com>, linux-kernel@...r.kernel.org,
 monstr@...str.eu, michal.simek@...inx.com, git@...inx.com
Cc: Bartosz Golaszewski <brgl@...ev.pl>, Conor Dooley <conor+dt@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Linus Walleij <linus.walleij@...aro.org>, Rob Herring <robh@...nel.org>,
 Shubhrajyoti Datta <shubhrajyoti.datta@....com>,
 Srinivas Neeli <srinivas.neeli@....com>,
 "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
 <devicetree@...r.kernel.org>,
 "moderated list:ARM/ZYNQ ARCHITECTURE"
 <linux-arm-kernel@...ts.infradead.org>,
 "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] dt-bindings: gpio: gpio-xilinx: Mark clocks as
 required property

On 16/06/2025 09:10, Krzysztof Kozlowski wrote:
> On 16/06/2025 08:51, Michal Simek wrote:
>> 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.
> 
One more thought: That was from submitter point of view. But from
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.

Best regards,
Krzysztof