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: <1fced39f-1077-4af7-9294-affb99860984@kernel.org>
Date: Mon, 16 Jun 2025 08:41:03 +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 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.

Best regards,
Krzysztof