How to ensure other module/driver is initialized?

How to ensure other module/driver is initialized?

[Ian Pilcher]

I maintain an out-of-tree kernel module that enables the front-panel
LEDs on the Thecus N5550 NAS.

   https://github.com/ipilcher/n5550/blob/master/modules/n5550_board.c

The drive activity LEDs are connected to GPIO pins on the ICH10R, so
the gpio_ich driver must be loaded and initialized before my module is
loaded.  Unfortunately, the "and initialized" part is giving me trouble
after a recent CentOS kernel update.

My modprobe configuration includes:

   install n5550_board /sbin/modprobe gpio_ich; /sbin/modprobe i2c_i801;
       /sbin/modprobe --ignore-install n5550_board

But although the gpio_ich module does get loaded, it apparently hasn't
finished initializing when my module is loaded.  The result looks like
this:

  [    2.049217] leds-pca953x 0-0064: setting platform data
  [    2.051756] leds-gpio leds-gpio: pins are not configured from the 
driver
  [    2.051886] ------------[ cut here ]------------
  [    2.052004] WARNING: at drivers/gpio/gpiolib.c:176 
gpio_to_desc+0x94/0xd0()
  [    2.052120] invalid GPIO 195
  [    2.052273] Modules linked in: leds_gpio(+) leds_pca9532(+) 
dm_mirror dm_region_hash dm_log dm_mod it87 hwmon_vid n5550_board(OE) 
i2c_i801 gpio_ich i2c_core
  ...
  [    2.055171] Call Trace:
  ...
  [    2.060439] ---[ end trace d53e8e3ea852c413 ]---
  [    2.060589] gpiod_request: invalid GPIO
  [    2.060767] leds-pca953x 0-0062: setting platform data
  [    2.062718] leds-gpio: probe of leds-gpio failed with error -22
  [    2.066156] leds-pca953x 0-0062: gpios 16...31
  ...
  [    2.265708] gpio_ich: GPIO from 195 to 255 on gpio_ich

You can see that gpio_ich does appear on the "Modules linked in" line,
but it hasn't finished initializing until more that 1/10th of a
second after my module tries to use its GPIOs (indirectly through
leds_gpio).

I can work around this by adding a sleep to my modprobe configuration,
but that feels hacky and fragile.

What is the "right" way to do this?

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================

Re: How to ensure other module/driver is initialized?

[Linus Walleij]

On Thu, Dec 15, 2016 at 8:50 PM, Ian Pilcher <arequipeno@gmail.com> wrote:

> I maintain an out-of-tree kernel module that enables the front-panel
> LEDs on the Thecus N5550 NAS.
>
>   https://github.com/ipilcher/n5550/blob/master/modules/n5550_board.c

Generally I'm not very happy about boardfiles and such stuff being
maintained out-of-tree.

Is there work ongoing to:

(A) work upstream with this stuff
(B) convert the whole platform to use device tree

Because that is what is needed for long-term maintenance.

The file you point to corresponds to just a few lines of device tree
code. c.f. my recent submission of Gemini patches:
http://marc.info/?l=linux-arm-kernel&m=148508801709983&w=2

I know it is a bit up upfront work, but hey, it's fun.

> The drive activity LEDs are connected to GPIO pins on the ICH10R, so
> the gpio_ich driver must be loaded and initialized before my module is
> loaded.  Unfortunately, the "and initialized" part is giving me trouble
> after a recent CentOS kernel update.
>
> My modprobe configuration includes:
>
>   install n5550_board /sbin/modprobe gpio_ich; /sbin/modprobe i2c_i801;
>       /sbin/modprobe --ignore-install n5550_board
>
> But although the gpio_ich module does get loaded, it apparently hasn't
> finished initializing when my module is loaded.  The result looks like
> this:

I have no idea how modprobe works, but a SoC GPIO driver is often
such a critical component of a system (often provididing an irqchip
as well) that their Kconfig should be made bool and set to 'y' in the
config so it is compiled-in to the kernel.

Then any dependent modules can happily utilize it.

If this doesn't work, it should make use of deferred probe I guess?

Yours,
Linus Walleij

Re: How to ensure other module/driver is initialized?

[Ian Pilcher]

On 01/24/2017 07:02 AM, Linus Walleij wrote:
> On Thu, Dec 15, 2016 at 8:50 PM, Ian Pilcher <arequipeno@gmail.com> wrote:
>
>> I maintain an out-of-tree kernel module that enables the front-panel
>> LEDs on the Thecus N5550 NAS.
>>
>>   https://github.com/ipilcher/n5550/blob/master/modules/n5550_board.c
>
> Generally I'm not very happy about boardfiles and such stuff being
> maintained out-of-tree.
>
> Is there work ongoing to:
>
> (A) work upstream with this stuff
> (B) convert the whole platform to use device tree
>
> Because that is what is needed for long-term maintenance.

In general, I completely agree with you.  In this case, however, I
don't think that moving the module upstream and/or converting to device
tree is realistic.

I say this because the purpose of my module is to enable the LEDs and
GPIOs in the Thecus N5550 NAS for "generic" x86_64 distributions --
CentOS, Fedora, Debian, Ubuntu, etc.  It has nothing to do with the
Linux-based "firmware" provided by Thecus.  To the best of my knowledge,
the worldwide number of users of this module is in the single digits.

So even if the module were to be accepted upstream (which I tend to
doubt), it's extremely unlikely that any of the aforementioned
distributions would include it in their kernel configuration.

Device tree presents even greater problems.  It's not clear to me that
device tree even works with x86_64, and even if it does, I'm almost
positive that none of the "generic" distributions are going to support
it.

If my understanding of device tree is inaccurate, please do let me
know.  I'd definitely like to replace the "board" module with a
device tree description if it's possible.

Thanks!

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================

Re: How to ensure other module/driver is initialized?

[Linus Walleij]

On Tue, Jan 24, 2017 at 5:40 PM, Ian Pilcher <arequipeno@gmail.com> wrote:

> Device tree presents even greater problems.  It's not clear to me that
> device tree even works with x86_64, and even if it does, I'm almost
> positive that none of the "generic" distributions are going to support
> it.
>
> If my understanding of device tree is inaccurate, please do let me
> know.  I'd definitely like to replace the "board" module with a
> device tree description if it's possible.

Sorry for my ignorance. I thought this was some ARM or MIPS thing.

It should indeed come in as a board file for x86 systems,
unless they have ACPI to do what DT does on other platforms,
which modern systems do.

The way on these systems is to put a file in
drivers/platform/x86/* I think, but I know too little about
x86 for that.

I do think it'll be accepted upstream nevertheless, we do not
really count users but rather check whether the code is nice
and maintainable.

Yours,
Linus Walleij