Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit ec064d3c authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'driver-core-4.18-rc1' of... 

Merge tag 'driver-core-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

Pull driver core updates from Greg KH:
 "Here is the driver core patchset for 4.18-rc1.

  The large chunk of these are firmware core documentation and api
  updates. Nothing major there, just better descriptions for others to
  be able to understand the firmware code better. There's also a user
  for a new firmware api call.

  Other than that, there are some minor updates for debugfs, kernfs, and
  the driver core itself.

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'driver-core-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (23 commits)
  driver core: hold dev's parent lock when needed
  driver-core: return EINVAL error instead of BUG_ON()
  driver core: add __printf verification to device_create_groups_vargs
  mm: memory_hotplug: use put_device() if device_register fail
  base: core: fix typo 'can by' to 'can be'
  debugfs: inode: debugfs_create_dir uses mode permission from parent
  debugfs: Re-use kstrtobool_from_user()
  Documentation: clarify firmware_class provenance and why we can't rename the module
  Documentation: remove stale firmware API reference
  Documentation: fix few typos and clarifications for the firmware loader
  ath10k: re-enable the firmware fallback mechanism for testmode
  ath10k: use firmware_request_nowarn() to load firmware
  firmware: add firmware_request_nowarn() - load firmware without warnings
  firmware_loader: make firmware_fallback_sysfs() print more useful
  firmware_loader: move kconfig FW_LOADER entries to its own file
  firmware_loader: replace ---help--- with help
  firmware_loader: enhance Kconfig documentation over FW_LOADER
  firmware_loader: document firmware_sysfs_fallback()
  firmware: rename fw_sysfs_fallback to firmware_fallback_sysfs()
  firmware: use () to terminate kernel-doc function names
  ...
parents abf7dba7 8c97a46a

Documentation/dell_rbu.txt

+1 −4
Original line number Diff line number Diff line
@@ -121,10 +121,7 @@ read back the image downloaded. 


.. note::



   This driver requires a patch for firmware_class.c which has the modified

   request_firmware_nowait function.



   Also after updating the BIOS image a user mode application needs to execute

   After updating the BIOS image a user mode application needs to execute

   code which sends the BIOS update request to the BIOS. So on the next reboot

   the BIOS knows about the new image downloaded and it updates itself.

   Also don't unload the rbu driver if the image has to be updated.

Documentation/driver-api/firmware/fallback-mechanisms.rst

+9 −5
Original line number Diff line number Diff line
@@ -72,9 +72,12 @@ the firmware requested, and establishes it in the device hierarchy by 
associating the device used to make the request as the device's parent.

The sysfs directory's file attributes are defined and controlled through

the new device's class (firmware_class) and group (fw_dev_attr_groups).

This is actually where the original firmware_class.c file name comes from,

as originally the only firmware loading mechanism available was the

mechanism we now use as a fallback mechanism.

This is actually where the original firmware_class module name came from,

given that originally the only firmware loading mechanism available was the

mechanism we now use as a fallback mechanism, which registers a struct class

firmware_class. Because the attributes exposed are part of the module name, the

module name firmware_class cannot be renamed in the future, to ensure backward

compatibility with old userspace.



To load firmware using the sysfs interface we expose a loading indicator,

and a file upload firmware into:
@@ -83,7 +86,7 @@ and a file upload firmware into: 
  * /sys/$DEVPATH/data



To upload firmware you will echo 1 onto the loading file to indicate

you are loading firmware. You then cat the firmware into the data file,

you are loading firmware. You then write the firmware into the data file,

and you notify the kernel the firmware is ready by echo'ing 0 onto

the loading file.
@@ -136,7 +139,8 @@ by kobject uevents. This is specially exacerbated due to the fact that most 
distributions today disable CONFIG_FW_LOADER_USER_HELPER_FALLBACK.



Refer to do_firmware_uevent() for details of the kobject event variables

setup. Variables passwdd with a kobject add event:

setup. The variables currently passed to userspace with a "kobject add"

event are:



* FIRMWARE=firmware name

* TIMEOUT=timeout value

Documentation/driver-api/firmware/firmware_cache.rst

+2 −2
Original line number Diff line number Diff line
@@ -29,8 +29,8 @@ Some implementation details about the firmware cache setup: 
* If an asynchronous call is used the firmware cache is only set up for a

  device if if the second argument (uevent) to request_firmware_nowait() is

  true. When uevent is true it requests that a kobject uevent be sent to

  userspace for the firmware request. For details refer to the Fackback

  mechanism documented below.

  userspace for the firmware request through the sysfs fallback mechanism

  if the firmware file is not found.



* If the firmware cache is determined to be needed as per the above two

  criteria the firmware cache is setup by adding a devres entry for the

Documentation/driver-api/firmware/request_firmware.rst

+5 −0
Original line number Diff line number Diff line
@@ -20,6 +20,11 @@ request_firmware 
.. kernel-doc:: drivers/base/firmware_loader/main.c

   :functions: request_firmware



firmware_request_nowarn

-----------------------

.. kernel-doc:: drivers/base/firmware_loader/main.c

   :functions: firmware_request_nowarn



request_firmware_direct

-----------------------

.. kernel-doc:: drivers/base/firmware_loader/main.c

drivers/base/Kconfig

+17 −73
Original line number Diff line number Diff line
@@ -70,81 +70,25 @@ config STANDALONE 
	  If unsure, say Y.



config PREVENT_FIRMWARE_BUILD

	bool "Prevent firmware from being built"

	bool "Disable drivers features which enable custom firmware building"

	default y

	help

	  Say yes to avoid building firmware. Firmware is usually shipped

	  with the driver and only when updating the firmware should a

	  rebuild be made.

	  If unsure, say Y here.



config FW_LOADER

	tristate "Userspace firmware loading support" if EXPERT

	default y

	---help---

	  This option is provided for the case where none of the in-tree modules

	  require userspace firmware loading support, but a module built

	  out-of-tree does.



config EXTRA_FIRMWARE

	string "External firmware blobs to build into the kernel binary"

	depends on FW_LOADER

	help

	  Various drivers in the kernel source tree may require firmware,

	  which is generally available in your distribution's linux-firmware

	  package.



	  The linux-firmware package should install firmware into

	  /lib/firmware/ on your system, so they can be loaded by userspace

	  helpers on request.



	  This option allows firmware to be built into the kernel for the case

	  where the user either cannot or doesn't want to provide it from

	  userspace at runtime (for example, when the firmware in question is

	  required for accessing the boot device, and the user doesn't want to

	  use an initrd).



	  This option is a string and takes the (space-separated) names of the

	  firmware files -- the same names that appear in MODULE_FIRMWARE()

	  and request_firmware() in the source. These files should exist under

	  the directory specified by the EXTRA_FIRMWARE_DIR option, which is

	  /lib/firmware by default.



	  For example, you might set CONFIG_EXTRA_FIRMWARE="usb8388.bin", copy

	  the usb8388.bin file into /lib/firmware, and build the kernel. Then

	  any request_firmware("usb8388.bin") will be satisfied internally

	  without needing to call out to userspace.



	  WARNING: If you include additional firmware files into your binary

	  kernel image that are not available under the terms of the GPL,

	  then it may be a violation of the GPL to distribute the resulting

	  image since it combines both GPL and non-GPL work. You should

	  consult a lawyer of your own before distributing such an image.



config EXTRA_FIRMWARE_DIR

	string "Firmware blobs root directory"

	depends on EXTRA_FIRMWARE != ""

	default "/lib/firmware"

	help

	  This option controls the directory in which the kernel build system

	  looks for the firmware files listed in the EXTRA_FIRMWARE option.



config FW_LOADER_USER_HELPER

	bool



config FW_LOADER_USER_HELPER_FALLBACK

	bool "Fallback user-helper invocation for firmware loading"

	depends on FW_LOADER

	select FW_LOADER_USER_HELPER

	help

	  This option enables / disables the invocation of user-helper

	  (e.g. udev) for loading firmware files as a fallback after the

	  direct file loading in kernel fails.  The user-mode helper is

	  no longer required unless you have a special firmware file that

	  resides in a non-standard path. Moreover, the udev support has

	  been deprecated upstream.



	  If you are unsure about this, say N here.

	  Say yes to disable driver features which enable building a custom

	  driver firmware at kernel build time. These drivers do not use the

	  kernel firmware API to load firmware (CONFIG_FW_LOADER), instead they

	  use their own custom loading mechanism. The required firmware is

	  usually shipped with the driver, building the driver firmware

	  should only be needed if you have an updated firmware source.



	  Firmware should not be being built as part of kernel, these days

	  you should always prevent this and say Y here. There are only two

	  old drivers which enable building of its firmware at kernel build

	  time:



	    o CONFIG_WANXL through CONFIG_WANXL_BUILD_FIRMWARE

	    o CONFIG_SCSI_AIC79XX through CONFIG_AIC79XX_BUILD_FIRMWARE



source "drivers/base/firmware_loader/Kconfig"



config WANT_DEV_COREDUMP

	bool