On Thu, Oct 13, 2016 at 02:10:40PM +0200, Benjamin Tissoires wrote: > The current SMBus Host Notify implementation relies on .alert() to > relay its notifications. However, the use cases where SMBus Host > Notify is needed currently is to signal data ready on touchpads. > > This is closer to an IRQ than a custom API through .alert(). > Given that the 2 touchpad manufacturers (Synaptics and Elan) that > use SMBus Host Notify don't put any data in the SMBus payload, the > concept actually matches one to one. I see the advantages. The only question I have: What if we encounter devices in the future which do put data in the payload? Can this mechanism be extended to handle that? > > Benefits are multiple: > - simpler code and API: the client will just have an IRQ, and > nothing needs to be added in the adapter beside internally > enabling it. > - no more specific workqueue, the threading is handled by IRQ core > directly (when required) > - no more races when removing the device (the drivers are already > required to disable irq on remove) > - simpler handling for drivers: use plain regular IRQs > - no more dependency on i2c-smbus for i2c-i801 (and any other adapter) > - the IRQ domain is created automatically when the adapter exports > the Host Notify capability > - the IRQ are assign only if ACPI, OF and the caller did not assign > one already > - the domain is automatically destroyed on remove > - fewer lines of code (minus 20, yeah!) > > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> Thanks for keeping at it!
Attachment:
signature.asc
Description: PGP signature
