Merge branch 'linus' into sched/core (8e9255e6) · Commits · e / devices / android_kernel_teracube_emerald

Documentation/ABI/testing/sysfs-bus-rbd

0 → 100644

+83 −0

Original line number	Original line	Diff line number	Diff line
			What: /sys/bus/rbd/
			Date: November 2010
			Contact: Yehuda Sadeh <yehuda@hq.newdream.net>,
			Sage Weil <sage@newdream.net>
			Description:

			Being used for adding and removing rbd block devices.

			Usage: <mon ip addr> <options> <pool name> <rbd image name> [snap name]

			$ echo "192.168.0.1 name=admin rbd foo" > /sys/bus/rbd/add

			The snapshot name can be "-" or omitted to map the image read/write. A <dev-id>
			will be assigned for any registered block device. If snapshot is used, it will
			be mapped read-only.

			Removal of a device:

			$ echo <dev-id> > /sys/bus/rbd/remove

			Entries under /sys/bus/rbd/devices/<dev-id>/
			--------------------------------------------

			client_id

			The ceph unique client id that was assigned for this specific session.

			major

			The block device major number.

			name

			The name of the rbd image.

			pool

			The pool where this rbd image resides. The pool-name pair is unique
			per rados system.

			size

			The size (in bytes) of the mapped block device.

			refresh

			Writing to this file will reread the image header data and set
			all relevant datastructures accordingly.

			current_snap

			The current snapshot for which the device is mapped.

			create_snap

			Create a snapshot:

			$ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_create

			rollback_snap

			Rolls back data to the specified snapshot. This goes over the entire
			list of rados blocks and sends a rollback command to each.

			$ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_rollback

			snap_*

			A directory per each snapshot


			Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
			-------------------------------------------------------------

			id

			The rados internal snapshot id assigned for this snapshot

			size

			The size of the image when this snapshot was taken.

Documentation/ABI/testing/sysfs-platform-asus-laptop

+15 −1

Original line number	Original line	Diff line number	Diff line
	@@ -47,6 +47,20 @@ Date: January 2007
	KernelVersion: 2.6.20		KernelVersion: 2.6.20
	Contact: "Corentin Chary" <corentincj@iksaif.net>		Contact: "Corentin Chary" <corentincj@iksaif.net>
	Description:		Description:
	Control the bluetooth device. 1 means on, 0 means off.		Control the wlan device. 1 means on, 0 means off.
	This may control the led, the device or both.		This may control the led, the device or both.
	Users: Lapsus		Users: Lapsus

			What: /sys/devices/platform/asus_laptop/wimax
			Date: October 2010
			KernelVersion: 2.6.37
			Contact: "Corentin Chary" <corentincj@iksaif.net>
			Description:
			Control the wimax device. 1 means on, 0 means off.

			What: /sys/devices/platform/asus_laptop/wwan
			Date: October 2010
			KernelVersion: 2.6.37
			Contact: "Corentin Chary" <corentincj@iksaif.net>
			Description:
			Control the wwan (3G) device. 1 means on, 0 means off.

Documentation/ABI/testing/sysfs-platform-eeepc-wmi

0 → 100644

+10 −0

Original line number	Original line	Diff line number	Diff line
			What: /sys/devices/platform/eeepc-wmi/cpufv
			Date: Oct 2010
			KernelVersion: 2.6.37
			Contact: "Corentin Chary" <corentincj@iksaif.net>
			Description:
			Change CPU clock configuration (write-only).
			There are three available clock configuration:
			* 0 -> Super Performance Mode
			* 1 -> High Performance Mode
			* 2 -> Power Saving Mode

Documentation/DocBook/sh.tmpl

+0 −4

Original line number	Original line	Diff line number	Diff line
	@@ -79,10 +79,6 @@
	</sect2>		</sect2>
	</sect1>		</sect1>
	</chapter>		</chapter>
	<chapter id="clk">
	<title>Clock Framework Extensions</title>
	!Iinclude/linux/sh_clk.h
	</chapter>
	<chapter id="mach">		<chapter id="mach">
	<title>Machine Specific Interfaces</title>		<title>Machine Specific Interfaces</title>
	<sect1 id="dreamcast">		<sect1 id="dreamcast">

Documentation/driver-model/interface.txt

deleted100644 → 0

+0 −129

Original line number	Original line	Diff line number	Diff line

	Device Interfaces

	Introduction
	~~~~~~~~~~~~

	Device interfaces are the logical interfaces of device classes that correlate
	directly to userspace interfaces, like device nodes.

	Each device class may have multiple interfaces through which you can
	access the same device. An input device may support the mouse interface,
	the 'evdev' interface, and the touchscreen interface. A SCSI disk would
	support the disk interface, the SCSI generic interface, and possibly a raw
	device interface.

	Device interfaces are registered with the class they belong to. As devices
	are added to the class, they are added to each interface registered with
	the class. The interface is responsible for determining whether the device
	supports the interface or not.


	Programming Interface
	~~~~~~~~~~~~~~~~~~~~~

	struct device_interface {
	char * name;
	rwlock_t lock;
	u32 devnum;
	struct device_class * devclass;

	struct list_head node;
	struct driver_dir_entry dir;

	int (add_device)(struct device );
	int (add_device)(struct intf_data );
	};

	int interface_register(struct device_interface *);
	void interface_unregister(struct device_interface *);


	An interface must specify the device class it belongs to. It is added
	to that class's list of interfaces on registration.


	Interfaces can be added to a device class at any time. Whenever it is
	added, each device in the class is passed to the interface's
	add_device callback. When an interface is removed, each device is
	removed from the interface.


	Devices
	~~~~~~~
	Once a device is added to a device class, it is added to each
	interface that is registered with the device class. The class
	is expected to place a class-specific data structure in
	struct device::class_data. The interface can use that (along with
	other fields of struct device) to determine whether or not the driver
	and/or device support that particular interface.


	Data
	~~~~

	struct intf_data {
	struct list_head node;
	struct device_interface * intf;
	struct device * dev;
	u32 intf_num;
	};

	int interface_add_data(struct interface_data *);

	The interface is responsible for allocating and initializing a struct
	intf_data and calling interface_add_data() to add it to the device's list
	of interfaces it belongs to. This list will be iterated over when the device
	is removed from the class (instead of all possible interfaces for a class).
	This structure should probably be embedded in whatever per-device data
	structure the interface is allocating anyway.

	Devices are enumerated within the interface. This happens in interface_add_data()
	and the enumerated value is stored in the struct intf_data for that device.

	sysfs
	~~~~~
	Each interface is given a directory in the directory of the device
	class it belongs to:

	Interfaces get a directory in the class's directory as well:

	class/
	`-- input
	\|-- devices
	\|-- drivers
	\|-- mouse
	`-- evdev

	When a device is added to the interface, a symlink is created that points
	to the device's directory in the physical hierarchy:

	class/
	`-- input
	\|-- devices
	\| `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/
	\|-- drivers
	\| `-- usb:usb_mouse -> ../../../bus/drivers/usb_mouse/
	\|-- mouse
	\| `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/
	`-- evdev
	`-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/


	Future Plans
	~~~~~~~~~~~~
	A device interface is correlated directly with a userspace interface
	for a device, specifically a device node. For instance, a SCSI disk
	exposes at least two interfaces to userspace: the standard SCSI disk
	interface and the SCSI generic interface. It might also export a raw
	device interface.

	Many interfaces have a major number associated with them and each
	device gets a minor number. Or, multiple interfaces might share one
	major number, and each will receive a range of minor numbers (like in
	the case of input devices).

	These major and minor numbers could be stored in the interface
	structure. Major and minor allocations could happen when the interface
	is registered with the class, or via a helper function.