Re: [RFC v2 PATCH 01/14] iio: st_common: New interrupt interface

[Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>]

On Tue, Oct 01, 2013 at 04:34:47PM +0100, Jonathan Cameron wrote:
> On 09/27/13 17:32, Lukasz Czerwinski wrote:
> > This patch adds two interrupts handling by the st_common library.
> > Additional second interrupt is used to indetify enabled event support for
> > chosen ST device. It supports board files and dt.
> >
> > For dt interface multiple interrupts are passed through interrupt-names
> > property.
> >
> > Read drdy_int_pin value is moved to the st_sensors_parse_platform_data()
> > in the st_sensors_i2c.c and st_sensors_spi.c Now drdy_int_pin can be
> > also configured via dt.
> >
> > Signed-off-by: Lukasz Czerwinski <l.czerwinski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> > Signed-off-by: Kyungmin Park <kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> 
> The code here is absolutely fine, though I would like some comments
> on this from Denis and/or Lee (as they are much more familiar with the driver
> than I am!
> 
> The one element that is problematic is the use of interrupt names in specifying
> the two interrupts.  Unforunately, for reasons that I think can be sumarized
> as historical precedence and avoiding complexity of passing in other OSes,
> the device tree powers that be are very anti doing multiple optional interrupts
> this way and consider interrupt-names to be merely for information rather than
> to be used to allow 'optional' interrupts.

There is some disagreement on this point. I think that using interrupt-names to
describe the set of interrupts you have makes a great deal of sense given how
common it is for only an arbitrary subset of interupts to be wired up.

There is an obvious problem in adding *-names properties to existing bindings
in that an existing OS will not know of the *-names property and may parse a DT
in a way that's not in accordance with the intended meaning. Depending on the
device this could mean a failure to probe, a failure to function, or a system
deadlock. This is an unfortunate problem, but one that we can work around on a
case-by-case basis.

For new bindings, I see no reason to not have interrupt-names from the start,
as a required component of the binding.

Thanks,
Mark.