Re: [PATCH v2 1/4] dt-bindings: net: ethernet-phy: move clocks property to invidivual PHY bindings

[George Moussalem]

On 6/5/26 01:39, Rob Herring wrote:
> On Tue, Jun 02, 2026 at 10:50:37AM +0400, George Moussalem wrote:
>> Move the clock property and restriction from the ethernet-phy.yaml file
>> to the individual PHY binding files. This allows each PHY to manage its
>> own clock requirements.
>>
>> Signed-off-by: George Moussalem <george.moussalem@xxxxxxxxxxx>
>> ---
>> Commit 350b7a258f20 introduced the clocks property with a restriction to
>> maximum 1 to the main ethernet-phy.yaml binding for Realtek to add an
>> optional external clock source. This is restrictive to all PHY bindings,
>> as some PHYs may require more than 1 clock such as the IPQ5018 PHY which
>> requires 2 clocks (for RX and TX).
>>
>> There are three other PHY drivers that require clock management:
>> - Micrel: requires 1 optional clock and the micrel.yaml file already
>> accomodates for the clock property.
> 
> It does? Where?

apologies, I see it's clock-names only:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/net/micrel.yaml#n103

> 
>> - SMSC: requires an optional clock and the legacy bindings file
>> (smsc-lan87xx.txt) already accomodates for the clock property.
>> - BCM7xxx: requires an optional clock. I could not find a bindings file
>> for this PHY family.
> 
> Because it only uses what is defined in ethernet-phy.yaml. The only way 
> to enforce 1 clock in this case is split ethernet-phy.yaml into common 
> properties (removing the 'select') and a 'generic' phy schema that 
> selects nodes with name 'ethernet-phy' and also have no 'compatible' 
> property. Not sure if that's really worth doing. We generally try to 
> require compatible for any new phys, but that's only if they try to add 
> something to ethernet-phy.yaml so we see it.
> 
> The simple solution is you need to keep 'clocks' and make it 1-2 
> clocks. It's been how many years until we needed 2 clocks? So probably 
> some time before needing more if ever.

I'll update in next version, thanks.

> 
> Rob

thanks,
George