From: Guenter Roeck <linux@roeck-us.net>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Ninad Palsule <ninad@linux.ibm.com>,
Conor Dooley <conor@kernel.org>
Cc: robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, joel@jms.id.au, andrew@codeconstruct.com.au,
peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca,
keescook@chromium.org, tony.luck@intel.com, gpiccoli@igalia.com,
johannes.holland@infineon.com, broonie@kernel.org,
patrick.rudolph@9elements.com, vincent@vtremblay.dev,
peteryin.openbmc@gmail.com, lakshmiy@us.ibm.com,
bhelgaas@google.com, naresh.solanki@9elements.com,
alexander.stein@ew.tq-group.com, festevam@denx.de,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-integrity@vger.kernel.org, linux-hardening@vger.kernel.org,
geissonator@yahoo.com
Subject: Re: [PATCH v1 7/8] tpm: tis-i2c: Add more compatible strings
Date: Wed, 10 Jan 2024 13:41:45 -0800 [thread overview]
Message-ID: <92625821-d79d-4aba-9bef-148f154be427@roeck-us.net> (raw)
In-Reply-To: <32d46b64-d4a5-437a-8737-c2d172608559@linaro.org>
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
next prev parent reply other threads:[~2024-01-10 21:41 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-12 16:39 [PATCH v1 0/8] Add device tree for IBM system1 BMC Ninad Palsule
2023-12-12 16:39 ` [PATCH v1 1/8] dt-bindings: arm: aspeed: add IBM system1-bmc Ninad Palsule
2023-12-12 17:09 ` Conor Dooley
2023-12-12 20:06 ` Ninad Palsule
2023-12-13 18:18 ` Jarkko Sakkinen
2023-12-13 18:36 ` Ninad Palsule
2023-12-12 16:39 ` [PATCH v1 2/8] dt-bindings: tpm: Add schema for TIS I2C devices Ninad Palsule
2023-12-12 17:14 ` Conor Dooley
2023-12-12 18:20 ` Guenter Roeck
2023-12-14 15:37 ` Ninad Palsule
2023-12-14 15:34 ` Ninad Palsule
2023-12-14 16:35 ` Conor Dooley
2023-12-14 20:13 ` Rob Herring
2023-12-13 16:13 ` Rob Herring
2023-12-14 22:23 ` Ninad Palsule
2024-01-08 19:44 ` Ninad Palsule
2023-12-13 18:20 ` Jarkko Sakkinen
2023-12-13 18:38 ` Ninad Palsule
2023-12-12 16:39 ` [PATCH v1 3/8] ARM: dts: aspeed: System1: IBM system1 BMC board Ninad Palsule
2023-12-12 20:20 ` Krzysztof Kozlowski
2023-12-14 15:06 ` Ninad Palsule
2023-12-12 16:40 ` [PATCH v1 4/8] ARM: dts: aspeed: System1: Add i2c and muxes Ninad Palsule
2023-12-12 20:21 ` Krzysztof Kozlowski
2023-12-14 18:34 ` Ninad Palsule
2023-12-15 7:35 ` Krzysztof Kozlowski
2023-12-12 16:40 ` [PATCH v1 5/8] ARM: dts: aspeed: System1: Voltage regulators Ninad Palsule
2023-12-12 20:22 ` Krzysztof Kozlowski
2023-12-14 16:30 ` Ninad Palsule
2023-12-12 16:40 ` [PATCH v1 6/8] ARM: dts: aspeed: System1: GPIO, Fan ctrl, Led Ninad Palsule
2023-12-12 20:25 ` Krzysztof Kozlowski
2024-01-08 19:56 ` Ninad Palsule
2023-12-12 16:40 ` [PATCH v1 7/8] tpm: tis-i2c: Add more compatible strings Ninad Palsule
2023-12-12 17:15 ` Conor Dooley
2023-12-12 18:00 ` Guenter Roeck
2023-12-12 18:51 ` Conor Dooley
2023-12-12 19:50 ` Guenter Roeck
2024-01-08 20:05 ` Ninad Palsule
2024-01-09 17:14 ` Conor Dooley
2024-01-09 23:55 ` Ninad Palsule
2024-01-09 23:55 ` Ninad Palsule
2024-01-10 7:50 ` Krzysztof Kozlowski
2024-01-10 14:31 ` Ninad Palsule
2024-01-10 15:37 ` Krzysztof Kozlowski
2024-01-10 15:54 ` Ninad Palsule
2024-01-10 16:23 ` Conor Dooley
2024-01-10 17:54 ` Krzysztof Kozlowski
2024-01-10 19:06 ` Guenter Roeck
2024-01-10 20:34 ` Krzysztof Kozlowski
2024-01-10 20:36 ` Krzysztof Kozlowski
2024-01-10 21:41 ` Guenter Roeck [this message]
2024-01-08 20:04 ` Ninad Palsule
2023-12-12 16:40 ` [PATCH v1 8/8] ARM: dts: aspeed: System1: PS, sensor and more Ninad Palsule
2023-12-12 20:26 ` Krzysztof Kozlowski
2023-12-13 19:02 ` Ninad Palsule
2023-12-13 19:37 ` Krzysztof Kozlowski
2023-12-13 19:49 ` Ninad Palsule
2023-12-14 7:24 ` Krzysztof Kozlowski
2023-12-14 14:24 ` Ninad Palsule
2023-12-14 15:04 ` Ninad Palsule
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=92625821-d79d-4aba-9bef-148f154be427@roeck-us.net \
--to=linux@roeck-us.net \
--cc=alexander.stein@ew.tq-group.com \
--cc=andrew@codeconstruct.com.au \
--cc=bhelgaas@google.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=festevam@denx.de \
--cc=geissonator@yahoo.com \
--cc=gpiccoli@igalia.com \
--cc=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=joel@jms.id.au \
--cc=johannes.holland@infineon.com \
--cc=keescook@chromium.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=lakshmiy@us.ibm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=naresh.solanki@9elements.com \
--cc=ninad@linux.ibm.com \
--cc=patrick.rudolph@9elements.com \
--cc=peterhuewe@gmx.de \
--cc=peteryin.openbmc@gmail.com \
--cc=robh+dt@kernel.org \
--cc=tony.luck@intel.com \
--cc=vincent@vtremblay.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).