[PATCH v2 3/8] dt-bindings: phy: Document PCIe PHY in EcoNet EN751221 and EN7528

[Krzysztof Kozlowski]

On 10/03/2026 11:40, Krzysztof Kozlowski wrote:
> On 10/03/2026 11:37, Caleb James DeLisle wrote:
>>
>> On 10/03/2026 09:24, Krzysztof Kozlowski wrote:
>>> On Mon, Mar 09, 2026 at 01:18:13PM +0000, Caleb James DeLisle wrote:
>>>> EN751221 and EN7528 SoCs have two PCIe slots, and each one has a PHY
>>>> which behaves slightly differently because one slot is Gen1/Gen2 while
>>>> the other is Gen1 only.
>>>>
>>>> Signed-off-by: Caleb James DeLisle <cjd at cjdns.fr>
>>> Still, four separate subsystems unnecessarily merged into one patchset.
>>> Split independent parts of your work per subsystem. See also submitting
>>> patches.
>>
>>
>> I asked for clarification last time and didn't get a reply. I'm not 
>> against changing it but need to understand exactly what's expected b/c 
>> the way I'm imagining it seems way worse. submitting-patches.rst only 
>> says of patch sets "only post say 15 or so at a time", obviously not the 
>> case here.
>>
>> If you're asking for one patchset for phy, one for clock, one for PCI, 
>> and then one to introduce them to the device, I can do that. I just want 
>> to be sure because introducing unused code, and patch sets that depend 
> 
> What is "unused" code? Or how is it unused? Do you understand this will
> go via different subsystems and nothing will be "used" anyway?
> 
>> on other patch sets both seem like anti-patterns to me.
> 
> And asking four different maintainers to manually pick up individual
> bits with multiple commands, instead of just applying entire set
> targeting their subsystem, is pro-pattern here? No. Why adding more work
> to maintainers?
> 
> Think how this is seen by individual subsystem maintainers and how they
> should handle it.
> 

Heh, and nothing of this is explained in cover letter - nothing about
dependencies or merging order - so how anyone can figure out what can be
applied here?

Best regards,
Krzysztof