02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
22 Jul, 2017
1 commit
-
Many drivers create additional driver-specific device attributes when
binding to the device. To avoid them calling SYSFS API directly, let's
export these helpers.Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
14 Jan, 2017
1 commit
-
This reverts commit 6751667a29d6fd64afb9ce30567ad616b68ed789.
Rob Herring objected to it, and a replacement for it will be added using
debugfs in the future.Cc: Ben Hutchings
Reported-by: Rob Herring
Signed-off-by: Greg Kroah-Hartman
11 Nov, 2016
1 commit
-
It is sometimes useful to know that a device is on the deferred probe
list rather than, say, not having a driver available. Expose this
information to user-space.Signed-off-by: Ben Hutchings
Signed-off-by: Greg Kroah-Hartman
01 Nov, 2016
1 commit
-
Currently, there is a problem with taking functional dependencies
between devices into account.What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
30 Nov, 2015
1 commit
-
It is unsafe [1] if probing of devices will happen during suspend or
hibernation and system behavior will be unpredictable in this case.
So, let's prohibit device's probing in dpm_prepare() and defer their
probing instead. The normal behavior will be restored in
dpm_complete().This patch introduces new DD core APIs:
device_block_probing()
It will disable probing of devices and defer their probes instead.
device_unblock_probing()
It will restore normal behavior and trigger re-probing of deferred
devices.[1] https://lkml.org/lkml/2015/9/11/554
Signed-off-by: Grygorii Strashko
Acked-by: Pavel Machek
Signed-off-by: Rafael J. Wysocki
06 Aug, 2015
2 commits
-
Now device's shutdown sequence is performed in reverse order of their
registration in devices_kset list and this sequence corresponds to the
reverse device's creation order. So, devices_kset data tracks
"parent
Signed-off-by: Grygorii Strashko
Signed-off-by: Greg Kroah-Hartman -
This field refers to the public device struct, not to classes.
Signed-off-by: Tomeu Vizoso
Signed-off-by: Greg Kroah-Hartman
20 May, 2015
1 commit
-
Some devices take a long time when initializing, and not all drivers are
suited to initialize their devices when they are open. For example,
input drivers need to interrogate their devices in order to publish
device's capabilities before userspace will open them. When such drivers
are compiled into kernel they may stall entire kernel initialization.This change allows drivers request for their probe functions to be
called asynchronously during driver and device registration (manual
binding is still synchronous). Because async_schedule is used to perform
asynchronous calls module loading will still wait for the probing to
complete.Note that the end goal is to make the probing asynchronous by default,
so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a temporary
measure that allows us to speed up boot process while we validating and
fixing the rest of the drivers and preparing userspace.This change is based on earlier patch by "Luis R. Rodriguez"
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
28 May, 2014
1 commit
-
Having to allocate memory as part of dev_set_drvdata() is a problem
because that memory may never get freed if the device itself is not
created. So move driver_data back to struct device.This is a partial revert of commit b4028437.
Signed-off-by: Jean Delvare
Signed-off-by: Greg Kroah-Hartman
29 Dec, 2013
1 commit
-
ACPI container devices require special hotplug handling, at least
on some systems, since generally user space needs to carry out
system-specific cleanup before it makes sense to offline devices in
the container. However, the current ACPI hotplug code for containers
first attempts to offline devices in the container and only then it
notifies user space of the container offline.Moreover, after commit 202317a573b2 (ACPI / scan: Add acpi_device
objects for all device nodes in the namespace), ACPI device objects
representing containers are present as long as the ACPI namespace
nodes corresponding to them are present, which may be forever, even
if the container devices are physically detached from the system (the
return values of the corresponding _STA methods change in those
cases, but generally the namespace nodes themselves are still there).
Thus it is useful to introduce entities representing containers that
will go away during container hot-unplug.The goal of this change is to address both the above issues.
The idea is to create a "companion" container system device for each
of the ACPI container device objects during the initial namespace
scan or on a hotplug event making the container present. That system
device will be unregistered on container removal. A new bus type
for container devices is added for this purpose, because device
offline and online operations need to be defined for them. The
online operation is a trivial function that is always successful
and the offline uses a callback pointed to by the container device's
offline member.For ACPI containers that callback simply walks the list of ACPI
device objects right below the container object (its children) and
checks if all of their physical companion devices are offline. If
that's not the case, it returns -EBUSY and the container system
devivce cannot be put offline. Consequently, to put the container
system device offline, it is necessary to put all of the physical
devices depending on its ACPI companion object offline beforehand.Container system devices created for ACPI container objects are
initially online. They are created by the container ACPI scan
handler whose hotplug.demand_offline flag is set. That causes
acpi_scan_hot_remove() to check if the companion container system
device is offline before attempting to remove an ACPI container or
any devices below it. If the check fails, a KOBJ_CHANGE uevent is
emitted for the container system device in question and user space
is expected to offline all devices below the container and the
container itself in response to it. Then, user space can finalize
the removal of the container with the help of its ACPI device
object's eject attribute in sysfs.Tested-by: Yasuaki Ishimatsu
Signed-off-by: Rafael J. Wysocki
Acked-by: Greg Kroah-Hartman
13 Aug, 2013
2 commits
-
attribute groups are much more flexible than just a list of attributes,
due to their support for visibility of the attributes, and binary
attributes. Add drv_groups to struct bus_type which should be used
instead of drv_attrs.drv_attrs will be removed from the structure soon.
Signed-off-by: Greg Kroah-Hartman
-
attribute groups are much more flexible than just a list of attributes,
due to their support for visibility of the attributes, and binary
attributes. Add dev_groups to struct bus_type which should be used
instead of dev_attrs.dev_attrs will be removed from the structure soon.
Signed-off-by: Greg Kroah-Hartman
13 Mar, 2013
1 commit
-
Kay tells me the most appropriate place to expose workqueues to
userland would be /sys/devices/virtual/workqueues/WQ_NAME which is
symlinked to /sys/bus/workqueue/devices/WQ_NAME and that we're lacking
a way to do that outside of driver core as virtual_device_parent()
isn't exported and there's no inteface to conveniently create a
virtual subsystem.This patch implements subsys_virtual_register() by factoring out
subsys_register() from subsys_system_register() and using it with
virtual_device_parent() as the origin directory. It's identical to
subsys_system_register() other than the origin directory but we aren't
gonna restrict the device names which should be used under it.This will be used to expose workqueue attributes to userland.
Signed-off-by: Tejun Heo
Acked-by: Greg Kroah-Hartman
Cc: Kay Sievers
09 Mar, 2012
2 commits
-
Nothing outside of the driver core needs to get to the deferred probe
pointer, so move it inside the private area of 'struct device' so no one
tries to mess around with it.Cc: Grant Likely
Signed-off-by: Greg Kroah-Hartman -
Allow drivers to report at probe time that they cannot get all the resources
required by the device, and should be retried at a later time.This should completely solve the problem of getting devices
initialized in the right order. Right now this is mostly handled by
mucking about with initcall ordering which is a complete hack, and
doesn't even remotely handle the case where device drivers are in
modules. This approach completely sidesteps the issues by allowing
driver registration to occur in any order, and any driver can request
to be retried after a few more other drivers get probed.v4: - Integrate Manjunath's addition of a separate workqueue
- Change -EAGAIN to -EPROBE_DEFER for drivers to trigger deferral
- Update comment blocks to reflect how the code really works
v3: - Hold off workqueue scheduling until late_initcall so that the bulk
of driver probes are complete before we start retrying deferred devices.
- Tested with simple use cases. Still needs more testing though.
Using it to get rid of the gpio early_initcall madness, or to replace
the ASoC internal probe deferral code would be ideal.
v2: - added locking so it should no longer be utterly broken in that regard
- remove device from deferred list at device_del time.
- Still completely untested with any real use case, but has been
boot tested.Signed-off-by: Grant Likely
Cc: Mark Brown
Cc: Arnd Bergmann
Cc: Dilan Lee
Cc: Manjunath GKondaiah
Cc: Alan Stern
Cc: Tony Lindgren
Cc: Alan Cox
Reviewed-by: Mark Brown
Acked-by: David Daney
Reviewed-by: Arnd Bergmann
Signed-off-by: Greg Kroah-Hartman
12 Jan, 2012
1 commit
-
cpu_dev_init() is only called from driver_init(), which does not check
its return value. Therefore make cpu_dev_init() return void.We must register the CPU subsystem, so panic if this fails.
If sched_create_sysfs_power_savings_entries() fails, the damage is
contained, so ignore this (as before).Signed-off-by: Ben Hutchings
Signed-off-by: Linus Torvalds
15 Dec, 2011
1 commit
-
All sysdev classes and sysdev devices will converted to regular devices
and buses to properly hook userspace into the event processing.There is no interesting difference between a 'sysdev' and 'device' which
would justify to roll an entire own subsystem with different userspace
export semantics. Userspace relies on events and generic sysfs subsystem
infrastructure from sysdev devices, which are currently not properly
available.Every converted sysdev class will create a regular device with the class
name in /sys/devices/system and all registered devices will becom a children
of theses devices.For compatibility reasons, the sysdev class-wide attributes are created
at this parent device. (Do not copy that logic for anything new, subsystem-
wide properties belong to the subsystem, not to some fake parent device
created in /sys/devices.)Every sysdev driver is implemented as a simple subsystem interface now,
and no longer called a driver.After all sysdev classes are ported to regular driver core entities, the
sysdev implementation will be entirely removed from the kernel.Signed-off-by: Kay Sievers
Signed-off-by: Greg Kroah-Hartman
01 Nov, 2011
1 commit
-
This file is currently relying on sneaking it in
through the implicit include paths from device.h. Once that
is cleaned up, this will happen:In file included from drivers/base/init.c:12:
drivers/base/base.h:34: error: field ‘bus_notifier’ has incomplete type
make[3]: *** [drivers/base/init.o] Error 1Fix it up in advance, so the cleanup can continue.
Signed-off-by: Paul Gortmaker
12 May, 2011
1 commit
-
Since suspend, resume and shutdown operations in struct sysdev_class
and struct sysdev_driver are not used any more, remove them. Also
drop sysdev_suspend(), sysdev_resume() and sysdev_shutdown() used
for executing those operations and modify all of their users
accordingly. This reduces kernel code size quite a bit and reduces
its complexity.Signed-off-by: Rafael J. Wysocki
Acked-by: Greg Kroah-Hartman
18 Nov, 2010
1 commit
-
As classes and busses are pretty much the same thing, and we want to
merge them together into a 'subsystem' in the future, let us share the
same private data parts to make that merge easier.Signed-off-by: Kay Sievers
Signed-off-by: Greg Kroah-Hartman
16 Sep, 2009
3 commits
-
Devtmpfs lets the kernel create a tmpfs instance called devtmpfs
very early at kernel initialization, before any driver-core device
is registered. Every device with a major/minor will provide a
device node in devtmpfs.Devtmpfs can be changed and altered by userspace at any time,
and in any way needed - just like today's udev-mounted tmpfs.
Unmodified udev versions will run just fine on top of it, and will
recognize an already existing kernel-created device node and use it.
The default node permissions are root:root 0600. Proper permissions
and user/group ownership, meaningful symlinks, all other policy still
needs to be applied by userspace.If a node is created by devtmps, devtmpfs will remove the device node
when the device goes away. If the device node was created by
userspace, or the devtmpfs created node was replaced by userspace, it
will no longer be removed by devtmpfs.If it is requested to auto-mount it, it makes init=/bin/sh work
without any further userspace support. /dev will be fully populated
and dynamic, and always reflect the current device state of the kernel.
With the commonly used dynamic device numbers, it solves the problem
where static devices nodes may point to the wrong devices.It is intended to make the initial bootup logic simpler and more robust,
by de-coupling the creation of the inital environment, to reliably run
userspace processes, from a complex userspace bootstrap logic to provide
a working /dev.Signed-off-by: Kay Sievers
Signed-off-by: Jan Blunck
Tested-By: Harald Hoyer
Tested-By: Scott James Remnant
Signed-off-by: Greg Kroah-Hartman -
No one should directly access the driver_data field, so remove the field
and make it private. We dynamically create the private field now if it
is needed, to handle drivers that call get/set before they are
registered with the driver core.Also update the copyright notices on these files while we are there.
Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
This patch (as1271) affects when new devices get linked into their
bus's list of devices. Currently this happens after probing, and it
doesn't happen at all if probing fails. Clearly this is wrong,
because at that point quite a few symbolic links have already been
created in sysfs. We are committed to adding the device, so it should
be linked into the bus's list regardless.In addition, this needs to happen before the uevent announcing the new
device gets issued. Otherwise user programs might try to access the
device before it has been added to the bus.To fix both these problems, the patch moves the call to
klist_add_tail() forward from bus_attach_device() to bus_add_device().
Since bus_attach_device() now does nothing but probe for drivers, it
has been renamed to bus_probe_device(). And lastly, the kerneldoc is
updated.Signed-off-by: Alan Stern
CC: Kay Sievers
Signed-off-by: Greg Kroah-Hartman
17 Apr, 2009
1 commit
-
This patch fixes a bug introduced in commit
49b420a13ff95b449947181190b08367348e3e1b.If a instance of bus_type doesn't have .match method,
all .probe of drivers in the bus should be called, or else
the .probe have not a chance to be called.Signed-off-by: Ming Lei
Reported-by: Guennadi Liakhovetski
Signed-off-by: Greg Kroah-Hartman
25 Mar, 2009
5 commits
-
Nothing outside of the driver core should ever touch knode_bus, so
move it out of the public eye.Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
Nothing outside of the driver core should ever touch knode_driver, so
move it out of the public eye.Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
Nothing outside of the driver core should ever touch klist_children, or
knode_parent, so move them out of the public eye.Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
This is to be used to move things out of struct device that no code
outside of the driver core should ever touch.Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
This patch moves bus->match out from driver_probe_device and
does not hold device lock to check the match between a device
and a driver.The idea has been verified by the commit 6cd495860901,
which leads to a faster boot. But the commit 6cd495860901 has
the following drawbacks: 1),only does the quick check in
the path of __driver_attach->driver_probe_device, not in other
paths; 2),for a matched device and driver, check the same match
twice. It is a waste of cpu ,especially for some drivers with long
device id table (eg. usb-storage driver).This patch adds a helper of driver_match_device to check the match
in all paths, and testes the match only once.Signed-off-by: Ming Lei
Acked-by: Cornelia Huck
Signed-off-by: Greg Kroah-Hartman
23 Feb, 2009
1 commit
-
Move the sysdev_suspend/resume from the callee to the callers, with
no real change in semantics, so that we can rework the disabling of
interrupts during suspend/hibernation.This is based on an earlier patch from Linus.
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Linus Torvalds
10 Jan, 2009
4 commits
-
This reverts commit 2831fe6f9cc4e16c103504ee09a47a084297c0f3.
Turns out that device_initialize shouldn't fail silently.
This series needs to be reworked in order to get into proper
shape.Reported-by: Stefan Richter
Cc: Alan Cox
Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
This reverts commit 11c3b5c3e08f4d855cbef52883c266b9ab9df879.
Turns out that device_initialize shouldn't fail silently.
This series needs to be reworked in order to get into proper
shape.Reported-by: Stefan Richter
Cc: Alan Cox
Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
This reverts commit 93e746db183b3bdbbda67900f79b5835f9cb388f.
Turns out that device_initialize shouldn't fail silently.
This series needs to be reworked in order to get into proper
shape.Reported-by: Stefan Richter
Cc: Alan Cox
Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
This reverts commit b9daa99ee533578e3f88231e7a16784dcb44ec42.
Turns out that device_initialize shouldn't fail silently.
This series needs to be reworked in order to get into proper
shape.Reported-by: Stefan Richter
Cc: Alan Cox
Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman
07 Jan, 2009
4 commits
-
Nothing outside of the driver core should ever touch knode_bus, so
move it out of the public eye.Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
Nothing outside of the driver core should ever touch knode_driver, so
move it out of the public eye.Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
Nothing outside of the driver core should ever touch klist_children, or
knode_parent, so move them out of the public eye.Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
This is to be used to move things out of struct device that no code
outside of the driver core should ever touch.Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman
09 Oct, 2008
1 commit
-
Iterating over entries using callback usually isn't too fun especially
when the entry being iterated over can't be manipulated freely. This
patch converts class->p->class_devices to klist and implements class
device iterator so that the users can freely build their own control
structure. The users are also free to call back into class code
without worrying about locking.class_for_each_device() and class_find_device() are converted to use
the new iterators, so their users don't have to worry about locking
anymore either.Note: This depends on klist-dont-iterate-over-deleted-entries patch
because class_intf->add/remove_dev() depends on proper synchronization
with device removal.Signed-off-by: Tejun Heo
Cc: Greg Kroah-Hartman
Cc: Jens Axboe
Signed-off-by: Jens Axboe