Re: bcm63xx gpio issue on 3.19

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux