From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.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: Thu, 15 Jan 2015 13:50:53 -0800 [thread overview]
Message-ID: <20150115215053.GF19367@dtor-ws> (raw)
In-Reply-To: <2883445.zFsE3pF3jL@avalon>
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.
>
> > > 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?
--
Dmitry
next prev parent reply other threads:[~2015-01-15 21:50 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 [this message]
2015-01-15 22:09 ` Laurent Pinchart
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=20150115215053.GF19367@dtor-ws \
--to=dmitry.torokhov@gmail.com \
--cc=geert@linux-m68k.org \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=laurent.pinchart@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).