> Because function naming is the same I'm afraid they easily can be used
> incorrectly (the bugs we just discuss are good examples). Maybe it
> could be an option to reflect the semantics in the name like this
> (better suited proposals welcome):
>
> case 1: mii_xxx_to_linkmode_yyy
> case 2: mii_x
> Eventually we'd have three types of mii_xxx_to_linkmode_yyy functions:
>
> 1. Function first zeroes the destination linkmode bitmap
> 2. Function sets bits in the linkmode bitmap but doesn't clear bits
>if condition isn't met
> 3. Function clears / sets bits it's responsible for
>
> example
On 25.11.2018 17:45, Andrew Lunn wrote:
> On Sun, Nov 25, 2018 at 03:23:42PM +0100, Heiner Kallweit wrote:
>> I wondered why ethtool suddenly reports that link partner doesn't
>> support aneg and GBit modes. It turned out that this is caused by two
>> bugs in conversion to linkmode bitmaps.
>>
>> 1
On Sun, Nov 25, 2018 at 03:23:42PM +0100, Heiner Kallweit wrote:
> I wondered why ethtool suddenly reports that link partner doesn't
> support aneg and GBit modes. It turned out that this is caused by two
> bugs in conversion to linkmode bitmaps.
>
> 1. In genphy_read_status the value of phydev->l
I wondered why ethtool suddenly reports that link partner doesn't
support aneg and GBit modes. It turned out that this is caused by two
bugs in conversion to linkmode bitmaps.
1. In genphy_read_status the value of phydev->lp_advertising is
overwritten, thus GBit modes aren't reported any longer
