From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE031C636C9 for ; Wed, 21 Jul 2021 19:50:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 97B5F6120C for ; Wed, 21 Jul 2021 19:50:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231989AbhGUTJ4 (ORCPT ); Wed, 21 Jul 2021 15:09:56 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:38976 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231872AbhGUTJx (ORCPT ); Wed, 21 Jul 2021 15:09:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=RBz23aFqo1ODUik8Itgcy3DHXYO9jsXTpzjV7A0RdnE=; b=YO/XIy9qLOxeALj0P7DY9c8dYf ciaM43Lopp1Wyie1Q0uN2NA2EvsANxjFggY/Z/PkDLopBNG76/mdk+G7OnqItmwvGlIEJzwDL40As MpLMgc8GT2Uwm5bnC3uqqlqwuEmsnnleVGopk09t59PHjlvhTOTV/pLhdb5RTx8v1y3Q=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1m6IEJ-00EFKl-UB; Wed, 21 Jul 2021 21:50:07 +0200 Date: Wed, 21 Jul 2021 21:50:07 +0200 From: Andrew Lunn To: Marek =?iso-8859-1?Q?Beh=FAn?= Cc: Heiner Kallweit , Pavel Machek , Tony Nguyen , davem@davemloft.net, kuba@kernel.org, Kurt Kanzenbach , netdev@vger.kernel.org, sasha.neftin@intel.com, vitaly.lifshits@intel.com, vinicius.gomes@intel.com, Sebastian Andrzej Siewior , Dvora Fuxbrumer , "linux-leds@vger.kernel.org" Subject: Re: [PATCH net-next 5/5] igc: Export LEDs Message-ID: References: <20210716212427.821834-1-anthony.l.nguyen@intel.com> <20210716212427.821834-6-anthony.l.nguyen@intel.com> <88d23db8-d2d2-5816-6ba1-3bd80738c398@gmail.com> <3b7ad100-643e-c173-0d43-52e65d41c8c3@gmail.com> <20210721204543.08e79fac@thinkpad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210721204543.08e79fac@thinkpad> Precedence: bulk List-ID: X-Mailing-List: linux-leds@vger.kernel.org > Hi Heiner, > > in sysfs, all devices registered under LED class will have symlinks in > /sys/class/leds. This is how device classes work in Linux. > > There is a standardized format for LED device names, please look at > Documentation/leds/leds-class.rst. > > Basically the LED name is of the format > devicename:color:function The interesting part here is, what does devicename mean, in this context? We cannot use the interface name, because it is not unique, and user space can change it whenever it wants. So we probably need to build something around the bus ID, e.g. pci_id. Which is not very friendly :-( Andrew