public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Olof Johansson <olof@lixom.net>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benson Leung <bleung@chromium.org>,
	Nick Dyer <nick.dyer@itdev.co.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] platform/chrome: chromeos_laptop - do not probe devices on Pixel 1
Date: Fri, 24 Apr 2015 22:09:02 -0700	[thread overview]
Message-ID: <20150425050902.GA14701@quad.lixom.net> (raw)
In-Reply-To: <20150414205009.GA35263@dtor-ws>

On Tue, Apr 14, 2015 at 01:50:09PM -0700, Dmitry Torokhov wrote:
> On Fri, Apr 10, 2015 at 10:41:54AM -0700, Dmitry Torokhov wrote:
> > On Thu, Apr 09, 2015 at 04:57:59PM -0700, Dmitry Torokhov wrote:
> > > Atmel MXT devices use different i2c addresses, depending on the current
> > > mode of operation (bootloader or application). The new Atmel MXT driver
> > > expects i2c client's address contain the application address of the
> > > chip, and calculates the expected bootloader address form the
> > > application address. Unfortunately chromeos_laptop does probe the
> > > devices and if touchpad (or touchscreen, or both) comes up in bootloader
> > > mode, the i2c device gets instantiated with the bootloader address
> > > instead of application address, which confuses the driver.
> > > 
> > > Given that hardware on Pixel is set and is not going to change let's not
> > > try to probe devices to see if they are present or not, but rather
> > > instantiate them always at expected addresses.
> > > 
> > > Since all devices are now probed and/or instantiated at given address,
> > > we no longer need to support probing multiple addresses for the same
> > 
> > Hmm, that strategy won't work on C720 since there are devices with touchscreen
> > and without one, so we do want to probe but always instantiate at primary
> > address. V3 will be upcoming...
> 
> OK, new version. Not sending to the wide world for now in case we decide
> it is too ugly...

I'm not a huge fan of this, but as mentioned in person, the whole situation is
somewhat awkward and we don't really have any better ideas.

I've applied this now, and will include it in the 4.1 branch since it's needed
for stable operation on pixel 1 going forward.


-Olof

      parent reply	other threads:[~2015-04-25  5:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-09 23:57 [PATCH v2] platform/chrome: chromeos_laptop - do not probe devices on Pixel 1 Dmitry Torokhov
2015-04-10 17:41 ` Dmitry Torokhov
2015-04-14 20:50   ` Dmitry Torokhov
2015-04-14 20:50     ` Dmitry Torokhov
2015-04-25  5:09     ` Olof Johansson [this message]

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=20150425050902.GA14701@quad.lixom.net \
    --to=olof@lixom.net \
    --cc=bleung@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nick.dyer@itdev.co.uk \
    /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