Hi Wolfram, On 13/06/16 18:13, Wolfram Sang wrote: > >> As we match on only the device, not the manufacturer, I've changed your sketch >> so that the test maxim line is on a compatible with name ds9999 to make it >> unique. Otherwise, we would match to the dallas,ds1307 id type. > > OK, so I assumed correctly that userspace instantiation wouldn't have > worked fully. > >> If you would prefer that we support separate manufacturers, I can update the >> match function so that it attempts a full match first, followed by a stripped >> manufacturer match. I'm not certain if we have a need for that at the moment >> though, as the current drivers simply match on the device name: > > I think we *need* that. We can't instantiate my previous example via > userspace otherwise. Also, stripping vendor names is what we want to get > rid of with this series, no? Awww <multiple expletives removed> I just re-read this - Has this series been blocked on me without me realising? /me cowers in a corner in shame... I think the aim of this series was to simplify the code structures. Making the vendor names usable, makes sense IMO, but I don't think that was a goal of the original series. I think the series was trying to make an improvement *without* changing functionality / usage. Re-introducing vendor names into the i2c matching would be a change in scope from my view, but if it's required to get this series moving let me know. >> This patch also demonstrates a method to obtain the device ID from the new >> match system for drivers which would normally have expected this information to >> be passed in. > > Thanks for the testing! > > Wolfram > -- Regards Kieran Bingham -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
