Messages in this thread | | | Date | Wed, 2 Sep 2015 14:09:51 +0200 | From | Arend van Spriel <> | Subject | Re: Problems loading firmware using built-in drivers with kernels that use initramfs. |
| |
On 09/02/2015 03:19 AM, Luis R. Rodriguez wrote: > On Mon, Aug 31, 2015 at 10:21:34PM +0800, Ming Lei wrote: >> On Sun, Aug 30, 2015 at 4:25 PM, Arend van Spriel <arend@broadcom.com> wrote: >>> Does this mean a built-in driver can not get firmware from initramfs or >>> built in the kernel early. Seems a bit too aggressive. The problem stated in >>> this thread is when the firmware is not on initramfs but only on the rootfs. >> >> Yes, strictly speaking, user mode request can't be handled with defer probe >> during booting because we don't know how the user helper handles the >> request, > > FWIW I have a strategy in mind to help us compartamentalize the user mode > helper only to the dell-rbu driver, and as such phase out that code eventually > completely. Its part of the goals I have with the extensible firmware API I've > been proposing. > >> that said even checking if the firmware exists in current path doesn't >> make sense for user mode request. >> >> So the patch should have used defer proble for direct load only >> during booting. > > What exact guarantees would we be giving to callers if they follow up on probe > with -EDEFER_PROBE ? I'd much prefer to try to avoid such uses in init / probe > (note that unless you're using async probe since we batch both so it doesn't really > matter where you place your code) all together and then for the few remaining > stragglers understand the requirements and provide an interface that lets them > claim their requirements and try to meets them. > > A grammatical hunt for drivers who call fw API on init / probe can be > completed, although I know the hunt needs a bit more fine tuning it surely can > be completed. If we don't have many callers the compexity added for only a > few callers with rather loose criteria seems rather unnecessary, specially if > we can change the drivers and make these driver sthe exception rather than > a norm. > > Then as for drivers *needing* the fw at probe why not have a proper interface > that does guarantee they get the requirements they ask for first ? For instance > a new probe type specified by the driver could enable the core to wait for say > an event and then tirgger a probe, kind of how we ended up defining the async > probe type preference: > > static struct some_bus_driver some_driver = { > .probe = some_probe, > .id_table = some_id, > .driver = { > .name = DEVICE_NAME, > .pm = &some_pm_ops, > .probe_type = PROBE_PREFER_POST_FOO, > }, > }; > > Then we just don't try just hoping for completion but rather can do something > about the criteria passed.
That sounds good to me and learning about the async probe type. We do a schedule work in our module_init to avoid the probe being done in init context. Guess we can change that using the async probe type :-p
Regards, Arend
| |