[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20121126140828.555CF3E196F@localhost>
Date: Mon, 26 Nov 2012 14:08:28 +0000
From: Grant Likely <grant.likely@...retlab.ca>
To: Bongkyu Kim <bongkyu.kim@....com>,
Rob Herring <robherring2@...il.com>
Cc: devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] of/i2c: support more interrupt specifiers
On Mon, 26 Nov 2012 14:11:27 +0900, Bongkyu Kim <bongkyu.kim@....com> wrote:
> On 11/21/2012 10:41 PM, Rob Herring wrote:
> > On 11/21/2012 02:58 AM, Bongkyu Kim wrote:
> >> This patch supports more interrupt specifiers for i2c client.
> >
> > Why?
> >
>
> If we are registering a device has 2 interrupts like the below,
> i2c@...68000 {
> lsm330_acc@1D {
> compatible = "ST,lsm330_acc",
> /* #interrupt-cells = <2> */
> interrupts = <73 0x2 65 0x2>,
> };
> };
>
> we can't use second irq(65) in a driver because of mapping first
> interrupt only.
> If second irq(65) is mapped, we can use by gpio_to_irq() function at a
> driver.
> So, I think that all interrupt specifiers should be parsed and mapped
> if DT's interrupts property is allowed several interrupt specifiers.
This doesn't look like a very good idea. If more than one interrupt is
provided, then each should be entirely parsed in the driver's .probe() or
in of_i2c_register_devices(), not split across the two. Using
gpio_to_irq() to fetch an irq number that was already calculated and
then thrown away is a bizarre back way of going about it. Plus it is
error-probe because nothing will check that the gpio and interrupts
properties agree.
Either the driver should do all the parsing of 2nd and subsequent irqs,
or the i2c subsystem should be extended to support multiple irq
resources.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists