linux-kernel - Re: [PATCH 01/14] Input: atmel_mxt_ts - do not pass suspend mode in platform data

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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180317204222.th54qyuajgam7iek@hairyalien>
Date:   Sat, 17 Mar 2018 20:42:22 +0000
From:   Nick Dyer <nick@...anahar.org>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     linux-input@...r.kernel.org, Benson Leung <bleung@...omium.org>,
        Olof Johansson <olof@...om.net>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/14] Input: atmel_mxt_ts - do not pass suspend mode in
 platform data

On Sat, Mar 17, 2018 at 10:42:40AM -0700, Dmitry Torokhov wrote:
> On Fri, Mar 16, 2018 at 08:40:02PM +0000, Nick Dyer wrote:
> > On Thu, Mar 15, 2018 at 04:56:21PM -0700, Dmitry Torokhov wrote:
> > > Ah, OK, I see. I would really like to drop this
> > > pdata->suspend_mode stuff and I do not want to create
> > > "pixel-screwed-up" property either...  I guess for the time being
> > > I'll put a DMI quirk for Link to restore T9 control method, and
> > > then look into cleaning it all up. We have quite a bit different
> > > code in chromeos kernel trees and I'd like to reconcile
> > > it.
> > 
> > Yes, it would be great to get rid of it. The driver does have the
> > ability to download configuration via the firmware loader interface.
> > So you would be able to grab a copy of the config by saving it with
> > mxt-app, tweak it to ensure that the T9 CTRL byte is set correctly,
> > then ship it somehow (presumably it could be added to
> > linux-firmware). This would override what's currently stored in
> > NVRAM on all those units and mean we could remove the T9_CTRL stuff.
> 
> We can't really rely on people fetching updated config. Do you think we
> could see if the device has only T9 and not T100 and if coming out of
> suspend the T9 CTRL byte is 0 we overwrite it with the 0x83?

I think that all we need to do is add something to
mxt_read_t9_resolution (and probably rename it to mxt_init_t9_config)
that reads the 1st (CTRL) byte, and if it's zero, writes 0x83 (and
probably a dev_dbg() wouldn't go amiss)

Also call the same logic on reset (look for "Detect reset"), because
that wipes out the config.

Once we've done that, we can get rid of the MXT_SUSPEND_T9_CTRL and use
the normal T7 power up/down logic for suspend/resume on all devices.

FWIW there may be two instances of T9, but I've never seen a device that
actually had two screens and it's not supported really anyway with this
driver.

N