[sonic_xcvr] Use advertised timeouts for CDB firmware commands

[pnakka28]

Description

Use module advertised timeouts for CDB firmware commands. This change parses the MaxDuration fields and uses them as per-command timeouts for firmware operations. These timeouts are passed to the Start, Abort, Write, and Complete firmware commands. Commands without a spec defined MaxDuration continue to use the default timeout. Unit tests have been updated accordingly.

Motivation and Context

The CDB firmware commands previously used a default timeout for all operations. However, per CMIS spec, modules advertise per command MaxDuration values, and commands can have different execution times. This change ensures to respect module advertised timing constraints as defined in the CMIS specification.

How Has This Been Tested?

• Tested the changes on a device performing a full firmware download and activation cycle
• Confirmed MaxDuration values are correctly parsed from the module
• Firmware download and activation completed successfully using module advertised timeouts
• Updated unit tests in test_cdb_fw.py and test_cdb.py pass with new timeout parameters -> 98 passed
• Tested on branch 202605 with 98 unit tests passing

root@sonic:~# sfputil firmware upgrade EthernetXX "/path/to/firmware.bin"
Image A Version: 1.5.0
Image B Version: 1.4.0
Factory Image Version: 1.6.0
Running Image: B
Committed Image: B
Active Firmware: 1.4.0
Inactive Firmware: 1.5.0

CDB: Starting firmware download
Downloading ...  [###################################-]   99%  00:00:00
CDB: firmware download complete
Firmware download complete success
Running firmware: Non-hitless Reset to Inactive Image
Firmware run in mode 0 successful
FW images switch successful : ImageA is running
Firmware commit successful

Additional Information (Optional)

MSFT ADO - 38035182

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This PR updates the CMIS CDB firmware-management implementation in sonic_platform_base/sonic_xcvr to use module-advertised per-command MaxDuration values (from CMIS page 9Fh) as timeouts for firmware operations, and adjusts unit tests accordingly.

Changes:

• Parse and expose MaxDuration fields (Start/Abort/Write/Complete/Copy) from CMIS page 9Fh CDB firmware management features.
• Thread per-command timeouts into firmware Start/Abort/Write/Complete command execution paths (and add a shared safety-margin constant).
• Update unit tests to expect the new timeout= arguments.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
tests/sonic_xcvr/test_cdb.py	Updates assertions to include the new timeout kwarg passed into send_cmd().
tests/sonic_xcvr/test_cdb_fw.py	Updates firmware handler tests to expect per-command timeout parameters.
sonic_platform_base/sonic_xcvr/mem_maps/public/cmis/pages/page9f_cdb.py	Adds MaxDuration fields to the firmware management features map on page 9Fh.
sonic_platform_base/sonic_xcvr/fields/cdb_consts.py	Adds new MaxDuration field names and a timeout safety-margin constant.
sonic_platform_base/sonic_xcvr/cdb/cdb.py	Plumbs timeout through firmware block-write helpers and uses the shared safety-margin constant.
sonic_platform_base/sonic_xcvr/cdb/cdb_fw.py	Computes per-command timeouts from advertised MaxDuration and passes them into Start/Abort/Write/Complete commands.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

This PR has backport request label(s) for branch(es): 202605, but is missing required test information. Please make sure you tick the tested branch(es) in the Tested branch section and provide test evidence (e.g., 202605: <test result>) in the Test result section as well in your PR description.

_{---Powered by SONiC BuildBot}

[rookie-who]

@pnakka28 — This PR is requested for the 202605 branch but is missing test evidence. To move forward with cherry-pick approval, please:

1. Test on the 202605 branch and add results (image version + test output) to the PR description
2. Check the 202605 box in the "Tested Branches" section of the PR description
3. Add the "Tested for 202605 branch" label once testing is complete

Also, to help us prioritize correctly, could you clarify: Is this PR a bug fix / regression fix, a new feature, a platform config change, or a dependency/infra update? Understanding the nature of the change helps us triage the cherry-pick queue.

Thank you!

Review by @vaibhavhd via automated tooling

[pnakka28]

@pnakka28 — This PR is requested for the 202605 branch but is missing test evidence. To move forward with cherry-pick approval, please:

1. Test on the 202605 branch and add results (image version + test output) to the PR description
2. Check the 202605 box in the "Tested Branches" section of the PR description
3. Add the "Tested for 202605 branch" label once testing is complete

Also, to help us prioritize correctly, could you clarify: Is this PR a bug fix / regression fix, a new feature, a platform config change, or a dependency/infra update? Understanding the nature of the change helps us triage the cherry-pick queue.

Thank you!

Review by @vaibhavhd via automated tooling

This is a spec-compliance fix, not a new feature. No new user-facing feature, platform config change, or dependency update.

Tested against 202605 and updated the PR description with the image version and test results.

Note on ordering: this PR should be cherry-picked to 202605 before #722, which builds on it. I verified that #681 cherry-picks cleanly onto the current 202605 branch, and #722 then applies cleanly on top with no conflict. @vaibhavhd