> -----Original Message----- > From: Marek Behun <marek.behun@xxxxxx> > Sent: Wednesday, October 07, 2020 2:15 AM > To: Vadim Pasternak <vadimp@xxxxxxxxxx> > Cc: jacek.anaszewski@xxxxxxxxx; linux-leds@xxxxxxxxxxxxxxx > Subject: Re: [PATCH led-next 1/1] leds: mlxreg: Allow multi-instantiation of > same name LED for modular systems > > On Tue, 6 Oct 2020 19:58:50 +0300 > Vadim Pasternak <vadimp@xxxxxxxxxx> wrote: > > > It could be more than one instance of LED with the same name in the > > modular systems. For example, "status" or "uid" LED can be located on > > chassis and on each line card of modular system. > > In order to avoid conflicts with duplicated names, append platform > > device Id, which is unquie, to LED name after driver name. > > Thus, for example, "status" LED on chassis is to be called, like it is > > called now on non modular systems, on which platform device Id is not > > specified: "mlxreg:status:green". While for the line cards LEDs it > > will be called like: "mlxreg48:status:green", "mlxreg66:status:green", > > etcetera. > > :( what types of modules are these? Are they hotpluggable network adapter or > something like that? What should I imagine for example mlxreg48 device to > be? This is new modular systems which could be equipped with the different types of replaceable line cards and management board. The first system flavor will support the line cards equipped with Lattice CPLD devices aimed for system and ASIC control, one Nvidia FPGA, and Nvidia Mellanox gearboxes for the port control and with 16x100GbE QSFP28 ports. The next line cards flavors are supposed to be equipped with 8x200Gbe QSFP28 ports, 4x400Gbe QSFP-DD ports and few flavors of smart cards equipped with Nvidia ARM CPU. System is equipped with management card and has eight slots for line cards. All these line cards are replicable. The system is based on Nvidia Spectrum-3 ASIC. The switch height is 4U and it fits standard rack size. > > Btw it would be nice if mlx-platform was converted to Device Tree API instead > of registering each device in a system by hand. > mlx-platform activates tens other platform drivers. So this is a huge change, which will require huge amount of new definitions for DT API - actually if will be register map description at bit granularity. I can think about it for the future. Which real benefits you see from such move? Currently all our system are based on x86 arch. Vadim. > Marek > > > > > Signed-off-by: Vadim Pasternak <vadimp@xxxxxxxxxx> > > --- > > drivers/leds/leds-mlxreg.c | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/leds/leds-mlxreg.c b/drivers/leds/leds-mlxreg.c > > index 82aea1cd0c12..53130a8656b1 100644 > > --- a/drivers/leds/leds-mlxreg.c > > +++ b/drivers/leds/leds-mlxreg.c > > @@ -228,8 +228,12 @@ static int mlxreg_led_config(struct > mlxreg_led_priv_data *priv) > > brightness = LED_OFF; > > led_data->base_color = MLXREG_LED_GREEN_SOLID; > > } > > - snprintf(led_data->led_cdev_name, sizeof(led_data- > >led_cdev_name), > > - "mlxreg:%s", data->label); > > + if (priv->pdev->id > 0) > > + sprintf(led_data->led_cdev_name, "%s%d:%s", > "mlxreg", > > + priv->pdev->id, data->label); > > + else > > + sprintf(led_data->led_cdev_name, "%s:%s", "mlxreg", > > + data->label); > > led_cdev->name = led_data->led_cdev_name; > > led_cdev->brightness = brightness; > > led_cdev->max_brightness = LED_ON;
