TechPanelGM/kernel_xiaomi_sm8250
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge 4.19.112 into android-4.19

Browse Source 
Changes in 4.19.112
	perf/amd/uncore: Replace manual sampling check with CAP_NO_INTERRUPT flag
	mmc: sdhci-omap: Add platform specific reset callback
	mmc: sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures (i929)
	mmc: host: Fix Kconfig warnings on keystone_defconfig
	ACPI: watchdog: Allow disabling WDAT at boot
	HID: apple: Add support for recent firmware on Magic Keyboards
	HID: i2c-hid: add Trekstor Surfbook E11B to descriptor override
	cfg80211: check reg_rule for NULL in handle_channel_custom()
	scsi: libfc: free response frame from GPN_ID
	net: usb: qmi_wwan: restore mtu min/max values after raw_ip switch
	net: ks8851-ml: Fix IRQ handling and locking
	mac80211: rx: avoid RCU list traversal under mutex
	signal: avoid double atomic counter increments for user accounting
	slip: not call free_netdev before rtnl_unlock in slip_open
	hinic: fix a irq affinity bug
	hinic: fix a bug of setting hw_ioctxt
	net: rmnet: fix NULL pointer dereference in rmnet_newlink()
	net: rmnet: fix NULL pointer dereference in rmnet_changelink()
	net: rmnet: fix suspicious RCU usage
	net: rmnet: remove rcu_read_lock in rmnet_force_unassociate_device()
	net: rmnet: do not allow to change mux id if mux id is duplicated
	net: rmnet: use upper/lower device infrastructure
	net: rmnet: fix bridge mode bugs
	net: rmnet: fix packet forwarding in rmnet bridge mode
	sfc: fix timestamp reconstruction at 16-bit rollover points
	jbd2: fix data races at struct journal_head
	wimax: i2400: fix memory leak
	wimax: i2400: Fix memory leak in i2400m_op_rfkill_sw_toggle
	mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
	mmc: sdhci-omap: Fix Tuning procedure for temperatures < -20C
	driver core: Remove the link if there is no driver with AUTO flag
	driver core: Fix adding device links to probing suppliers
	driver core: Make driver core own stateful device links
	driver core: Add device link flag DL_FLAG_AUTOPROBE_CONSUMER
	driver core: Remove device link creation limitation
	driver core: Fix creation of device links with PM-runtime flags
	net: qrtr: fix len of skb_put_padto in qrtr_node_enqueue
	ARM: 8957/1: VDSO: Match ARMv8 timer in cntvct_functional()
	ARM: 8958/1: rename missed uaccess .fixup section
	mm: slub: add missing TID bump in kmem_cache_alloc_bulk()
	HID: google: add moonball USB id
	efi: Fix debugobjects warning on 'efi_rts_work'
	ipv4: ensure rcu_read_lock() in cipso_v4_error()
	Linux 4.19.112

Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I68bb3ea9d74f698994a1b958d112827a0873a0f7
This commit is contained in:
Greg Kroah-Hartman
2020-03-21 08:37:27 +01:00
parent cbec6a3c0d 14cfdbd39e
commit 417d28a44d
40 changed files with 641 additions and 251 deletions
Download Patch File Download Diff File Expand all files Collapse all files

61
Documentation/driver-api/device_link.rst
View File

@@ -25,8 +25,8 @@ suspend/resume and shutdown ordering.
Device links allow representation of such dependencies in the driver core.
In its standard form, a device link combines *both* dependency types:
It guarantees correct suspend/resume and shutdown ordering between a
In its standard or *managed* form, a device link combines *both* dependency
types: It guarantees correct suspend/resume and shutdown ordering between a
"supplier" device and its "consumer" devices, and it guarantees driver
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
@@ -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
represents a driver presence dependency, yet is added from the consumer's
``->probe`` callback while the supplier hasn't probed yet: Had the driver
core known about the device link earlier, it wouldn't have probed the
``->probe`` callback while the supplier hasn't started to probe yet: Had 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
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
know that the supplier is functional already at the link creation time (that is
the case, for instance, if the consumer has just acquired some resources that
would not have been available had the supplier not been functional then).]
If a device link 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.
If a device link with ``DL_FLAG_STATELESS`` set (i.e. a stateless device link)
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
have already been mentioned above: ``DL_FLAG_STATELESS`` to express that no
@@ -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
device link. ``DL_FLAG_AUTOREMOVE_CONSUMER`` causes the device link to be
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,
``DL_FLAG_AUTOREMOVE_SUPPLIER`` causes the device link to be automatically
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
===========
Driver authors should be aware that a driver presence dependency (i.e. when
``DL_FLAG_STATELESS`` is not specified on link addition) may cause probing of
the consumer to be deferred indefinitely. This can become a problem if the
consumer is required to probe before a certain initcall level is reached.
Worse, if the supplier driver is blacklisted or missing, the consumer will
never be probed.
Driver authors should be aware that a driver presence dependency for managed
device links (i.e. when ``DL_FLAG_STATELESS`` is not specified on link addition)
may cause probing of the consumer to be deferred indefinitely. This can become
a problem if the consumer is required to probe before a certain initcall level
is reached. Worse, if the supplier driver is blacklisted or missing, the
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
in a degraded mode (reduced feature set or performance) when those resources
@@ -283,4 +304,4 @@ API
===
.. kernel-doc:: drivers/base/core.c
:functions: device_link_add device_link_del
:functions: device_link_add device_link_del device_link_remove