lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <AANLkTinWGw5AR8KSSdCyOWqCaMVL-wZH+2uB7zh404_i@mail.gmail.com> Date: Wed, 6 Oct 2010 11:30:19 -0600 From: Grant Likely <grant.likely@...retlab.ca> To: Holger brunck <holger.brunck@...mile.com> Cc: hs@...x.de, linuxppc-dev@...abs.org, netdev@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org, Detlev Zundel <dzu@...x.de> Subject: Re: powerpc, fs_enet: scanning PHY after Linux is up On Wed, Oct 6, 2010 at 7:50 AM, Holger brunck <holger.brunck@...mile.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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists