add phone capability via MACHINE_FEATURE for Industrial kits.#1861
Conversation
mdembla-bit
requested review from
anujm1,
koenkooi,
lumag,
ndechesne,
ricardosalveti,
sbanerjee-quic and
vkraleti
as code owners
|
Fix your git environment (user), and fix your DCO. Do we really have modems in all these variants? |
Sure got the issue with DCO, will update. Yes these variants support external M.2 attach modems |
Then add this information as part of the commit message. |
mdembla-bit
force-pushed
the
enable_modemmanager_externalattach
branch
from
38ae55c to
9e2e921
Compare
Updated as part of commit message for all the commits. Also fixed DCO environment errors, please help to review the changes |
lumag
left a comment
lumag
left a comment
There was a problem hiding this comment.
to support cellular and
telephony functionality for external M.2 attach modems.
At least RB3 Gen2 core/vision kits don't have M.2 slots. Please be more specific, is M.2 a part of the kit or it is on the mezzanine?
@lumag Thanks for the clarification. I’m can update the commit message / PR description to explicitly say “external modem via carrier/mezzanine board” for better clarification. Let me know your comments |
Which mezzanine? Which carrier board? Please be specific. If we later refactor machines in any way (like spawning industrial mezz away or merging more machines) I'd like to know what exactly is going on. |
@lumag Thanks for the clarification request. This applies to industrial mezzanine / carrier boards that provide an M.2 B‑key slot for external SDX modems on RB3Gen2, RB4, and RB8 platforms. The phone MACHINE_FEATURE reflects validated industrial mezzanine‑based configurations with external M.2 SDX modems and does not imply native M.2 support on the base core/vision kits. For reference, the mezzanine board details are documented here: https://qualcomm-confluence.atlassian.net/wiki/spaces/CSSENG/pages/747015275/Mezzanine+Board+-+Industrial+INDU+Mezzanine+Board |
|
@mdembla-bit please mention RB3 Gen2 industrial kit in the commit message. Also mention that for IQ kits it is the normal carrier board. |
Add 'phone' to MACHINE_FEATURES to support cellular and telephony functionality for external M.2 attach modems on RB3Gen2 Industrial kit configurations. On RB3 Gen2, the SDX modem is attached via the Industrial Mezzanine Board, which provides an M.2 B-key slot (PCIe/MHI). The base RB3 Gen2 core/vision kits do not include native M.2 support. Signed-off-by: Mrigank Dembla <mdembla@qti.qualcomm.com>
Add 'phone' to MACHINE_FEATURES to support cellular and telephony functionality for rb8 for external M.2 attach modems. On IQ-9075, the SDX modem is attached via the standard carrier board, which provides the M.2 slot. Signed-off-by: Mrigank Dembla <mdembla@qti.qualcomm.com>
Add 'phone' to MACHINE_FEATURES to support cellular and telephony functionality for rb4 for external M.2 attach modems. On IQ-8275, the SDX modem is attached via the standard carrier board, which provides the M.2 slot. Signed-off-by: Mrigank Dembla <mdembla@qti.qualcomm.com>
mdembla-bit
force-pushed
the
enable_modemmanager_externalattach
branch
from
9e2e921 to
0ba4826
Compare
Hi @lumag , I have updated all the commits with this info for better clarification. Please take another look and let me know if anything else needs adjustment. |
…attach through MHI ports (#1728) **Scope and intent** This change is intended only for Qualcomm SoC industrial platforms (RB3 Gen2/QCS6490, RB4/QCS8300, RB8/QCS9100) running meta-qcom/QLI. In this environment, ModemManager is not enabled globally; it is enabled only on targets that explicitly declare MACHINE_FEATURES += "phone" (added via PR #1861). **Problem** On Qualcomm SoC platforms with a PCIe-attached SDX modem (e.g. SDX35/55 on QCS6490), the modem is controlled via QRTR through the MHI IPCR channel. ModemManager currently has no way to associate the QRTR control path with the mhi_net data interface, so the modem is not detected. **What this patch adds** - Routes PCIe mhi_net interfaces to the qcom-soc plugin via udev, guarded by ENV{ID_BUS}=="pci". - Adds a dedicated QMI data endpoint handler for mhi_net (PCIe endpoint, interface number 4). - Skips wwan control ports only when the MHI IPCR channel is bound to a QRTR driver. The presence of a bound *_IPCR MHI channel is the definitive runtime evidence that QRTR is the active control path. - Enables multiplexed bearers (REQUESTED) for the QRTR + mhi_net case. Without this enablement, ModemManager cannot detect MHI-attached external modems on these platforms, preventing cellular data bring-up on otherwise supported hardware configurations. **Why this is not a general-purpose solution** The current implementation intentionally targets single external modem configurations, which are sufficient to enable cellular data functionality on the above platforms for this release. A more generic solution covering multiple concurrently attached SDX modems requires additional kernel and ModemManager changes and broader hardware validation, and is being worked on separately. For this reason, the patch is marked Upstream-Status: Inappropriate and is carried strictly as a downstream, Qualcomm SoC-specific workaround. A generic upstream solution requires kernel-level support to bind QRTR nodes to network interfaces at runtime and will be proposed separately once that support is ready. **Testing and feature validation usecases** The wwan port exclusion fires only when an *_IPCR MHI channel with a driver bound is found under the device's physdev path. This check is timing-independent: the IPCR channel binding is established before wwan ports appear. The following configurations have been analyzed and are unaffected: - Qualcomm SoC platforms (RB3 Gen2, RB4, RB8) with PCIe-attached SDX modems: mhi0_IPCR is present and bound to qcom_mhi_qrtr. Wwan ports are correctly skipped. Verified on RB3 Gen2 with SDX35. - ARM laptops (X13s/SC8280XP) with PCIe-attached SDX55 (T99W175): the MHI device exposes channels DIAG, DUN, IP_HW0_MBIM, LOOPBACK, MBIM but no *_IPCR channel. WWAN/MBIM control path is unaffected. - x86/AMD hosts with M.2 modems (Telit FN990, Sierra EM9xxx, and similar Qualcomm-chipset modules): these modems use WWAN/MBIM and do not expose an *_IPCR channel. The check does not fire. - Platform modems (qcom-q6v5-mss): the physdev path contains no MHI device. The directory scan finds no mhi* entry and the check does not fire. - USB-attached MHI modems: the physdev path is a USB device path with no MHI device at the physdev level. The check does not fire. - Non-Qualcomm PCIe modems: no MHI device, no *_IPCR channel. The check does not fire. - Virtual devices: physdev is NULL. The NULL guard prevents the check from running. This change provides minimal, platform-scoped support for the current meta-qcom release, without precluding future refinement as multi-modem support is stabilized.
5 participants
This change adds the 'phone' capability to MACHINE_FEATURES for the
Rb3gen2-core-kit, iq-9075-evk and iq-8275-evk machines having external M.2 attach modems.
The intent is to advertise telephony support at the machine level,
allowing higher layers to conditionally enable cellular-related components based on MACHINE_FEATURES.