On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote: > > You don't "know" the id of the device you are looking up, due to > > multiple devices being in the system (dynamic ids, look back earlier in > > this thread for details about that.) > > I got copied in very late so don't have most of the thread I'm afraid, > I did try looking at web archives but didn't see a clear problem > statement. In any case this is why the APIs doing lookups do the > lookups in the context of the requesting device - devices ask for > whatever name they use locally. What do you mean by "locally"? The problem with the api was that the phy core wanted a id and a name to create a phy, and then later other code was doing a "lookup" based on the name and id (mushed together), because it "knew" that this device was the one it wanted. Just like the clock api, which, for multiple devices, has proven to cause problems. I don't want to see us accept an api that we know has issues in it now, I'd rather us fix it up properly. Subsystems should be able to create ids how ever they want to, and not rely on the code calling them to specify the names of the devices that way, otherwise the api is just too fragile. I think, that if you create a device, then just carry around the pointer to that device (in this case a phy) and pass it to whatever other code needs it. No need to do lookups on "known names" or anything else, just normal pointers, with no problems for multiple devices, busses, or naming issues. > > > Having to write platform data for everything gets old fast and the code > > > duplication is pretty tedious... > > > Adding a single pointer is "tedious"? Where is the "name" that you are > > going to lookup going to come from? That code doesn't write itself... > > It's adding platform data in the first place that gets tedious - and of > course there's also DT and ACPI to worry about, it's not just a case of > platform data and then you're done. Pushing the lookup into library > code means that drivers don't have to worry about any of this stuff. I agree, so just pass around the pointer to the phy and all is good. No need to worry about DT or ACPI or anything else. > For most of the APIs doing this there is a clear and unambiguous name in > the hardware that can be used (and for hardware process reasons is > unlikely to get changed). The major exception to this is the clock API > since it is relatively rare to have clear, segregated IP level > information for IPs baked into larger chips. The other APIs tend to be > establishing chip to chip links. The clock api is having problems with multiple "names" due to dynamic devices from what I was told. I want to prevent the PHY interface from having that same issue. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
