Loading Documentation/admin-guide/kernel-parameters.txt +4 −0 Original line number Original line Diff line number Diff line Loading @@ -136,6 +136,10 @@ dynamic table installation which will install SSDT dynamic table installation which will install SSDT tables to /sys/firmware/acpi/tables/dynamic. tables to /sys/firmware/acpi/tables/dynamic. acpi_no_watchdog [HW,ACPI,WDT] Ignore the ACPI-based watchdog interface (WDAT) and let a native driver control the watchdog device instead. acpi_rsdp= [ACPI,EFI,KEXEC] acpi_rsdp= [ACPI,EFI,KEXEC] Pass the RSDP address to the kernel, mostly used Pass the RSDP address to the kernel, mostly used on machines running EFI runtime service to boot the on machines running EFI runtime service to boot the Loading Documentation/driver-api/device_link.rst +42 −21 Original line number Original line Diff line number Diff line Loading @@ -25,8 +25,8 @@ suspend/resume and shutdown ordering. Device links allow representation of such dependencies in the driver core. Device links allow representation of such dependencies in the driver core. In its standard form, a device link combines *both* dependency types: In its standard or *managed* form, a device link combines *both* dependency It guarantees correct suspend/resume and shutdown ordering between a types: It guarantees correct suspend/resume and shutdown ordering between a "supplier" device and its "consumer" devices, and it guarantees driver "supplier" device and its "consumer" devices, and it guarantees driver presence on the supplier. The consumer devices are not probed before the presence on the supplier. The consumer devices are not probed before the supplier is bound to a driver, and they're unbound before the supplier supplier is bound to a driver, and they're unbound before the supplier Loading Loading @@ -59,18 +59,24 @@ device ``->probe`` callback or a boot-time PCI quirk. Another example for an inconsistent state would be a device link that Another example for an inconsistent state would be a device link that represents a driver presence dependency, yet is added from the consumer's represents a driver presence dependency, yet is added from the consumer's ``->probe`` callback while the supplier hasn't probed yet: Had the driver ``->probe`` callback while the supplier hasn't started to probe yet: Had the core known about the device link earlier, it wouldn't have probed the driver core known about the device link earlier, it wouldn't have probed the consumer in the first place. The onus is thus on the consumer to check consumer in the first place. The onus is thus on the consumer to check presence of the supplier after adding the link, and defer probing on presence of the supplier after adding the link, and defer probing on non-presence. non-presence. [Note that it is valid to create a link from the consumer's ``->probe`` callback while the supplier is still probing, but the consumer must If a device link is added in the ``->probe`` callback of the supplier or know that the supplier is functional already at the link creation time (that is consumer driver, it is typically deleted in its ``->remove`` callback for the case, for instance, if the consumer has just acquired some resources that symmetry. That way, if the driver is compiled as a module, the device would not have been available had the supplier not been functional then).] link is added on module load and orderly deleted on unload. The same restrictions that apply to device link addition (e.g. exclusion of a If a device link with ``DL_FLAG_STATELESS`` set (i.e. a stateless device link) parallel suspend/resume transition) apply equally to deletion. is added in the ``->probe`` callback of the supplier or consumer driver, it is typically deleted in its ``->remove`` callback for symmetry. That way, if the driver is compiled as a module, the device link is added on module load and orderly deleted on unload. The same restrictions that apply to device link addition (e.g. exclusion of a parallel suspend/resume transition) apply equally to deletion. Device links managed by the driver core are deleted automatically by it. Several flags may be specified on device link addition, two of which Several flags may be specified on device link addition, two of which have already been mentioned above: ``DL_FLAG_STATELESS`` to express that no have already been mentioned above: ``DL_FLAG_STATELESS`` to express that no Loading @@ -83,22 +89,37 @@ link is added from the consumer's ``->probe`` callback: ``DL_FLAG_RPM_ACTIVE`` can be specified to runtime resume the supplier upon addition of the can be specified to runtime resume the supplier upon addition of the device link. ``DL_FLAG_AUTOREMOVE_CONSUMER`` causes the device link to be device link. ``DL_FLAG_AUTOREMOVE_CONSUMER`` causes the device link to be automatically purged when the consumer fails to probe or later unbinds. automatically purged when the consumer fails to probe or later unbinds. This obviates the need to explicitly delete the link in the ``->remove`` callback or in the error path of the ``->probe`` callback. Similarly, when the device link is added from supplier's ``->probe`` callback, Similarly, when the device link is added from supplier's ``->probe`` callback, ``DL_FLAG_AUTOREMOVE_SUPPLIER`` causes the device link to be automatically ``DL_FLAG_AUTOREMOVE_SUPPLIER`` causes the device link to be automatically purged when the supplier fails to probe or later unbinds. purged when the supplier fails to probe or later unbinds. If neither ``DL_FLAG_AUTOREMOVE_CONSUMER`` nor ``DL_FLAG_AUTOREMOVE_SUPPLIER`` is set, ``DL_FLAG_AUTOPROBE_CONSUMER`` can be used to request the driver core to probe for a driver for the consumer driver on the link automatically after a driver has been bound to the supplier device. Note, however, that any combinations of ``DL_FLAG_AUTOREMOVE_CONSUMER``, ``DL_FLAG_AUTOREMOVE_SUPPLIER`` or ``DL_FLAG_AUTOPROBE_CONSUMER`` with ``DL_FLAG_STATELESS`` are invalid and cannot be used. Limitations Limitations =========== =========== Driver authors should be aware that a driver presence dependency (i.e. when Driver authors should be aware that a driver presence dependency for managed ``DL_FLAG_STATELESS`` is not specified on link addition) may cause probing of device links (i.e. when ``DL_FLAG_STATELESS`` is not specified on link addition) the consumer to be deferred indefinitely. This can become a problem if the may cause probing of the consumer to be deferred indefinitely. This can become consumer is required to probe before a certain initcall level is reached. a problem if the consumer is required to probe before a certain initcall level Worse, if the supplier driver is blacklisted or missing, the consumer will is reached. Worse, if the supplier driver is blacklisted or missing, the never be probed. consumer will never be probed. Moreover, managed device links cannot be deleted directly. They are deleted by the driver core when they are not necessary any more in accordance with the ``DL_FLAG_AUTOREMOVE_CONSUMER`` and ``DL_FLAG_AUTOREMOVE_SUPPLIER`` flags. However, stateless device links (i.e. device links with ``DL_FLAG_STATELESS`` set) are expected to be removed by whoever called :c:func:`device_link_add()` to add them with the help of either :c:func:`device_link_del()` or :c:func:`device_link_remove()`. Sometimes drivers depend on optional resources. They are able to operate Sometimes drivers depend on optional resources. They are able to operate in a degraded mode (reduced feature set or performance) when those resources in a degraded mode (reduced feature set or performance) when those resources Loading Loading @@ -283,4 +304,4 @@ API === === .. kernel-doc:: drivers/base/core.c .. kernel-doc:: drivers/base/core.c :functions: device_link_add device_link_del :functions: device_link_add device_link_del device_link_remove Documentation/filesystems/porting +7 −0 Original line number Original line Diff line number Diff line Loading @@ -627,3 +627,10 @@ in your dentry operations instead. DCACHE_RCUACCESS is gone; having an RCU delay on dentry freeing is the DCACHE_RCUACCESS is gone; having an RCU delay on dentry freeing is the default. DCACHE_NORCU opts out, and only d_alloc_pseudo() has any default. DCACHE_NORCU opts out, and only d_alloc_pseudo() has any business doing so. business doing so. -- [mandatory] [should've been added in 2016] stale comment in finish_open() nonwithstanding, failure exits in ->atomic_open() instances should *NOT* fput() the file, no matter what. Everything is handled by the caller. Documentation/usb/raw-gadget.rst 0 → 100644 +61 −0 Original line number Original line Diff line number Diff line ============== USB Raw Gadget ============== USB Raw Gadget is a kernel module that provides a userspace interface for the USB Gadget subsystem. Essentially it allows to emulate USB devices from userspace. Enabled with CONFIG_USB_RAW_GADGET. Raw Gadget is currently a strictly debugging feature and shouldn't be used in production, use GadgetFS instead. Comparison to GadgetFS ~~~~~~~~~~~~~~~~~~~~~~ Raw Gadget is similar to GadgetFS, but provides a more low-level and direct access to the USB Gadget layer for the userspace. The key differences are: 1. Every USB request is passed to the userspace to get a response, while GadgetFS responds to some USB requests internally based on the provided descriptors. However note, that the UDC driver might respond to some requests on its own and never forward them to the Gadget layer. 2. GadgetFS performs some sanity checks on the provided USB descriptors, while Raw Gadget allows you to provide arbitrary data as responses to USB requests. 3. Raw Gadget provides a way to select a UDC device/driver to bind to, while GadgetFS currently binds to the first available UDC. 4. Raw Gadget uses predictable endpoint names (handles) across different UDCs (as long as UDCs have enough endpoints of each required transfer type). 5. Raw Gadget has ioctl-based interface instead of a filesystem-based one. Userspace interface ~~~~~~~~~~~~~~~~~~~ To create a Raw Gadget instance open /dev/raw-gadget. Multiple raw-gadget instances (bound to different UDCs) can be used at the same time. The interaction with the opened file happens through the ioctl() calls, see comments in include/uapi/linux/usb/raw_gadget.h for details. The typical usage of Raw Gadget looks like: 1. Open Raw Gadget instance via /dev/raw-gadget. 2. Initialize the instance via USB_RAW_IOCTL_INIT. 3. Launch the instance with USB_RAW_IOCTL_RUN. 4. In a loop issue USB_RAW_IOCTL_EVENT_FETCH calls to receive events from Raw Gadget and react to those depending on what kind of USB device needs to be emulated. Potential future improvements ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Implement ioctl's for setting/clearing halt status on endpoints. - Reporting more events (suspend, resume, etc.) through USB_RAW_IOCTL_EVENT_FETCH. - Support O_NONBLOCK I/O. Makefile +2 −2 Original line number Original line Diff line number Diff line # SPDX-License-Identifier: GPL-2.0 # SPDX-License-Identifier: GPL-2.0 VERSION = 4 VERSION = 4 PATCHLEVEL = 19 PATCHLEVEL = 19 SUBLEVEL = 110 SUBLEVEL = 113 EXTRAVERSION = EXTRAVERSION = NAME = "People's Front" NAME = "People's Front" Loading Loading @@ -853,7 +853,7 @@ LD_FLAGS_LTO_CLANG := -mllvm -import-instr-limit=5 KBUILD_LDFLAGS += $(LD_FLAGS_LTO_CLANG) KBUILD_LDFLAGS += $(LD_FLAGS_LTO_CLANG) KBUILD_LDFLAGS_MODULE += $(LD_FLAGS_LTO_CLANG) KBUILD_LDFLAGS_MODULE += $(LD_FLAGS_LTO_CLANG) KBUILD_LDS_MODULE += $(srctree)/scripts/module-lto.lds KBUILD_LDFLAGS_MODULE += -T $(srctree)/scripts/module-lto.lds # allow disabling only clang LTO where needed # allow disabling only clang LTO where needed DISABLE_LTO_CLANG := -fno-lto DISABLE_LTO_CLANG := -fno-lto Loading Loading
Documentation/admin-guide/kernel-parameters.txt +4 −0 Original line number Original line Diff line number Diff line Loading @@ -136,6 +136,10 @@ dynamic table installation which will install SSDT dynamic table installation which will install SSDT tables to /sys/firmware/acpi/tables/dynamic. tables to /sys/firmware/acpi/tables/dynamic. acpi_no_watchdog [HW,ACPI,WDT] Ignore the ACPI-based watchdog interface (WDAT) and let a native driver control the watchdog device instead. acpi_rsdp= [ACPI,EFI,KEXEC] acpi_rsdp= [ACPI,EFI,KEXEC] Pass the RSDP address to the kernel, mostly used Pass the RSDP address to the kernel, mostly used on machines running EFI runtime service to boot the on machines running EFI runtime service to boot the Loading
Documentation/driver-api/device_link.rst +42 −21 Original line number Original line Diff line number Diff line Loading @@ -25,8 +25,8 @@ suspend/resume and shutdown ordering. Device links allow representation of such dependencies in the driver core. Device links allow representation of such dependencies in the driver core. In its standard form, a device link combines *both* dependency types: In its standard or *managed* form, a device link combines *both* dependency It guarantees correct suspend/resume and shutdown ordering between a types: It guarantees correct suspend/resume and shutdown ordering between a "supplier" device and its "consumer" devices, and it guarantees driver "supplier" device and its "consumer" devices, and it guarantees driver presence on the supplier. The consumer devices are not probed before the presence on the supplier. The consumer devices are not probed before the supplier is bound to a driver, and they're unbound before the supplier supplier is bound to a driver, and they're unbound before the supplier Loading Loading @@ -59,18 +59,24 @@ device ``->probe`` callback or a boot-time PCI quirk. Another example for an inconsistent state would be a device link that Another example for an inconsistent state would be a device link that represents a driver presence dependency, yet is added from the consumer's represents a driver presence dependency, yet is added from the consumer's ``->probe`` callback while the supplier hasn't probed yet: Had the driver ``->probe`` callback while the supplier hasn't started to probe yet: Had the core known about the device link earlier, it wouldn't have probed the driver core known about the device link earlier, it wouldn't have probed the consumer in the first place. The onus is thus on the consumer to check consumer in the first place. The onus is thus on the consumer to check presence of the supplier after adding the link, and defer probing on presence of the supplier after adding the link, and defer probing on non-presence. non-presence. [Note that it is valid to create a link from the consumer's ``->probe`` callback while the supplier is still probing, but the consumer must If a device link is added in the ``->probe`` callback of the supplier or know that the supplier is functional already at the link creation time (that is consumer driver, it is typically deleted in its ``->remove`` callback for the case, for instance, if the consumer has just acquired some resources that symmetry. That way, if the driver is compiled as a module, the device would not have been available had the supplier not been functional then).] link is added on module load and orderly deleted on unload. The same restrictions that apply to device link addition (e.g. exclusion of a If a device link with ``DL_FLAG_STATELESS`` set (i.e. a stateless device link) parallel suspend/resume transition) apply equally to deletion. is added in the ``->probe`` callback of the supplier or consumer driver, it is typically deleted in its ``->remove`` callback for symmetry. That way, if the driver is compiled as a module, the device link is added on module load and orderly deleted on unload. The same restrictions that apply to device link addition (e.g. exclusion of a parallel suspend/resume transition) apply equally to deletion. Device links managed by the driver core are deleted automatically by it. Several flags may be specified on device link addition, two of which Several flags may be specified on device link addition, two of which have already been mentioned above: ``DL_FLAG_STATELESS`` to express that no have already been mentioned above: ``DL_FLAG_STATELESS`` to express that no Loading @@ -83,22 +89,37 @@ link is added from the consumer's ``->probe`` callback: ``DL_FLAG_RPM_ACTIVE`` can be specified to runtime resume the supplier upon addition of the can be specified to runtime resume the supplier upon addition of the device link. ``DL_FLAG_AUTOREMOVE_CONSUMER`` causes the device link to be device link. ``DL_FLAG_AUTOREMOVE_CONSUMER`` causes the device link to be automatically purged when the consumer fails to probe or later unbinds. automatically purged when the consumer fails to probe or later unbinds. This obviates the need to explicitly delete the link in the ``->remove`` callback or in the error path of the ``->probe`` callback. Similarly, when the device link is added from supplier's ``->probe`` callback, Similarly, when the device link is added from supplier's ``->probe`` callback, ``DL_FLAG_AUTOREMOVE_SUPPLIER`` causes the device link to be automatically ``DL_FLAG_AUTOREMOVE_SUPPLIER`` causes the device link to be automatically purged when the supplier fails to probe or later unbinds. purged when the supplier fails to probe or later unbinds. If neither ``DL_FLAG_AUTOREMOVE_CONSUMER`` nor ``DL_FLAG_AUTOREMOVE_SUPPLIER`` is set, ``DL_FLAG_AUTOPROBE_CONSUMER`` can be used to request the driver core to probe for a driver for the consumer driver on the link automatically after a driver has been bound to the supplier device. Note, however, that any combinations of ``DL_FLAG_AUTOREMOVE_CONSUMER``, ``DL_FLAG_AUTOREMOVE_SUPPLIER`` or ``DL_FLAG_AUTOPROBE_CONSUMER`` with ``DL_FLAG_STATELESS`` are invalid and cannot be used. Limitations Limitations =========== =========== Driver authors should be aware that a driver presence dependency (i.e. when Driver authors should be aware that a driver presence dependency for managed ``DL_FLAG_STATELESS`` is not specified on link addition) may cause probing of device links (i.e. when ``DL_FLAG_STATELESS`` is not specified on link addition) the consumer to be deferred indefinitely. This can become a problem if the may cause probing of the consumer to be deferred indefinitely. This can become consumer is required to probe before a certain initcall level is reached. a problem if the consumer is required to probe before a certain initcall level Worse, if the supplier driver is blacklisted or missing, the consumer will is reached. Worse, if the supplier driver is blacklisted or missing, the never be probed. consumer will never be probed. Moreover, managed device links cannot be deleted directly. They are deleted by the driver core when they are not necessary any more in accordance with the ``DL_FLAG_AUTOREMOVE_CONSUMER`` and ``DL_FLAG_AUTOREMOVE_SUPPLIER`` flags. However, stateless device links (i.e. device links with ``DL_FLAG_STATELESS`` set) are expected to be removed by whoever called :c:func:`device_link_add()` to add them with the help of either :c:func:`device_link_del()` or :c:func:`device_link_remove()`. Sometimes drivers depend on optional resources. They are able to operate Sometimes drivers depend on optional resources. They are able to operate in a degraded mode (reduced feature set or performance) when those resources in a degraded mode (reduced feature set or performance) when those resources Loading Loading @@ -283,4 +304,4 @@ API === === .. kernel-doc:: drivers/base/core.c .. kernel-doc:: drivers/base/core.c :functions: device_link_add device_link_del :functions: device_link_add device_link_del device_link_remove
Documentation/filesystems/porting +7 −0 Original line number Original line Diff line number Diff line Loading @@ -627,3 +627,10 @@ in your dentry operations instead. DCACHE_RCUACCESS is gone; having an RCU delay on dentry freeing is the DCACHE_RCUACCESS is gone; having an RCU delay on dentry freeing is the default. DCACHE_NORCU opts out, and only d_alloc_pseudo() has any default. DCACHE_NORCU opts out, and only d_alloc_pseudo() has any business doing so. business doing so. -- [mandatory] [should've been added in 2016] stale comment in finish_open() nonwithstanding, failure exits in ->atomic_open() instances should *NOT* fput() the file, no matter what. Everything is handled by the caller.
Documentation/usb/raw-gadget.rst 0 → 100644 +61 −0 Original line number Original line Diff line number Diff line ============== USB Raw Gadget ============== USB Raw Gadget is a kernel module that provides a userspace interface for the USB Gadget subsystem. Essentially it allows to emulate USB devices from userspace. Enabled with CONFIG_USB_RAW_GADGET. Raw Gadget is currently a strictly debugging feature and shouldn't be used in production, use GadgetFS instead. Comparison to GadgetFS ~~~~~~~~~~~~~~~~~~~~~~ Raw Gadget is similar to GadgetFS, but provides a more low-level and direct access to the USB Gadget layer for the userspace. The key differences are: 1. Every USB request is passed to the userspace to get a response, while GadgetFS responds to some USB requests internally based on the provided descriptors. However note, that the UDC driver might respond to some requests on its own and never forward them to the Gadget layer. 2. GadgetFS performs some sanity checks on the provided USB descriptors, while Raw Gadget allows you to provide arbitrary data as responses to USB requests. 3. Raw Gadget provides a way to select a UDC device/driver to bind to, while GadgetFS currently binds to the first available UDC. 4. Raw Gadget uses predictable endpoint names (handles) across different UDCs (as long as UDCs have enough endpoints of each required transfer type). 5. Raw Gadget has ioctl-based interface instead of a filesystem-based one. Userspace interface ~~~~~~~~~~~~~~~~~~~ To create a Raw Gadget instance open /dev/raw-gadget. Multiple raw-gadget instances (bound to different UDCs) can be used at the same time. The interaction with the opened file happens through the ioctl() calls, see comments in include/uapi/linux/usb/raw_gadget.h for details. The typical usage of Raw Gadget looks like: 1. Open Raw Gadget instance via /dev/raw-gadget. 2. Initialize the instance via USB_RAW_IOCTL_INIT. 3. Launch the instance with USB_RAW_IOCTL_RUN. 4. In a loop issue USB_RAW_IOCTL_EVENT_FETCH calls to receive events from Raw Gadget and react to those depending on what kind of USB device needs to be emulated. Potential future improvements ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Implement ioctl's for setting/clearing halt status on endpoints. - Reporting more events (suspend, resume, etc.) through USB_RAW_IOCTL_EVENT_FETCH. - Support O_NONBLOCK I/O.
Makefile +2 −2 Original line number Original line Diff line number Diff line # SPDX-License-Identifier: GPL-2.0 # SPDX-License-Identifier: GPL-2.0 VERSION = 4 VERSION = 4 PATCHLEVEL = 19 PATCHLEVEL = 19 SUBLEVEL = 110 SUBLEVEL = 113 EXTRAVERSION = EXTRAVERSION = NAME = "People's Front" NAME = "People's Front" Loading Loading @@ -853,7 +853,7 @@ LD_FLAGS_LTO_CLANG := -mllvm -import-instr-limit=5 KBUILD_LDFLAGS += $(LD_FLAGS_LTO_CLANG) KBUILD_LDFLAGS += $(LD_FLAGS_LTO_CLANG) KBUILD_LDFLAGS_MODULE += $(LD_FLAGS_LTO_CLANG) KBUILD_LDFLAGS_MODULE += $(LD_FLAGS_LTO_CLANG) KBUILD_LDS_MODULE += $(srctree)/scripts/module-lto.lds KBUILD_LDFLAGS_MODULE += -T $(srctree)/scripts/module-lto.lds # allow disabling only clang LTO where needed # allow disabling only clang LTO where needed DISABLE_LTO_CLANG := -fno-lto DISABLE_LTO_CLANG := -fno-lto Loading
