[PATCH v2 00/14] HSI2, UFS & UFS phy support for Tensor GS101

[Krzysztof Kozlowski]

On 25/04/2024 12:31, Peter Griffin wrote:
> Hi Krzysztof,
> 
> On Thu, 25 Apr 2024 at 08:08, Krzysztof Kozlowski <krzk at kernel.org> wrote:
>>
>> On 23/04/2024 22:49, Peter Griffin wrote:
>>> Hi James, Martin, Alim, Bart, Krzysztof, Vinod, all
>>>
>>> Firstly, many thanks to everyone who reviewed and tested v1.
>>>
>>> This series adds support for the High Speed Interface (HSI) 2 clock
>>> management unit, UFS controller and UFS phy calibration/tuning for GS101
>>> found in Pixel 6.
>>>
>>> With this series applied, UFS is now functional on gs101. The SKhynix
>>> HN8T05BZGKX015 can be enumerated, partitions mounted etc. This allows us to
>>> move away from the initramfs rootfs we have been using for development so far.
>>>
>>> Merge Strategy
>>> 1) UFS driver/bindings via UFS/SCSI tree (James / Martin / Alim)
>>> 2) GS101 DTS/DTSI should go via Krzysztofs Exynos SoC tree
>>> 3) Clock driver/bindings via Clock tree (Krzysztof / Stephen)
>>> 4) PHY driver/bindings via PHY tree (Vinod)
>>>
>>> The v2 series has been rebased on next-20240422, as such all the phy parts
>>> which were already queued by Vinod have been dropped. Two new phy patches
>>> are added to address review feedback received after the patches were queued.
>>>
>>> The series is broadly split into the following parts:
>>> 1) dt-bindings documentation updates
>>> 2) gs101/oriole dts & dtsi updates
>>> 3) Prepatory patches for ufs-exynos driver
>>> 4) GS101 ufs-exynos support
>>> 5) gs101 phy fixes
>>>
>>
>> I asked to split, otherwise please explain why PHY and UFS depends on
>> DTS and clk.
> 
> Seems I misunderstood your feedback. I thought you just want me to
> make clear who was merging what from the series via which tree. But
> you want separate series?
> 
> 1) ufs host dt bindings & driver
> 2) minor phy fixes series (most patches got applied already for phy)
> 
> What do you want for cmu_hsi2 clocks and dts/dtsi? The device tree
> depends on the clock bindings to compile

This is not specific to Samsung Soc, Qualcomm soc or any other arm-soc.
Independent patches for different subsystems should not be put together
in one patchset. You create false impression of dependencies, grow CC
list, cause issues when applying (I cannot just apply entire set with
one command, but need to run multiple commands (!!!), plus certain
subsystems will reject your patchset because they take everything or
nothing) and possible bisection issues (because patches which should be
tested independently, are put together so testing does not uncover
undocumented dependencies).

Almost never combine independent patches which are targeted to entirely
different subsystems. There are exceptions, but regular feature work is
not one of them.

Subsystem is everything in top level of drivers/ and drivers/soc/ (or
kind of arch/arm64/boot/dts/, but that tricky because
Tesla/Google/Exynos are one subsystem). Or whatever is there in
MAINTAINERS file.

I don't know, we keep repeating this over multiple times, so it could be
added to some docs, but people do not read docs...

1. Drivers and driver bindings go to subsystems.
2. DTS and board compatibles go to soc.
a. Any dependency on driver is a near-NAK.
b. Any dependency on headers must be clearly expressed, because headers
cannot be back-merged from subsystem tree to DTS tree.
c. Any usage or usage of bindings from other sets must be clearly
expressed (linked).
3. drivers/soc go to soc.

Things from list above targeting the same maintainer tree, can be
combined in one series, with dependencies expressed in patch changelogs
or cover letter.

Best regards,
Krzysztof