Re: [PATCH net-next 2/3] net: dp83869: Add ability to advertise Fiber connection

Dan Murphy
2020-09-17T19:55:19Z

Andrew

On 9/16/20 5:13 PM, Andrew Lunn wrote:
> On Wed, Sep 16, 2020 at 03:54:34PM -0500, Dan Murphy wrote:
>> Andrew
>>
>> On 9/15/20 3:17 PM, Andrew Lunn wrote:
>>>> + linkmode_set_bit(ETHTOOL_LINK_MODE_100baseFX_Full_BIT,
>>>> + phydev->supported);
>>>> + linkmode_set_bit(ETHTOOL_LINK_MODE_100baseFX_Half_BIT,
>>>> + phydev->supported);
>>>> +
>>>> + /* Auto neg is not supported in 100base FX mode */
>>> Hi Dan
>>>
>>> If it does not support auto neg, how do you decide to do half duplex?
>>> I don't see any code here which allows the user to configure it.
>> Ethtool has the provisions to set the duplex and speed right?.
> What i'm getting at is you say you support
> ETHTOOL_LINK_MODE_100baseFX_Full_BIT &
> ETHTOOL_LINK_MODE_100baseFX_Half_BIT. If there is no auto neg in FX
> mode, i'm questioning how these two different modes code be used? I'm
> guessing the PHY defaults to ETHTOOL_LINK_MODE_100baseFX_Full_BIT? How
> does the user set it to ETHTOOL_LINK_MODE_100baseFX_Half_BIT?

The user can use ethtool to set the speed and duplex. And ethtool uses
the IOCTLs to configure the device.

So if the user creates their own HAL then they can use those IOCTLs as well.

The data sheet indicates

"In fiber mode, the speed is not
decided through auto-negotiation. Both sides of the link must be
configured to the same operating speed."

>
>> The only call back I see which is valid is config_aneg which would still
>> require a user space tool to set the needed link modes.
> Correct. Maybe all you need to do is point me at the code in the
> driver which actually sets the PHY into half duplex in FX mode when
> the user asks for it. Is it just clearing BMCR_FULLDPLX?

Here is the full flow when setting the speed and duplex mode from the
Ethtool or when the IOCTL's are called to update the PHY

phy_ethtool_ksettings_set updates the phydev->speed and phydev->duplex

Since Auto Neg is disabled the call to genphy_setup_forced is done in
the __genphy_config_aneg in phy_device.

genphy_setup_forced updates the BMCR with the updated values.

So IMO there is no need to populate the config_aneg call back to

root@am335x-evm:~# ./ethtool -s eth0 speed 10 duplex half
[   92.098491] phy_ethtool_ksettings_set
[   92.102247] phy_ethtool_ksettings_set: speed 10 duplex 0
[   92.107755] phy_sanitize_settings
[   92.111085] phy_config_aneg
[   92.113930] genphy_config_aneg
[   92.116997] __genphy_config_aneg
[   92.120237] genphy_setup_forced
[   92.123419] genphy_setup_forced: Update the BMCR
root@am335x-evm:~# ./ethtool -s eth0 speed 100 duplex full
[  102.693105] phy_ethtool_ksettings_set
[  102.697029] phy_ethtool_ksettings_set: speed 100 duplex 1
[  102.702462] phy_sanitize_settings
[  102.705892] phy_config_aneg
[  102.708702] genphy_config_aneg
[  102.711770] __genphy_config_aneg
[  102.715051] genphy_setup_forced
[  102.718209] genphy_setup_forced: Update the BMCR

I am hoping this answers your question.

Dan