Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp2748139rwb; Sat, 8 Oct 2022 13:35:14 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6gSNrDJenCBRUbXPir6hEymqm7cUDjot/+XNUw5bxBicsH7O7NeVio0xXgMNwRadOjdSx7 X-Received: by 2002:a17:902:f708:b0:178:9b70:310b with SMTP id h8-20020a170902f70800b001789b70310bmr10788677plo.65.1665261314364; Sat, 08 Oct 2022 13:35:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665261314; cv=none; d=google.com; s=arc-20160816; b=EDD+GqFx+nHKHCISM0EiPKYuwzaB4IvtMhY8BbECSr+qk5Gmf+FkFxDxVb6vx2+2Vi FCFJznsDpx/+np9YnX2OK5zrTZj8EDNop5rbK3/7M2X+QHwHSuaHFC8u83QBnd3T71Pn 94gMOXHfGedEtEX6y1X1/ZlYb31s0+nl5CdUsH1zmP+ROfJ63xgZw7LPH01AH3qxxawM +yNqmCbahCF88U8qaWBcPwHVkaXeN+XaDG0i6XvxES62eOdnmfRRAzmdvjYlz6inumOu zSfCjMsm8qdVlGz0xLa0fxzWj1wiHHEb6Ud2BL7tC1LicnrPLXE5tOMzcaXPffcWWJIt At6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=kv5pLuppf3Jboc0nPEbTk92/XrIUrH3iSpM0s9qu3m0=; b=UBpwDNMRUnxMcMVQzSb8c+u5Jt8+4umLlN0zzLep4Ez/4TTON4EkOK5OcdKL3PeT/d XOYIyw+RsWtohOMmLtFEKSP0ZWmQW9GW+9XvOykRLGkWkZJH5Watm/JQ8VTrno0e5Jtt hEuTeAXNU1/1gOr+u21lzOEWGUyriXVbdccGbQmnuRurhcz+GP61VOAlqmRePpETjPbq eVNYhtHBmTIXGvKX4/QkYmwA4ouw6n8B7AaAUy0oLuZKnuf00QaNkZnDfcDDt7X9SgaU 8KJSD1K3O8CCHHS+Q1qdAwfynPomJDMIEgEEaQ63dUllQcSBNQ7ZhaWw4B3+7RUwIEdx ertg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="IU+04/yS"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g22-20020a17090a579600b001fb1bec57casi11087155pji.61.2022.10.08.13.35.02; Sat, 08 Oct 2022 13:35:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="IU+04/yS"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229938AbiJHTrT (ORCPT + 99 others); Sat, 8 Oct 2022 15:47:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229946AbiJHTrQ (ORCPT ); Sat, 8 Oct 2022 15:47:16 -0400 Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AFB3232DA5; Sat, 8 Oct 2022 12:47:10 -0700 (PDT) Received: by mail-oo1-xc29.google.com with SMTP id c13-20020a4ac30d000000b0047663e3e16bso5625904ooq.6; Sat, 08 Oct 2022 12:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=kv5pLuppf3Jboc0nPEbTk92/XrIUrH3iSpM0s9qu3m0=; b=IU+04/ySviKMflRZiRVJnIMoc/T9kNnNSAGeaHf75cIRXIxnFD7K6AOs+48p9y1s9d wlorjnHW3qzpoGnnHBYW33w0ONsdsWqyf9ieYvQYcLQeDLq/KQzh08WUmmgv8RMIrann K6tnfcK+e3QzeToLoKWhVr/jzgpraFNoYIxArqKOXZLwib/l4oC9l7Pve6Wa+XZdlpT8 sbunuOomDRz8dy4jkKOfmop2DxOu2DDYJ4A7MV4NOETymc1HWcbz19RyFeHf6IIFises v037l+WRGvmafdakxH38Ft6atk8SWGdW5bjJzDlfA5QukLLpNfZB2GgsImk9TudUtmM/ mIIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kv5pLuppf3Jboc0nPEbTk92/XrIUrH3iSpM0s9qu3m0=; b=BTzDP41Qxmtx67YTt+HBizLGlSMN7S3uoHHMAyNxhR3aNCw4AKuYEQ/PnaWLFoXZ+M 5qTAcG2wIGx5EJIeMO0A7IRqoayj1iEmaCzZacAmLlH2ZkMeJnlBJQELHVWIapOu+Gy+ r4cEdMYOVYcXSFgwX9hHRnY+XmCXJ2sK5pB2Akf3AG5fGHe1aLJGvpeJcYf/KN2KcQY0 5KLP/ox2GjbtOcY9VKh2wBszqaTE8bA9pDp5q+96ClO/dKUBnLThAG8CSIYSYhPFXtcp Y5gIodUkdBDLl0P5rgGrcYyoAk0p0o/b7bgKecB+ZD3q31fjF7ucTBQaSnQYJtk44734 i3Gg== X-Gm-Message-State: ACrzQf0hgkQPnhs7GkqxTAY7oHY5Cr/YXmiDvevsGtXai8omko/1Fi5i l+YK7S58mmUPVWasTKDCzbg= X-Received: by 2002:a9d:6405:0:b0:661:481:783b with SMTP id h5-20020a9d6405000000b006610481783bmr4814851otl.273.1665258429563; Sat, 08 Oct 2022 12:47:09 -0700 (PDT) Received: from ian.penurio.us ([47.184.52.85]) by smtp.gmail.com with ESMTPSA id y16-20020a9d4610000000b00656039161b1sm2976854ote.40.2022.10.08.12.47.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Oct 2022 12:47:09 -0700 (PDT) From: Ian Pilcher To: pavel@ucw.cz Cc: linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org, kabel@kernel.org Subject: [RESEND PATCH v12 1/2] docs: Add block device (blkdev) LED trigger documentation Date: Sat, 8 Oct 2022 14:47:06 -0500 Message-Id: <20221008194707.370805-2-arequipeno@gmail.com> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20221008194707.370805-1-arequipeno@gmail.com> References: <20221008194707.370805-1-arequipeno@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Add Documentation/ABI/testing/sysfs-class-led-trigger-blkdev to document: * /sys/class/leds//blink_time * /sys/class/leds//check_interval * /sys/class/leds//blink_on_{read,write,discard,flush} * /sys/class/leds//link_dev_by_path * /sys/class/leds//unlink_dev_by_path * /sys/class/leds//unlink_dev_by_name * /sys/class/leds//linked_devices Add /sys/block//linked_leds to Documentation/ABI/stable/sysfs-block. Add overview in Documentation/leds/ledtrig-blkdev.rst. Signed-off-by: Ian Pilcher --- Documentation/ABI/stable/sysfs-block | 10 ++ .../testing/sysfs-class-led-trigger-blkdev | 78 +++++++++ Documentation/leds/index.rst | 1 + Documentation/leds/ledtrig-blkdev.rst | 158 ++++++++++++++++++ 4 files changed, 247 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-blkdev create mode 100644 Documentation/leds/ledtrig-blkdev.rst diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block index cd14ecb3c9a5..853cb2601242 100644 --- a/Documentation/ABI/stable/sysfs-block +++ b/Documentation/ABI/stable/sysfs-block @@ -101,6 +101,16 @@ Description: devices that support receiving integrity metadata. +What: /sys/block//linked_leds +Date: October 2022 +Contact: Ian Pilcher +Description: + Directory that contains symbolic links to all LEDs that + are associated with (linked to) this block device by the + blkdev LED trigger. Only present when at least one LED + is linked. (See Documentation/leds/ledtrig-blkdev.rst.) + + What: /sys/block///alignment_offset Date: April 2009 Contact: Martin K. Petersen diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-blkdev b/Documentation/ABI/testing/sysfs-class-led-trigger-blkdev new file mode 100644 index 000000000000..45275eb0bad3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-blkdev @@ -0,0 +1,78 @@ +What: /sys/class/leds//blink_time +Date: October 2022 +Contact: Ian Pilcher +Description: + Time (in milliseconds) that the LED will be on during a single + "blink". + +What: /sys/class/leds//check_interval +Date: October 2022 +Contact: Ian Pilcher +Description: + Interval (in milliseconds) between checks of the block devices + linked to this LED. The LED will be blinked if the correct type + of activity (see blink_on_{read,write,discard,flush} attributes) + has occurred on any of the linked devices since the previous + check. + +What: /sys/class/leds//blink_on_read +Date: October 2022 +Contact: Ian Pilcher +Description: + Boolean that determines whether the LED will blink in response + to read activity on any of its linked block devices. + +What: /sys/class/leds//blink_on_write +Date: October 2022 +Contact: Ian Pilcher +Description: + Boolean that determines whether the LED will blink in response + to write activity on any of its linked block devices. + +What: /sys/class/leds//blink_on_discard +Date: October 2022 +Contact: Ian Pilcher +Description: + Boolean that determines whether the LED will blink in response + to discard activity on any of its linked block devices. + +What: /sys/class/leds//blink_on_flush +Date: October 2022 +Contact: Ian Pilcher +Description: + Boolean that determines whether the LED will blink in response + to cache flush activity on any of its linked block devices. + +What: /sys/class/leds//link_dev_by_path +Date: October 2022 +Contact: Ian Pilcher +Description: + Associate a block device with this LED by writing the path to + the device special file (e.g. /dev/sda) to this attribute. + Symbolic links are followed. + +What: /sys/class/leds//unlink_dev_by_path +Date: October 2022 +Contact: Ian Pilcher +Description: + Remove the association between this LED and a block device by + writing the path to the device special file (e.g. /dev/sda) to + this attribute. Symbolic links are followed. + +What: /sys/class/leds//unlink_dev_by_name +Date: October 2022 +Contact: Ian Pilcher +Description: + Remove the association between this LED and a block device by + writing the kernel name of the device (e.g. sda) to this + attribute. + +What: /sys/class/leds//linked_devices +Date: October 2022 +Contact: Ian Pilcher +Description: + Directory containing links to all block devices that are + associated with this LED. (Note that the names of the + symbolic links in this directory are *kernel* names, which + may not match the device special file paths written to + link_device and unlink_device.) diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst index e5d63b940045..e3c24e468cbc 100644 --- a/Documentation/leds/index.rst +++ b/Documentation/leds/index.rst @@ -10,6 +10,7 @@ LEDs leds-class leds-class-flash leds-class-multicolor + ledtrig-blkdev ledtrig-oneshot ledtrig-transient ledtrig-usbport diff --git a/Documentation/leds/ledtrig-blkdev.rst b/Documentation/leds/ledtrig-blkdev.rst new file mode 100644 index 000000000000..9ff5b99de451 --- /dev/null +++ b/Documentation/leds/ledtrig-blkdev.rst @@ -0,0 +1,158 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================= +Block Device (blkdev) LED Trigger +================================= + +Available when ``CONFIG_LEDS_TRIGGER_BLKDEV=y`` or +``CONFIG_LEDS_TRIGGER_BLKDEV=m``. + +See also: + +* ``Documentation/ABI/testing/sysfs-class-led-trigger-blkdev`` +* ``Documentation/ABI/stable/sysfs-block`` (``/sys/block//linked_leds``) + +Overview +======== + +.. note:: + The examples below use ```` to refer to the name of a + system-specific LED. If no suitable LED is available on a test + system (in a virtual machine, for example), it is possible to + use a userspace LED. (See ``Documentation/leds/uleds.rst``.) + +Verify that the ``blkdev`` LED trigger is available:: + + # grep blkdev /sys/class/leds//trigger + ... rfkill-none blkdev + +(If the previous command produces no output, you may need to load the trigger +module - ``modprobe ledtrig_blkdev``. If the module is not available, check +the value of ``CONFIG_LEDS_TRIGGER_BLKDEV`` in your kernel configuration.) + +Associate the LED with the ``blkdev`` LED trigger:: + + # echo blkdev > /sys/class/leds//trigger + + # cat /sys/class/leds//trigger + ... rfkill-none [blkdev] + +Note that several new device attributes are available in the +``/sys/class/leds/`` directory. + +* ``link_dev_by_path``, ``unlink_dev_by_path``, and ``unlink_dev_by_name`` are + used to manage the set of block devices associated with this LED. The LED + will blink when activity occurs on any of its linked devices. + +* ``blink_on_read``, ``blink_on_write``, ``blink_on_discard``, and + ``blink_on_flush`` are boolean values that determine whether the LED will + blink when a particular type of activity is detected on one of its linked + block devices. + +* ``blink_time`` is the duration (in milliseconds) of each blink of this LED. + (The minimum value is 10 milliseconds.) + +* ``check_interval`` is the frequency (in milliseconds) with which block devices + linked to this LED will be checked for activity and the LED blinked (if the + correct type of activity has occurred). + +* The ``linked_devices`` directory will contain a symbolic link to every device + that is associated with this LED. + +Link a block device to the LED:: + + # echo /dev/sda > /sys/class/leds//link_dev_by_path + + # ls /sys/class/leds//linked_devices + sda + +(The value written to ``link_dev_by_path`` must be the path of the device +special file, such as ``/dev/sda``, that represents the block device - or the +path of a symbolic link to such a device special file.) + +Activity on the device will now cause the LED to blink. The duration of each +blink (in milliseconds) can be adjusted by setting +``/sys/class/leds//blink_time``. (But see **check_interval and +blink_time** below.) + +Associate a second device with the LED:: + + # echo /dev/sdb > /sys/class/leds//link_dev_by_path + + # ls /sys/class/leds//linked_devices + sda sdb + +When a block device is linked to one or more LEDs, the LEDs are linked from +the device's ``linked_leds`` directory:: + + # ls /sys/class/block/sd{a,b}/linked_leds + /sys/class/block/sda/linked_leds: + + + /sys/class/block/sdb/linked_leds: + + +(The ``linked_leds`` directory only exists when the block device is linked to +at least one LED.) + +``check_interval`` and ``blink_time`` +===================================== + +* By default, linked block devices are checked for activity every 100 + milliseconds. This frequency can be changed for an LED via the + ``/sys/class/leds//check_interval`` attribute. (The minimum value is 25 + milliseconds.) + +* All block devices associated with an LED are checked for activity every + ``check_interval`` milliseconds, and a blink is triggered if the correct type + of activity (as determined by the LED's ``blink_on_*`` attributes) is + detected. The duration of an LED's blink is determined by its ``blink_time`` + attribute. Thus (when the correct type of activity is detected), the LED will + be on for ``blink_time`` milliseconds and off for + ``check_interval - blink_time`` milliseconds. + +* The LED subsystem ignores new blink requests for an LED that is already in + in the process of blinking, so setting a ``blink_time`` greater than or equal + to ``check_interval`` will cause some blinks to be missed. + +* Because of processing times, scheduling latencies, etc., avoiding missed + blinks actually requires a difference of at least a few milliseconds between + the ``blink_time`` and ``check_interval``. The required difference is likely + to vary from system to system. As a reference, a Thecus N5550 NAS requires a + difference of 7 milliseconds (e.g. ``check_interval == 100``, + ``blink_time == 93``). + +* The default values (``check_interval == 100``, ``blink_time == 75``) cause the + LED associated with a continuously active device to blink rapidly. For a more + "always on" effect, increase the ``blink_time`` (but not too much; see the + previous bullet). + +Other Notes +=========== + +* Many (possibly all) types of block devices work with this trigger, including: + + * SCSI (including SATA and USB) hard disk drives and SSDs + * SCSI (including SATA and USB) optical drives + * NVMe SSDs + * SD cards + * loopback block devices (``/dev/loop*``) + * device mapper devices, such as LVM logical volumes + * MD RAID devices + * zRAM compressed RAM-disks + * partitions on block devices that support them + +* The names of the symbolic links in ``/sys/class/leds//linked_devices`` + are **kernel** names, which may not match the paths used for + ``link_dev_by_path`` and ``unlink_dev_by_path``. This is most likely when a + symbolic link is used to refer to the device (as is common with logical + volumes), but it can be true for any device, because nothing prevents the + creation of device special files with arbitrary names (e.g. + ``sudo mknod /foo b 8 0``). + + Kernel names can be used to unlink block devices from LEDs by writing them to + the LED's ``unlink_dev_by_name`` attribute. + +* The ``blkdev`` LED trigger supports many-to-many device/LED associations. + A device can be associated with multiple LEDs, and an LED can be associated + with multiple devices. -- 2.37.3