Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[201911] Initialize fan led in thermalctld for the first run #186

Merged
merged 1 commit into from
May 27, 2021

Conversation

Junchao-Mellanox
Copy link
Collaborator

Backport PR #167 since there is no clean cherry-pick.

Description

Initialize fan led in thermalcltd for the first run. Add a flag "led_initialized" in FanStatus and set it as False on init function. FanUpdater will use this flag to determine if fan led should be set even if no fan event detected.

Motivation and Context

Make sure fan led is initialized to correct color.

How Has This Been Tested?

Manual test

Additional Information (Optional)

@liat-grozovik liat-grozovik requested a review from jleveque May 23, 2021 08:58
@liat-grozovik
Copy link
Collaborator

@abdosi FYI.

@jleveque jleveque changed the title [201911] Backport Initialize fan led in thermalctld for the first run to 201911 [201911] Initialize fan led in thermalctld for the first run May 27, 2021
@jleveque jleveque merged commit bb1254b into sonic-net:201911 May 27, 2021
@Junchao-Mellanox Junchao-Mellanox deleted the backport-pr-167 branch May 28, 2021 01:41
vdahiya12 added a commit to vdahiya12/sonic-platform-daemons that referenced this pull request Apr 4, 2022
…I support for multiple vendors (sonic-net#186)

Description
For multiple Y-Cable vendor support once we do have a mapping from vendor/part number to the appropriate Y-Cable module to load, we need to map appropriate port to a module as well. This PR adds definition for base abstract class.

Motivation and Context
Basically, the key idea is once we have a port identified as being of a certain vendor and it has been identified to load a certain module, it is then needed to call the correct module/API on each port each time we call the API on the port

it is required to maintain this mapping in memory since xcvrd does not want to read/parse this y_cable_vendor_mapping.py file again and again each time we call the Y-Cable API

Also note that the module loaded might change during xcvrd running lifetime since cable/transceiver can be changed from one vendor to another. So we need to take this into consideration as well

Proposed Solution for this
Each module of the Y-Cable vendor can be a class (of each transceiver type) and all we need to do is instantiate the objects of these classes as class instances and these objects will provide the interface of calling the API's for the appropriate vendor Y-Cable.

This instantiation will be done inside xcvrd, when xcvrd starts

These objects basically emulate Y-Cable instances and whatever action/interaction needs to be done with the Y-Cable the methods of these objects would provide that

each vendor in their implementation can inherit from a base class where there will be definitions for all the supported capabilities of the Y-Cable.

for vendors the recommended approach in case their subclass implementation does not support a method, is to set the method equal to None. This differentiates it from a method they forgot to implement. Then, the calling code should first check if the method is None before attempting to call it.

Design document for the support is sonic-net/SONiC#757

Signed-off-by: vaibhav-dahiya <vdahiya@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants