On Mon, 24 Jul 2017, Benjamin Tissoires 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. > > > > Worse, after the probe failure the i2c / ACPI core code will put the ACPI > > device in D3 state and when the chipone_icn8318 driver then loads the > > device is put back in D0 state, executing its PS0 ACPI method, which > > resets the controller, causing the controller to loose its firmware > > which was loaded by the BIOS. The chipone_icn8318 driver has a workaround > > for this, but that requires it to be the only (or the first) driver to > > probe the device. > > > > 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. > > > > Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx> > > --- > > Changes in v2: > > -Use the new i2c_driver match callback to only filter out the CHPN0001 > > ACPI device, rather then use acpi_dev_present in probe and not > > registering the driver at all when the system has a CHPN0001 device > > I like the v2 much more than the v1. > > Reviewed-By: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> Wolfram, what do we do with this patchset? I think it makes sense for both patches to go in via one tree. Either I can take it through hid.git with your Ack for the first patch, or vice versa. Please let me know what you'd prefer. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
