sb: rb: add svs function and modified setting value

[khoung76642]

Summary:

• change polling rate to match item (7) MEDHA0/1_VDD = 2ms, VDDQC = 10ms, OWL_E/W_VDD/HAMSA=100ms
• change the following default time windows
  • MEDHA0/1 LV1 = 100us
  • MEDHA0/1 LV2 = 100ms
  • MEDHA0/1 LV3 = 1000ms
• change the following default thresholds
  • MEDHA0/1 LV1 = 1200A
  • MEDHA0/1 LV2 = 1523W
  • MEDHA0/1 LV3 = 1025W
• add "voltage svs_apply_offset" cli cmd and default is set to 1 (enabled).
  • voltage svs_apply_offset get
  • voltage svs_apply_offset set <1:enable / 0:disable>
• add new command "voltage svs_asic_voltage" and default value is 1 (apply).
  • voltage svs_asic_voltage get
  • voltage svs_asic_voltage set <1:apply / 0:block>
• modified when DC off, I3C_RAINBOW_ALERT_R_N will set to 1
• change fw update EID data from mctp to eeprom
• change clock status CLK_GEN_100M_U86 from check LOSEVENT to check apll_lock_sts
• add clock status 312.5MHz APLL lock status
• modified pldm "get status" will not show in the log
• modify iris_smbus temp sensor ucr
• Add plat_ubc_otw_otp_init() to initialize UBC OTW/OTP related settings on EVT2 boards.
• For supported UBC modules (DELTA/LUXSHARE), iterate UBC temp sensors and program:
  • reg 0x10 to remove protection
  • reg 0x51 (OTW/OWL)
  • reg 0x4F (OTP/OFL)
  • Skip initialization on non-EVT2 board revisions and unsupported UBC modules.
• modified vout get all restore to previous way
• update ucr, lcr value

Test Plan:

• Build code: Pass

[meta-codesync]

This pull request has been imported. If you are a Meta employee, you can view this in D118091297. (Because this pull request was imported automatically, there will not be any future comments.)

[khoung76642]

common/service/pldm/pldm_firmware_update.c:1780:4:The buffer 'data' may not be null-terminated after the call to strncpy().
common/service/pldm/pldm_firmware_update.c:1102:19:Condition 'check_result!=PLDM_SUCCESS' is always false

1. The strncpy() warning is related to the existing char data[2] implementation. We would prefer not to modify the common code as part of this change.
2. The check_result != PLDM_SUCCESS warning is caused by the default weak implementation of plat_pldm_pass_component_table_check() returning PLDM_SUCCESS. This function is intended to be overridden by platform-specific implementations when ENABLE_PLDM_PASS_COMPONENT_CHECK is enabled.

Therefore, we would like to keep the existing common code unchanged.

[jagpalgill]

@khoung76642 Please address the following cpp check failures on this patch -

Checking common/service/sensor/sensor.c: ENABLE_RAA228249...
Checking common/service/sensor/sensor.c: ENABLE_RS31380R...
Checking common/service/sensor/sensor.c: ENABLE_RTQ6056...
Checking common/service/sensor/sensor.c: ENABLE_S54SS4P180PMDCF...
Checking common/service/sensor/sensor.c: ENABLE_TMP421...
Checking common/service/sensor/sensor.c: ENABLE_U50SU4P180PMDAFC...
Checking common/service/sensor/sensor.c: ENABLE_VISTARA...
Checking common/service/sensor/sensor.c: ENABLE_XDP710...
Checking common/service/sensor/sensor.c: MORE_THAN_ONE_ADM1272...
20/20 files checked 100% done
Errors Found:
common/service/pldm/pldm_firmware_update.c:1780:4:The buffer 'data' may not be null-terminated after the call to strncpy().
common/service/pldm/pldm_firmware_update.c:1102:19:Condition 'check_result!=PLDM_SUCCESS' is always false

[khoung76642]

Hi @jagpalgill,

common/service/pldm/pldm_firmware_update.c:1780:4:The buffer 'data' may not be null-terminated after the call to strncpy().
common/service/pldm/pldm_firmware_update.c:1102:19:Condition 'check_result!=PLDM_SUCCESS' is always false

1. The strncpy() warning is related to the existing char data[2] implementation. We would prefer not to modify the common code as part of this change.
   3.The check_result != PLDM_SUCCESS warning is caused by the default weak implementation of plat_pldm_pass_component_table_check() returning PLDM_SUCCESS. This function is intended to be overridden by platform-specific implementations when ENABLE_PLDM_PASS_COMPONENT_CHECK is enabled.

Therefore, we would like to keep the existing common code unchanged.

[jagpalgill]

@khoung76642 These checks are merge blockers. I can understand they are not in your change set but they are in the same file as your change set, so they are being prompted as land blockers. Please see - https://github.com/facebook/OpenBIC/actions/runs/33364950526/job/99403675288?pr=2771

[facebook-github-tools]

@khoung76642 has updated the pull request. You must reimport the pull request before landing.

[facebook-github-tools]

@khoung76642 has updated the pull request. You must reimport the pull request before landing.

[khoung76642]

Hi @jagpalgill,
Since several new pull requests have already been merged, we rebase the new main branch and re-upload.

Currently, only one Cpp check fails. This failure has already been explained above; making changes will affect other projects, and it's not a true Cpp error.
"Errors Found:
common/service/pldm/pldm_firmware_update.c:1141:19:Condition 'check_result!=PLDM_SUCCESS' is always false"

This is a Cppcheck false positive, not a runtime logic error.
The pldm_firmware_update.c:97 always returns PLDM_SUCCESS, which explains the warning.
Minerva provides a plat_pldm_fw_update.c:881 that can return PLDM_FW_UPDATE_CC_UNABLE_TO_INITIATE_UPDATE when version parsing or VR protection checks fail.
At link time, that override replaces the weak default, so check_result != PLDM_SUCCESS can be true. Keep the condition; removing it would bypass platform error handling.
The CI failure is real, but this diagnostic should be addressed through analyzer configuration or a narrowly scoped suppression. No code need changed.

Thanks!