Support for /dev/wwan0qcdm0

[riccardoferti]

Hi, i would like to know if it is possibile to have scat working with Foxconn T99W175 that on linux exposes only three devices through MHI PCI:

02:00.0 Wireless controller [0d40]: Foxconn International, Inc. Device [105b:e0ab]
        Subsystem: Foxconn International, Inc. Device [105b:e0ab]
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin ? routed to IRQ 48
        Region 0: Memory at f7001000 (64-bit, non-prefetchable) [size=4K]
        Region 2: Memory at f7000000 (64-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
        Capabilities: [50] MSI: Enable+ Count=8/32 Maskable+ 64bit+
                Address: 00000000fee00418  Data: 0000
                Masking: ffffffe0  Pending: 00000000
        Capabilities: [70] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 25W
                DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend-
                LnkCap: Port #0, Speed 16GT/s, Width x2, ASPM L0s L1, Exit Latency L0s <1us, L1 <64us
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
                LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 5GT/s (downgraded), Width x1 (downgraded)
                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+
                         10BitTagComp+ 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix-
                         EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
                         FRS- TPHComp+ ExtTPHComp-
                         AtomicOpsCap: 32bit- 64bit- 128bitCAS-
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR+ 10BitTagReq- OBFF Disabled,
                         AtomicOpsCtl: ReqEn-
                LnkCap2: Supported Link Speeds: 2.5-16GT/s, Crosslink- Retimer+ 2Retimers+ DRS-
                LnkCtl2: Target Link Speed: 16GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1-
                         EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
                         Retimer- 2Retimers- CrosslinkRes: Upstream Port
        Kernel driver in use: mhi-pci-generic

[peremen]

This is one of the modem I was planning to investigate... Does the modem expose any serial device through PCIe bus? Can ModemManager talk to it? Also, if Windows is also installed, is the debug/DIAG port exposed in Windows too?

In my opinion, it should speak the DIAG protocol, but finding out the right device node will be the problem.

[riccardoferti]

This is one of the modem I was planning to investigate... Does the modem expose any serial device through PCIe bus? Can ModemManager talk to it? Also, if Windows is also installed, is the debug/DIAG port exposed in Windows too?

In my opinion, it should speak the DIAG protocol, but finding out the right device node will be the problem.

/dev/wwan0at0 is the AT console and it is working as a normal tty like a charm.

While DIAG Port is working only on Windows as USB device using old Dell driver for UDE.

[peremen]

Hmm, if that /dev/wwan0qcdm0 is not the same as a serial port, then I am currently running out of the idea. If there is something like libusb for PCIe devices (i.e. userspace library to communicate with PCIe devices) then it might be doable, but capturing a PCIe packet trace from working DIAG port setup seems a nontrivial task.

While I have a RM500Q available, I never tried to use it in a PCIe mode due to lack of adequate cables and connectors (no, I don't have a laptop with M.2 3052 slot). Hope this uses the same driver as this Foxconn module, then experiences could be reused...

[riccardoferti]

Hmm, if that /dev/wwan0qcdm0 is not the same as a serial port, then I am currently running out of the idea. If there is something like libusb for PCIe devices (i.e. userspace library to communicate with PCIe devices) then it might be doable, but capturing a PCIe packet trace from working DIAG port setup seems a nontrivial task.

While I have a RM500Q available, I never tried to use it in a PCIe mode due to lack of adequate cables and connectors (no, I don't have a laptop with M.2 3052 slot). Hope this uses the same driver as this Foxconn module, then experiences could be reused...

The problem Is that there Is no way to use T99 in USB mode, so i don't really know how QCDM Is exposed in Windows, Maybe someone Expert can study the Windows driver to under stand how dm Port is started and linked.

[peremen]

The problem Is that there Is no way to use T99 in USB mode

What I meant here is opening the /dev/wwan0qcdm0 as a serial device: -t qc -s /dev/wwan0qcdm0. Does that work?

[riccardoferti]

The problem Is that there Is no way to use T99 in USB mode

What I meant here is opening the /dev/wwan0qcdm0 as a serial device: -t qc -s /dev/wwan0qcdm0. Does that work?

No

''''
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/serial/serialposix.py", line 398, in _reconfigure_port
orig_attr = termios.tcgetattr(self.fd)
^^^^^^^^^^^^^^^^^^^^^^^^^^
termios.error: (25, 'Not a tty')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/bin/scat", line 8, in
sys.exit(scat_main())
^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/scat/main.py", line 122, in scat_main
io_device = scat.iodevices.SerialIO(args.serial, args.baudrate, not args.no_rts, not args.no_dsr)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/scat/iodevices/serialio.py", line 9, in init
self.port = serial.Serial(port_name, baudrate=baudrate, timeout=0.5, rtscts=rts, dsrdtr=dsr)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/serial/serialutil.py", line 244, in init
self.open()
File "/usr/lib/python3.11/site-packages/serial/serialposix.py", line 332, in open
self._reconfigure_port(force_update=True)
File "/usr/lib/python3.11/site-packages/serial/serialposix.py", line 401, in _reconfigure_port
raise SerialException("Could not configure port: {}".format(msg))
serial.serialutil.SerialException: Could not configure port: (25, 'Not a tty')
''''

[peremen]

Argh. Then all the easy solutions are really gone. I can think of some methods, but not all of them will be a low-hanging fruit. I hope Qualcomm won't change the PCIe drivers like what they are doing for on-device DIAG drivers from time to time.