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@redhat.com>

Thanks for keeping at it!