All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	linux-input@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-i2c@vger.kernel.org, Geert Uytterhoeven <geert@glider.be>
Subject: Re: [PATCH] input: adxl34x: Add OF match support
Date: Thu, 18 Dec 2014 14:49:28 +0200	[thread overview]
Message-ID: <1492007.8cQN1myWLD@avalon> (raw)
In-Reply-To: <20141218082151.GA1038@katana>

Hi Wolfram,

On Thursday 18 December 2014 09:21:51 Wolfram Sang wrote:
> On Thu, Dec 18, 2014 at 04:15:23AM +0200, Laurent Pinchart wrote:
> > The I2C subsystem can match devices without explicit OF support based on
> > the part of their compatible property after the comma. However, this
> > mechanism uses the first compatible value only. For adxl34x OF device
> > nodes the compatible property should list the more specific
> > "adi,adxl345" or "adi,adxl346" value first and the "adi,adxl34x"
> > fallback value second. This prevents the device node from being matched
> > with the adxl34x driver.
> > 
> > Fix this by adding an OF match table with an "adi,adxl34x" compatible
> > entry.
> > 
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> > 
> >  drivers/input/misc/adxl34x-i2c.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > Another option would have been to add "adxl325" and "adxl326" entries to
> > the adxl34x_id I2C match table, but it would have had the drawback of
> > requiring a driver update for every new device.
> 
> AFAIK this is even required for compatible entries, to be as specific as
> possible. I think this makes sense. With platform_ids, we already had
> the problem that pca954x was too generic and was used for both GPIO
> extenders and I2C muxers (IIRC).

There are three compatible strings defined for the ADXL345 and ADXL346 in 
Documentation/devicetree/bindings/i2c/trivial-devices.txt: "adi,adxl345", 
"adi,adxl346", "adi,adxl34x". Given that the last one is a fallback for the 
first two I don't see a need to add the specific compatible strings to the 
driver for now. If a new totally incompatible chip named ADXL347 comes out we 
will need a new driver which won't be allowed to use the "adi,adxl34x" 
compatible string.

An option would be to remove "adi,adxl34x" from 
Documentation/devicetree/bindings/i2c/trivial-devices.txt, in which case the 
driver should match explicitly on "adi,adxl345" and "adi,adxl346". That might 
clash with the DT ABI stability requirements though.

-- 
Regards,

Laurent Pinchart


WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	linux-input@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-i2c@vger.kernel.org, Geert Uytterhoeven <geert@glider.be>
Subject: Re: [PATCH] input: adxl34x: Add OF match support
Date: Thu, 18 Dec 2014 12:49:28 +0000	[thread overview]
Message-ID: <1492007.8cQN1myWLD@avalon> (raw)
In-Reply-To: <20141218082151.GA1038@katana>

Hi Wolfram,

On Thursday 18 December 2014 09:21:51 Wolfram Sang wrote:
> On Thu, Dec 18, 2014 at 04:15:23AM +0200, Laurent Pinchart wrote:
> > The I2C subsystem can match devices without explicit OF support based on
> > the part of their compatible property after the comma. However, this
> > mechanism uses the first compatible value only. For adxl34x OF device
> > nodes the compatible property should list the more specific
> > "adi,adxl345" or "adi,adxl346" value first and the "adi,adxl34x"
> > fallback value second. This prevents the device node from being matched
> > with the adxl34x driver.
> > 
> > Fix this by adding an OF match table with an "adi,adxl34x" compatible
> > entry.
> > 
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> > 
> >  drivers/input/misc/adxl34x-i2c.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > Another option would have been to add "adxl325" and "adxl326" entries to
> > the adxl34x_id I2C match table, but it would have had the drawback of
> > requiring a driver update for every new device.
> 
> AFAIK this is even required for compatible entries, to be as specific as
> possible. I think this makes sense. With platform_ids, we already had
> the problem that pca954x was too generic and was used for both GPIO
> extenders and I2C muxers (IIRC).

There are three compatible strings defined for the ADXL345 and ADXL346 in 
Documentation/devicetree/bindings/i2c/trivial-devices.txt: "adi,adxl345", 
"adi,adxl346", "adi,adxl34x". Given that the last one is a fallback for the 
first two I don't see a need to add the specific compatible strings to the 
driver for now. If a new totally incompatible chip named ADXL347 comes out we 
will need a new driver which won't be allowed to use the "adi,adxl34x" 
compatible string.

An option would be to remove "adi,adxl34x" from 
Documentation/devicetree/bindings/i2c/trivial-devices.txt, in which case the 
driver should match explicitly on "adi,adxl345" and "adi,adxl346". That might 
clash with the DT ABI stability requirements though.

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2014-12-18 12:49 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-18  2:15 [PATCH] input: adxl34x: Add OF match support Laurent Pinchart
2014-12-18  2:15 ` Laurent Pinchart
2014-12-18  8:21 ` Wolfram Sang
2014-12-18  8:21   ` Wolfram Sang
2014-12-18 12:49   ` Laurent Pinchart [this message]
2014-12-18 12:49     ` Laurent Pinchart
2014-12-18 13:03     ` Geert Uytterhoeven
2014-12-18 13:03       ` Geert Uytterhoeven
     [not found]       ` <CAMuHMdXcfe0JQhZzGSAoqjKR346-QJrvyi=afHF7cAaHKa56pw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-12-18 19:23         ` Laurent Pinchart
2014-12-18 19:23           ` Laurent Pinchart
2015-01-05  8:27           ` Laurent Pinchart
2015-01-05  8:27             ` Laurent Pinchart
2015-01-06 13:28           ` Geert Uytterhoeven
2015-01-06 13:28             ` Geert Uytterhoeven
2015-01-15 12:53     ` Wolfram Sang
2015-01-15 12:53       ` Wolfram Sang
2015-01-15 13:03       ` Geert Uytterhoeven
2015-01-15 13:03         ` Geert Uytterhoeven
2015-01-15 14:19       ` Laurent Pinchart
2015-01-15 14:19         ` Laurent Pinchart
2015-01-15 14:23         ` Laurent Pinchart
2015-01-15 14:23           ` Laurent Pinchart
2015-01-15 14:36           ` Wolfram Sang
2015-01-15 14:36             ` Wolfram Sang
2015-01-15 14:38             ` Laurent Pinchart
2015-01-15 14:38               ` Laurent Pinchart
2015-01-15 14:23         ` Geert Uytterhoeven
2015-01-15 14:23           ` Geert Uytterhoeven

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=1492007.8cQN1myWLD@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=geert@glider.be \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.