On Mon, 17 Dec 2007 12:48:17 -0600 Scott Wood wrote: > Vitaly Bordug wrote: > > On Mon, 17 Dec 2007 11:03:04 -0600 Scott Wood wrote: > >>> These phy nodes have basically no information in them. PHY nodes > >>> are optional - > >> If they are truly optional, then several Linux drivers (including > >> ucc_geth, which this board uses) are broken, as they'll error out > >> if there's no phy-handle (gianfar is even worse -- it looks like > >> the fsl_soc code will crash in that case). But what do you propose > >> they do in the absence of a phy-handle? Hope that probing only > >> finds one phy? > > > > up-to-date fixed phy patch solves it in gianfar and fs_enet case. it > > is implied, that either there *are* phy nodes (and the code will > > look up their reg and phandle) or there should be fixed-link > > property in NIC node, that describes to what link stuff is really > > connected. > > There's a difference between the phy *node* being optional and phy > *usage* being optional. :-) > And I am telling exactly that :) [added David to the loop since it was his issue].
currently phy nodes are required by the drivers (referring phy-handle), and I'd tell it looks pretty settled. We got rid of "pretend" phy nodes, but I don't think it makes sense to change the things for this particular board, especially since there is no example, how to do that in correct way. Addition of compatible prop may be useful though, at least one may just look into dts to memorize what type of phys board has.. -- Sincerely, Vitaly _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
