[PATCH v2 3/8] dt-bindings: phy: Document PCIe PHY in EcoNet EN751221 and EN7528
Krzysztof Kozlowski
krzk at kernel.org
Tue Mar 10 04:20:31 PDT 2026
On 10/03/2026 12:13, Caleb James DeLisle wrote:
>
> 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?
>
>
> Unused in the sense that you can't exercise that code without additional
> code which is out of tree - at least until the subsequent patch set lands.
Which is exactly the same as with your method of combining independent
subsystems here. Do you know this goes via independent subsystems?
Around four of them?
Best regards,
Krzysztof
More information about the Linux-mediatek
mailing list