[lkml]   [2016]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v5 6/6] i2c: use an IRQ to report Host Notify events, not alert
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 <>

Thanks for keeping at it!

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2016-11-07 01:20    [W:0.080 / U:1.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site