Messages in this thread | | | Subject | Re: [PATCH net-next v5 4/4] net: dp83869: Add RGMII internal delay configuration | From | Dan Murphy <> | Date | Tue, 2 Jun 2020 18:25:38 -0500 |
| |
Florian
On 6/2/20 6:18 PM, Dan Murphy wrote: > Florian > > On 6/2/20 6:13 PM, Florian Fainelli wrote: >> >> On 6/2/2020 4:10 PM, Dan Murphy wrote: >>> Florian >>> >>> On 6/2/20 5:33 PM, Florian Fainelli wrote: >>>> On 6/2/2020 9:45 AM, Dan Murphy wrote: >>>>> Add RGMII internal delay configuration for Rx and Tx. >>>>> >>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com> >>>>> --- >>>> [snip] >>>> >>>>> + >>>>> enum { >>>>> DP83869_PORT_MIRRORING_KEEP, >>>>> DP83869_PORT_MIRRORING_EN, >>>>> @@ -108,6 +113,8 @@ enum { >>>>> struct dp83869_private { >>>>> int tx_fifo_depth; >>>>> int rx_fifo_depth; >>>>> + s32 rx_id_delay; >>>>> + s32 tx_id_delay; >>>>> int io_impedance; >>>>> int port_mirroring; >>>>> bool rxctrl_strap_quirk; >>>>> @@ -232,6 +239,22 @@ static int dp83869_of_init(struct phy_device >>>>> *phydev) >>>>> &dp83869->tx_fifo_depth)) >>>>> dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB; >>>>> + ret = of_property_read_u32(of_node, "rx-internal-delay-ps", >>>>> + &dp83869->rx_id_delay); >>>>> + if (ret) { >>>>> + dp83869->rx_id_delay = >>>>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF]; >>>>> + ret = 0; >>>>> + } >>>>> + >>>>> + ret = of_property_read_u32(of_node, "tx-internal-delay-ps", >>>>> + &dp83869->tx_id_delay); >>>>> + if (ret) { >>>>> + dp83869->tx_id_delay = >>>>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF]; >>>>> + ret = 0; >>>>> + } >>>> It is still not clear to me why is not the parsing being done by >>>> the PHY >>>> library helper directly? >>> Why would we do that for these properties and not any other? >> Those properties have a standard name, which makes them suitable for >> parsing by the core PHY library. >>> Unless there is a new precedence being set here by having the PHY >>> framework do all the dt node parsing for common properties. >> You could parse the vendor properties through the driver, let the PHY >> library parse the standard properties, and resolve any ordering >> precedence within the driver. In general, I would favor standard >> properties over vendor properties. >> >> Does this help? > > Ok so new precedence then. > > Because there are common properties like tx-fifo-depth, rx-fifo-depth, > enet-phy-lane-swap and max_speed that the PHY framework should parse > as well. > I am assuming that the retrieval of the property and getting the index should be 2 separate APIs?
One API to get the property value and one API to find the index value.
Dan
> Dan >
| |