bcm63xx gpio issue on 3.19

Hello Alexandre,

Using the latest 3.19 kernel, the bcm63xx GPIO code under arch/mips/bcm63xx/gpio.c is unable to register the gpio chip via gpiochip_add(), as it returns -ENOMEM. The kcalloc call for the gpio_desc array fails, as during prom code, it is too early for the kmalloc to work.

It looks like the issue is caused by your patch: "gpio: remove gpio_descs global array"

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).

Quoted 2 lines

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?

Quoted 18 lines · Alexandre Courbot

Quoted 2 lines

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.

Quoted 7 lines

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.

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.