Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali RohÃr]

On Wednesday 04 January 2017 10:13:38 Benjamin Tissoires wrote:
> On Jan 03 2017 or thereabouts, Dmitry Torokhov wrote:
> > On Tue, Jan 03, 2017 at 10:29:34PM +0100, Benjamin Tissoires wrote:
> > > On Jan 03 2017 or thereabouts, Dmitry Torokhov wrote:
> > >
> > > > Yet another option: can we add a new flag to i2c_board_info controlling
> > > > whether we want to enable/disable wiring up host notify interrupt?
> > > 
> > > That should be fairly easy to implement. For now, given that only Elan
> > > and Synaptics are the one in need for Host Notify, it could be better to
> > > request the Host Notify IRQ instead of disabling it unconditionally
> > > (which would make the current yet 8 years old lis3lv02d driver happy
> > > again).
> > 
> > I like that we have it done in i2c core instead of having drivers
> > implementing it individually. Since you are saying that handling host
> > notify is property of the slave/driver maybe we should be adding a flag
> > to the *i2c_driver* structure to let i2c core that we want to have host
> > notify mapped as interrupt if "native" interrupt is not supplied by the
> > platform code?
> 
> I don't think this is a good idea. It's still a property of the I2C
> device, not the driver. It's crappy under Windows, but that doesn't
> prevent us to do the right thing.
> 
> I think the idea of having it at the i2c_board_info level is the good
> one. It's a property of the device node and it wouldn't hurt me to have
> a device tree property for that too (not entering the DT field now).
> There is no ACPI prop for it too, but I wouldn't be surprised if it
> comes in a later revision. The advantage of having it turned on
> unconditionally is that we can instantiate it from userspace without
> breaking the sysfs ABI.
> 
> Note that in the 2 uses I have seen so far of Host Notify, in both cases
> I need to instantiate the I2C device from an other driver (psmouse) so I
> can control the content of i2c_board_info.

If I understand it correctly, there is problem that i2c lis3lv02d driver
needs to get IRQ number for freefall and in current structure you pass
host notify IRQ number.

It means that one property in lis3lv02d driver is used for two things:
free fall IRQ and host notify IRQ. So the only way how to fix it is to
use two different IRQ properties. Probably free fall IRQ is lis3lv02d
specific and should be in platform data structure, not in generic
i2c_board_info shared across all i2c drivers?

-- 
Pali RohÃr
pali.rohar@xxxxxxxxx