Hi Dmitry, On Thursday 15 January 2015 13:50:53 Dmitry Torokhov wrote: > On Thu, Jan 15, 2015 at 11:34:00PM +0200, Laurent Pinchart wrote: > > On Thursday 15 January 2015 13:06:32 Dmitry Torokhov wrote: > >> On Thu, Jan 15, 2015 at 10:34:29PM +0200, Laurent Pinchart wrote: > >>> On Thursday 15 January 2015 21:00:37 Geert Uytterhoeven wrote: > >>>> On Thu, Jan 15, 2015 at 7:54 PM, Dmitry Torokhov wrote: > >>>>> I still do not understand what we are trying to fix here. Why is > >>>>> "adi,adxl34x" compatible string no good anymore? If we start using > >>>>> exact models and the physical device does not match do we abort > >>>>> probe? What is the problem that we are solving here? > >>>> > >>>> Because there's no guarantee that the driver actually supports all > >>>> "adi,adxl34<x>" with <x> = 0..9, some of which don't exist yet. > >> > >> So, what? When we encounter such devices and decide that we actually > >> want a different driver for them (instead of enhancing the existing one) > >> we'll give them their own compatible string. It's not like "adi,adxl348" > >> will automatically match with "adi,adxl34x", is it? > > > > Please remember that compatible strings shouldn't be decided based on a > > particular operating system implementation. > > In this case we can never have generic compatible strings of whatever > since in 10 years there might appear an OS that handles them > differently. Let's be a bit realistic here as well. I don't agree with you. The generic compatible strings should express compatibility with a hardware interface to the system, not compatibility with particular drivers on particular operating systems. We can thus have generic compatible strings without taking the OS into account. > >>> That's one of the reasons. Another one is that the adxl34x driver > >>> won't match DT nodes that list the "adi,adxl34x" compatible value in > >>> positions other than the first. > >> > >> Will it match anything else in the position other than 1st (i.e. > >> if device has compatible sting like "adi,adxl345-1", "adi,adxl345")? > > > Why "adi,adxl34x" is special? > > > > The problem on the driver side is that the automatic I2C DT compatible to > > device name matching implementation only tries to match with the first > > compatible string without looking at the other ones. The driver thus needs > > to be enhanced with an explicit OF match table to be able to match on DT > > nodes that specify "adi,adxl345" or "adi,adxl346" as the first compatible > > entry. > > Why don't we enhance I2C core instead to do proper matching? That would also be possible, but I believe that patch 1/2 is still the right thing to do, in which case patch 2/2 is required anyway. -- Regards, Laurent Pinchart -- 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
