linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
	Linux I2C <linux-i2c@vger.kernel.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Wolfram Sang <wsa@the-dreams.de>
Subject: Re: [PATCH v2 2/2] input: adxl34x: Add OF match support
Date: Fri, 16 Jan 2015 00:09:46 +0200	[thread overview]
Message-ID: <1884690.xY9sKG5Ntd@avalon> (raw)
In-Reply-To: <20150115215053.GF19367@dtor-ws>

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


  reply	other threads:[~2015-01-15 22:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-15 14:54 [PATCH v2 0/2] Fix OF match for adxl34x driver Laurent Pinchart
2015-01-15 14:54 ` [PATCH v2 1/2] DT: i2c: Deprecate adi,adxl34x compatible string Laurent Pinchart
2015-01-15 17:49   ` Geert Uytterhoeven
     [not found]   ` <1421333655-31029-2-git-send-email-laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
2015-01-15 17:02     ` Wolfram Sang
2015-01-15 17:27       ` Dmitry Torokhov
2015-01-15 17:32       ` Geert Uytterhoeven
     [not found]         ` <CAMuHMdW7ETcFGSPiE9BWA2dAE93477fzoyF-+_EaiPSDT9WMWA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-15 17:43           ` Wolfram Sang
2015-01-15 17:51             ` Geert Uytterhoeven
2015-01-26 12:09               ` Wolfram Sang
2015-02-26 14:27                 ` Laurent Pinchart
2015-03-02  6:40                   ` Wolfram Sang
2015-03-02 22:52                     ` Laurent Pinchart
2015-01-15 20:51             ` Laurent Pinchart
2015-01-26 12:12     ` Wolfram Sang
2015-01-15 14:54 ` [PATCH v2 2/2] input: adxl34x: Add OF match support Laurent Pinchart
2015-01-15 16:55   ` Wolfram Sang
     [not found]   ` <1421333655-31029-3-git-send-email-laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
2015-01-15 17:45     ` Geert Uytterhoeven
     [not found]       ` <CAMuHMdWmGi6qKKt5YJm1i7FqDceqKosxsSRJRd8zqXO9jMzyoQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-15 18:54         ` Dmitry Torokhov
2015-01-15 20:00           ` Geert Uytterhoeven
     [not found]             ` <CAMuHMdXrRtgAahaEUh8x61E-koE25VL-6LOJrkjx4_fohKQtwQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-15 20:34               ` Laurent Pinchart
2015-01-15 21:06                 ` Dmitry Torokhov
2015-01-15 21:34                   ` Laurent Pinchart
2015-01-15 21:50                     ` Dmitry Torokhov
2015-01-15 22:09                       ` Laurent Pinchart [this message]
2015-01-15 22:05                 ` Sergei Shtylyov
  -- strict thread matches above, loose matches on Subject: below --
2015-05-21 11:42 [PATCH v2 0/2] Fix OF match for adxl34x driver Geert Uytterhoeven
     [not found] ` <1432208546-18615-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
2015-05-21 11:42   ` [PATCH v2 2/2] input: adxl34x: Add OF match support Geert Uytterhoeven
     [not found]     ` <1432208546-18615-3-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
2015-05-22  1:32       ` Simon Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1884690.xY9sKG5Ntd@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=wsa@the-dreams.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).