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: <103b5438-9f7c-7e89-28b9-29fe11eb818c@redhat.com>
Date:   Mon, 18 Oct 2021 10:30:04 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     Tsuchiya Yuto <kitakar@...il.com>
Cc:     Patrik Gfeller <patrik.gfeller@...il.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Kaixu Xia <kaixuxia@...cent.com>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Arnd Bergmann <arnd@...db.de>, linux-media@...r.kernel.org,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [BUG 5/5] [BUG] media: atomisp: atomisp causes touchscreen to
 stop working on Microsoft Surface 3

Hi,

On 10/17/21 18:23, Tsuchiya Yuto wrote:
> Touchscreen input works fine before loading atomisp driver on Surface 3.
> 
> However, after loading atomisp driver, touchscreen works only when
> capturing images. This sounds like atomisp turns off something needed
> for touchscreen when atomisp is idle.
> 
> There is no useful kernel log. Just the touchscreen stops working
> with no log.
> 
> I'll update if I find something further. First of all, can someone
> reproduce this issue on the other devices?

My first bet would be some regulator getting turned off.

What you can do is:

1. ls -l /dev/bus/i2c/devices

And then write down the number of the i2c-bus to which the
CRC PMIC is connected, lets say it is number "4". Then:

2. Before loading the atomisp drivers run:
   "sudo i2cdump -y -f 4 0x6e > crc-regs-good"

3. After loading the atomisp drivers run:
   "sudo i2cdump -y -f 4 0x6e > crc-regs-bad

4. "diff -u crc-regs-good crc-regs-bad"

And see what changed.

There are 2 possible root causes here:

1. Some regulator is shared between the cameras and
touchscreen

2. The crc code in atomisp which you are using is
poking registers assuming the Bay Trail version of
the Crystal Cove PMIC (aka CRC PMIC) but your
Surface 3 has the Cherry Trail version and we know
that the regulators are add different register
addresses there, see the comment in:
drivers/acpi/pmic/intel_pmic_chtcrc.c
so it is possible that the atomisp code is simply
poking the wrong register for one of the regulators

I also wonder if this goes away if you do the

	hrv = 0x03;

Hack inside drivers/mfd/intel_soc_pmic_core.c ?

Without that we end up using the wrong PMIC
OpRegion driver which also uses the wrong
regulator addresses.

Regards,

Hans


p.s.

Here are the 2 different regulator drivers the
comment in drivers/acpi/pmic/intel_pmic_chtcrc.c
refers to:

https://github.com/Zenfone2-Dev/android_kernel_asus_moorefield-1/blob/stock/drivers/regulator/pmic_crystal_cove.c
https://github.com/Zenfone2-Dev/android_kernel_asus_moorefield-1/blob/stock/drivers/regulator/pmic_crystal_cove_plus.c

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ