Re: bcm63xx gpio issue on 3.19

[Nicolas Schichan <nschichan@freebox.fr>]

On 03/11/2015 06:23 AM, Alexandre Courbot wrote:
>> Could you please advise on how to fix/workaround that ? (ideally while keeping
>> the possibility to invoke the gpiolib code from the setup/prom code).
> 
> The only allocation performed by gpiochip_add() is the array of gpio_descs.
> Having this array pre-allocated in your early code (maybe by using a static
> array variable) and passing it to a gpiochip_add_early() function would do the
> trick.
> 
> However, it is not that simple since gpio_desc is a private structure which
> details (including its size) are not visible outside of drivers/gpio.
> 
> Another solution I could see would be to have a kernel config option that
> would make gpiolib "pre-allocate" a number of gpio descriptors as a static
> array for such cases - similar to the global GPIO array, but not as big.
> 
> Finally, we can also restore the global GPIO array as a config option for the
> few architectures that need it.
> 
> Of course, I would prefer a solution based on dynamic allocation - is there a
> kind a primitive memory allocator that we can use at this early stage of boot?
> I.e. would alloc_pages() maybe work?
> 
> How do other subsystems that rely on dynamic allocation for registering their
> resources handle this? I guess regulator must fall in the same use-case,
> doesn't it?

Hi Alexandre,

Moving the bcm63xx_gpio_init() call from board_prom_init() to
bcm63xx_register_devices() (an arch_initcall) is enough to get called when
kmalloc is working. If code poking GPIOs is invoked earlier by a board code,
it will have to move in the board_register_devices() function though there
doesn't seem to any problems with the mainline bcm63xx board code in that regard.

I can produce a patch for that if it is an accepted solution. It has the
advantage of not requiring changes to the gpiolib code.

Regards,

-- 
Nicolas Schichan
Freebox SAS