> I think adding it in the core would be a bit of a challenge. I think each
> PHY driver needs to handle parsing and validating this property on its own
> (like fifo-depth). It is a PHY specific setting.
fifo-depth yes. But some delays follow a common pattern.
e.g.
Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
Device Tree Value Delay Pad Skew Register Value
-----------------------------------------------------
0 -840ps 0000
200 -720ps 0001
400 -600ps 0010
600 -480ps 0011
800 -360ps 0100
1000 -240ps 0101
1200 -120ps 0110
1400 0ps 0111
1600 120ps 1000
1800 240ps 1001
2000 360ps 1010
2200 480ps 1011
2400 600ps 1100
2600 720ps 1101
2800 840ps 1110
3000 960ps 1111
Documentation/devicetree/bindings/net/adi,adin.yaml
adi,rx-internal-delay-ps:
description: |
RGMII RX Clock Delay used only when PHY operates in RGMII mode with
internal delay (phy-mode is 'rgmii-id' or 'rgmii-rxid') in pico-seconds.
enum: [ 1600, 1800, 2000, 2200, 2400 ]
default: 2000
adi,tx-internal-delay-ps:
description: |
RGMII TX Clock Delay used only when PHY operates in RGMII mode with
internal delay (phy-mode is 'rgmii-id' or 'rgmii-txid') in pico-seconds.
enum: [ 1600, 1800, 2000, 2200, 2400 ]
default: 2000
Documentation/devicetree/bindings/net/apm-xgene-enet.txt
- tx-delay: Delay value for RGMII bridge TX clock.
Valid values are between 0 to 7, that maps to
417, 717, 1020, 1321, 1611, 1913, 2215, 2514 ps
Default value is 4, which corresponds to 1611 ps
- rx-delay: Delay value for RGMII bridge RX clock.
Valid values are between 0 to 7, that maps to
273, 589, 899, 1222, 1480, 1806, 2147, 2464 ps
Default value is 2, which corresponds to 899 ps
You could implement checking against a table of valid values, which is
something you need for your PHY. You could even consider making it a
2D table, and return the register value, not the delay?
Andrew
