diff options
Diffstat (limited to 'Documentation/ABI')
| -rw-r--r-- | Documentation/ABI/README | 2 | ||||
| -rw-r--r-- | Documentation/ABI/testing/sysfs-block | 42 | ||||
| -rw-r--r-- | Documentation/ABI/testing/sysfs-bus-vfio-mdev | 111 | ||||
| -rw-r--r-- | Documentation/ABI/testing/sysfs-class-led | 14 | ||||
| -rw-r--r-- | Documentation/ABI/testing/sysfs-class-remoteproc | 50 | ||||
| -rw-r--r-- | Documentation/ABI/testing/sysfs-kernel-slab | 2 |
6 files changed, 216 insertions, 5 deletions
diff --git a/Documentation/ABI/README b/Documentation/ABI/README index 1fafc4b0753b..3121029dce21 100644 --- a/Documentation/ABI/README +++ b/Documentation/ABI/README @@ -84,4 +84,4 @@ stable: - Kernel-internal symbols. Do not rely on the presence, absence, location, or type of any kernel symbol, either in System.map files or the kernel binary - itself. See Documentation/stable_api_nonsense.txt. + itself. See Documentation/process/stable-api-nonsense.rst. diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block index 71d184dbb70d..2da04ce6aeef 100644 --- a/Documentation/ABI/testing/sysfs-block +++ b/Documentation/ABI/testing/sysfs-block @@ -235,3 +235,45 @@ Description: write_same_max_bytes is 0, write same is not supported by the device. +What: /sys/block/<disk>/queue/write_zeroes_max_bytes +Date: November 2016 +Contact: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> +Description: + Devices that support write zeroes operation in which a + single request can be issued to zero out the range of + contiguous blocks on storage without having any payload + in the request. This can be used to optimize writing zeroes + to the devices. write_zeroes_max_bytes indicates how many + bytes can be written in a single write zeroes command. If + write_zeroes_max_bytes is 0, write zeroes is not supported + by the device. + +What: /sys/block/<disk>/queue/zoned +Date: September 2016 +Contact: Damien Le Moal <damien.lemoal@hgst.com> +Description: + zoned indicates if the device is a zoned block device + and the zone model of the device if it is indeed zoned. + The possible values indicated by zoned are "none" for + regular block devices and "host-aware" or "host-managed" + for zoned block devices. The characteristics of + host-aware and host-managed zoned block devices are + described in the ZBC (Zoned Block Commands) and ZAC + (Zoned Device ATA Command Set) standards. These standards + also define the "drive-managed" zone model. However, + since drive-managed zoned block devices do not support + zone commands, they will be treated as regular block + devices and zoned will report "none". + +What: /sys/block/<disk>/queue/chunk_sectors +Date: September 2016 +Contact: Hannes Reinecke <hare@suse.com> +Description: + chunk_sectors has different meaning depending on the type + of the disk. For a RAID device (dm-raid), chunk_sectors + indicates the size in 512B sectors of the RAID volume + stripe segment. For a zoned block device, either + host-aware or host-managed, chunk_sectors indicates the + size of 512B sectors of the zones of the device, with + the eventual exception of the last zone of the device + which may be smaller. diff --git a/Documentation/ABI/testing/sysfs-bus-vfio-mdev b/Documentation/ABI/testing/sysfs-bus-vfio-mdev new file mode 100644 index 000000000000..452dbe39270e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-vfio-mdev @@ -0,0 +1,111 @@ +What: /sys/.../<device>/mdev_supported_types/ +Date: October 2016 +Contact: Kirti Wankhede <kwankhede@nvidia.com> +Description: + This directory contains list of directories of currently + supported mediated device types and their details for + <device>. Supported type attributes are defined by the + vendor driver who registers with Mediated device framework. + Each supported type is a directory whose name is created + by adding the device driver string as a prefix to the + string provided by the vendor driver. + +What: /sys/.../<device>/mdev_supported_types/<type-id>/ +Date: October 2016 +Contact: Kirti Wankhede <kwankhede@nvidia.com> +Description: + This directory gives details of supported type, like name, + description, available_instances, device_api etc. + 'device_api' and 'available_instances' are mandatory + attributes to be provided by vendor driver. 'name', + 'description' and other vendor driver specific attributes + are optional. + +What: /sys/.../mdev_supported_types/<type-id>/create +Date: October 2016 +Contact: Kirti Wankhede <kwankhede@nvidia.com> +Description: + Writing UUID to this file will create mediated device of + type <type-id> for parent device <device>. This is a + write-only file. + For example: + # echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" > \ + /sys/devices/foo/mdev_supported_types/foo-1/create + +What: /sys/.../mdev_supported_types/<type-id>/devices/ +Date: October 2016 +Contact: Kirti Wankhede <kwankhede@nvidia.com> +Description: + This directory contains symbolic links pointing to mdev + devices sysfs entries which are created of this <type-id>. + +What: /sys/.../mdev_supported_types/<type-id>/available_instances +Date: October 2016 +Contact: Kirti Wankhede <kwankhede@nvidia.com> +Description: + Reading this attribute will show the number of mediated + devices of type <type-id> that can be created. This is a + readonly file. +Users: + Userspace applications interested in creating mediated + device of that type. Userspace application should check + the number of available instances could be created before + creating mediated device of this type. + +What: /sys/.../mdev_supported_types/<type-id>/device_api +Date: October 2016 +Contact: Kirti Wankhede <kwankhede@nvidia.com> +Description: + Reading this attribute will show VFIO device API supported + by this type. For example, "vfio-pci" for a PCI device, + "vfio-platform" for platform device. + +What: /sys/.../mdev_supported_types/<type-id>/name +Date: October 2016 +Contact: Kirti Wankhede <kwankhede@nvidia.com> +Description: + Reading this attribute will show human readable name of the + mediated device that will get created of type <type-id>. + This is optional attribute. For example: "Grid M60-0Q" +Users: + Userspace applications interested in knowing the name of + a particular <type-id> that can help in understanding the + type of mediated device. + +What: /sys/.../mdev_supported_types/<type-id>/description +Date: October 2016 +Contact: Kirti Wankhede <kwankhede@nvidia.com> +Description: + Reading this attribute will show description of the type of + mediated device that will get created of type <type-id>. + This is optional attribute. For example: + "2 heads, 512M FB, 2560x1600 maximum resolution" +Users: + Userspace applications interested in knowing the details of + a particular <type-id> that can help in understanding the + features provided by that type of mediated device. + +What: /sys/.../<device>/<UUID>/ +Date: October 2016 +Contact: Kirti Wankhede <kwankhede@nvidia.com> +Description: + This directory represents device directory of mediated + device. It contains all the attributes related to mediated + device. + +What: /sys/.../<device>/<UUID>/mdev_type +Date: October 2016 +Contact: Kirti Wankhede <kwankhede@nvidia.com> +Description: + This is symbolic link pointing to supported type, <type-id> + directory of which this mediated device is created. + +What: /sys/.../<device>/<UUID>/remove +Date: October 2016 +Contact: Kirti Wankhede <kwankhede@nvidia.com> +Description: + Writing '1' to this file destroys the mediated device. The + vendor driver can fail the remove() callback if that device + is active and the vendor driver doesn't support hot unplug. + Example: + # echo 1 > /sys/bus/mdev/devices/<UUID>/remove diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led index 86ace287d48b..491cdeedc195 100644 --- a/Documentation/ABI/testing/sysfs-class-led +++ b/Documentation/ABI/testing/sysfs-class-led @@ -4,16 +4,24 @@ KernelVersion: 2.6.17 Contact: Richard Purdie <rpurdie@rpsys.net> Description: Set the brightness of the LED. Most LEDs don't - have hardware brightness support so will just be turned on for + have hardware brightness support, so will just be turned on for non-zero brightness settings. The value is between 0 and /sys/class/leds/<led>/max_brightness. + Writing 0 to this file clears active trigger. + + Writing non-zero to this file while trigger is active changes the + top brightness trigger is going to use. + What: /sys/class/leds/<led>/max_brightness Date: March 2006 KernelVersion: 2.6.17 Contact: Richard Purdie <rpurdie@rpsys.net> Description: - Maximum brightness level for this led, default is 255 (LED_FULL). + Maximum brightness level for this LED, default is 255 (LED_FULL). + + If the LED does not support different brightness levels, this + should be 1. What: /sys/class/leds/<led>/trigger Date: March 2006 @@ -21,7 +29,7 @@ KernelVersion: 2.6.17 Contact: Richard Purdie <rpurdie@rpsys.net> Description: Set the trigger for this LED. A trigger is a kernel based source - of led events. + of LED events. You can change triggers in a similar manner to the way an IO scheduler is chosen. Trigger specific parameters can appear in /sys/class/leds/<led> once a given trigger is selected. For diff --git a/Documentation/ABI/testing/sysfs-class-remoteproc b/Documentation/ABI/testing/sysfs-class-remoteproc new file mode 100644 index 000000000000..d188afebc8ba --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-remoteproc @@ -0,0 +1,50 @@ +What: /sys/class/remoteproc/.../firmware +Date: October 2016 +Contact: Matt Redfearn <matt.redfearn@imgtec.com> +Description: Remote processor firmware + + Reports the name of the firmware currently loaded to the + remote processor. + + To change the running firmware, ensure the remote processor is + stopped (using /sys/class/remoteproc/.../state) and write a new filename. + +What: /sys/class/remoteproc/.../state +Date: October 2016 +Contact: Matt Redfearn <matt.redfearn@imgtec.com> +Description: Remote processor state + + Reports the state of the remote processor, which will be one of: + + "offline" + "suspended" + "running" + "crashed" + "invalid" + + "offline" means the remote processor is powered off. + + "suspended" means that the remote processor is suspended and + must be woken to receive messages. + + "running" is the normal state of an available remote processor + + "crashed" indicates that a problem/crash has been detected on + the remote processor. + + "invalid" is returned if the remote processor is in an + unknown state. + + Writing this file controls the state of the remote processor. + The following states can be written: + + "start" + "stop" + + Writing "start" will attempt to start the processor running the + firmware indicated by, or written to, + /sys/class/remoteproc/.../firmware. The remote processor should + transition to "running" state. + + Writing "stop" will attempt to halt the remote processor and + return it to the "offline" state. diff --git a/Documentation/ABI/testing/sysfs-kernel-slab b/Documentation/ABI/testing/sysfs-kernel-slab index 91bd6ca5440f..2cc0a72b64be 100644 --- a/Documentation/ABI/testing/sysfs-kernel-slab +++ b/Documentation/ABI/testing/sysfs-kernel-slab @@ -347,7 +347,7 @@ Description: because of fragmentation, SLUB will retry with the minimum order possible depending on its characteristics. When debug_guardpage_minorder=N (N > 0) parameter is specified - (see Documentation/kernel-parameters.txt), the minimum possible + (see Documentation/admin-guide/kernel-parameters.rst), the minimum possible order is used and this sysfs entry can not be used to change the order at run time. |