linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vadim Pasternak <vadimp@nvidia.com>
To: Marek Behun <marek.behun@nic.cz>
Cc: Pavel Machek <pavel@ucw.cz>,
	"jacek.anaszewski@gmail.com" <jacek.anaszewski@gmail.com>,
	"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>
Subject: RE: [PATCH led-next 1/1] leds: mlxreg: Allow multi-instantiation of same name LED for modular systems
Date: Mon, 12 Oct 2020 10:14:18 +0000	[thread overview]
Message-ID: <DM6PR12MB38989BFE9D1967C69E397A6BAF070@DM6PR12MB3898.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20201008123214.2a5de507@nic.cz>



> -----Original Message-----
> From: Marek Behun <marek.behun@nic.cz>
> Sent: Thursday, October 08, 2020 1:32 PM
> To: Vadim Pasternak <vadimp@nvidia.com>
> Cc: Pavel Machek <pavel@ucw.cz>; jacek.anaszewski@gmail.com; linux-
> leds@vger.kernel.org
> Subject: Re: [PATCH led-next 1/1] leds: mlxreg: Allow multi-instantiation of
> same name LED for modular systems
> 
> > >
> > > Vadim, the LED core constructs names in form
> > >   device:color:function-enumerator
> > > so if you must have number there, IMO it should be
> > >   mlxreg:green:status-48
> > >   mlxreg:green:status-56
> > >   ...
> >
> > But why you consider it as function enumerator?
> > For example card48, card56 are two different devices of same type.
> > Both have 'status' LED.
> 
> OK this is a fair point.
> 
> I was thinking such because in my mind I had this idea that for an ethernet
> switch with interfaces lan0 - lan4 it would make sense to use the
> LED_FUNCTION_LAN function with function enumerator. But thinking about
> this now again makes me wonder if instead the lan0 - lan4 should be
> devicenames instead, since normally they are network interface names.
> 
> Vadim, the reason why Pavel and I think that mlxreg (or mlxregN) is not
> valid devicename part (although mlxreg has to stay since many users
> already depend on it, as you say), is that the mlxreg name is not exposed
> anywhere else in Linux from userspace point of view.
> 
> Devicename eth0 is okay, because it is network interface name.
> Devicename sda would be okay, because everyone knows it is a block device
> and you can access it via /dev/sda.
> Devicename hci0 would be okay because it is bluetooth interface accessible
> via hcitool.
> Devicenames mtd0, kbd0, mouse0 would be okay, I think.
> 
> But mlxreg is not accessible via anything else in the system. Unless your
> systems also have something like /dev/mlxreg, that is.
> 
> Do the LEDs on these cards only indicate status of the cards themselves as a
> whole? Or are there LEDs on these cards dedicated to their peripherals? For
> example if there is an ethernet port with LEDs on one of these cards, the
> devicename part for these LEDs should be of the device of that ethernet
> port, not mlxreg...

Hi Marek,

Each line card must have 'status' LED, indicating status of line card itself.
User can set non-green in case some there are some alarms on different devices,
equipped on this line card. It can be set blink during line card initialization.

Line card could be equipped with UID LED. User can set this LED in order to
find physical location of line card. Sometimes it's hard to see the sticker on
chassis.

Line card also equipped with per port LED, but those LEDs are handled by FW.

So, the device in this case is 'line card'.

In my previous reply I suggest name 'fru' stands for the filed replaceable unit.
This is not something, that is exposed in '/dev', but it describes any replaceable
unit within the system.

> 
> Marek

  reply	other threads:[~2020-10-12 10:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-06 16:58 [PATCH led-next 1/1] leds: mlxreg: Allow multi-instantiation of same name LED for modular systems Vadim Pasternak
2020-10-06 23:15 ` Marek Behun
2020-10-07  6:07   ` Vadim Pasternak
2020-10-07 12:17     ` Marek Behun
2020-10-07 11:31 ` Pavel Machek
2020-10-07 12:20   ` Marek Behun
2020-10-08  6:16     ` Vadim Pasternak
2020-10-08  7:56       ` Pavel Machek
2020-10-08  8:47         ` Vadim Pasternak
2020-10-08  8:55           ` Marek Behun
2020-10-08  9:30             ` Vadim Pasternak
2020-10-08 10:05               ` Pavel Machek
2020-10-08 10:32                 ` Vadim Pasternak
2020-11-25 11:20                   ` Pavel Machek
2020-11-25 12:01                     ` Vadim Pasternak
2020-12-30 18:48                       ` Pavel Machek
2020-10-08 10:32               ` Marek Behun
2020-10-12 10:14                 ` Vadim Pasternak [this message]
2020-10-21  8:33                   ` Pavel Machek
2020-10-21 12:29                     ` Vadim Pasternak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM6PR12MB38989BFE9D1967C69E397A6BAF070@DM6PR12MB3898.namprd12.prod.outlook.com \
    --to=vadimp@nvidia.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-leds@vger.kernel.org \
    --cc=marek.behun@nic.cz \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).