Re: [PATCH 2/2] HID: i2c-hid: Do not bind to CHPN0001 touchscreen

On Thu, Aug 17, 2017 at 12:39 PM, Wolfram Sang [off-list ref] wrote:

Hey guys,

Sorry, I don't understand some of the stuff here. But I'd like to
understand it before I add something to the I2C core. Especially as it
feels a bit a the edge of the driver model to me.

On Sat, Jul 22, 2017 at 08:55:37PM +0200, Hans de Goede wrote:

quoted

The CHPN0001 ACPI device has a _CID of PNP0C50 but is not HID compatible,
it uses its own protocol which is handled by the chipone_icn8318 driver.

If the i2c_hid_driver's probe functon gets called it will fail with a
"hid_descr_cmd failed" error.

That sounds like it fails pretty late. I'd assume we could check the
blacklist right at the beginning of probe and bail out immediately?

quoted

Worse, after the probe failure the i2c / ACPI core code will put the ACPI
device in D3 state

So I guess this will also happen if I unbind/rebind chipone_icn8318 driver?

Where does that happen? Sorry, I can't find it. Would it be an idea to
add a flag somewhere telling the device should not be put into D3? That
would be way more generic in case this happens outside I2C world, or?
Disclaimer: I am brainstorming here, don't know super much about ACPI.

quoted

This commit adds a match callback and returns -ENODEV for i2c_client-s
with a CHPN0001 ACPI device id, so that the probe function never gets
called, fixing the controller losing its firmware.

Do you know if something like a match-callback exists somewhere else in
the kernel?

Having blacklist means that we are failing at design somewhere...

In this case what we have is wrong ACPI table. Instead of adding hooks
to i2c core can we fix it (DSDT) up? I know people do not like it, but
I'd say this is task for yet another platform driver to adjust ACPI
properties (kill the wrong _CID, disable PS0) before instantiating the
device.

Thanks.

-- 
Dmitry