Re: [PATCH v2 2/2] input: adxl34x: Add OF match support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux