linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Holger brunck <holger.brunck@keymile.com>
Cc: linuxppc-dev@ozlabs.org, devicetree-discuss@lists.ozlabs.org,
	hs@denx.de, Detlev Zundel <dzu@denx.de>,
	netdev@vger.kernel.org
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> w=
rote:
> 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/sc=
an_phy"
>>>> (so there is no need for using of_find_node_by_path(), as we should
>>>> =A0have the associated device node here, and can step through the chil=
d
>>>> =A0nodes with "for_each_child_of_node(np, child)" and check if reg =3D=
=3D 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. =A0Then 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. =A0At which point the phy id can be
>>> probed and the correct driver can be chosen. =A0If binding succeeds,
>>> then return the phy_device handle. =A0If 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 =3D =A0of_phy_find_device(fep->fpi->phy_node);
>>
>> Look if there is a driver (phy_dev->drv =3D=3D 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 pa=
rent 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 md=
io_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 t=
he
> mdio_bus:
> ofdevice* ofdev =3D 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.

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