From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D218B324B38; Mon, 29 Dec 2025 14:45:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767019509; cv=none; b=FeZjMUSFYfKdyMZPbogm2xDa8A+jruCP5X8U1NNE2QKQ6aPmV2IX+jnU77boMsWnqiXyKKOnQr5n4NWDY4ANGjwCUOdypA8dD5t26d1jqCIxbKNvHOb4OvY6WUDT7YzhZSpvAS0XWCG6CgAw4j7witNgRXIWocOHRgTwS9RuYv4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767019509; c=relaxed/simple; bh=J1uHplXdrwr0inBDFFyAjDkgJWCZiDHYzKQAZA2t/gw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nWXVagl2D5yNlcXzG68tT1K5kjrgwzBNg8DzGZJBk4fnQs4AAompfj/z7Mz98bDtQzFEp8SayTp58TXWSTHGZ4U0m2sStoLOmwUqqSCSdjVIdB84dlHYR5+o1/f1jpaBKVqZzzfN34b1o9Zpg39LYTPhLqZDSVFAl7l7QPSyh8s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=AE81mOhY; arc=none smtp.client-ip=192.198.163.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="AE81mOhY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1767019508; x=1798555508; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=J1uHplXdrwr0inBDFFyAjDkgJWCZiDHYzKQAZA2t/gw=; b=AE81mOhYMPuRbhlJUo81TmR4EerFa/yy7e95gkmquaCO0ICziMVyGw/8 atY370CuJxaHGvS/IIgrIqLgXdn/sf9jFXxtdFsNLPedpwp00ptDy5Yps cezFpH4sjr0M2NBtfSTNTIc5epiVCjNNalsLnY7dDtq/FsV7foinfSlCJ IfKDniIegKBr6PnvM9DD0JtN7oQ26AjS5X1QvOKx0OITF6e58hVElPHCj RVe3wUGC2LcE3v6O63S2jmeY6u3XBUGQLk03sc8UiLUt2s5UrNY6/KSZa htNAxIndmOiOFK27LVwFBZO4q7vsaIQE59cbHR8P9vyy2VhL2tt92UoND g==; X-CSE-ConnectionGUID: VUKnLocQRNyyo4CvGo7zZg== X-CSE-MsgGUID: M5DV3VqqSxKFy/rEbmHcXQ== X-IronPort-AV: E=McAfee;i="6800,10657,11656"; a="79993352" X-IronPort-AV: E=Sophos;i="6.21,186,1763452800"; d="scan'208";a="79993352" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Dec 2025 06:45:06 -0800 X-CSE-ConnectionGUID: ickCDvqaQrCyZLss4i0Zpw== X-CSE-MsgGUID: EuQByldwR8WsDY8IrD4ivg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,186,1763452800"; d="scan'208";a="200932638" Received: from kniemiec-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.245.31]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Dec 2025 06:45:03 -0800 Date: Mon, 29 Dec 2025 16:45:00 +0200 From: Andriy Shevencho To: Jacek Anaszewski Cc: Jonathan Brophy , lee Jones , Pavel Machek , Jonathan Brophy , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Radoslav Tsvetkov , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org Subject: Re: [RFC PATCH 0/2] leds: Add optional instance identifier for deterministic naming Message-ID: References: <20251228182252.1550173-1-professorjonny98@gmail.com> <761d6573-3751-47fb-9b0e-8063f3cecf76@gmail.com> <44ffa209-48b8-439e-a1ce-f9eb2aeb2f26@gmail.com> Precedence: bulk X-Mailing-List: linux-leds@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <44ffa209-48b8-439e-a1ce-f9eb2aeb2f26@gmail.com> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Mon, Dec 29, 2025 at 03:28:20PM +0100, Jacek Anaszewski wrote: > On 12/29/25 13:30, Andriy Shevencho wrote: > > On Mon, Dec 29, 2025 at 12:16:17PM +0100, Jacek Anaszewski wrote: > > > On 12/28/25 19:22, Jonathan Brophy wrote: > > > > > > 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. > > > > > > I think that we have currently everything in place to address the issue > > > you're trying to solve with this patch. Just introduce dedicated > > > function like LAN_PORT, and exploit function-enumerator. > > > > The problem as I understood not exactly in this. The reporter wants > > deterministic way of the mapping between HW numbered LEDs and their respective > > names. It seems it was already mentioned that current code depends on the > > arbitrary probe ordering. Saying this, I now think that perhaps GPIO led driver > > should somehow allocate a range of the LEDs and then enumerate them in > > accordance with the DT description? > > function-enumerator DT property enables deterministic enumeration. Ah, that's nice! -- With Best Regards, Andy Shevchenko