From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B4AC9DF76 for ; Sun, 28 Dec 2025 18:23:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766946204; cv=none; b=oWWD8gI661BfE8GKvLyzY8Kji4oC+lLTIqbQ4sArA4+K3dmDmycwaairTay0IDZa8H+NVpGd0Mzhcxj2CPIVTpbnF2pBfzxSjz9QMEMgmY/qxjkFx1bg4cmrF2Rnwg+el/UZiXW99i1Ig+Knx8AWIfQhhP5aGWOzgACoSzNVSAE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766946204; c=relaxed/simple; bh=GNdsGhLWAjPtHybVUZwNwUls+lSmwION9C+FutEVaAI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=YrKU21RWqWlrycxQGCOhIzWAJcOCpF4nqma8RfJlDkD1+9hrDSqavEthEec4lvQfv5f23kzdphhv5jrazQNbgpCOk/qRB6njZ3mj2ZcO743iiJWROBOKtwb4O6syxXqeJX0aFdeq3bvKE+J1K67TtZtDW/ewqLSPpA0KQUoD+PM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=AMSqfDnt; arc=none smtp.client-ip=209.85.210.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AMSqfDnt" Received: by mail-pf1-f182.google.com with SMTP id d2e1a72fcca58-7b852bb31d9so9978420b3a.0 for ; Sun, 28 Dec 2025 10:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766946202; x=1767551002; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=QeDSdNZFPeVa6HDvCoOYO+9p7A0DV8ybWdKjNHOp+qw=; b=AMSqfDntx3g7C/lkR7ohfvpLOE83iJS33XKuRvNS2GZBWlnrNpqZk1qC5FxzVZ/XLB +GHWfsOa1cqXhBe7ZsN+Rtl+6Tw1urosXFNYH6B6FBL9rlTb0ZU+UH8rHcmXQ1BSlUw4 x8R8fLe4LRs54/eU9NE+Op6yxk7QZvi4WEfDsHAnJwBw1EvDSj7e0F7q0nypM/8Coae7 9uNO21t4l5f7NLZU7278ccRplsMQSSKTiqijn9dZKpM8si18hQaMY2LXvKj3yFsg4s6a CnAov95MQtreSpUtGAeyfro9gSROprt2dZ5duxUQ3sWAwClgnZDsTXoApkvBgnd0kqbv 4+KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766946202; x=1767551002; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QeDSdNZFPeVa6HDvCoOYO+9p7A0DV8ybWdKjNHOp+qw=; b=wi0ap1hNLVkjtFObMQ6KicoROgI5AUxg+XKc1T4R2ekF+WQA0xmq7aKNSH6MXVBps7 yM4go1nEPa/bHj0nVujlHXvKGQpBZfP2OA9iXWF2bnsBXUVy6B800JXJLDcRoHBoQ29F 4wtVvPBOUnNywOqQY7hKXvPnUhM3DOGQ3+5GgTcFGliTRdhu9ej3DBhxn0Bm4bHx9lsx jwC1SRxnkcLh60pDeH2jQdXrkN0o7d72Z9F9LTNoluX+UUsE6Q7RHIGdRA3RfO6rjtbM Vq5BkrS32/KwdKxXs6y8BEbeXUZ1GnF2yMS69mXrICNdKjfV8LylVt+vhkNukEDSBr87 tLBQ== X-Forwarded-Encrypted: i=1; AJvYcCWFql4BsAjhCKYqJqmrYg7kJ3Hi35Uk9kAmZ1BBbeVJPld+PNU8ZmMaH6Q4W/5SLDZ2DUE7t4rXdHSZFM8=@vger.kernel.org X-Gm-Message-State: AOJu0YwM/NFdSbl/o495bVVFNlj9aJyfoQwuAJQgeoa62Ya6h2JjYyrU //kpH9fy2kzZDpUE3SbuyOXsk92YD9FHGfq8pn1NNfTgcpej12NIF43Y X-Gm-Gg: AY/fxX4hFnvKX9FnimzfvdHMt9YmI3k5QDk68AcKYL3n7FWc4LIZkgY5wY+HkxzCXym UUGwuy/X5hYtp4G3SwIbv7ZTkI+IOZUP2F//LXWvhzqhTEhsfoUFc4ihBlF5BPnTppxrYiHOjpm aIJejD3dSDPHvivoFi2dEjsZPC07L+jTopFuwmpQax6chd+cfKRDsezbkGRuCR7WzlRKe7Zjqjg gWhTn030Xney8S7mruGGO+MKfTDLKil+X4/FgQytAYO/zOGGXmhy2eHl8+BsNkYgXanF01VzMCr krK9N+AL1i0B4BFQq9JKYy6m2sEC8wrx1ASb5gAPv0ocHP+ad7SEhaK3lhm/JmpAh8JbW4KeS1t l4YFbwRD5voVGCCGv9DOLAlvZALNvzmsyjeOuV0Q3DmgpEAAOFoYPmjPHoECuMUrASBrBSEJfpA wT/nrQlOsFGXhT5nzX3i7BRO+wsPKHTUU1JTbh1zY4AOI= X-Google-Smtp-Source: AGHT+IFKng9YDxqymUd0O4EhoC70dKkY7AKl9HVF4EIAvoDTwUAlP6lo1Cv0UYS8JhxRaysQ/FVv4g== X-Received: by 2002:a05:6a00:278b:b0:782:7052:5167 with SMTP id d2e1a72fcca58-7ff650c7fe1mr26251152b3a.6.1766946201986; Sun, 28 Dec 2025 10:23:21 -0800 (PST) Received: from MRSPARKLE.localdomain ([150.228.155.85]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7ff7e48f3d7sm27399695b3a.51.2025.12.28.10.23.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Dec 2025 10:23:21 -0800 (PST) From: Jonathan Brophy To: lee Jones , Pavel Machek , Andriy Shevencho , Jonathan Brophy , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Radoslav Tsvetkov Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org Subject: [RFC PATCH 0/2] leds: Add optional instance identifier for deterministic naming Date: Mon, 29 Dec 2025 07:22:43 +1300 Message-ID: <20251228182252.1550173-1-professorjonny98@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=y Content-Transfer-Encoding: 8bit From: Jonathan Brophy This patch series introduces an optional "led-instance" device tree property to address non-deterministic LED naming when multiple LEDs share the same function and color. Currently, the LED core appends numerical suffixes (_1, _2, etc.) based on registration order when duplicate function:color combinations exist. This creates several problems: 1. **Non-deterministic naming**: Registration order determines suffix values, which can change across boots due to probe ordering, async initialization, or module load order. 2. **Non-semantic identifiers**: Names like "lan:green_23" provide no indication of which physical LED or subsystem they represent. 3. **Breaks userspace automation**: Network management tools, LED control daemons, and hardware monitoring cannot reliably identify LEDs. 4. **Ambiguous numbering**: "lan:green_23" could be mistaken for LAN port 23 when it may actually be the 23rd registered LED of any port. 5. **Namespace pollution**: The alternative of adding vendor-specific function names (LED_FUNCTION_LAN_PORT0, LED_FUNCTION_LAN_PORT1...) pollutes the function namespace. The instance identifier keeps standard functions clean while allowing contextual differentiation. 6. **Breaks naming convention**: The _1, _2 suffix was intended only as a collision avoidance workaround, but has become the de facto standard for hardware with multiple identical LEDs. **Example: 48-port network switch** Current behavior (non-deterministic): /sys/class/leds/lan:green ← Port 0? Unknown /sys/class/leds/lan:green_1 ← Could be any port /sys/class/leds/lan:green_2 ← Could be any port ... /sys/class/leds/lan:green_47 ← Could be port 1 due to probe order Proposed behavior (deterministic): /sys/class/leds/lan:green:port0 ← Always port 0 /sys/class/leds/lan:green:port1 ← Always port 1 /sys/class/leds/lan:green:port2 ← Always port 2 ... /sys/class/leds/lan:green:port47 ← Always port 47 **Example: Multi-domain power indicators** Current behavior (non-deterministic): /sys/class/leds/power:red ← Which power source? /sys/class/leds/power:red_1 ← Which power source? /sys/class/leds/power:red_2 ← Which power source? Proposed behavior (deterministic): /sys/class/leds/power:red:mains ← Mains power indicator /sys/class/leds/power:red:battery ← Battery power indicator /sys/class/leds/power:red:usb ← USB power indicator **Design principles:** - Backward compatible: Instance identifier is optional - Extends existing convention: function:color becomes function:color:instance - Follows kernel precedent: Similar to eth0/eth1, gpio0/gpio1 naming patterns - Ignored with deprecated "label" property: Avoids conflicts with legacy code **Alternative solutions considered:** 1. function-enumerator: Only supports numbers (0, 1, 2), producing names like "lan:green-0" which are still non-semantic. The 48-port switch needs "port0" to match physical port labels. 2. Deprecated "label" property: Being actively removed from LED bindings. New code should not rely on deprecated APIs. 3. Different function names: LED_FUNCTION_LAN_PORT0, LED_FUNCTION_LAN_PORT1... This pollutes the function namespace with hardware-specific combinations. This RFC seeks feedback on: - Property naming: "led-instance" vs "led-subsystem" vs "led-context" - Implementation approach - Additional use cases to document Jonathan Brophy (2): leds: core: Add support for led-instance property dt-bindings: leds: common: Add led-instance property .../devicetree/bindings/leds/common.yaml | 93 +++++++++++++++++++ drivers/leds/led-core.c | 43 +++++++-- 2 files changed, 126 insertions(+), 10 deletions(-) -- 2.43.0