[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9fa0ce38-d3b5-a60e-cfc4-7799b832065f@hauke-m.de>
Date: Sat, 17 Jul 2021 18:38:43 +0200
From: Hauke Mehrtens <hauke@...ke-m.de>
To: Andrew Lunn <andrew@...n.ch>, Martin Schiller <ms@....tdt.de>
Cc: Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
f.fainelli@...il.com, hkallweit1@...il.com, linux@...linux.org.uk,
davem@...emloft.net, kuba@...nel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v3] net: phy: intel-xway: Add RGMII internal
delay configuration
On 7/13/21 3:06 PM, Andrew Lunn wrote:
>>> [...]
>>>> +#if IS_ENABLED(CONFIG_OF_MDIO)
>>> is there any particular reason why we need to guard this with
>>> CONFIG_OF_MDIO?
>>> The dp83822 driver does not use this #if either (as far as I
>>> understand at least)
>>>
>>
>> It makes no sense to retrieve properties from the device tree if we are
>> compiling for a target that does not support a device tree.
>> At least that is my understanding of this condition.
>
> There should be stubs for all these functions, so if OF is not part of
> the configured kernel, stub functions take their place. That has the
> advantage of at least compiling the code, so checking parameter types
> etc. We try to avoid #ifdef where possible, so we get better compiler
> build test coverage. The more #ifef there are, the more different
> configurations that need compiling in order to get build coverage.
>
> Andrew
>
The phy_get_internal_delay() function does not have a stub function
directly, but it calls phy_get_int_delay_property() which has a stub, if
CONFIG_OF_MDIO is not set, see:
https://elixir.bootlin.com/linux/v5.14-rc1/source/drivers/net/phy/phy_device.c#L2797
The extra ifdef in the PHY driver only saves some code in the HY driver,
but it should still work as before on systems without CONFIG_OF_MDIO.
I would also prefer to remove the ifdef from the intel-xway phy driver.
Hauke
Powered by blists - more mailing lists