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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGVrzcaHwd=jEd75NuRUAEaJC_hYyDTu-=+skPv9TTB+ShZy5Q@mail.gmail.com>
Date:	Thu, 19 Dec 2013 09:49:58 -0800
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Hauke Mehrtens <hauke@...ke-m.de>
Cc:	David Miller <davem@...emloft.net>, zambrano@...adcom.com,
	netdev <netdev@...r.kernel.org>,
	Vitaly Bordug <vbordug@...mvista.com>,
	Anton Vorontsov <avorontsov@...mvista.com>
Subject: Re: [PATCH v2 1/9] fixed-phy: register fixed PHY as platform driver

2013/12/19 Hauke Mehrtens <hauke@...ke-m.de>:
> On 12/19/2013 02:48 AM, Florian Fainelli wrote:
>> 2013/12/18 Hauke Mehrtens <hauke@...ke-m.de>:
>>> This changes the fixed phy driver from registering the mdio bus when
>>> the module gets loaded to registering it when a device was registered.
>>> A phy has to get registered to this driver before it registered the
>>> mdio bus, but this only worked when the phys are registered in some
>>> arch code before the system booted completely. Now we want to do so
>>> when the Ethernet driver gets initialized which could be happen every
>>> time.
>>>
>>> To make this driver work with such a case, convert it to a platform
>>> driver which could be registered every time with the phys which should
>>> be on the bus.
>>>
>>> This was only tested on BCM47XX, but not on AR7 because I do not have
>>> such a device.
>>
>> I do understand why you would want to do it that way, but I believe
>> this is should be addressed separately, outside of the actual b44
>> changes. Converting the fixed PHY driver into a platform driver also
>> has an impact on how Device Tree callers such as PowerPC would be
>> dealing with this.
>
> For the ADM switch we could initialize the fixed phy in the arch code,
> because with that switch fixed phys are always needed, but this is also
> needed for some Broadcom switches and I can not automatically detect if
> that is the case. The detection could be done  based on the board the
> kernel was booted on, but there are some hundreds different ones for
> BCM47XX.

Cannot we unconditionally register a fixed PHY at address 0 and use it whether:

- we are connected to an ADM switch
- we have a dual-MAC configuration

It seems to me like this would always work, the driver is the one
deciding which MDIO bus to bind the PHY to.

>
> Sorry I missed some calls to fixed_phy_ads() in the arch code where it
> is used by the device tree platforms, but that could be easily converted
> to a platform device as well.
>
>> Can you submit the required changes to arch/mips/bcm47xx/ for now and
>> get this change merged via David's tree? This would buy us some time
>> to discuss how to best deal with fixed PHY, and also take Device Tree
>> aware platform into account since that part has been an on-going
>> discussion for a while.
>
> What changes to arch/mips/bcm47xx/ are you talking about?

I am talking about the call to fixed_phy_add() which have to happen
early enough before the fixed MDIO bus is probed, just like what AR7
does currently.

I do agree though that something needs to be done because the fixed
MDIO bus usage comes from days where it was easy to add a call to
fixed_phy_add() early enough in your platform code, this is no longer
the case with Device Tree and such.

> Do you mean I should send the b44 patches without the fixed phy stuff
> first and then we can discuss the fixed phy stuff separately, that would
> be my next strategy? ;-)
--
Florian
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ