All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bastien Nocera <hadess@hadess.net>
To: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Jonathan Cameron <jic23@kernel.org>
Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	Octavian Purdila <octavian.purdila@intel.com>
Subject: Re: [PATCH 2/2] iio:accel:bmc150-accel: Use the chip ID to detect sensor variant
Date: Tue, 04 Aug 2015 11:58:13 +0200	[thread overview]
Message-ID: <1438682293.22369.10.camel@hadess.net> (raw)
In-Reply-To: <1438632544.17718.46.camel@spandruv-DESK3.jf.intel.com>

On Mon, 2015-08-03 at 13:09 -0700, Srinivas Pandruvada wrote:
> On Sun, 2015-08-02 at 18:18 +0100, Jonathan Cameron wrote:
> > On 23/07/15 16:21, Bastien Nocera wrote:
> > > Instead of using the I2C or ACPI ID to determine which variant of
> > > the chipset to use, determine that from the chip ID.
> > > 
> > > Under Windows, the same driver is used for those variants and, 
> > > despite
> > > incorrect ACPI data, it is able to load and operate the 
> > > accelerometer.
> > > 
> > > Fixes the accelerometer failing with:
> > > bmc150_accel i2c-BMA250E:00: Invalid chip f8
> > > on the WinBook TW100
> > > 
> > > Signed-off-by: Bastien Nocera <hadess@hadess.net>
> > I'll start by saying I hate that this change is necessary down
> > at the driver level.
> > 
> > Is there no way to catch it as an ACPI quirk? (I know next to 
> > nothing about
> > ACPI and a quick a google isn't pointing me in the right 
> > direction!)
> > Seems irritating that we have to deal with this but such is life I 
> > guess
> > (anyone want to take the bet that at some point the windows driver 
> > will break
> >  horribly as well for these machines?)
> > 
> > Anyhow, Srinivas, could you also take a look at this one.
> > 
> > I suppose I'll cope with the horribleness :)
> We have seen where manufactures replaces a part for some reason, 
> without
> modifying ACPI tables. So matching chip id makes sense logically. But
> even this is not fail proof. Some parts have same chip id with 
> different
> features (clones), in that case ACPI match makes more sense.
> There is a way to patch ACPI tables but that also need to be based on
> some DMI information.
> I am not aware of such issue with Bosch parts. So I think this would 
> be
> OK to use chip id here instead of acpi id here. But what about using
> this only when the current logic fails? In this way we can still have
> another entry in the table for clones, if required.

For clones which don't advertise the right chip ID, I'd just have a
separate quirk table, "use this chip ID for that hardware".

Seems simpler, and I'm happy to write that code when we encounter the
problem.

  reply	other threads:[~2015-08-04  9:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-23 15:21 [PATCH 2/2] iio:accel:bmc150-accel: Use the chip ID to detect sensor variant Bastien Nocera
2015-08-02 17:18 ` Jonathan Cameron
2015-08-03 13:34   ` Bastien Nocera
2015-08-03 20:09   ` Srinivas Pandruvada
2015-08-04  9:58     ` Bastien Nocera [this message]
2015-08-08 15:36       ` Jonathan Cameron

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=1438682293.22369.10.camel@hadess.net \
    --to=hadess@hadess.net \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=octavian.purdila@intel.com \
    --cc=srinivas.pandruvada@linux.intel.com \
    /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.