qcom-soc: add BAM-DMUX data path support

[hsharm-bit]

Problem

Qualcomm SoC modems using the BAM-DMUX kernel data path driver were not functional in ModemManager. Two separate issues prevented them from working:

Probe-time failure: The wwan0 net interface is not created at boot for BAM-DMUX modems. It only appears after the modem firmware receives a DPM Open Port command, which is sent during modem initialization — after organize_ports() has already run. This caused modem creation to fail because no net port was present at probe time.

WDA data format failure: The WDA GET DATA FORMAT command on QRTR ports requires an endpoint TLV identifying the data endpoint. The bam-dmux driver was excluded from the endpoint TLV path, causing the request to be sent without it. Some firmware versions reject this with an InvalidArgument error instead of the more descriptive MissingArgument.

---

Solution

The MR contains 1 commit, and the corresponding PR has 1 commit touching the subsystems:

1. port/qmi: add BAM-DMUX DPM support and fix QRTR WDA endpoint handling

• Add dpm_open_port_bam_dmux() with the correct BAM-DMUX DPM parameters and wire it into the data format step machine alongside the existing IPA path

• Remove the bam-dmux exclusion from the use_endpoint=TRUE path; for ports with an unrecognized net driver, default the endpoint type to EMBEDDED/0 instead of the invalid UNDEFINED type

• Add a fallback in get_data_format_ready() to retry without the endpoint TLV when the modem rejects it, handling firmware that uses InvalidArgument instead of MissingArgument

• Add mm_port_qmi_set_net_driver(), mm_port_qmi_get_net_driver(), and mm_port_qmi_peek_device() public API

2. base-modem: allow QMI modem creation without net port for BAM-DMUX

• Add mm_base_modem_get_bam_dmux_pending() which returns TRUE when the plugin is "qcom-soc" and no data port has been grabbed yet; IPA modems always have a data port at probe time so this is safe

• Skip the net port and data port error checks in organize_ports() when BAM-DMUX is pending

• Pre-configure the QMI port's net driver to "bam-dmux" before wwan0 appears so the correct endpoint type is set for WDA requests

3. bearer/qmi: use BindMuxDataPort for BAM-DMUX WDS client binding

• Add a BAM-DMUX branch at the bind data port steps that sends BindMuxDataPort with ep-type=BAM_DMUX, mux-id=0; the existing SIO port and rmnet mux paths are unchanged

4. plugins/qcom-soc: send DPM open port during enabling_modem_init

• Override enabling_modem_init() to send DPM Open Port early in the enable sequence, triggering wwan0 creation; only runs for BAM-DMUX modems, IPA modems return immediately without any action

• Fix peek_port_qmi_for_data_bam_dmux() to use QMI_SIO_PORT_NONE since BAM-DMUX uses BindMuxDataPort rather than BindDataPort

---

Non-regression

Every change is guarded by a driver string comparison or the mm_base_modem_get_bam_dmux_pending() predicate, which returns FALSE for all non-BAM-DMUX modems:

Modem type	Impact
USB (qmi_wwan)	None
PCIe (mhi_net)	None
qcom-soc IPA	None — data port present at probe, predicate returns FALSE
Devices requiring endpoint TLV (e.g. Quectel RM500Q)	None — existing MissingArgument handler preserved
Any modem that accepts the endpoint TLV	None — InvalidArgument fallback only fires on rejection

---

Known limitation

mm_base_modem_get_bam_dmux_pending() checks the plugin name "qcom-soc" in core code. The preferred approach would be a virtual method in MMBroadbandModemQmiClass, but that requires a larger refactor. This is explicitly documented with a NOTE: comment and can be addressed in a follow-up patch.

---

Testing

Tested on Shikra platform (qcom-soc, BAM-DMUX data path, QRTR transport):

• wwan0 appears after DPM Open Port during enabling_modem_init

• WDA GET DATA FORMAT succeeds

• Modem reaches searching → registered state

• IPv4 data connection established and verified

• qcom-soc IPA modem tested in parallel: no regression observed

Signed-off-by: Harsh Sharma hsharm@qti.qualcomm.com

[github-actions]

Test run workflow

Test jobs for commit 0169c08

qcom-distro
Pass: 240 | Fail: 1 | Total: 273

nodistro
Pass: 9 | Fail: 0 | Total: 9

qcom-distro_linux-qcom-6.18
Pass: 207 | Fail: 1 | Total: 231

[test-reporting-app]

Test Results

  103 files  ± 0    632 suites  ±0   5h 6m 1s ⏱️ - 1h 36m 19s
  128 tests  -  1     99 ✅  - 11   0 💤 ±0  29 ❌ +10 
5 984 runs   - 34  5 874 ✅  - 71  55 💤 +8  55 ❌ +29 

For more details on these failures, see this check.

Results for commit 0169c08. ± Comparison against base commit 30e5a33.

This pull request removes 2 and adds 1 tests. Note that renamed tests count towards both.

lava ‑ lava-test-retry
lava ‑ lava-test-shell

lava ‑ reset-device

[lumag]

This MR contains 4 commits, each touching one subsystem:

This PR contains exactly 1 commit.

[lumag]

Missing commit message. Also unsquash your patches.

[ricardosalveti]

You used AI to generate a long PR description but no commit message at all, get your agent to read and consume AGENTS.md (https://github.com/qualcomm-linux/meta-qcom/blob/master/AGENTS.md#7-commit-message-best-practices-project-style).

[hsharm-bit]

This MR contains 4 commits, each touching one subsystem:

This PR contains exactly 1 commit.

Apologies for the confusion, this PR is only having 1 commit as all of the 4 commits from the MR 1452 has been included in a single patch, please let me know if you want all those 4 commits message included in that single patch, then I will update the same.

[hsharm-bit]

Missing commit message. Also unsquash your patches.

I will add the commit message shortly.

[hsharm-bit]

I have updated the MR also, now it's having a single commit.

[lumag]

I have updated the MR also, now it's having a single commit.

Why???