Messages in this thread | | | Date | Tue, 26 Jan 2010 20:43:47 +0300 | From | Anton Vorontsov <> | Subject | Re: [PATCH 2/4] of/gpio: Add support for two-stage registration for the of_gpio_chips |
| |
On Mon, Jan 25, 2010 at 10:36:15PM -0800, David Brownell wrote: > On Monday 25 January 2010, Anton Vorontsov wrote: > > With this patch there are two ways to register OF GPIO controllers: > > > > 1. Allocating the of_gpio_chip structure and passing the > > &of_gc->gc pointer to the gpiochip_add. (Can use container_of > > to convert the gpio_chip to the of_gpio_chip.) > > > > 2. Allocating and registering the gpio_chip structure separately > > from the of_gpio_chip. (Since two allocations are separate, > > container_of won't work.) > > > > As time goes by we'll kill the first option. > > Why have two options, instead of just the first/simpler one??
Because I2C/SPI drivers allocate (and register) gpio_chip structures by themselves, so the first option is a no-go.
You can see the first option in use in arch/powerpc/sysdev/qe_lib/gpio.c:
struct qe_gpio_chip { struct of_mm_gpio_chip mm_gc; .... };
Now include/linux/of_gpio.h:
struct of_mm_gpio_chip { struct of_gpio_chip of_gc; ... };
struct of_gpio_chip { struct gpio_chip gc; <- here, I'm going to get rid of it ... };
I2C/SPI drivers allocate gpio_chip structure already, so we don't need to store 'struct gpio_chip gc', instead we need to store just a pointer, and then attach the already allocated gpio_chip to the of_gpio_chip stuff.
Having two ways to store gpio_chip isn't good, that's why I stated that the first option will have to go, i.e. I'm going to convert arch/powerpc/sysdev/qe_lib/gpio.c and few other of_mm gpio chips to the new registration scheme soon.
Thanks,
-- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |