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

[Krzysztof Kozlowski]

On 16/06/2025 09:18, Michal Simek wrote:
> 
> 
> 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?
We just discuss about the process. You disagreed with me, I responded.
If you ask in general how to solve such problems: either squash such
patches or document the dependency/merging strategy.

General kernel submitting patches also asks about this:

https://elixir.bootlin.com/linux/v6.16-rc1/source/Documentation/process/submitting-patches.rst#L186

(which is third argument against your implied dependency within patchset).

Best regards,
Krzysztof