USB under mainline on mica (2026-11-02)

Attempt 2026-11-02-3: the first-boot image plus kernel/mica-usb.config (the USB chain built in) and USB captures in /init. Source: the AP console over SuzyQ (raw log dumps/firstboot/2026-11-02-ap.log). Same DTB as the first boot.

Result: USB host works on all four controllers

Bus	Controller (DT)	Device	Speed
1	`a200000` `usb_2` (USB 2 only)	Integrated Webcam FHD `1bcf:28dc`	480M
2, 3	`a400000` `usb_mp` (multiport)	FPMCU `18d1:5406`	12M
4, 5	`a600000` `usb_1_ss0`	none (inference: the left Type-C port, holding the SuzyQ)
6, 7	`a800000` `usb_1_ss1`	the kernel image stick, Lexar `21c4:0809` → `sda`, `sda1` = KERN-A	480M

Root hubs: four USB 2 (480M) and three SuperSpeed (10000M), one per SS-capable controller.
The right Type-C port is usb_1_ss1 (the stick booted from it and enumerated on bus 6).
SuperSpeed does not come up on Type-C yet: the same stick runs at 5 Gbps on the build host. Inference: the PS8830 retimer and the QMP combo PHY get no orientation or mode, because pmic-glink stays deferred (qcom_pmic_glink: failed to initialize pdr): it needs the ADSP running with its firmware.

Still deferred (`/sys/kernel/debug/devices_deferred`)

Device	Reason
`pmic-glink`	`failed to initialize pdr` (ADSP not running)
`3da0000.iommu` (GPU SMMU)	supplier `3d90000.clock-controller` (GPU clock controller) not ready
`firmware:scmi`	supplier `17430000.mailbox` not ready
`aux_bridge.0`-`.3`	`failed to acquire drm_bridge` (DisplayPort chain)
`1bf8000.pcie`, `1c08000.pcie`	`Failed to parse Root Port: -517`

What changed from the first boot

The first boot left every dwc3 deferred (“failed to register DWC3 Core”) because the eUSB2 and QMP PHYs, the eUSB2 repeaters, the PTN3222 redrivers, GENI I2C, TYPEC and PS883X were all =m in defconfig and no module loads. The QMP children also need their menu parent PHY_QCOM_QMP=y (drivers/phy/qualcomm/Kconfig:53-125 at a804c57); scripts/build-kernel.sh caught that demotion.

Attempt 2026-11-02-4: ADSP (failed, cause found)

kernel/mica-adsp.config + the stock adsp.mdt firmware in the initramfs. Results (AP console):

remoteproc0: Booting fw image qcom/x1e80100/google/mica/adsp.mdt, then qcom_q6v5_pas 6800000.remoteproc: Error in getting resource table: -5; adsp stays offline.
pmic-glink now probes (no longer deferred): the PD mapper and QRTR are built in. qcom-battmgr-{ac,bat,usb,wls} register but read empty, since the ADSP is down. No Type-C ports yet. The stick is still at 480M.
The GPU SMMU and the DP aux bridges are no longer on the deferred list; SCMI and PCIe still are.

Cause: the resource-table request runs only when the PAS node has iommus (qcom_pas_parse_firmware, a804c57), which mainline’s x1-el2.dtso adds for the 9345. Mica’s TrustZone answers -EIO. The stock mica tree has no iommus on the ADSP or CDSP node (entry00-base.dts:5513, :12925) and uses the same adsp.mdt/adsp_dtb.mdt names. Fix: dts/mica-el2.fixups deletes both properties after the overlay (attempt 2026-11-02-5).

Attempt 2026-11-02-5: ADSP running, SuperSpeed on Type-C

Same kernel and firmware as attempt 4; the DTB drops the PAS iommus (dts/mica-el2.fixups).

remoteproc remoteproc0: remote processor adsp is now up at 1.6 s; adsp running. cdsp stays offline (no firmware shipped: -2).
pmic_glink UCSI registers two Type-C ports: port0 (host, sink) and port1 (host, source: powering the stick), both orientation=normal.
qcom-battmgr answers: USB supply online, battery Charging (inference: power from the SuzyQ link in the left port); capacity still empty at capture time. UCSI adds two ucsi-source-psy supplies.
The kernel image stick enumerates on bus 7, the SuperSpeed hub of usb_1_ss1, at 5000M (480M before).
Still deferred: arm-scmi (mailbox) and both PCIe controllers.

USB on mica now works end to end: all four controllers, both Type-C ports at SuperSpeed (the right port tested), Type-C role/orientation and battery reporting through the ADSP.

Keyboard shortcuts