From: Grant Likely <grant.likely@secretlab.ca>
To: Holger brunck <holger.brunck@keymile.com>
Cc: hs@denx.de, linuxppc-dev@ozlabs.org, netdev@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org, Detlev Zundel <dzu@denx.de>
Subject: Re: powerpc, fs_enet: scanning PHY after Linux is up
Date: Wed, 6 Oct 2010 11:30:19 -0600 [thread overview]
Message-ID: <AANLkTinWGw5AR8KSSdCyOWqCaMVL-wZH+2uB7zh404_i@mail.gmail.com> (raw)
In-Reply-To: <4CAC7EB0.6080502@keymile.com>
On Wed, Oct 6, 2010 at 7:50 AM, Holger brunck <holger.brunck@keymile.com> wrote:
> Hello Heiko,
>
> On 10/06/2010 11:53 AM, Heiko Schocher wrote:
>>>> So, the question is, is there a possibility to solve this problem?
>>>>
>>>> If there is no standard option, what would be with adding a
>>>> "scan_phy" file in
>>>>
>>>> /proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40
>>>> (or better destination?)
>>>>
>>>> which with we could rescan a PHY with
>>>> "echo addr > /proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40/scan_phy"
>>>> (so there is no need for using of_find_node_by_path(), as we should
>>>> have the associated device node here, and can step through the child
>>>> nodes with "for_each_child_of_node(np, child)" and check if reg == addr)
>>>>
>>>> or shouldn;t be at least, if the phy couldn;t be found when opening
>>>> the port, retrigger a scanning, if the phy now is accessible?
>>>
>>> One option would be to still register a phy_device for each phy
>>> described in the device tree, but defer binding a driver to each phy
>>> that doesn't respond. Then at of_phy_find_device() time, if it
>>
>> Maybe I din;t get the trick, but the problem is, that
>> you can;t register a phy_device in drivers/of/of_mdio.c
>> of_mdiobus_register(), if the phy didn;t respond with the
>> phy_id ... and of_phy_find_device() is not (yet) used in fs_enet
>>
>>> matches with a phy_device that isn't bound to a driver yet, then
>>> re-trigger the binding operation. At which point the phy id can be
>>> probed and the correct driver can be chosen. If binding succeeds,
>>> then return the phy_device handle. If not, then fail as it currently
>>> does.
>>
>> Wouldn;t it be good, just if we need a PHY (on calling fs_enet_open)
>> to look if there is one?
>>
>> Something like that (not tested):
>>
>> in drivers/net/fs_enet/fs_enet-main.c in fs_init_phy()
>> called from fs_enet_open():
>>
>> Do first:
>> phydev = of_phy_find_device(fep->fpi->phy_node);
>>
>> Look if there is a driver (phy_dev->drv == NULL ?)
>>
>> If not, call new function
>> of_mdiobus_register_phy(mii_bus, fep->fpi->phy_node)
>> see below patch for it.
>>
>> If this succeeds, all is OK, and we can use this phy,
>> else ethernet not work.
>>
>> !!just no idea, how to get mii_bus pointer ...
>>
>
> in my understanding it should be posssible to get this pointer via the parent of
> the device_node you got via the private data of the fs_enet:
> fep->fpi->phy_node->parent should point you to the device_node for the mdio_bus.
Yes, this will give you the mdio bus node pointer.
> In the next step you should be able to get the pointer of of_device for the
> mdio_bus:
> ofdevice* ofdev = to_of_device(fep->fpi->phy_node->parent);
of_device is just an alias for platform_device now, and not all mdio
busses will be instantiated by a platform device. This method won't
always work. What is really needed is the pointer to the mii_bus
structure. That can be obtained by looping over the members of the
mdio_bus_class and comparing the mii_bus->device.parent->of_node to
the parent node from above.
g.
prev parent reply other threads:[~2010-10-06 17:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-04 7:32 powerpc, fs_enet: scanning PHY after Linux is up Heiko Schocher
2010-10-04 16:20 ` Grant Likely
2010-10-06 9:53 ` Heiko Schocher
2010-10-06 16:52 ` Grant Likely
2010-10-08 8:50 ` Holger brunck
2010-10-08 17:06 ` Grant Likely
[not found] ` <20101008170615.GC3863-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
2010-10-11 11:49 ` Holger brunck
[not found] ` <4CAC7EB0.6080502@keymile.com>
2010-10-06 17:30 ` Grant Likely [this message]
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=AANLkTinWGw5AR8KSSdCyOWqCaMVL-wZH+2uB7zh404_i@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dzu@denx.de \
--cc=holger.brunck@keymile.com \
--cc=hs@denx.de \
--cc=linuxppc-dev@ozlabs.org \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).