On 03/12/2015 02:49 AM, Nicolas Schichan wrote:
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.
If that works for you and doesn't break bcm63xx, then yes that would be
great. GPIO chips are indeed devices, so moving their registration to
bcm63xx_register_devices() seems to make sense.
The GPIO subsystem might require more dynamic allocations in the near
future (including maybe when requesting GPIOs), but hopefully all
consumers will be safe with that. We'll find a solution for early GPIO
support if they aren't.
