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