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

			The filter can be disabled or changed to another

			driver later using sysfs.

	driver_async_probe=  [KNL]

			List of driver names to be probed asynchronously.

			Format: <driver_name1>,<driver_name2>...

	drm.edid_firmware=[<connector>:]<file>[,[<connector>:]<file>]

			Broken monitors, graphic adapters, KVMs and EDIDless

			panels may send no or incorrect EDID data sets.

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

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.

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.

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 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 with ``DL_FLAG_STATELESS`` unset (i.e. managed

device links) are deleted automatically by the driver core.

Several flags may be specified on device link addition, two of which

have already been mentioned above:  ``DL_FLAG_STATELESS`` to express that no

Two other flags are specifically targeted at use cases where the device

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.

can be specified to runtime resume the supplier and prevent it from suspending

before the consumer is runtime suspended.  ``DL_FLAG_AUTOREMOVE_CONSUMER``

causes the device link to be automatically purged when the consumer fails to

probe or later unbinds.

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()`.

Passing ``DL_FLAG_RPM_ACTIVE`` along with ``DL_FLAG_STATELESS`` to

:c:func:`device_link_add()` may cause the PM-runtime usage counter of the

supplier device to remain nonzero after a subsequent invocation of either

:c:func:`device_link_del()` or :c:func:`device_link_remove()` to remove the

device link returned by it.  This happens if :c:func:`device_link_add()` is

called twice in a row for the same consumer-supplier pair without removing the

link between these calls, in which case allowing the PM-runtime usage counter

of the supplier to drop on an attempt to remove the link may cause it to be

suspended while the consumer is still PM-runtime-active and that has to be

avoided.  [To work around this limitation it is sufficient to let the consumer

runtime suspend at least once, or call :c:func:`pm_runtime_set_suspended()` for

it with PM-runtime disabled, between the :c:func:`device_link_add()` and

:c:func:`device_link_del()` or :c:func:`device_link_remove()` calls.]

Sometimes drivers depend on optional resources.  They are able to operate

in a degraded mode (reduced feature set or performance) when those resources

===

.. kernel-doc:: drivers/base/core.c

   :functions: device_link_add device_link_del

   :functions: device_link_add device_link_del device_link_remove

ifeq ($(KBUILD_EXTMOD),)

# Objects we will link into vmlinux / subdirs we need to visit

init-y		:= init/

drivers-y	:= drivers/ sound/ firmware/

drivers-y	:= drivers/ sound/

net-y		:= net/

libs-y		:= lib/

core-y		:= usr/

	return out;

}

static ssize_t ibmebus_store_probe(struct bus_type *bus,

				   const char *buf, size_t count)

static ssize_t probe_store(struct bus_type *bus, const char *buf, size_t count)

{

	struct device_node *dn = NULL;

	struct device *dev;

		return rc;

	return count;

}

static BUS_ATTR(probe, 0200, NULL, ibmebus_store_probe);

static BUS_ATTR_WO(probe);

static ssize_t ibmebus_store_remove(struct bus_type *bus,

				    const char *buf, size_t count)

static ssize_t remove_store(struct bus_type *bus, const char *buf, size_t count)

{

	struct device *dev;

	char *path;

		return -ENODEV;

	}

}

static BUS_ATTR(remove, 0200, NULL, ibmebus_store_remove);

static BUS_ATTR_WO(remove);

static struct attribute *ibmbus_bus_attrs[] = {

	&bus_attr_probe.attr,

 * @knode_parent - node in sibling list

 * @knode_driver - node in driver list

 * @knode_bus - node in bus list

 * @knode_class - node in class list

 * @deferred_probe - entry in deferred_probe_list which is used to retry the

 *	binding of drivers which were unable to get all the resources needed by

 *	the device; typically because it depends on another driver getting

 *	probed first.

 * @async_driver - pointer to device driver awaiting probe via async_probe

 * @device - pointer back to the struct device that this structure is

 * associated with.

 * @dead - This device is currently either in the process of or has been

 *	removed from the system. Any asynchronous events scheduled for this

 *	device should exit without taking any action.

 *

 * Nothing outside of the driver core should ever touch these fields.

 */

	struct klist_node knode_parent;

	struct klist_node knode_driver;

	struct klist_node knode_bus;

	struct klist_node knode_class;

	struct list_head deferred_probe;

	struct device_driver *async_driver;

	struct device *device;

	u8 dead:1;

};

#define to_device_private_parent(obj)	\

	container_of(obj, struct device_private, knode_parent)

	container_of(obj, struct device_private, knode_driver)

#define to_device_private_bus(obj)	\

	container_of(obj, struct device_private, knode_bus)

#define to_device_private_class(obj)	\

	container_of(obj, struct device_private, knode_class)

/* initialisation functions */

extern int devices_init(void);

			     const struct attribute_group **groups);

extern void driver_remove_groups(struct device_driver *drv,

				 const struct attribute_group **groups);

int device_driver_attach(struct device_driver *drv, struct device *dev);

void device_driver_detach(struct device *dev);

extern char *make_class_name(const char *name, struct kobject *kobj);