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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <ccec896b-d639-40f5-8c5b-3527caf17d0c@amd.com>
Date: Mon, 16 Jun 2025 09:18:39 +0200
From: Michal Simek <michal.simek@....com>
To: Krzysztof Kozlowski <krzk@...nel.org>, 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 6/16/25 09:13, Krzysztof Kozlowski wrote:
> 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.

What do you want me to do?

Thanks,
Michal