<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 7, 2022 at 9:41 PM Ed Tanous <<a href="mailto:edtanous@google.com">edtanous@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jun 7, 2022 at 12:07 AM Jayashree D <<a href="mailto:srid.11486@gmail.com" target="_blank">srid.11486@gmail.com</a>> wrote:<br>
><br>
> Hi Team,<br>
><br>
> Could you please provide your suggestions on the above design for LED.<br>
><br>
> Thanks,<br>
> Jayashree<br>
><br>
><br>
> On Fri, May 27, 2022 at 12:42 PM Jayashree D <<a href="mailto:srid.11486@gmail.com" target="_blank">srid.11486@gmail.com</a>> wrote:<br>
>><br>
>> Hi Team,<br>
>><br>
>> Problem Description :<br>
>><br>
>> In the existing phosphor-led-sysfs design, it exposes one service per LED. Therefore, multiple services will be created for multiple GPIO pins configured for LED. To abstract this method and also to create LEDs under a single service, a new implementation is proposed.<br>
<br>
You've kind of jumped directly to a solution without spending any<br>
details on why this design is necessary.  What are you trying to<br>
achieve?  Why does the existing solution not work?  You allude to<br>
multiple services being bad, but you don't really state why, or what's<br>
preventing that from working.  This is a section labeled problem<br>
description, it needs to describe the problem, ideally in much more<br>
length than your solution itself.<br>
<br></blockquote><div> The Yosemite V2 Platform combines a Power LED and a System Identification LED into a single bicolor blue-yellow LED per host. <br>A total of 4 × LEDs will be placed along the front edge of the board in a grid. <br>The grid will be 2×rows of 2 × LEDs to match the layout of the card slots.<br><br>Based on each host status, blue or yellow led needs to be blink, OFF or ON. Therefore, bi-color led needs to be paired as a group and exposed in the userspace. <br></div><div><br></div><div>Based on the existing implementation in phopshor-led-sysfs, pairing groups will be difficult, since it exposes one service per LED. <br><br>Therefore, refactoring the phosphor-led-sysfs repo to run under a single service and pair a group of LED which represents each host.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>><br>
>> Existing Implementation :<br>
>><br>
>> 1. Physical Leds are defined in the device tree under "leds" section.<br>
>> 2. Corresponding GPIO pin are defined for the physical LEDs.<br>
>> 3. "udev rules" are used to monitor the physical LEDs.<br>
>> 4. Once the LED in initialized in device tree, udev event will be created and it will trigger a systemd service for that LED.<br>
>> 5. Therefore, if multiple GPIO pins are configured for LEDs, then it will create a multiple systemd services (xyz.openbmc_project.led.controller@.service) for phosphor-led-sysfs based on the LED name.<br>
>><br>
>> Example :<br>
>><br>
>> busctl tree xyz.openbmc_project.LED.Controller.led1<br>
>> `-/xyz<br>
>>   `-/xyz/openbmc_project<br>
>>     `-/xyz/openbmc_project/led<br>
>>       `-/xyz/openbmc_project/led/physical<br>
>>         `-/xyz/openbmc_project/led/physical/led1<br>
>><br>
>> busctl tree xyz.openbmc_project.LED.Controller.led2<br>
>> `-/xyz<br>
>>   `-/xyz/openbmc_project<br>
>>     `-/xyz/openbmc_project/led<br>
>>       `-/xyz/openbmc_project/led/physical<br>
>>         `-/xyz/openbmc_project/led/physical/led2<br>
>><br>
>><br>
>><br>
>> New Implementation :<br>
>><br>
>> 1. Physical Leds are defined in the device tree under "leds" section.<br>
>> 2. Corresponding GPIO pin are defined for the physical LEDs.<br>
>> 3. "udev rules" are used to monitor the physical LEDs.<br>
>> 4. Once the udev event is initialized for the LED, it will store those LED name using the script in udev instead of triggering systemd   service.<br>
>> 5. Phosphor-led-sysfs will have a single systemd service (xyz.openbmc_project.led.controller.service) running by default at system startup.<br>
>> 6. A dbus method call will be exposed from the service. udev will notify the LEDs detected in the driver.<br>
>><br>
>> Example :<br>
>><br>
>> busctl tree xyz.openbmc_project.LED.Controller<br>
>> `-/xyz<br>
>>   `-/xyz/openbmc_project<br>
>>     `-/xyz/openbmc_project/led<br>
>>       `-/xyz/openbmc_project/led/physical<br>
>>         `-/xyz/openbmc_project/led/physical/led1<br>
>>         `-/xyz/openbmc_project/led/physical/led2<br>
>><br>
>><br>
>> This was already discussed in the previous mail thread. Please refer to the below link.<br>
>> <a href="https://lists.ozlabs.org/pipermail/openbmc/2022-April/030272.html" rel="noreferrer" target="_blank">https://lists.ozlabs.org/pipermail/openbmc/2022-April/030272.html</a><br>
>><br>
>> Please provide your suggestions on this new proposal.<br>
>><br>
>><br>
>> Thanks<br>
>> Jayashree<br>
</blockquote></div></div>