-----Original Message----- From: Dave Hylands [mailto:dhylands@gmail.com] Sent: Wednesday, April 18, 2012 5:07 PM To: Holmes, Michael A (Mike) Cc: kernelnewbies@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@lsi.com> wrote:
-----Original Message----- From: Dave Hylands [mailto:dhylands@gmail.com] Sent: Wednesday, April 18, 2012 3:15 PM To: Holmes, Michael A (Mike) Cc: kernelnewbies@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@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