From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] net: fec: Add support for multiple phys on mdiobus
Date: Mon, 21 Jan 2013 12:56:53 +0100 [thread overview]
Message-ID: <20130121115653.GY1906@pengutronix.de> (raw)
In-Reply-To: <50FD22B4.5070307@openwrt.org>
On Mon, Jan 21, 2013 at 12:12:52PM +0100, Florian Fainelli wrote:
> On 01/21/2013 12:07 PM, Wolfgang Grandegger wrote:
> >On 01/21/2013 11:07 AM, Sascha Hauer wrote:
> >>On Mon, Jan 21, 2013 at 09:56:24AM +0100, Wolfgang Grandegger wrote:
> >>>On 01/21/2013 09:37 AM, Sascha Hauer wrote:
> >>>>There may be multiple phys on an mdio bus. This series adds support
> >>>>for this to the fec driver. I recently had a board which has a switch
> >>>>connected to the fec's mdio bus, so I had to pick the correct phy.
> >>>
> >>>Pick one PHY from a switch port? Well, does a PHY-less (or fixed-link)
> >>>configuration for a switch not make more sense?
> >>
> >>Yes, you're probably right.
> >>
> >>>Various ARM Ethernet
> >>>contoller drivers do not support it. I recently needed a hack for an
> >>>AT91 board.
> >>
> >>I wonder how we want to proceed. Should there be a devicetree property
> >>'fixed-link' like done for fs_enet (and not recommended for new code,
> >>stated in the comment above of_phy_connect_fixed_link)?
> >
> >Also the gianfar and ucc_geth drivers use this interface (via fixed
> >link phy). I tried to use it for the AT91 macb driver but stopped
> >quickly because the usage was not straight forward (too much code)...
> >even if the idea of using a fake fixed-link phy is not bad.
> >
> >>Currently I have a property 'phy' in the fec binding which has a phandle
> >>to a phy provided by the fec's mdio bus, but this could equally well
> >
> >But than the cable must be connected to the associated switch port.
> >
> >>point to a fixed dummy phy:
> >>
> >> phy = &fixed-phy;
> >
> >The link speed, full/half duplex and maybe some mroe parameter should
> >be configurable via device tree.
> >
> >>Currently there seems to be no common convention for the devicetree how
> >>to handle such situations, or am I missing something?
> >
> >That's also may impression. There seem to be a few more related hacks:
> >
> >$ find . -name '*.c'| xargs grep -i "phy-less"
> >./ethernet/amd/au1000_eth.c: netdev_info(dev, "using PHY-less setup\n");
> >./ethernet/amd/au1000_eth.c: } else { /* PHY-less op, assume full-duplex */
> >./ethernet/ibm/emac/core.c: /* PHY-less configuration.
> >./ethernet/ibm/emac/core.c: /* PHY-less configuration.
> >
> >I would prefer to handle the "fixed-link" property of the ethernet dt
> >node directly in the driver with a generic helper function.
>
> Is not what of_phy_connect_fixed_link() offer? I am not sure there
> can be much done by an helper than that.
The comment above this function states:
/**
* of_phy_connect_fixed_link - Parse fixed-link property and return a dummy phy
* @dev: pointer to net_device claiming the phy
* @hndlr: Link state callback for the network device
* @iface: PHY data interface type
*
* This function is a temporary stop-gap and will be removed soon. It is
* only to support the fs_enet, ucc_geth and gianfar Ethernet drivers. Do
* not call this function from new drivers.
*/
And the commit introducing it has:
Note: the dummy phy handling in arch/powerpc is a bit of a hack and
needs to be reworked. This function is being added now to solve the
regression in the Ethernet drivers, but it should be considered a
temporary measure until the fixed link handling can be reworked.
The 'temporary measure' exists for 3 1/2 years now ;)
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
WARNING: multiple messages have this Message-ID (diff)
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Florian Fainelli <florian@openwrt.org>
Cc: Wolfgang Grandegger <wg@grandegger.com>,
netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
shawn.guo@linaro.org, davem@davemloft.net
Subject: Re: [PATCH] net: fec: Add support for multiple phys on mdiobus
Date: Mon, 21 Jan 2013 12:56:53 +0100 [thread overview]
Message-ID: <20130121115653.GY1906@pengutronix.de> (raw)
In-Reply-To: <50FD22B4.5070307@openwrt.org>
On Mon, Jan 21, 2013 at 12:12:52PM +0100, Florian Fainelli wrote:
> On 01/21/2013 12:07 PM, Wolfgang Grandegger wrote:
> >On 01/21/2013 11:07 AM, Sascha Hauer wrote:
> >>On Mon, Jan 21, 2013 at 09:56:24AM +0100, Wolfgang Grandegger wrote:
> >>>On 01/21/2013 09:37 AM, Sascha Hauer wrote:
> >>>>There may be multiple phys on an mdio bus. This series adds support
> >>>>for this to the fec driver. I recently had a board which has a switch
> >>>>connected to the fec's mdio bus, so I had to pick the correct phy.
> >>>
> >>>Pick one PHY from a switch port? Well, does a PHY-less (or fixed-link)
> >>>configuration for a switch not make more sense?
> >>
> >>Yes, you're probably right.
> >>
> >>>Various ARM Ethernet
> >>>contoller drivers do not support it. I recently needed a hack for an
> >>>AT91 board.
> >>
> >>I wonder how we want to proceed. Should there be a devicetree property
> >>'fixed-link' like done for fs_enet (and not recommended for new code,
> >>stated in the comment above of_phy_connect_fixed_link)?
> >
> >Also the gianfar and ucc_geth drivers use this interface (via fixed
> >link phy). I tried to use it for the AT91 macb driver but stopped
> >quickly because the usage was not straight forward (too much code)...
> >even if the idea of using a fake fixed-link phy is not bad.
> >
> >>Currently I have a property 'phy' in the fec binding which has a phandle
> >>to a phy provided by the fec's mdio bus, but this could equally well
> >
> >But than the cable must be connected to the associated switch port.
> >
> >>point to a fixed dummy phy:
> >>
> >> phy = &fixed-phy;
> >
> >The link speed, full/half duplex and maybe some mroe parameter should
> >be configurable via device tree.
> >
> >>Currently there seems to be no common convention for the devicetree how
> >>to handle such situations, or am I missing something?
> >
> >That's also may impression. There seem to be a few more related hacks:
> >
> >$ find . -name '*.c'| xargs grep -i "phy-less"
> >./ethernet/amd/au1000_eth.c: netdev_info(dev, "using PHY-less setup\n");
> >./ethernet/amd/au1000_eth.c: } else { /* PHY-less op, assume full-duplex */
> >./ethernet/ibm/emac/core.c: /* PHY-less configuration.
> >./ethernet/ibm/emac/core.c: /* PHY-less configuration.
> >
> >I would prefer to handle the "fixed-link" property of the ethernet dt
> >node directly in the driver with a generic helper function.
>
> Is not what of_phy_connect_fixed_link() offer? I am not sure there
> can be much done by an helper than that.
The comment above this function states:
/**
* of_phy_connect_fixed_link - Parse fixed-link property and return a dummy phy
* @dev: pointer to net_device claiming the phy
* @hndlr: Link state callback for the network device
* @iface: PHY data interface type
*
* This function is a temporary stop-gap and will be removed soon. It is
* only to support the fs_enet, ucc_geth and gianfar Ethernet drivers. Do
* not call this function from new drivers.
*/
And the commit introducing it has:
Note: the dummy phy handling in arch/powerpc is a bit of a hack and
needs to be reworked. This function is being added now to solve the
regression in the Ethernet drivers, but it should be considered a
temporary measure until the fixed link handling can be reworked.
The 'temporary measure' exists for 3 1/2 years now ;)
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2013-01-21 11:56 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-21 8:37 [PATCH] net: fec: Add support for multiple phys on mdiobus Sascha Hauer
2013-01-21 8:37 ` Sascha Hauer
2013-01-21 8:37 ` [PATCH 1/2] net: fec: refactor dt probing Sascha Hauer
2013-01-21 8:37 ` Sascha Hauer
2013-01-21 17:48 ` Baruch Siach
2013-01-21 17:48 ` Baruch Siach
2013-01-21 18:27 ` Sascha Hauer
2013-01-21 18:27 ` Sascha Hauer
2013-01-21 8:37 ` [PATCH 2/2] net: fec: Add support for phys from devicetree Sascha Hauer
2013-01-21 8:37 ` Sascha Hauer
2013-01-21 8:56 ` [PATCH] net: fec: Add support for multiple phys on mdiobus Wolfgang Grandegger
2013-01-21 8:56 ` Wolfgang Grandegger
2013-01-21 10:07 ` Sascha Hauer
2013-01-21 10:07 ` Sascha Hauer
2013-01-21 11:07 ` Wolfgang Grandegger
2013-01-21 11:07 ` Wolfgang Grandegger
2013-01-21 11:12 ` Florian Fainelli
2013-01-21 11:12 ` Florian Fainelli
2013-01-21 11:33 ` Wolfgang Grandegger
2013-01-21 11:33 ` Wolfgang Grandegger
2013-01-21 11:56 ` Sascha Hauer [this message]
2013-01-21 11:56 ` Sascha Hauer
2013-01-21 12:06 ` Sascha Hauer
2013-01-21 12:06 ` Sascha Hauer
2013-01-22 7:22 ` Wolfgang Grandegger
2013-01-22 7:22 ` Wolfgang Grandegger
2013-01-22 14:47 ` Florian Fainelli
2013-01-22 14:47 ` Florian Fainelli
2013-01-22 15:03 ` Wolfgang Grandegger
2013-01-22 15:03 ` Wolfgang Grandegger
2013-01-22 15:19 ` Florian Fainelli
2013-01-22 15:19 ` Florian Fainelli
2013-01-22 15:26 ` Wolfgang Grandegger
2013-01-22 15:26 ` Wolfgang Grandegger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130121115653.GY1906@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.