On Mar 10 2017 or thereabouts, Dmitry Torokhov wrote: > From: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> > > This provides glue between PS/2 devices that enumerate the RMI4 devices > and Elan touchpads to the RMI4 (or Elan) SMBus driver. > > The SMBus devices keep their PS/2 connection alive. If the initialization > process goes too far (psmouse_activate called), the device disconnects > from the I2C bus and stays on the PS/2 bus, that is why we explicitly > disable PS/2 device reporting (by calling psmouse_deactivate) before > trying to register SMBus companion device. > > The HID over I2C devices are enumerated through the ACPI DSDT, and > their PS/2 device also exports the InterTouch bit in the extended > capability 0x0C. However, the firmware keeps its I2C connection open > even after going further in the PS/2 initialization. We don't need > to take extra precautions with those device, especially because they > block their PS/2 communication when HID over I2C is used. > > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> > --- Actually, one thing I noticed but forgot to say in my previous email: If you call rescan from the sysfs, there is a chance the i2c device is still there while we are trying to reconnect the device. Which means that we fail at creating the i2c device, and then fall back on PS/2. It's not a big issue, but still it will show some warning in the dmesg while attempting to create some sysfs files that already exist. S solution could be to unlock the mutexes and wait for the termination of i2c_unregister_device, but I would believe the best approach would be to remove the mutexes in serio and psmouse, and directly call i2c_unregister_device in .disconnect. Cheers, Benjamin -- 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
