30 Jul, 2020
1 commit
-
/sys/kernel/debug/devices_deferred property contains list of deferred devices.
This list does not contain reason why the driver deferred probe, the patch
improves it.
The natural place to set the reason is dev_err_probe function introduced
recently, ie. if dev_err_probe will be called with -EPROBE_DEFER instead of
printk the message will be attached to a deferred device and printed when user
reads devices_deferred property.Signed-off-by: Andrzej Hajda
Reviewed-by: Mark Brown
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Andy Shevchenko
Reviewed-by: Rafael J. Wysocki
Link: https://lore.kernel.org/r/20200713144324.23654-3-a.hajda@samsung.com
Signed-off-by: Greg Kroah-Hartman
10 Jul, 2020
1 commit
-
The current deferred probe implementation can mess up suspend/resume
ordering if deferred probe thread is kicked off in parallel with the
main initcall thread (kernel_init thread) [1].For example:
Say device-B is a consumer of device-A.
Initcall thread Deferred probe thread
=============== =====================
1. device-A is added.
2. device-B is added.
3. dpm_list is now [device-A, device-B].
4. driver-A defers probe of device-A.
5. device-A is moved to
end of dpm_list
6. dpm_list is now
[device-B, device-A]
7. driver-B is registereed and probes device-B.
8. dpm_list stays as [device-B, device-A].The reverse order of dpm_list is used for suspend. So in this case
device-A would incorrectly get suspended before device-B.Commit 716a7a259690 ("driver core: fw_devlink: Add support for batching
fwnode parsing") kicked off the deferred probe thread early during boot
to run in parallel with the initcall thread and caused suspend/resume
regressions. This patch removes the parallel run of the deferred probe
thread to avoid the suspend/resume regressions.[1] - https://lore.kernel.org/lkml/CAGETcx8W96KAw-d_siTX4qHB_-7ddk0miYRDQeHE6E0_8qx-6Q@mail.gmail.com/
Fixes: 716a7a259690 ("driver core: fw_devlink: Add support for batching fwnode parsing")
Signed-off-by: Saravana Kannan
Tested-by: Geert Uytterhoeven
Link: https://lore.kernel.org/r/20200701194259.3337652-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman
15 May, 2020
1 commit
-
The amount of time spent parsing fwnodes of devices can become really
high if the devices are added in an non-ideal order. Worst case can be
O(N^2) when N devices are added. But this can be optimized to O(N) by
adding all the devices and then parsing all their fwnodes in one batch.This commit adds fw_devlink_pause() and fw_devlink_resume() to allow
doing this.Signed-off-by: Saravana Kannan
Link: https://lore.kernel.org/r/20200515053500.215929-4-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman
16 Dec, 2019
1 commit
-
The devtmpfs functions do not need to be in device.h as only the driver
core uses them, so move them to the private .h file for the driver core.Cc: "Rafael J. Wysocki"
Cc: Suzuki K Poulose
Cc: Saravana Kannan
Cc: Heikki Krogerus
Link: https://lore.kernel.org/r/20191209193303.1694546-3-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman
12 Dec, 2019
1 commit
-
base.h didn't have any copyright information in it, so update it with
the correct information.Cc: "Rafael J. Wysocki"
Link: https://lore.kernel.org/r/20191209193303.1694546-2-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman
14 Aug, 2019
1 commit
-
This commit applies the consolidated hlist_for_each_entry_rcu() support
for lockdep conditions.Acked-by: Greg Kroah-Hartman
Signed-off-by: Joel Fernandes (Google)
Signed-off-by: Paul E. McKenney
31 Jan, 2019
3 commits
-
Probe devices asynchronously instead of the driver. This results in us
seeing the same behavior if the device is registered before the driver or
after. This way we can avoid serializing the initialization should the
driver not be loaded until after the devices have already been added.The motivation behind this is that if we have a set of devices that
take a significant amount of time to load we can greatly reduce the time to
load by processing them in parallel instead of one at a time. In addition,
each device can exist on a different node so placing a single thread on one
CPU to initialize all of the devices for a given driver can result in poor
performance on a system with multiple nodes.This approach can reduce the time needed to scan SCSI LUNs significantly.
The only way to realize that speedup is by enabling more concurrency which
is what is achieved with this patch.To achieve this it was necessary to add a new member "async_driver" to the
device_private structure to store the driver pointer while we wait on the
deferred probe call.Reviewed-by: Bart Van Assche
Reviewed-by: Dan Williams
Signed-off-by: Alexander Duyck
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
Try to consolidate all of the locking and unlocking of both the parent and
device when attaching or removing a driver from a given device.To do that I first consolidated the lock pattern into two functions
__device_driver_lock and __device_driver_unlock. After doing that I then
created functions specific to attaching and detaching the driver while
acquiring these locks. By doing this I was able to reduce the number of
spots where we touch need_parent_lock from 12 down to 4.This patch should produce no functional changes, it is meant to be a code
clean-up/consolidation only.Reviewed-by: Luis Chamberlain
Reviewed-by: Bart Van Assche
Reviewed-by: Dan Williams
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Alexander Duyck
Signed-off-by: Greg Kroah-Hartman -
Add an additional bit flag to the device_private struct named "dead".
This additional flag provides a guarantee that when a device_del is
executed on a given interface an async worker will not attempt to attach
the driver following the earlier device_del call. Previously this
guarantee was not present and could result in the device_del call
attempting to remove a driver from an interface only to have the async
worker attempt to probe the driver later when it finally completes the
asynchronous probe call.One additional change added was that I pulled the check for dev->driver
out of the __device_attach_driver call and instead placed it in the
__device_attach_async_helper call. This was motivated by the fact that the
only other caller of this, __device_attach, had already taken the
device_lock() and checked for dev->driver. Instead of testing for this
twice in this path it makes more sense to just consolidate the dev->dead
and dev->driver checks together into one set of checks.Reviewed-by: Dan Williams
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Alexander Duyck
Signed-off-by: Greg Kroah-Hartman
18 Jan, 2019
1 commit
-
As the description of struct device_private says, it stores data which
is private to driver core. And it already has similar fields like:
knode_parent, knode_driver, knode_driver and knode_bus. This look it is
more proper to put knode_class together with those fields to make it
private to driver core.This patch move device->knode_class to device_private to make it comply
with code convention.Signed-off-by: Wei Yang
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
16 Jul, 2018
1 commit
-
device_private_init is called only in core.c, extern declare is
unnecessary and make it static.Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Signed-off-by: Shaokun Zhang
Signed-off-by: Greg Kroah-Hartman
24 Apr, 2018
1 commit
-
When bridge and its endpoint is enumerated the devices are added to the
dpm list. Afterward, the bridge defers probe when IOMMU is not ready.
This causes the bridge to be moved to the end of the dpm list when
deferred probe kicks in. The order of the dpm list for bridge and
endpoint is reversed.Add reordering code to move the bridge and its children and consumers to
the end of the pm list so the order for suspend and resume is not altered.
The code also move device and its children and consumers to the tail of
device_kset list if it is registered.Signed-off-by: Toan Le
Signed-off-by: Feng Kan
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Rafael J. Wysocki
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
3 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