From patchwork Thu Oct 7 03:50:16 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Ungerer X-Patchwork-Id: 66995 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 7857FB6F07 for ; Thu, 7 Oct 2010 14:52:02 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760072Ab0JGDv5 (ORCPT ); Wed, 6 Oct 2010 23:51:57 -0400 Received: from dalsmrelay2.nai.com ([205.227.136.216]:24825 "HELO dalsmrelay2.nai.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752430Ab0JGDv4 (ORCPT ); Wed, 6 Oct 2010 23:51:56 -0400 Received: from (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 1756_0577_3a1f2436_d1c6_11df_bc5f_00219b929abd; Thu, 07 Oct 2010 03:51:54 +0000 Received: from dalexbr1.corp.nai.org (161.69.111.81) by DALEXHT2.corp.nai.org (10.64.5.52) with Microsoft SMTP Server id 8.2.254.0; Wed, 6 Oct 2010 22:51:55 -0500 Received: from sncexbr1.corp.nai.org ([161.69.5.246]) by dalexbr1.corp.nai.org with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Oct 2010 22:51:54 -0500 Received: from STPSMTP01.scur.com ([10.96.96.163]) by sncexbr1.corp.nai.org with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Oct 2010 20:51:54 -0700 Received: from cyberguard.com.au ([10.46.129.16]) by STPSMTP01.scur.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 22:51:53 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by bne.snapgear.com (Postfix) with ESMTP id BB67AEBAD0; Thu, 7 Oct 2010 13:51:51 +1000 (EST) X-Virus-Scanned: amavisd-new at snapgear.com Received: from bne.snapgear.com ([127.0.0.1]) by localhost (bne.snapgear.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8TWMFKl2hDn; Thu, 7 Oct 2010 13:51:42 +1000 (EST) Received: from snapgear.com (bnelabfw.scur.com [10.46.129.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bne.snapgear.com (Postfix) with ESMTP; Thu, 7 Oct 2010 13:51:42 +1000 (EST) Received: from goober.internal.moreton.com.au (localhost [127.0.0.1]) by snapgear.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o973oHcu026911; Thu, 7 Oct 2010 13:50:17 +1000 Received: (from gerg@localhost) by goober.internal.moreton.com.au (8.14.3/8.14.3/Submit) id o973oGFE026910; Thu, 7 Oct 2010 13:50:16 +1000 Date: Thu, 7 Oct 2010 13:50:16 +1000 From: Greg Ungerer Message-ID: <201010070350.o973oGFE026910@goober.internal.moreton.com.au> CC: Subject: [RFC] net: allow FEC driver to not have attached PHY To: X-Mailer: mail (GNU Mailutils 2.1) X-OriginalArrivalTime: 07 Oct 2010 03:51:53.0400 (UTC) FILETIME=[FAB69B80:01CB65D2] MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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? 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 --- drivers/net/Kconfig | 9 +++++++++ drivers/net/fec.c | 7 +++++++ 2 files changed, 16 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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;