[PATCH v2 3/8] dt-bindings: phy: Document PCIe PHY in EcoNet EN751221 and EN7528
Krzysztof Kozlowski
krzk at kernel.org
Tue Mar 10 03:40:06 PDT 2026
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.
Best regards,
Krzysztof
More information about the Linux-mediatek
mailing list