From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> To: Wolfram Sang <wsa@the-dreams.de> Cc: 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, 15 Jan 2015 14:23:04 +0000 [thread overview] Message-ID: <2445803.jDZCe1u2Wf@avalon> (raw) In-Reply-To: <2054159.e1XeKNyynp@avalon> On Thursday 15 January 2015 16:19:19 Laurent Pinchart wrote: > On Thursday 15 January 2015 13:53:22 Wolfram Sang wrote: > > On Thu, Dec 18, 2014 at 02:49:28PM +0200, Laurent Pinchart wrote: > >> 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. > > > > Been there, got bitten. We only found out too late, because one driver > > was in i2c and the other in GPIO (or LED even?), both using "953x" :( > > That seems like a development, review and/or merge process failure to me, I > wouldn't avoid generic compatible strings for that reason only. > > > > 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. > > > > I do prefer this: > > > > 1) add specific compatible values to the driver. We do those updates for > > new devices all the time > > Do you mean OF compatible values, or I2C match table entries ? I assume OF > compatible values. > > As the ADXL346 is backward-compatible with the ADXL345, and as the driver > doesn't support the ADXL346-specific features, how about adding only the > adxl345 for now, and using compatible = "adi,adxl346", "adi,adxl345"; for > the ADXL346 ? I spoke too fast. The driver supports ADXL346-specific features, but does so by detecting the device model at runtime. I still believe it would make sense to list both the 346 and 345 models in DT for 346 devices, as they're compatible with the 345. > > 2) also add "34x" as a compatible but mark it as deprecateed > > 3) delete "34x" from trivial devices > > OK. > > > Everyone OK with that? -- 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: 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, 15 Jan 2015 16:23:04 +0200 [thread overview] Message-ID: <2445803.jDZCe1u2Wf@avalon> (raw) In-Reply-To: <2054159.e1XeKNyynp@avalon> On Thursday 15 January 2015 16:19:19 Laurent Pinchart wrote: > On Thursday 15 January 2015 13:53:22 Wolfram Sang wrote: > > On Thu, Dec 18, 2014 at 02:49:28PM +0200, Laurent Pinchart wrote: > >> 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. > > > > Been there, got bitten. We only found out too late, because one driver > > was in i2c and the other in GPIO (or LED even?), both using "953x" :( > > That seems like a development, review and/or merge process failure to me, I > wouldn't avoid generic compatible strings for that reason only. > > > > 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. > > > > I do prefer this: > > > > 1) add specific compatible values to the driver. We do those updates for > > new devices all the time > > Do you mean OF compatible values, or I2C match table entries ? I assume OF > compatible values. > > As the ADXL346 is backward-compatible with the ADXL345, and as the driver > doesn't support the ADXL346-specific features, how about adding only the > adxl345 for now, and using compatible = "adi,adxl346", "adi,adxl345"; for > the ADXL346 ? I spoke too fast. The driver supports ADXL346-specific features, but does so by detecting the device model at runtime. I still believe it would make sense to list both the 346 and 345 models in DT for 346 devices, as they're compatible with the 345. > > 2) also add "34x" as a compatible but mark it as deprecateed > > 3) delete "34x" from trivial devices > > OK. > > > Everyone OK with that? -- Regards, Laurent Pinchart
next prev parent reply other threads:[~2015-01-15 14:23 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 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 [this message] 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=2445803.jDZCe1u2Wf@avalon \ --to=laurent.pinchart@ideasonboard.com \ --cc=geert@glider.be \ --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: linkBe 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.