[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101025004541.GD21564@trinity.fluff.org>
Date: Mon, 25 Oct 2010 01:45:41 +0100
From: Ben Dooks <ben-i2c@...ff.org>
To: Mike Frysinger <vapier@...too.org>
Cc: Jean Delvare <khali@...ux-fr.org>,
"Hennerich, Michael" <Michael.Hennerich@...log.com>,
David Brownell <david-b@...bell.net>,
"uclinux-dist-devel@...ckfin.uclinux.org"
<uclinux-dist-devel@...ckfin.uclinux.org>,
"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
"device-drivers-devel@...ckfin.uclinux.org"
<device-drivers-devel@...ckfin.uclinux.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Device-drivers-devel] [PATCH] i2c: add irq_flags to board info
On Mon, Oct 18, 2010 at 03:51:49PM -0400, Mike Frysinger wrote:
> On Mon, Oct 18, 2010 at 10:33, Jean Delvare wrote:
> > Why do we have set_irq_type() if we're not supposed to call it? I am
> > not claiming to be an expert in the area, but it seems totally
> > reasonable to me that the same piece of code instantiating an I2C
> > device is also responsible for setting its IRQ type.
>
> but we're back to the same issue mentioned earlier -- you cant have a
> single kernel build with modules supporting multiple drivers
> simultaneously. we like to ship development boards with a single
> kernel build on it with many modules. then people can pick the addon
> boards they wish to prototype with at runtime by plugging in the card
> and loading the module.
I also dislike set_irq_type() as it doesn't check whether there is anyone
registered with the interrupt, which means that you could set the irq
type of someone else's irq.
I wonder if we should pass a struct resource instead, in case there
are multiple interrupt sources, as well as having it registered with
the right resource systems.
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
--
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