DTS patches were always expected to be either sent separately or put at
the end of patchset, but the first part of paragraph regarding this rule
used a "should be placed at the end of patchset" phrase which might
create wrong impression. This "should be" about order of patches applies
only to the case when DTS is combined into this patchset.

Suggested-by: Luca Weiss <luca.weiss@fairphone.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/submitting-patches.rst | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/submitting-patches.rst b/Documentation/devicetree/bindings/submitting-patches.rst
index 81e27e50f905..2a5533f68830 100644
--- a/Documentation/devicetree/bindings/submitting-patches.rst
+++ b/Documentation/devicetree/bindings/submitting-patches.rst
@@ -64,9 +64,10 @@ I. For patch submitters
 
   7) DTS is treated in general as driver-independent hardware description, thus
      any DTS patches, regardless whether using existing or new bindings, should
-     be placed at the end of patchset to indicate no dependency of drivers on
-     the DTS.  DTS will be anyway applied through separate tree or branch, so
-     different order would indicate the series is non-bisectable.
+     be a separate posting or, when combined with driver patches, placed at the
+     end of the patchset to indicate no dependency of drivers on the DTS.  DTS
+     will be anyway applied through separate tree or branch, so different order
+     would indicate the series is non-bisectable.
 
      If a driver subsystem maintainer prefers to apply entire set, instead of
      their relevant portion of patchset, please split the DTS patches into
-- 
2.51.0

Hi Krzysztof,

On Wed Feb 25, 2026 at 11:59 AM CET, Krzysztof Kozlowski wrote:
> DTS patches were always expected to be either sent separately or put at
> the end of patchset, but the first part of paragraph regarding this rule
> used a "should be placed at the end of patchset" phrase which might
> create wrong impression. This "should be" about order of patches applies
> only to the case when DTS is combined into this patchset.
>
> Suggested-by: Luca Weiss <luca.weiss@fairphone.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/submitting-patches.rst | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/submitting-patches.rst b/Documentation/devicetree/bindings/submitting-patches.rst
> index 81e27e50f905..2a5533f68830 100644
> --- a/Documentation/devicetree/bindings/submitting-patches.rst
> +++ b/Documentation/devicetree/bindings/submitting-patches.rst
> @@ -64,9 +64,10 @@ I. For patch submitters
>  
>    7) DTS is treated in general as driver-independent hardware description, thus
>       any DTS patches, regardless whether using existing or new bindings, should
> -     be placed at the end of patchset to indicate no dependency of drivers on
> -     the DTS.  DTS will be anyway applied through separate tree or branch, so
> -     different order would indicate the series is non-bisectable.
> +     be a separate posting or, when combined with driver patches, placed at the

"when combined with driver patches"

Is there some guidance *when* this is appropriate and when it's not?

For example would touchscreen bindings & driver, and dts addition be
appropriate to combine into one patch series?

From our discussion on IRC, you said a series covering 3 or 4 subsystems
is too much and they should be split.

Thanks for working on updating the docs!

Regards
Luca

> +     end of the patchset to indicate no dependency of drivers on the DTS.  DTS
> +     will be anyway applied through separate tree or branch, so different order
> +     would indicate the series is non-bisectable.
>  
>       If a driver subsystem maintainer prefers to apply entire set, instead of
>       their relevant portion of patchset, please split the DTS patches into

On 25/02/2026 12:02, Luca Weiss wrote:
> Hi Krzysztof,
> 
> On Wed Feb 25, 2026 at 11:59 AM CET, Krzysztof Kozlowski wrote:
>> DTS patches were always expected to be either sent separately or put at
>> the end of patchset, but the first part of paragraph regarding this rule
>> used a "should be placed at the end of patchset" phrase which might
>> create wrong impression. This "should be" about order of patches applies
>> only to the case when DTS is combined into this patchset.
>>
>> Suggested-by: Luca Weiss <luca.weiss@fairphone.com>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>> ---
>>  Documentation/devicetree/bindings/submitting-patches.rst | 7 ++++---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/submitting-patches.rst b/Documentation/devicetree/bindings/submitting-patches.rst
>> index 81e27e50f905..2a5533f68830 100644
>> --- a/Documentation/devicetree/bindings/submitting-patches.rst
>> +++ b/Documentation/devicetree/bindings/submitting-patches.rst
>> @@ -64,9 +64,10 @@ I. For patch submitters
>>  
>>    7) DTS is treated in general as driver-independent hardware description, thus
>>       any DTS patches, regardless whether using existing or new bindings, should
>> -     be placed at the end of patchset to indicate no dependency of drivers on
>> -     the DTS.  DTS will be anyway applied through separate tree or branch, so
>> -     different order would indicate the series is non-bisectable.
>> +     be a separate posting or, when combined with driver patches, placed at the
> 
> "when combined with driver patches"
> 
> Is there some guidance *when* this is appropriate and when it's not?

It depends what maintainer wants, so depends which subsystem you target.
Several maintainers take everything or nothing, exactly for the reasons
I explained on IRC, thus for them you cannot include DTS.

Please understand that DTS is soc thus another subsystem in such
patchset, therefore, unless you send patchset to drivers/soc + DTS, then
you are always mixing at least two subsystems.

> 
> For example would touchscreen bindings & driver, and dts addition be
> appropriate to combine into one patch series?
> 
> From our discussion on IRC, you said a series covering 3 or 4 subsystems
> is too much and they should be split.

Mixing two is fine (with respect to rule from my first paragraph).
Mixing three is already discouraged, mixing four is too much, unless
subsystem maintainers do not care.


Best regards,
Krzysztof