netdev - Re: [RFC] net: allow FEC driver to not have attached PHY

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 8 Oct 2010 15:57:59 +1000
From:	Greg Ungerer <gerg@...pgear.com>
To:	Florian Fainelli <florian@...nwrt.org>
CC:	netdev@...r.kernel.org
Subject: Re: [RFC] net: allow FEC driver to not have attached PHY


Hi Florian,

On 07/10/10 23:24, Florian Fainelli wrote:
> On Thursday 07 October 2010 05:50:16 Greg Ungerer wrote:
>> Hi All,
>>
>> I have a board with a ColdFire SoC on it with the built-in FEC
>> ethernet module. On this hardware the FEC eth output is directly
>> attached to a RTL8305 4-port 10/100 switch. There is no conventional
>> PHY, the FEC output is direct into the uplink port of the switch
>> chip.
>>
>> This setup doesn't work after the FEC code was switch to using
>> phylib. The driver used to have code to bypass phy detection/setup
>> for this particular board. The phylib probe finds nothing, and of
>> course sets a no-link condition.
>>
>> So, what is the cleanest way to support this?
>
> If phy detection fails and you cannot attach to a known PHY driver, you could
> register a fixed-PHY driver wich will report the link to be up. I had to do
> something like this for the cpmac driver[1] where various switches and
> external PHY configurations are supported.
>
> [1]:
> https://dev.openwrt.org/browser/trunk/target/linux/ar7/patches-2.6.35/972-
> cpmac_multi_probe.patch

Ah yes, that looks like exactly what I need.
Thanks for the pointer.

Regards
Greg



>> The attached patch adds a config option to do this sort of generically
>> for the FEC driver. But I am wondering if there isn't a better way?
>>
>> Regards
>> Greg
>>
>>
>> ---
>>
>> [RFC] net: allow FEC driver to not have attached PHY
>>
>> At least one board using the FEC driver does not have a conventional
>> PHY attached to it, it is directly connected to a somewhat simple
>> ethernet switch (the board is the SnapGear/LITE, and the attached
>> 4-port ethernet switch is a RealTek RTL8305). This switch does not
>> present the usual register interface of a PHY, it presents nothing.
>> So a PHY scan will find nothing.
>>
>> After the FEC driver was changed to use phylib for supporting phys
>> it no longer works on this particular board/switch setup.
>>
>> Add a config option to allow configuring the FEC driver to not expect
>> a PHY to be present.
>>
>> Signed-off-by: Greg Ungerer<gerg@...inux.org>
>> ---
>>   drivers/net/Kconfig |    9 +++++++++
>>   drivers/net/fec.c   |    7 +++++++
>>   2 files changed, 16 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
>> index 93494e2..ee44728 100644
>> --- a/drivers/net/Kconfig
>> +++ b/drivers/net/Kconfig
>> @@ -1934,6 +1934,15 @@ config FEC2
>>   	  Say Y here if you want to use the second built-in 10/100 Fast
>>   	  ethernet controller on some Motorola ColdFire processors.
>>
>> +config FEC_NOPHY
>> +	bool "FEC has no attached PHY"
>> +	depends on FEC
>> +	help
>> +	  Some boards using the FEC driver may not have a PHY directly
>> +	  attached to it. Typically in this scenario the FEC output is
>> +	  directly connected to the input of an ethernet switch or hub.
>> +	  Say Y here if your hardware is like this.
>> +
>>   config FEC_MPC52xx
>>   	tristate "MPC52xx FEC driver"
>>   	depends on PPC_MPC52xx&&  PPC_BESTCOMM
>> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
>> index 768b840..3637f89 100644
>> --- a/drivers/net/fec.c
>> +++ b/drivers/net/fec.c
>> @@ -910,6 +910,11 @@ fec_enet_open(struct net_device *dev)
>>   	if (ret)
>>   		return ret;
>>
>> +#ifdef CONFIG_FEC_NOPHY
>> +	/* No PHY connected, assume link is always up */
>> +	fep->link = 1;
>> +	fec_restart(dev, 0);
>> +#else
>>   	/* Probe and connect to PHY when open the interface */
>>   	ret = fec_enet_mii_probe(dev);
>>   	if (ret) {
>> @@ -917,6 +922,8 @@ fec_enet_open(struct net_device *dev)
>>   		return ret;
>>   	}
>>   	phy_start(fep->phy_dev);
>> +#endif
>> +
>>   	netif_start_queue(dev);
>>   	fep->opened = 1;
>>   	return 0;
>> --
>> 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
>


-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@...pgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
--
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