From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (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 DE17C284684 for ; Tue, 30 Dec 2025 16:35:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767112558; cv=none; b=LAUzSiENZxQt5l6dSIjL4aRHAR3LOnXXGAXf10zLcGj9jB1xlH19BINhHrKY8vsHMlIl3DRKz14a8H5bzYfhp6V6cRmnKZvrCYgb+9zkGuGyWuL2dpe0GI0sPVNbyKe0xsJiIbDg8d/f/jbfhrKsD15w++mkZHLsNrCmf30sJmg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767112558; c=relaxed/simple; bh=1wQ/WIqwcgmKRkbPIx0yDFY45a7cXR6s67FQ4b9/Kvk=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=ktSqd2C21yKdlxeWdgaz4urElI8TEStRRhnpPehHc/oeJesKx9yWgELwfn2O1ImSoz1+eki2pq4p9rsos6NIjytGeCmry/8XUfPO/U7WFx8isSa7rw7dJkR3qqGv6EiMZaN5wiAPPudZqBJgfsr8JDO+311yXk6/PuQIu70zEfI= 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=ji9qwTpO; arc=none smtp.client-ip=209.85.167.49 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="ji9qwTpO" Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-5942b58ac81so8301294e87.2 for ; Tue, 30 Dec 2025 08:35:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767112555; x=1767717355; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=lPKpQJlCeJhCd8J/11ap+widQ29YewZ9v5ztqzPCYik=; b=ji9qwTpOjIVYeay2OnuRJFztTd+3iTPQpQr1svfFvaui1p7LQgzUDlJLyMEu290qQ5 bdAltO/d/iKFbPTSsbdCkz0hCABih0TUNHaUbVYehSsi9nELPEQxZLYKlI7q5mcSPHDn Oe8gbe9shZbr/I3xZiXzbdNy8zKkjsRtfV4Pk1Xep/Eh4hlwLsbNbzCJW94K3tXCEIEw BQ0ApemdkxCX0ZMtSXGvWrVcZUiWenKpB38jOs5ACCFqiaPURWRrMtTEReuFlINmqcMk jcwgSHRs6uAe28y7NeWDrF9h5mBGnr2cjt2dqxtJpMeJfmsKfXU6C4TVxscLpRVNRfdR gHLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767112555; x=1767717355; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lPKpQJlCeJhCd8J/11ap+widQ29YewZ9v5ztqzPCYik=; b=H70ZGykoVlLJJQd1aJBikiaDG+RYDBOt9gcf3Mj+kxRzex1D2uKnE46ol3XUb1VVxK s0t9RXN+qKjBYug36ROiwB3yqvOD4Ux2CF5aomMzPPdR+bQc6DJlLqTSTFolXE53QLFj ZSOvGOFzU7QEqMgvcZwukDruaFkF0EX+T9LKbm0RSK9mLzMICEFJXeiXulEIYQZM+qqw FSsfHlNIYDYQf5VJRTTLs3ktzgekbfGrw4U32QxMqgQalUPXJ+ZipKxLcPnEzeniScev ETlagwnrLL1SqDVscYpy1Vc40CKCwjVQEBJa8LdRMpoMm84spvx1TmLIyqoCCnKSJGsq HdoA== X-Forwarded-Encrypted: i=1; AJvYcCWBn51Ml29nRnPR/dfgd5peIYEEjQgb/SMGXHEuKlEpv7Ln5H15sQjtf/oxKzYSk+P+2m5QXMWZmTFowG4=@vger.kernel.org X-Gm-Message-State: AOJu0Yz93b+qFR696DSwEnKTOpiN49f5HAf0Dj10lB9hcEYStaQhOyYu bFhEA+WIbq91f0x9m+xE5umjYt72evbn5coSBpGK7eodPKtNZuN354Fq X-Gm-Gg: AY/fxX7F1QVxlJ8AEjd1oY8GzEGRx7zhvFA9O32rg270WHqlm0fdrjrpt8InMzS2acP Y3fhp/bXPxwpwokXqYntFkUxhKug+mVNZQHRCynh9ZdU0ZNJLkW18Kchn1GLGMINKpq13O6E9tD NPSFg/EsPvtCq08p9xA9fVImJHzZaj3SQSan1Yr4n867LqjhDcQLOULEZstbUYDl1M1MBZqRcD0 LltcexB7GXjOTwi0j9hBKxvCPpQy71L8KCHic+0rPz53aNYKFIIWf46Bsrs2GmJ+ycrNQ/lR1Lc 8VlrQ7WHLKPmOAxnvukcUyuvm/yE6Ht+HlDN88M5n07/Fdl+HC3sAjes7Icq8IfYtFNEU2SnOK/ ie40hSPKFoYJIOEi6Fd77j2aQdmXxJvb4o2TWkItwGpDaSll3yakg32Bs3RkBAqPUUl6IpIWmIF gpipVDH/lzDRE1uzZzkQOfmhHS4S6stiuHQg== X-Google-Smtp-Source: AGHT+IEh3MZf6CTJOzZeHGCYU9GIDpW05Uh+YS/H0es49h+fagK6eB66vYua5uI+HyG3ZwOGSMS1kg== X-Received: by 2002:a05:6512:b05:b0:59a:10c1:8f11 with SMTP id 2adb3069b0e04-59a17de704emr12001326e87.39.1767112554670; Tue, 30 Dec 2025 08:35:54 -0800 (PST) Received: from [192.168.0.131] ([194.183.54.57]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-59a185d5e32sm10121302e87.8.2025.12.30.08.35.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Dec 2025 08:35:54 -0800 (PST) Message-ID: <8022bcc7-c47d-44f8-b5b0-d2ff74ad9efd@gmail.com> Date: Tue, 30 Dec 2025 17:35:52 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jacek Anaszewski Subject: Re: [RFC PATCH 0/2] leds: Add optional instance identifier for deterministic naming To: Jonathan Brophy , Andriy Shevencho Cc: Jonathan Brophy , lee Jones , Pavel Machek , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Radoslav Tsvetkov , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-leds@vger.kernel.org" References: <20251228182252.1550173-1-professorjonny98@gmail.com> <761d6573-3751-47fb-9b0e-8063f3cecf76@gmail.com> <44ffa209-48b8-439e-a1ce-f9eb2aeb2f26@gmail.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/30/25 00:59, Jonathan Brophy wrote: > >>> 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. > > >> -- >> Best regards, >> Jacek Anaszewski > > That's not really the the problem I'm trying to solve but it is part of it. > The functions are quite ambiguous at the moment. > Having a string that can define something custom, the fallback _1 _2 identifiers are > high lighting the issue because the lack of options. > > I have a virtual led grouping driver that this restriction will highlight the issue even more. > with a status led on a typical oem device that indicate multiple states eg: > > - Solid Blue: setting up/ committing settings change. > - Pulse Blue: factory reset/ first boot ready for setup or WPS in progress. > - Fade in-out Blue: system upgrade in progress > - Solid Yellow: starting up.*/ > - pulse Yellow: resetting/ rebooting.*/ > > From sysfs i will end up with the below that really does not explain the use: > > led:status:blue > led:status:blue_1 > led:ststus:blue_2 > led:status:yellow > led:status:yellow_1 > > The LED subsystem has a semantic ambiguity: > What does LED_FUNCTION_LAN actually mean? > LAN port exists? > LAN cable connected? > LAN link active? > LAN traffic activity? > LAN speed indicator? > > Rather than making custom identifiers that are overly specific we could make > them up from stacking qualifiers or include a custom string to add meaning. > Would this be preferable over filling the common.h with long time gone > devices past identifiers that are overly specific to that platform or device? we > already have a few of them now. > > Something like this: > > led-lan-link { > function = LED_FUNCTION_LAN; > function-qualifier = "link-speed"; // NEW PROPERTY > color = ; > led-instance = "port5"; > /* Result: green:lan-link-speed:port5 */ > }; > > led-cellular-signal { > function = LED_FUNCTION_WLAN; // or new LED_FUNCTION_CELLULAR > function-qualifier = "signal-strength"; > color = ; > led-instance = "modem0"; > /* Result: green:wlan-signal-strength:modem0 */ > }; LED naming standardization was introduced to avoid multiplication of custom LED names for the same functionality. Allowing to define parts of LED function in plain text would bring back that old problem. Both function-qualifier and led-instance are not telling anything at first glance. Their purpose would be to define meaningful LED function name, thus we should rather think of introducing more advanced mechanism for composing LED function name, instead of extending the LED naming pattern. That could be preprocessor macros that would concatenate standard LED function name segments that would be still defined in common.h, which would allow to keep the standardization. Below example shows how some of your exemplary LED names could be created with that (for numerical postfixes function-enumerator would have to employed in addition to those): // These ones already exist in common.h #define LED_FUNCTION_WLAN "wlan" #define LED_FUNCTION_LAN "lan" #define LED_FUNCTION_INDICATOR "indicator" #define LED_FUNCTION_PORT "port" #define LED_FUNCTION_CABLE "cable" #define LED_FUNCTION_CONNECTED "connected" #define LED_FUNCTION_CABLE "cable" #define LED_FUNCTION_LINK "link" #define LED_FUNCTION_TRAFFIC "traffic" #define LED_FUNCTION_SPEED "speed" #define LED_FUNCTION_SIGNAL "signal" #define LED_FUNCTION_STRENGTH "strength" #define LED_FUNCTION_MODEM "modem" #define MAKE_LED_FUNCTION2(seg1, seg2) seg1"-"seg2 #define MAKE_LED_FUNCTION3(seg1, seg2, seg3) seg1"-"seg2"-"seg3 #define MAKE_LED_FUNCTION4(seg1, seg2, seg3, seg4) seg1"-"seg2"-"seg3"-"seg4 Then, when called as below: MAKE_LED_FUNCTION3(LED_FUNCTION_LAN, LED_FUNCTION_CABLE, LED_FUNCTION_CONNECTED) MAKE_LED_FUNCTION3(LED_FUNCTION_WLAN, LED_FUNCTION_SPEED, LED_FUNCTION_INDICATOR) MAKE_LED_FUNCTION4(LED_FUNCTION_WLAN, LED_FUNCTION_SIGNAL, LED_FUNCTION_STRENGTH, LED_FUNCTION_MODEM) MAKE_LED_FUNCTION4(LED_FUNCTION_LAN, LED_FUNCTION_LINK, LED_FUNCTION_SPEED, LED_FUNCTION_PORT) would produce below: lan-cable-connected wlan-speed-indicator wlan-signal-strength-modem lan-link-speed-port > // Network qualifiers > "link" // Cable connected > "activity" // Data transfer > "speed" // Link speed indication > "duplex" // Full/half duplex > "mesh" // Mesh node > > // Cellular qualifiers > "signal" // Signal strength > "activity" // Data activity > "registered" // Registered to network > "roaming" // Roaming status > > // Power qualifiers > "charging" // Battery charging > "low" // Low battery warning > "present" // Power source present > > I'm just really trying to find a way to make the naming more descriptive and I'm > open to suggestions. > > regards Jonathan Brophy > > -- Best regards, Jacek Anaszewski