Can request_firmware be called from a platform_driver ?

[Holmes, Michael A (Mike)]

-----Original Message-----
From: Dave Hylands [mailto:dhylands at gmail.com] 
Sent: Wednesday, April 18, 2012 5:07 PM
To: Holmes, Michael A (Mike)
Cc: kernelnewbies at kernelnewbies.org
Subject: Re: Can request_firmware be called from a platform_driver ?

HI Mike,

On Wed, Apr 18, 2012 at 1:24 PM, Holmes, Michael A (Mike)
<Mike.Holmes at lsi.com> wrote:
> -----Original Message-----
> From: Dave Hylands [mailto:dhylands at gmail.com]
> Sent: Wednesday, April 18, 2012 3:15 PM
> To: Holmes, Michael A (Mike)
> Cc: kernelnewbies at kernelnewbies.org
> Subject: Re: Can request_firmware be called from a platform_driver ?
>
> Hi Mike,
>
> On Wed, Apr 18, 2012 at 11:07 AM, Holmes, Michael A (Mike)
> <Mike.Holmes at lsi.com> wrote:
>> Hi
>>
>> I have a fully working system to which I want to add the request firmware
>> mechanism to an existing platform driver I have working.
>>
>> I instrumented mdev in busybox 1.5.1 and in firmware_class.c 2.6.35 so that
>> I could figure this out.
>>
>> What I see with firmware_request() is that the kernel makes the firmware
>> request and does not find any firmware and mdev sees nothing.
>>
>> However if I change my code to do request_firmare_nowait(), the entire
>> system comes up and about 30seconds in the timeout calls my kernel side
>> continue for request_firmare_nowait() and I DO now see my request handled by
>> mdev, however it is a REMOVE request not the ADD request.
>>
>> All this makes me think that platform drivers exist before the hotplug
>> mechanism is able to operate, is this true ?
>
> Well, request_firmware is ultimately serviced by a user-space process.
>
> So platform drivers compiled statically into the kernel get
> initialized long before user-space starts.
>
> Platform drivers compiled as modules will get the firmware loaded much
> more quickly after loading the module.
>
>>>>>>>>>
> Thanks Dave,
>
> Currently in make menuconfig I put '*' against it to compile it into the kernel, I made it an 'm' so that it is made as a module.
> For modules made outside the tree I call modprobe to load them, but I never made a module in the tree before, I don't know how to get its init called.
> When it was compiled in, I called the init from my machine init directly in my mach-lcp/arch.c via platform_device_register()

As far as init being called, this is identical for modules compiled as
part of the kernel as it is for modules compiled out of tree.

Normally, you would use module_init to specify a function to be
called. This function will be called when a module is loaded
(regardless of whether its compiled in or out of tree).

For modules statically compiled into the kernel, module_init becomes
the same as device_initcall.

For code compiled as a module, all of the various xxx_initcall stuff
gets translated to module_init
See: include/linux/init.h

>>>>>>>>>
Thanks, my module does use module_init, but now that this code is compiled as a module and not compiled into the kernel, I find that the .probe method is never called so I must still be missing something.

I tried calling the probe directly in the init but this still fails with modprobe complaining.

Should my .probe be called if my init only calls platform_driver_register and this module is loaded with modprobe rather than by the kernel booting?
And really I only want to call the probe method so that I can get hold of a struct platform_device *pdev to call firmware_request() with, maybe I am going about this completely incorrectly?

I see at this link http://lwn.net/Articles/198461/  they do not use a platform_driver_register but a device_register, is that my mistake ?

Still struggling, but I am now using the shotgun programming approach of trying anything I can dream up to figure it out :-)

Mike