There's a race when the device is unbound (maybe because the module is unloaded) while the opmode start hasn't finished yet. The complete(request_firmware_complete) after the opmode start was meant (and commented accordingly) to prevent this problem, but it's not sufficient when the opmode module is loaded after the firmware load already completed, which happens regularly now because firmware load doesn't require userspace, unlike module load. Fix this by using the existing opmode registration mutex to protected the start/stop flows against each other properly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230926110319.85951554fed8.I62f20f40d79d0f136fa05e46d7fc16dc437fa3db@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
…
Linux kernel ============ There are several guides for kernel developers and users. These guides can be rendered in a number of formats, like HTML and PDF. Please read Documentation/admin-guide/README.rst first. In order to build the documentation, use ``make htmldocs`` or ``make pdfdocs``. The formatted documentation can also be read online at: https://www.kernel.org/doc/html/latest/ There are various text files in the Documentation/ subdirectory, several of them using the Restructured Text markup notation. Please read the Documentation/process/changes.rst file, as it contains the requirements for building and running the kernel, and information about the problems which may result by upgrading your kernel.
Description
Languages
C
97.6%
Assembly
1%
Shell
0.5%
Python
0.3%
Makefile
0.3%