> > > So i think it would be better to have > > > > > > enum { > > > MDIOBUS_UNKNOWN = 0, > > > MDIOBUS_C22, > > > MDIOBUS_C45, > > > MDIOBUS_C45_C22, > > > } bus_capabilities; > > > > > > Describe just what the bus master can support. > > > > Yes, the naming is reasonable and I will update it in the next patch. I went > > around a bit myself with this naming early on, and the problem I saw was > > that a C45 capable master, can have C45 electrical phy's that only respond > > to c22 requests (AFAIK). > > If you have a master that can only generate clause 45 cycles, and > someone is daft enough to connect a clause 22 only PHY to it, the > result is hardware that doesn't work - there's no getting around > that. The MDIO interface can't generate the appropriate cycles to > access the clause 22 PHY. So, this is not something we need care > about. > > > So the MDIOBUS_C45 (I think I was calling it > > C45_ONLY) is an invalid selection. Not, that it wouldn't be helpful to have > > a C45_ONLY case, but that the assumption is that you wouldn't try and probe > > c22 registers, which I thought was a mistake. > > MDIOBUS_C45 means "I can generate clause 45 cycles". > MDIOBUS_C22 means "I can generate clause 22 cycles". > MDIOBUS_C45_C22 means "I can generate both clause 45 and clause 22 > cycles." > > Notice carefully the values these end up with - MDIOBUS_C22 = BIT(0), > MDIOBUS_C45 = BIT(1), MDIOBUS_C45_C22 = BIT(0) | BIT(1). I suspect > that was no coincidence in Andrew's suggestion.
Hi Russell What was a nice side affect. Since i doubt Jeremy is going to go through every MDIO driver and set the capabilities correctly, i wanted 0 to have a safe meaning. In the code we should treat MDIOBUS_UNKNOWN and MDIOBUS_C22 identically. But maybe some time in the distant future, we can make 0 issue a warning. Andrew