On Thursday 08 February 2018 18:23:23 Mario.Limonciello@xxxxxxxx wrote: > After Paul's recent message regarding the odd wifi issue he had a > comment I wanted to investigate: > > dell_smbios: "No dell-smbios drivers are loaded" > > Coming up early in boot. This is a side effect of dell-smbios having two > backend drivers that can be compiled as modules but no tie to force > them to initialize before calls to dell_smbios_call. > > So I believe what is happening is dell_micmute_led_set is called from > the HDA driver and calls dell_smbios_call early too. > > I haven't tried it on a platform with mic mute, but I suspect it might cause > the mic mute LED status to be wrong initially (but corrected later when > toggled). > > Ideas that came to mind: > > 1) In dell_smbios_call if no backends loaded, explicitly do a symbol_request > for both backends and run initialization at that time. > > If that works, that would also resolve if someone manually unloaded both > backends but a kernel module still tried to perform a request. > > 2) Add a notifier chain for when the driver is ready (a backend is loaded) > to all consumers of dell_smbios_call. Don't let other modules call > dell_smbios_call until notified. > Don't let the HDA driver call dell_micmute_led_set either. > > 3) try_module_get during dell-smbios initialization for both the backends > > What's the correct way to address this? I'm not really sure what is the best approach. But in my opinion, if somebody call blocking function symbol_request() then after function return, caller wants to use this symbol and expects to be ready. Therefore I think that exported function (dell_micmute_led_set) should probably ensure that everything is initialized and after that continue... So maybe add "initialize & wait until backends are ready" code into beginning of that function? -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
