lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 24 Apr 2015 22:09:02 -0700
From:	Olof Johansson <olof@...om.net>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Benson Leung <bleung@...omium.org>,
	Nick Dyer <nick.dyer@...ev.co.uk>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] platform/chrome: chromeos_laptop - do not probe
 devices on Pixel 1

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists