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: <3141a819-5964-4082-6f05-1926e16468b4@linux.intel.com>
Date:   Tue, 3 Sep 2019 15:03:49 +0300
From:   Jarkko Nikula <jarkko.nikula@...ux.intel.com>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Chris Chiu <chiu@...lessm.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        lee.jones@...aro.org, Linux Kernel <linux-kernel@...r.kernel.org>,
        Linux Upstreaming Team <linux@...lessm.com>
Subject: Re: Tweak I2C SDA hold time on GemniLake to make touchpad work

Hi Chris

On 9/3/19 11:18 AM, Mika Westerberg wrote:
> +Jarkko
> 
> On Tue, Sep 03, 2019 at 04:10:27PM +0800, Chris Chiu wrote:
>> Hi,
>>
>> We're working on the acer Gemnilake laptop TravelMate B118-M for
>> touchpad not working issue. The touchpad fails to bring up and the
>> i2c-hid ouput the message as follows
>>      [    8.317293] i2c_hid i2c-ELAN0502:00: hid_descr_cmd failed
>> We tried on latest linux kernel 5.3.0-rc6 and it reports the same.
>>
>> We then look into I2C signal level measurement to find out why.
>> The following is the signal output from LA for the SCL/SDA.
>> https://imgur.com/sKcpvdo
>> The SCL frequency is ~400kHz from the SCL period, but the SDA
>> transition is quite weird. Per the I2C spec, the data on the SDA line
>> must be stable during the high period of the clock. The HIGH or LOW
>> state of the data line can only change when the clock signal on the
>> SCL line is LOW. The SDA period span across 2 SCL high, I think
>> that's the reason why the I2C read the wrong data and fail to initialize.
>>
>> Thus, we treak the SDA hold time by the following modification.
>>
>> --- a/drivers/mfd/intel-lpss-pci.c
>> +++ b/drivers/mfd/intel-lpss-pci.c
>> @@ -97,7 +97,8 @@ static const struct intel_lpss_platform_info bxt_uart_info = {
>>   };
>>
>>   static struct property_entry bxt_i2c_properties[] = {
>> -       PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 42),
>> +       PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 230),
>>          PROPERTY_ENTRY_U32("i2c-sda-falling-time-ns", 171),
>>          PROPERTY_ENTRY_U32("i2c-scl-falling-time-ns", 208),
>>          { },
>>
>> The reason why I choose sda hold time is by the Table 10 of
>> https://www.nxp.com/docs/en/user-guide/UM10204.pdf, the device
>> must provide a hold time at lease 300ns and and 42 here is relatively
>> too small. The signal measurement result for the same pin on Windows
>> is as follows.
>> https://imgur.com/BtKUIZB
>> Comparing to the same result running Linux
>> https://imgur.com/N4fPTYN
>>
>> After applying the sda hold time tweak patch above, the touchpad can
>> be correctly initialized and work. The LA signal is shown as down below.
>> https://imgur.com/B3PmnIp
>>
Could you try does attached patch work for you?

It's from last year for another related issue but there platform was 
actually Apollo Lake instead of Gemini Lake but anyway it was found out 
that Windows uses different timing parameters than Linux on Gemini Lake.

I didn't take patch forward back then due known Gemini Lake machines 
were working with the Broxton I2C timing parameters but now it's time if 
attached patch fixes the issue on your machine.

Patch is from top of v5.3-rc7 but should probably apply also to older 
kernels.

-- 
Jarkko

View attachment "0001-mfd-intel-lpss-Add-default-I2C-device-properties-for.patch" of type "text/x-patch" (3270 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ