[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110504110939.GB13514@pulham.picochip.com>
Date: Wed, 4 May 2011 12:09:39 +0100
From: Jamie Iles <jamie@...ieiles.com>
To: Anton Vorontsov <cbouatmailru@...il.com>
Cc: Jamie Iles <jamie@...ieiles.com>,
Grant Likely <grant.likely@...retlab.ca>,
linux-kernel@...r.kernel.org, linux@....linux.org.uk,
tglx@...utronix.de, arnd@...db.de, nico@...xnic.net,
Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCHv3 0/7] gpio: extend basic_mmio_gpio for different
controllers
On Wed, May 04, 2011 at 02:34:15AM +0400, Anton Vorontsov wrote:
> On Tue, May 03, 2011 at 11:04:08PM +0100, Jamie Iles wrote:
> [...]
> > The advantage that Grant's proposal has though is that the user can
> > override the gpio_chip callbacks. When I tried porting over some
> > existing ARM platforms, one of the blocking issues was that lots of
> > platforms had some annoying small detail that was slightly different
> > (such as doing muxing in the _get() callback or needing a to_irq
> > callback).
> >
> > If we make bgpio_chip public and return that from bgpio_probe
> > unregistered then the calling code can override some of the methods then
> > register the gpio_chip.
>
> Oh, that makes sense, right.
I've just given this a try and it largely works, but it's probably
better if we allow bgpio_chip to be embedded in other structures. For
example, the langwell driver has a gpio_to_irq callback that we would
need to get the IRQ base for the bank. We could add a void *priv member
to bgpio_chip but that doesn't feel quite right.
So,
int bgpio_init(struct bgpio_chip *bgc, struct device *dev,
unsigned long sz, void __iomem *dat, ...)
rather than a probe() that returns the bgpio_chip?
Jamie
--
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