linux-kernel - RE: [PATCH v3 1/5] Input: goodix

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: <1F3AC3675D538145B1661F571FE1805F2F0EBB24@irsmsx105.ger.corp.intel.com>
Date:	Tue, 29 Sep 2015 17:47:06 +0000
From:	"Tirdea, Irina" <irina.tirdea@...el.com>
To:	Bastien Nocera <hadess@...ess.net>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"Purdila, Octavian" <octavian.purdila@...el.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Mark Rutland <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: RE: [PATCH v3 1/5] Input: goodix - reset device at init



> -----Original Message-----
> From: Bastien Nocera [mailto:hadess@...ess.net]
> Sent: 29 September, 2015 5:04
> To: Tirdea, Irina; linux-input@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org; Rob Herring; Pawel Moll; Ian Campbell; Kumar Gala; Purdila, Octavian; Dmitry Torokhov; Mark
> Rutland; devicetree@...r.kernel.org
> Subject: Re: [PATCH v3 1/5] Input: goodix - reset device at init
> 
> On Fri, 2015-09-25 at 21:04 +0000, Tirdea, Irina wrote:
> >
<snip>
> >
> > The warning from your dmesg output will not cause probe to fail.
> > If you look at the code for byt_gpio_direction_output, it will just
> > print
> > a warning and continue [1]:
> > 	WARN(readl(conf_reg) & BYT_DIRECT_IRQ_EN,
> > 		"Potential Error: Setting GPIO with direct_irq_en to
> > output");
> > I thought probe finishes successfully, but due to the warning in
> > dmesg you
> > are not sure whether the IRQ GPIO pin can be used as output.
> > If probe fails, it must be for another reason than the direct_irq_en
> > warning.
> >
> > > Would you have a patch for me to test that would bypass this error,
> > > or
> > > at least fallback gracefully to not resetting, not probing GPIOs if
> > > they're badly setup?
> >
> > If the driver fails to initialize the GPIOs, it will at least print
> > some
> > "Failed to get GPIO" warnings in dmesg. Do you have such messages in
> > dmesg or any additional information on why probe fails?
> >
> > The current code will ignore GPIOs if they are not defined in ACPI
> > (see the check for -ENOENT), but does not ignore other error codes.
> > If you want to bypass all GPIO errors, you can use the code below.
> 
> The failure isn't there, it's when running goodix_i2c_test():
> Sep 25 16:39:20 winbook kernel: Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 1: -121
> Sep 25 16:39:20 winbook kernel: Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 2: -121
> Sep 25 16:39:20 winbook kernel: Goodix-TS i2c-GDIX1001:00: I2C communication failure: -121
> Sep 25 16:39:20 winbook kernel: Goodix-TS: probe of i2c-GDIX1001:00 failed with error -121
> 

Are you using v6 of the patches? There was an issue with reset that Aleksei reported
and was fixed in v6 (although he had a different i2c error and a different scenario).

> The GPIO setup seems to work (bar the warnings), and the reset as well,
> but then the device fails to communicate. Likely a fallout from the
> reset actually failing.
> 
> Swapping around the RST and INT pins leads to the same problem. Either
> this device's GPIO PINs aren't actually functional, and the firmware
> contains garbage, or something else is wrong.
> 

I agree. Either the interrupt pin cannot be used as output in your configuration
or there are some specifics in the ACPI tables that prevent using these pins. 

> I'm not sure how we can detect, and blacklist, those devices. At least
> my original device, the Onda v975w, and the WinBook TW100 would have
> those problems.
> 

I can use DMI quirks to exclude these devices from using the features that
depend on the gpio pins. I already have the DMI information for WinBook TW100
and WinBook TW700. Could you tell me the DMI_SYS_VENDOR and
DMI_PRODUCT_NAME for Onda v975w so I can add it as well?

Thanks,
Irina

> Cheers