fusb302: a USB-PD sink that works

Stand up a minimal driver that just detects the cable orientation and reports it through sysctl. 10e8b0a fusb302: minimal USB Type-C port controller driver attaches the chip at 0x22, dumps device_id, configures the CC pull-downs (PDWN_CC1 / PDWN_CC2), and reads back STATUS0.BC_LVL to identify which CC pin saw Rp. That much works on the first try — dev.fusb302.0.orientation updates when the cable flips. But VBUS still defaults to 5 V because the chip never does anything past detection.

Build the full sink policy engine. 88f04f4 fusb302: add USB-PD sink state machine is the big one — 1 000 lines added to fusb302.c. Adds the FUSB302 register map (CONTROL3, MASKA, MASKB, FIFO at 0x43, SLICE), USB-PD r3.1 message framing (16-bit headers, Fixed Supply PDO parser, Request RDO builder), the BMC PHY enable sequence (AUTO_CRC, PD r2.0 spec rev, sink-only role, retry config), the TX/RX FIFO paths, and the sink policy engine state machine following USB-PD r3.1 §8.3.3.3:

Disabled → Startup → Discovery → Wait_for_Capabilities
        → Evaluate_Capability → Select_Capability
        → Transition_Sink → Ready

Plus standard timers (tSenderResponse 30 ms, tPSTransition 550 ms, tNoResponse 5 s) and a 100 Hz polled kproc that ticks the SM, drains RX, ages timers. Untested at commit time — the phone wedged with a brownout-induced kernel panic before the kernel built with this could be deployed.

Once deployed, the chip wasn’t seeing the cable at all in PE_DISABLED. 6bf3223 fusb302: drop PDWN on inactive CC line post-attach dropped the PDWN on the inactive CC line after attach so the active line could actually drive — the CC pulldowns were fighting the source’s Rp. Cable detection became reliable.

RX FIFO drain wasn’t working — interrupts fired but the policy engine didn’t see Source_Capabilities. 33f0e7a fusb302: log chip status periodically + drain RX when FIFO non-empty logs chip status periodically and drains the RX FIFO whenever it’s non-empty regardless of which interrupt bit fired. 0d6a355 fusb302: accumulate interrupt bits across diagnostic dump window accumulates interrupt bits across the diagnostic dump window so a fast-clearing interrupt doesn’t get missed. 7fb5992 fusb302: clear CONTROL0.M_INT_MASK so interrupt latches actually fire clears CONTROL0.M_INT_MASK so interrupt latches actually fire.

That gets Source_Capabilities decoded.

The Request transmits but the source ignores it. Watching with a logic probe: TX FIFO is being filled correctly, header looks right, but the BMC line never goes active. c3809d5 fusb302: actually trigger transmission with CONTROL0.TX_START finds it: TXOFF/TXON sets up the transmit window but the actual trigger is CONTROL0.TX_START, which we weren’t writing. One bit. Linux’s fusb302.c doesn’t write it (the TXON token in the FIFO is enough on the part variant they target); on this part, it isn’t. After this commit the source replies with Accept and then PS_RDY.

Robustness — silent timeouts shouldn’t escalate. 809d9cf fusb302: stop blasting hard resets; advertise PD r3.0 GoodCRC stops blasting hard resets when tSenderResponse expires; advertises PD r3.0 in our GoodCRC so sources don’t reject our framing. a9121e3 fusb302: forgive Request/PS_RDY timeouts; stop spurious hard resets further forgives Request / PS_RDY timeouts — keep the link, retry the request, don’t burn the policy engine to the ground on every blip. a4f63d3 fusb302: retry cable detection while in PE_DISABLED retries cable detection while in PE_DISABLED so a flaky plug-in isn’t terminal. 2d3fc5f fusb302: flush TX FIFO before queuing each PD message flushes the TX FIFO before queuing each PD message so leftover bytes from a prior failed transmission don’t corrupt the next frame.

Negotiation became flaky again across reboots: Request transmitted, no Accept, and a chip dump showed CONTROL3 immediately reading back the wrong value after we wrote it. The bits we set in BMC PHY enable weren’t sticking. ee8daad fusb302: dynamic SPECREV, programmed MEASURE/POWER, rx_msgid tracking + a8b584d fusb302: default GoodCRC to Rev3 (downgrade only on Rev2 partner) made SPECREV dynamic — the chip was advertising Rev2 in our GoodCRC against a Rev3 source, and the mismatch was producing GoodCRC frames the source silently dropped. Default to Rev3 in our GoodCRC; only downgrade when the partner answers Rev2. That cleared the silent-drop case.

TX completion was timing-fragile — the policy engine assumed the message had landed once TX_START was asserted and didn’t wait for a real chip event. 045efa2 fusb302: event-driven TX completion + per-TX retry program + COLLISION unmask moved TX completion to the IRQ path: handle TX_SENT, RETRY_FAIL, HARD_RESET, and COLLISION as discrete events, with a per-TX retry program. 5ca6317 fusb302: switch from 10ms polling to IRQ-driven worker meanwhile replaced the 100 Hz polling kproc with an interrupt-driven worker, so the policy engine wakes on actual chip events rather than every 10 ms. 12a63fe fusb302: PD timers via callout instead of state-age polling moved PD timers off state-age polling onto callout(9) so the kproc no longer needs to wake just to check elapsed time.

Narrow the boot mask. Linux treats SWITCH2_EN as a separate regulator the RK818 sub-PMIC needs on during certain transitions, not as the Type-C VBUS switch. 4d190f3 rk818: decouple SWITCH2 from Type-C OTG drops SWITCH2_EN from the boot-time clear and removes the bogus comment in rk818_battery.h that conflated the two. 8eac8e7 site: correct RK818 OTG switch docs fixes the same conflation in the appendix and HARDWARE notes. FUSB attach reliability comes back. PD Request TX on CC1 still fails.

Manual register poking shows PD Request TX succeeds the moment DCDC_EN is forced from 0x7f (OTG clear, SWITCH2 on) to 0x3f (both clear). So the failure isn’t FUSB-side at all — RK818’s DCDC topology was somehow back-pressuring CC1 BMC signaling. But FUSB needed SWITCH2 on during its own reset/probe (otherwise the I2C Reset NACK’d). The two requirements were directly opposite — and timed: SWITCH2 had to be on during probe and off before PD TX.

The order matters. Hold SWITCH2 high until FUSB has finished probing, then have FUSB tell RK818 it’s safe to drop it once the sink path is wired up. That requires a contract between the two drivers — but FUSB shouldn’t know about RK818 directly, and the polling-thread coupling that ef6035e fusb302+rk818: apply PD-negotiated input current to the charger shipped was already a code smell.

6469f2e power: add charger coordination layer adds dev/power_supply/ — a minimal coordination layer modelled on Linux’s power_supply framework but stripped to what we actually need. Two function pointers (set_input_current_limit, set_typec_source_role), a notifier (power_supply_changed), and string-keyed lookup. RK818 calls power_supply_register("rk818", &ops, cookie) at attach. FUSB calls power_supply_set_input_current_limit("rk818", mA) and a new power_supply_prepare_typec_sink("rk818") without ever naming the PMIC’s symbols. 2036021 power: fix files.arm64 patch hunk wires it into sys/conf/files.arm64. ccd3862 rk818: publish charger after lock init publishes the charger only after the rwlock init so the first IRQ doesn’t race against an uninitialised lock.

06348c6 fusb302: prepare sink path after TCPC attach adds the prepare_typec_sink callback: FUSB calls it after Reset + device_id succeeds but before the first PD TX. 9041600 rk818: hold SWITCH2 through TCPC probe makes RK818 force SWITCH2 on during early charger init so the next warm reboot reliably passes FUSB probe. d51baa8 fusb302: settle non-PD Type-C sources handles the orthogonal case of legacy 5 V walls: settle to a stable Type-C current advertisement instead of looping on PD discovery against a non-PD source.

With the prepare contract in place, PD Request TX on CC1 is still timing out. Comparing register state to Linux: on attach, the Linux FUSB driver leaves Rd enabled on both CC pins and changes only the polarity / measure / TX selection in SWITCHES0. Our post-attach write was floating the inactive CC line. 036fecc fusb302: keep sink Rd on both CC pins keeps PDWN1 | PDWN2 set after attach and only swaps MEAS_CC1 vs MEAS_CC2. CC1 PD now negotiates at the protocol level on the bench.

Still flaky in the field. Boot logs after 036fecc revealed the last layer:

rk818_pmu0: rk818[typec-sink]: prepared Type-C sink path (DCDC_EN 0x7f->0x3f)
fusb3020: IRQ mode (irq 84)
rk818_pmu0: rk818[irq]: cleared OTG in sink mode (DCDC_EN 0xff->0x7f)

FUSB had cleared SWITCH2 via prepare_typec_sink, but the RK818 PMIC IRQ handler — newly introduced in d1b3a0b rk818: drive charger updates from PMIC IRQ , which moves charger updates off the 5 Hz polling thread onto the chip’s INT pin (with parent-IRQ plumbing in aa76411 rk8xx: fix IRQ patch hunk count + 6399b97 rk8xx: use insertion hunks for IRQ patch + 65a65a1 rk8xx: carry PMIC IRQ parent as overlay and a tunable gate in 6351db4 rk8xx: gate PMIC IRQ behind tunable ) — immediately re-armed SWITCH2 because its own enforce path only masked OTG. The contract worked exactly once, then the IRQ undid it on the very next interrupt.

544bd86 rk818: preserve prepared Type-C sink path tracks a rk818_typec_sink_prepared flag inside the PMIC. Once FUSB has called prepare_typec_sink, the sink-enforce path masks DCDC_EN_PPP_SINK_MASK (OTG | SWITCH2) instead of DCDC_EN_OTG_MASK. The flag resets on source-role transitions so a future sink attach re-prepares cleanly.