From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [PATCH v2 2/2] input: adxl34x: Add OF match support Date: Fri, 16 Jan 2015 00:09:46 +0200 Message-ID: <1884690.xY9sKG5Ntd@avalon> References: <1421333655-31029-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com> <2883445.zFsE3pF3jL@avalon> <20150115215053.GF19367@dtor-ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: In-Reply-To: <20150115215053.GF19367@dtor-ws> Sender: linux-sh-owner@vger.kernel.org To: Dmitry Torokhov Cc: Geert Uytterhoeven , Laurent Pinchart , "linux-input@vger.kernel.org" , Linux I2C , Linux-sh list , Wolfram Sang List-Id: linux-input@vger.kernel.org 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" with = 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