2017-11-07 16:30:07 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2002-3 Patrick Mochel
|
|
|
|
* Copyright (c) 2002-3 Open Source Development Labs
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/device.h>
|
|
|
|
#include <linux/init.h>
|
2005-10-30 01:16:54 +00:00
|
|
|
#include <linux/memory.h>
|
2015-05-14 14:28:24 +00:00
|
|
|
#include <linux/of.h>
|
2022-06-15 13:22:29 +00:00
|
|
|
#include <linux/backing-dev.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2005-10-13 16:54:41 +00:00
|
|
|
#include "base.h"
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
2008-01-25 06:50:12 +00:00
|
|
|
* driver_init - initialize driver model.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2008-01-25 06:50:12 +00:00
|
|
|
* Call the driver model init functions to initialize their
|
|
|
|
* subsystems. Called early from init/main.c.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
void __init driver_init(void)
|
|
|
|
{
|
|
|
|
/* These are the core pieces */
|
2022-06-15 13:22:29 +00:00
|
|
|
bdi_init(&noop_backing_dev_info);
|
Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev
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 <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Tested-By: Harald Hoyer <harald@redhat.com>
Tested-By: Scott James Remnant <scott@ubuntu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 13:23:42 +00:00
|
|
|
devtmpfs_init();
|
2005-04-16 22:20:36 +00:00
|
|
|
devices_init();
|
|
|
|
buses_init();
|
|
|
|
classes_init();
|
|
|
|
firmware_init();
|
2006-05-09 10:53:49 +00:00
|
|
|
hypervisor_init();
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* These are also core pieces, but must come after the
|
|
|
|
* core core pieces.
|
|
|
|
*/
|
2018-06-21 13:37:37 +00:00
|
|
|
of_core_init();
|
2005-04-16 22:20:36 +00:00
|
|
|
platform_bus_init();
|
2021-02-10 20:16:11 +00:00
|
|
|
auxiliary_bus_init();
|
2005-10-30 01:16:54 +00:00
|
|
|
memory_dev_init();
|
2022-03-22 21:47:13 +00:00
|
|
|
node_dev_init();
|
2023-11-21 13:44:41 +00:00
|
|
|
cpu_dev_init();
|
ACPI / hotplug / driver core: Handle containers in a special way
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 <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-29 14:25:48 +00:00
|
|
|
container_dev_init();
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|