linux-kernel - Re: [PATCH v1 7/8] tpm: tis-i2c: Add more compatible strings

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] [day] [month] [year] [list]

Message-ID: <92625821-d79d-4aba-9bef-148f154be427@roeck-us.net>
Date: Wed, 10 Jan 2024 13:41:45 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 Ninad Palsule <ninad@...ux.ibm.com>, Conor Dooley <conor@...nel.org>
Cc: robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
 conor+dt@...nel.org, joel@....id.au, andrew@...econstruct.com.au,
 peterhuewe@....de, jarkko@...nel.org, jgg@...pe.ca, keescook@...omium.org,
 tony.luck@...el.com, gpiccoli@...lia.com, johannes.holland@...ineon.com,
 broonie@...nel.org, patrick.rudolph@...ements.com, vincent@...emblay.dev,
 peteryin.openbmc@...il.com, lakshmiy@...ibm.com, bhelgaas@...gle.com,
 naresh.solanki@...ements.com, alexander.stein@...tq-group.com,
 festevam@...x.de, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-aspeed@...ts.ozlabs.org,
 linux-kernel@...r.kernel.org, linux-integrity@...r.kernel.org,
 linux-hardening@...r.kernel.org, geissonator@...oo.com
Subject: Re: [PATCH v1 7/8] tpm: tis-i2c: Add more compatible strings

On 1/10/24 12:34, Krzysztof Kozlowski wrote:
> On 10/01/2024 20:06, Guenter Roeck wrote:
>> On 1/10/24 09:54, Krzysztof Kozlowski wrote:
>>> On 10/01/2024 16:54, Ninad Palsule wrote:
>>>> Hello Krzysztof,
>>>>
>>>>
>>>> On 1/10/24 09:37, Krzysztof Kozlowski wrote:
>>>>> On 10/01/2024 15:31, Ninad Palsule wrote:
>>>>>> Hello Krzysztof,
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>> I have send it as a separate commit. https://lore.kernel.org/linux-kernel/20231214144954.3833998-1-ninad@linux.ibm.com/
>>>>>>>>> Why did you do that? It now just adds undocumented compatibles to the
>>>>>>>>> driver. Please, as Rob requested, work with Lukas on his series to make
>>>>>>>>> sure that these devices are documented.
>>>>>>>> I think krzysztof kozlowski suggested to send these patches separately:
>>>>>>>> https://lore.kernel.org/linux-kernel/1c5ace65-2fd8-4503-b22f-e0f564d1c83f@linaro.org/
>>>>>>>>
>>>>>>>> Did I misunderstood it? Do you guys want me to include that commit again?
>>>>>>> My comment was in DTS thread under specific DTS patch. How did you
>>>>>>> figure out it applies to driver and bindings? This does not make sense.
>>>>>> Sorry for the misunderstanding. Where do you want me to add driver
>>>>>> patch? Before all DTS patches or after all DTS patches?
>>>>> Does not matter, why do you insist on combining them with DTS? Drivers
>>>>> and bindings are going together. DTS better separate, although depending
>>>>> on the case can be together.
>>>>>
>>>> I have combined DTS and Driver because DTS was using compatibility
>>>> string which is not upstream yet hence I thought it is logical to send
>>>> it under same patchset.
>>>
>>> Sometimes yes, sometimes not. DTS must not go via driver subsystem, so
>>> sending it in the same patchset has implications on maintainers applying
>>> it. Some like it, some don't and you will be nagged for combining them.
>>>
>>
>> "DTS must not go via driver subsystem"
>>
>> I always thought the guideline was to submit separate _patches_ for dts
>> and driver changes, but as part of a single series. I didn't know that
>> there is a rule to submit separate patch _series_. I also didn't know
>> (and as far as I know no one called me on it) that I am not supposed
>> to _apply_ dts changes. So far, I typically applied dts changes together
>> with driver patches after receiving an Acked-by: or Reviewed-by:
>> from a devicetree maintainer.
> 
> I did not notice you applying them, but such guideline - DTS must go via
> respective SoC tree - was always repeated by me and SoC maintainers.
> Just like gazillion other things probably was not documented... or even
> if it was documented, it would be so deep among hundreds of other rules
> nobody would find it. :)
> 
>>
>> This exchange suggests that I did it all wrong. Should I reject devicetree
>> patches submitted as part of a driver patch series going forward ?
> 
> I propose: just ignore them. The SoC maintainer will pick them up.
> 
>> Should I not apply dts patches submitted as part of a patch series ?
> 
> No, please do not apply them.
> 
>> If so, it would help to have some documentation I can point to to explain
>> the rationale to submitters (and myself). Also, in that case, how is the
> 
> Yes, it would. I can try to create something.
> 
>> synchronization between device tree patches and driver patches supposed
>> to happen ?
> 
> There should not be synchronization. Just to remind: we talk about DTS
> (so also DTSI and DTSO), thus everything being in arch/*/boot/dts/. We
> do not talk about DT bindings, right? The bindings are obvious (and
> documented): preferably go via driver subsystem, with fallback/special
> cases via SoC tree and fallback to Rob.
> 

Sorry, misunderstanding on my side. I do not and never did apply patches
in arch/*/boot/dts/. I referred to patches in Documentation/devicetree/

Sorry, I though you also referred to bindings. My bad.

Guenter