lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 28 Jan 2014 00:36:15 +0400
From:	Max Filippov <jcmvbkbc@...il.com>
To:	Florian Fainelli <f.fainelli@...il.com>
Cc:	Ben Hutchings <ben@...adent.org.uk>,
	"linux-xtensa@...ux-xtensa.org" <linux-xtensa@...ux-xtensa.org>,
	netdev <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Chris Zankel <chris@...kel.net>,
	Marc Gauthier <marc@...ence.com>,
	"David S. Miller" <davem@...emloft.net>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <rob.herring@...xeda.com>
Subject: Re: [PATCH 1/3] net: ethoc: don't advertise gigabit speed on attached PHY

On Mon, Jan 27, 2014 at 11:36 PM, Florian Fainelli <f.fainelli@...il.com> wrote:
> 2014-01-27 Max Filippov <jcmvbkbc@...il.com>:
>> On Mon, Jan 27, 2014 at 2:18 PM, Ben Hutchings <ben@...adent.org.uk> wrote:
>>> On Mon, 2014-01-27 at 07:59 +0400, Max Filippov wrote:
>>>> OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does
>>>> not disable advertisement when PHY supports them. This results in
>>>> non-functioning network when the MAC is connected to a gigabit PHY connected
>>>> to a gigabit switch.
>>>>
>>>> The fix is to disable gigabit speed advertisement on attached PHY
>>>> unconditionally.
>>>>
>>>> Signed-off-by: Max Filippov <jcmvbkbc@...il.com>
>>>> ---
>>>>  drivers/net/ethernet/ethoc.c | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
>>>> index 4de8cfd..0aa1a05 100644
>>>> --- a/drivers/net/ethernet/ethoc.c
>>>> +++ b/drivers/net/ethernet/ethoc.c
>>>> @@ -712,6 +712,8 @@ static int ethoc_open(struct net_device *dev)
>>>>               netif_start_queue(dev);
>>>>       }
>>>>
>>>> +     priv->phy->advertising &= ~(ADVERTISED_1000baseT_Full |
>>>> +                                 ADVERTISED_1000baseT_Half);
>>>>       phy_start(priv->phy);
>>>>       napi_enable(&priv->napi);
>>>>
>>>
>>> This is not sufficient to disable gigabit speeds; the supported mask
>>> should also be limited.  And it should be done even before the net
>>
>> I tried that, but when I also limit supported mask the phy driver doesn't
>> touch gigabit advertising register int the genphy_config_advert at all.
>> That's probably right for ethtool interface, but ethoc doesn't support
>> ethtool.
>
> This is not right for libphy either, phydev->supported must reflect
> that you support Gigabit or not.

I'm sorry, does that mean that I must not touch phydev->supported,
or that I must update it too and somehow fix genphy_config_advert?

> Since ethoc supports libphy, there really is no reason not to
> implement the ethtool_{get,set}_settings callbacks using
> phy_mii_ioctl().

Ok, I'll add that.

>>> device is registered.
>>>
>>> Rather than poking into the phy_device structure directly from this
>>> driver, I think you should add a function in phylib for this purpose.
>
> All drivers are currently modifying phydev->advertising and
> phydev->supported directly, most of them do it correctly as far as I
> checked. It does make some sense to add a helper function though.

[...]

>> diff --git a/include/linux/phy.h b/include/linux/phy.h
>> index 48a4dc3..0282a8d 100644
>> --- a/include/linux/phy.h
>> +++ b/include/linux/phy.h
>> @@ -559,6 +559,11 @@ static inline int phy_read_status(struct phy_device *phydev) {
>>         return phydev->drv->read_status(phydev);
>>  }
>>
>> +static inline void phy_update_adv(struct phy_device *phydev, u32 mask, u32 set)
>> +{
>> +       phydev->advertising = (phydev->advertising & mask) | set;
>> +}
>> +
>
> This should be a preliminary patch to this patchset, so you first
> introduce the function, then use it in the driver, but the idea looks
> good. There is room for updating quite some drivers out there since
> those used to modify phydev->advertising and phydev->supported
> directly without using an accessor.

What about those that do something like this:

phydev->advertising = phydev->supported;

leave them as is, or provide read accessor for phydev->supported?

-- 
Thanks.
-- Max
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists