All of lore.kernel.org
 help / color / mirror / Atom feed
From: florian@openwrt.org (Florian Fainelli)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] net: fec: Add support for multiple phys on mdiobus
Date: Mon, 21 Jan 2013 12:12:52 +0100	[thread overview]
Message-ID: <50FD22B4.5070307@openwrt.org> (raw)
In-Reply-To: <50FD2172.2020608@grandegger.com>

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.
--
Florian

WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <florian@openwrt.org>
To: Wolfgang Grandegger <wg@grandegger.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>,
	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:12:52 +0100	[thread overview]
Message-ID: <50FD22B4.5070307@openwrt.org> (raw)
In-Reply-To: <50FD2172.2020608@grandegger.com>

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.
--
Florian

  reply	other threads:[~2013-01-21 11:12 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 [this message]
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
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=50FD22B4.5070307@openwrt.org \
    --to=florian@openwrt.org \
    --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.