Loading Documentation/driver-api/usb/power-management.rst +9 −5 Original line number Diff line number Diff line Loading @@ -370,11 +370,15 @@ autosuspend the interface's device. When the usage counter is = 0 then the interface is considered to be idle, and the kernel may autosuspend the device. Drivers need not be concerned about balancing changes to the usage counter; the USB core will undo any remaining "get"s when a driver is unbound from its interface. As a corollary, drivers must not call any of the ``usb_autopm_*`` functions after their ``disconnect`` routine has returned. Drivers must be careful to balance their overall changes to the usage counter. Unbalanced "get"s will remain in effect when a driver is unbound from its interface, preventing the device from going into runtime suspend should the interface be bound to a driver again. On the other hand, drivers are allowed to achieve this balance by calling the ``usb_autopm_*`` functions even after their ``disconnect`` routine has returned -- say from within a work-queue routine -- provided they retain an active reference to the interface (via ``usb_get_intf`` and ``usb_put_intf``). Drivers using the async routines are responsible for their own synchronization and mutual exclusion. Loading Documentation/networking/ip-sysctl.txt +2 −0 Original line number Diff line number Diff line Loading @@ -1337,6 +1337,7 @@ tag - INTEGER Default value is 0. xfrm4_gc_thresh - INTEGER (Obsolete since linux-4.14) The threshold at which we will start garbage collecting for IPv4 destination cache entries. At twice this value the system will refuse new allocations. Loading Loading @@ -1920,6 +1921,7 @@ echo_ignore_all - BOOLEAN Default: 0 xfrm6_gc_thresh - INTEGER (Obsolete since linux-4.14) The threshold at which we will start garbage collecting for IPv6 destination cache entries. At twice this value the system will refuse new allocations. Loading Documentation/networking/netdev-FAQ.rst +1 −1 Original line number Diff line number Diff line Loading @@ -132,7 +132,7 @@ version that should be applied. If there is any doubt, the maintainer will reply and ask what should be done. Q: I made changes to only a few patches in a patch series should I resend only those changed? -------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------- A: No, please resend the entire patch series and make sure you do number your patches such that it is clear this is the latest and greatest set of patches that can be applied. Loading Documentation/virtual/kvm/api.txt +6 −5 Original line number Diff line number Diff line Loading @@ -321,7 +321,7 @@ cpu's hardware control block. 4.8 KVM_GET_DIRTY_LOG (vm ioctl) Capability: basic Architectures: x86 Architectures: all Type: vm ioctl Parameters: struct kvm_dirty_log (in/out) Returns: 0 on success, -1 on error Loading Loading @@ -3810,7 +3810,7 @@ to I/O ports. 4.117 KVM_CLEAR_DIRTY_LOG (vm ioctl) Capability: KVM_CAP_MANUAL_DIRTY_LOG_PROTECT Architectures: x86 Architectures: x86, arm, arm64, mips Type: vm ioctl Parameters: struct kvm_dirty_log (in) Returns: 0 on success, -1 on error Loading @@ -3830,8 +3830,9 @@ The ioctl clears the dirty status of pages in a memory slot, according to the bitmap that is passed in struct kvm_clear_dirty_log's dirty_bitmap field. Bit 0 of the bitmap corresponds to page "first_page" in the memory slot, and num_pages is the size in bits of the input bitmap. Both first_page and num_pages must be a multiple of 64. For each bit that is set in the input bitmap, the corresponding page is marked "clean" first_page must be a multiple of 64; num_pages must also be a multiple of 64 unless first_page + num_pages is the size of the memory slot. For each bit that is set in the input bitmap, the corresponding page is marked "clean" in KVM's dirty bitmap, and dirty tracking is re-enabled for that page (for example via write-protection, or by clearing the dirty bit in a page table entry). Loading Loading @@ -4799,7 +4800,7 @@ and injected exceptions. 7.18 KVM_CAP_MANUAL_DIRTY_LOG_PROTECT Architectures: all Architectures: x86, arm, arm64, mips Parameters: args[0] whether feature should be enabled or not With this capability enabled, KVM_GET_DIRTY_LOG will not automatically Loading MAINTAINERS +2 −1 Original line number Diff line number Diff line Loading @@ -6462,7 +6462,7 @@ S: Maintained F: drivers/media/radio/radio-gemtek* GENERIC GPIO I2C DRIVER M: Haavard Skinnemoen <hskinnemoen@gmail.com> M: Wolfram Sang <wsa+renesas@sang-engineering.com> S: Supported F: drivers/i2c/busses/i2c-gpio.c F: include/linux/platform_data/i2c-gpio.h Loading Loading @@ -12176,6 +12176,7 @@ F: arch/*/kernel/*/*/perf_event*.c F: arch/*/include/asm/perf_event.h F: arch/*/kernel/perf_callchain.c F: arch/*/events/* F: arch/*/events/*/* F: tools/perf/ PERSONALITY HANDLING Loading Loading
Documentation/driver-api/usb/power-management.rst +9 −5 Original line number Diff line number Diff line Loading @@ -370,11 +370,15 @@ autosuspend the interface's device. When the usage counter is = 0 then the interface is considered to be idle, and the kernel may autosuspend the device. Drivers need not be concerned about balancing changes to the usage counter; the USB core will undo any remaining "get"s when a driver is unbound from its interface. As a corollary, drivers must not call any of the ``usb_autopm_*`` functions after their ``disconnect`` routine has returned. Drivers must be careful to balance their overall changes to the usage counter. Unbalanced "get"s will remain in effect when a driver is unbound from its interface, preventing the device from going into runtime suspend should the interface be bound to a driver again. On the other hand, drivers are allowed to achieve this balance by calling the ``usb_autopm_*`` functions even after their ``disconnect`` routine has returned -- say from within a work-queue routine -- provided they retain an active reference to the interface (via ``usb_get_intf`` and ``usb_put_intf``). Drivers using the async routines are responsible for their own synchronization and mutual exclusion. Loading
Documentation/networking/ip-sysctl.txt +2 −0 Original line number Diff line number Diff line Loading @@ -1337,6 +1337,7 @@ tag - INTEGER Default value is 0. xfrm4_gc_thresh - INTEGER (Obsolete since linux-4.14) The threshold at which we will start garbage collecting for IPv4 destination cache entries. At twice this value the system will refuse new allocations. Loading Loading @@ -1920,6 +1921,7 @@ echo_ignore_all - BOOLEAN Default: 0 xfrm6_gc_thresh - INTEGER (Obsolete since linux-4.14) The threshold at which we will start garbage collecting for IPv6 destination cache entries. At twice this value the system will refuse new allocations. Loading
Documentation/networking/netdev-FAQ.rst +1 −1 Original line number Diff line number Diff line Loading @@ -132,7 +132,7 @@ version that should be applied. If there is any doubt, the maintainer will reply and ask what should be done. Q: I made changes to only a few patches in a patch series should I resend only those changed? -------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------- A: No, please resend the entire patch series and make sure you do number your patches such that it is clear this is the latest and greatest set of patches that can be applied. Loading
Documentation/virtual/kvm/api.txt +6 −5 Original line number Diff line number Diff line Loading @@ -321,7 +321,7 @@ cpu's hardware control block. 4.8 KVM_GET_DIRTY_LOG (vm ioctl) Capability: basic Architectures: x86 Architectures: all Type: vm ioctl Parameters: struct kvm_dirty_log (in/out) Returns: 0 on success, -1 on error Loading Loading @@ -3810,7 +3810,7 @@ to I/O ports. 4.117 KVM_CLEAR_DIRTY_LOG (vm ioctl) Capability: KVM_CAP_MANUAL_DIRTY_LOG_PROTECT Architectures: x86 Architectures: x86, arm, arm64, mips Type: vm ioctl Parameters: struct kvm_dirty_log (in) Returns: 0 on success, -1 on error Loading @@ -3830,8 +3830,9 @@ The ioctl clears the dirty status of pages in a memory slot, according to the bitmap that is passed in struct kvm_clear_dirty_log's dirty_bitmap field. Bit 0 of the bitmap corresponds to page "first_page" in the memory slot, and num_pages is the size in bits of the input bitmap. Both first_page and num_pages must be a multiple of 64. For each bit that is set in the input bitmap, the corresponding page is marked "clean" first_page must be a multiple of 64; num_pages must also be a multiple of 64 unless first_page + num_pages is the size of the memory slot. For each bit that is set in the input bitmap, the corresponding page is marked "clean" in KVM's dirty bitmap, and dirty tracking is re-enabled for that page (for example via write-protection, or by clearing the dirty bit in a page table entry). Loading Loading @@ -4799,7 +4800,7 @@ and injected exceptions. 7.18 KVM_CAP_MANUAL_DIRTY_LOG_PROTECT Architectures: all Architectures: x86, arm, arm64, mips Parameters: args[0] whether feature should be enabled or not With this capability enabled, KVM_GET_DIRTY_LOG will not automatically Loading
MAINTAINERS +2 −1 Original line number Diff line number Diff line Loading @@ -6462,7 +6462,7 @@ S: Maintained F: drivers/media/radio/radio-gemtek* GENERIC GPIO I2C DRIVER M: Haavard Skinnemoen <hskinnemoen@gmail.com> M: Wolfram Sang <wsa+renesas@sang-engineering.com> S: Supported F: drivers/i2c/busses/i2c-gpio.c F: include/linux/platform_data/i2c-gpio.h Loading Loading @@ -12176,6 +12176,7 @@ F: arch/*/kernel/*/*/perf_event*.c F: arch/*/include/asm/perf_event.h F: arch/*/kernel/perf_callchain.c F: arch/*/events/* F: arch/*/events/*/* F: tools/perf/ PERSONALITY HANDLING Loading
