RE: [External Mail] Re: [PATCH v6 0/7] net: wwan: t9xx: Add MediaTek T9XX WWAN driver
"Wu. JackBB (GSM)" <[email protected]>
| Newsgroups | org.kernel.vger.linux-doc,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-mediatek,org.kernel.vger.linux-kernel,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 17 Aug 2026 at 22:39, Jakub Kicinski <[email protected]> wrote: > This FSM exists in the driver, even tho you call it "core logic". > Please provide more details in the patch description of patch 5 > and consider whether any of this logic should live in the WWAN > framework. Good point on the naming — "core logic" is misleading. Will rename it to "device lifecycle management" in the cover letter to make the scope clear. Will also expand P5's commit message to describe the FSM states (OFF → BOOTUP → READY → ON → OFF), the HS1/HS2/HS3 handshake protocol, CLDMA init/exit wiring, and the error-recovery paths. Regarding whether this belongs in the WWAN framework: the FSM manages the T9xx-specific boot sequence — PCIe link bringup, firmware handshake via CLDMA-based runtime feature table (RTFT) exchange, and hardware error recovery (FLDR/PLDR). Every state and transition is dictated by T9xx hardware behaviour. The t7xx driver has its own FSM (t7xx_fsm.c / t7xx_modem_ops.c) in the driver for the same reason — its boot sequence and handshake protocol are equally device-specific. The WWAN subsystem today provides port management and netdev helpers, which t9xx uses (wwan_create_port in P6). A generic device lifecycle state machine would need to abstract over these vendor-specific boot protocols, and we don't think that abstraction exists without hardware-specific knowledge from each vendor. We believe the FSM belongs in the driver, but we are happy to discuss if you see specific pieces that could be factored out. Thanks. -- Jack