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: > 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? > Worse, after the probe failure the i2c / ACPI core code will put the ACPI > device in D3 state 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. > 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? Regards, Wolfram
Attachment:
signature.asc
Description: PGP signature
