Re: [PATCH v2 0/6] Enable UFS support on Milos

[Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>]

On 26/02/2026 04:36, Martin K. Petersen wrote:
> 
> Hi Krzysztof!
> 
>> Driver subsystems CANNOT take DTS patches because DTS is independent
>> hardware description, thus combining them implies dependency and
>> usually means users can be silently affected. We expressed it many
>> times and documented it in point 7 of [1] (although it does not need
>> any documenting because it is different subsystem - why would you ever
>> take arm64 stuff without acks/permission from its maintainers?)
> 
> I frequently add impending series to my staging tree. This is done to
> see what breaks and what doesn't if I were to actually merge something.
> Being in staging does not imply that things subsequently go into
> scsi-queue. But obviously it does send the message that I am looking at
> merging patches from a given series in near future.
> 
> My script tries to cherry-pick any commits from a series that are not
> already in linux-next and which look relevant for the code to build and
> run in a cross-compiled environment. The script is certainly not
> perfect, figuring out cross-tree dependencies is not at all trivial. And
> I certainly appreciate when submitters clearly indicate which patches
> need to go through which tree. In this particular case there isn't a

The subsystem prefix defines it - first prefix in the subject.

Why would you take arm, arm64, mips or riscv marked patches without
their maintainers agreeing on this?

> dependency that would prevent me from building the code that I actually

You took patches which have nothing to do with building code. DTS has
nothing to do with that.

> merge. But that isn't always the case. And I clearly need to be able to
> build and validate the patches I subsequently put in scsi-queue.

You cannot validate DTS outside of SoC changes. It does not work like that.

> 
> I'll try to make my script more iterative and only backfill patches if
> the build fails. Hopefully that'll resolve the situation...

Can you instead DO NOT pick up patches which are clearly marked not for
SCSI? Like prefixes: arm64, ARM, RISC-V, MIPS and powerpc, unless
maintainers ask for that?

Best regards,
Krzysztof