According to the 8548 and 8572 manuals (not sure about others...), the TBIPA register value for all PHYs is 0x0 at reset, which is reserved according to the manuals. The description of the MIIMADD register supports this by stating: "Up to 31 PHYs can be addressed (0 is reserved)". So I believe that if the TBIPA value is 0, the corresponding TBI PHY can't be accessed and thus doesn't cause any problems as far as overlapping with other PHY addresses. The fact that the TBI phy never shows up when probing the MII bus on a variety of 8548 boards (which don't use any TBI PHYs) I've used supports this.
Oh, there is much confusion, here.
1) 0 is reserved, according to the spec. However, *most* Freescale development systems use address zero for the PHY connected to TSEC0. 2) The manual only recently added this information, perhaps to encourage our own board designers to pay attention to it. :) 3) If the TBI PHY doesn't show up on a scan, it is because we have done something to make them ignored. I used to see the TBI PHY all the time, and I think we changed things so it didn't show up anymore (to avoid confusion). 4) The current default value for CFG_TBIPA_VALUE is 0x1f, not 0. So keep that in mind.
Anyway, I think we should leave in that write for now. In the future, we will change the code to sensibly move the TBIPA out of the way, like Linux does.
I was under the impression that PHY address 0 was reserved for broadcast usage, or something similar. I don't have the PHY spec handy to verify that however.
Yeah, I'm not sure what it's reserved for, but many board designers ignore that, and put the first PHY at 0.
If you feel more comfortable leaving the write to priv->phyregs->tbipa in place, its OK with me. I don't think its necessary (at least for the 8548 and 8572 processors) but the only damage it does is some extra MII writes and adding a non-existent TBI PHY which a user might find a bit confusing.
No extra MII writes should be done. Just a few memory-mapped io register writes.
One other note: currently we don't support accessing the TBI PHYs through the mii utilities. This is mostly due to difficulties in finding addresses for the TBI PHYs that don't conflict with existing PHY addresses. If you have some clever ideas that don't involve hard-coding the addresses (I have to anticipate the advent of chips with 10+ ethernet controllers), I'm open to hearing them. :) It's an issue I intend to address, but it's not getting any timeslices this quarter.
FWIW, I was able to see the TBI PHY on an 8572 board using U-Boot's mii command. I only had one TBI PHY configured, but I could read its registers at address 0x1f as desired. I was surprised this worked and didn't dig into why it did however... I'm not sure how the mii command would work with multiple TBI PHYs at 0x1f on different busses however, but if it doesn't work that seems like an issue with the mii subsystem more than the tsec driver in my opinion. We have a board in the pipeline with multiple TBI PHYs - perhaps I can dig into it then.
Sorry, I should have been clearer -- we support accessing the TBI PHY connected to TSEC0. The others require knowing that you have to use different registers. One solution might be to create 4 MDIO buses, but that seems excessive. We might want to just create a tsec-specific command to deal with it. Anyway, thank you for bearing with me.
Thanks for the feedback. I'd vote for keeping the patch the same as it is now, but if you'd like me to resubmit with the "phyregs->tbipa = CFG_TBIPA_VALUE" put back in let me know and I'll send it again.
Please do.
Thanks, Andy