On Fri, Feb 15, 2008 at 02:40:29PM +0300, Anton Vorontsov wrote:
[...]
> > > {
> > > qe_chip = container_of(gpio_to_chip(...), struct qe_chip, chip);
> > > ...
> >
> > You know, you can write all this yourself, without needing any
> > support from the GPIO framework whatsoever. The QE stuff that
> > registered a gpio_chip interface to its hardware probably keeps
> > some records itself, sufficient for such (infrequent) mappings.
>
> Yes, surely. And as I've said already, I do know how to workaround
> that, without GPIOLIB support. The thing is that I don't like the
> way I'm going to do it.
...please, don't force me to do these dirty hacks inside the arch code,
nobody will like them, I know it beforehand. ;-)
...if you so reluctant supporting dedicated functions inside the gpiolib,
then nothing could be easier than exporting gpio_to_chip(), so arch code
can write extensions without dirty hacks. Please?
p.s. By "dirty hacks" I mean:
a) drivers will need to fetch and store device_node in their private
driver data, in _addition_ to gpio numbers;
b) which means that I'll have to introduce of_get_gpio_controller()
to solely workaround gpio_to_chip() absence;
c) and all that will result in 9 * N additional lines of code to
handle by the drivers, where N is the number of GPIOs we want to use:
struct drvdata {
(1) struct device_node *gpioX_controller;
drv_probe()
(2) drvdata->gpioX_controller = of_get_gpio_controller(...);
(3) if (!drvdata->gpioX_controller) {
(4) ret = -EINVAL;
(5) goto gpioX_contr_failed;
(6) }
(7) gpioX_contr_failed:
(8) of_put_gpio_controller(drvdata->gpioX_controller)
drv_remove()
{
(9) of_put_gpio_controller(drvdata->gpioX_controller)
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
