Subject: Re: [PATCH net] net: wwan: iosm: Fix 7360 WWAN card control channel mapping

From: Shane Parslow <[email-masked]>
Date: Tue, 27 Sep 2022 23:06:48 -0700

On Tue, Sep 27, 2022 at 01:43:22PM +0000, Kumar, M Chetan wrote:
> > -----Original Message-----
> > From: Shane Parslow <[email-masked]>
> > Sent: Monday, September 26, 2022 9:35 AM
> > To: [email-masked]
> > Cc: Kumar, M Chetan <[email-masked]>; linuxwwan
> > <[email-masked]>; Loic Poulain <[email-masked]>; Sergey
> > Ryazanov <[email-masked]>; Johannes Berg
> > <[email-masked]>; David S. Miller <[email-masked]>; Eric
> > Dumazet <[email-masked]>; Jakub Kicinski <[email-masked]>;
> > Paolo Abeni <[email-masked]>; [email-masked]; linux-
> > [email-masked]
> > Subject: [PATCH net] net: wwan: iosm: Fix 7360 WWAN card control channel
> > mapping
> > 
> > This patch fixes the control channel mapping for the 7360, which was
> > previously the same as the 7560.
> > 
> > As shown by the reverse engineering efforts of James Wah [1], the layout of
> > channels on the 7360 is actually somewhat different from that of the 7560.
> > 
> > A new ipc_chnl_cfg is added specifically for the 7360. The new config
> > updates channel 7 to be an AT port and removes the mbim interface, as it
> > does not exist on the 7360. The config is otherwise left the same as the
> > 7560. ipc_chnl_cfg_get is updated to switch between the two configs.
> > In ipc_imem, a special case for the mbim port is removed as it no longer
> > exists in the 7360 ipc_chnl_cfg.
> > 
> > As a result of this, the second userspace AT port now functions whereas
> > previously it was routed to the trace channel. Modem crashes ("confused
> > phase", "msg timeout", "PORT open refused") resulting from garbage being
> > sent to the modem are also fixed.
> 
> Trace channel is mapped to 3rd entry.
> 
> /* Trace */
> { IPC_MEM_CTRL_CHL_ID_3, IPC_MEM_PIPE_6, IPC_MEM_PIPE_7,
>   IPC_MEM_TDS_TRC, IPC_MEM_TDS_TRC, IPC_MEM_MAX_DL_TRC_BUF_SIZE,
>   WWAN_PORT_UNKNOWN },
> 
> I cross checked by running AT test on 7360. Both ports are functional as expected.
> We should be able to send or receive AT commands with existing below config. 
> 
> /* IAT0 */
> { IPC_MEM_CTRL_CHL_ID_2, IPC_MEM_PIPE_4, IPC_MEM_PIPE_5,
>   IPC_MEM_MAX_TDS_AT, IPC_MEM_MAX_TDS_AT, IPC_MEM_MAX_DL_AT_BUF_SIZE,
>   WWAN_PORT_AT },  -----------> wwan0at0
> 
> /* IAT1 */
> { IPC_MEM_CTRL_CHL_ID_4, IPC_MEM_PIPE_8, IPC_MEM_PIPE_9,
>   IPC_MEM_MAX_TDS_AT, IPC_MEM_MAX_TDS_AT, IPC_MEM_MAX_DL_AT_BUF_SIZE,
>   WWAN_PORT_AT }, ------------> wwan0at1
> 
> Does this second AT port (wwan0at1) goes bad at some point or is always not functional/modem
> crashes sooner we issue AT command ?
> 
> Could you please help to check the modem fw details by running below command.
> at+xgendata

Upon further investigation, it looks like the modem crashes only occur
after S3 sleep, and are likely a different issue that this patch does
not fix. Sorry for the confusion.

I say that the channels are mapped incorrectly because upon opening
wwan0at0, I recieve "+XLCSINIT: UtaLcsInitializeRspCb received result = 0",
and no response to AT commands. The behavior I would expect, and the
behavior I get after applying the patch, is normal responses to AT
commands in the same way as wwan0at1 pre-patch.

To be clear, my patch points wwan0at0 to channel 4, and wwan0at1 to channel
7. I have perhaps been ambiguous with the terms I have been using.

To recap:
-- The modem crashes are likely an unrelated issue.
-- wwan0at0 is currently unresponsive to commands, and outputs
   "+XLCSINIT...", but responds normally post-patch.

AT+XGENDATA returns the following:
+XGENDATA: "XG736ES21S5E20NAMAV2DEFA19223101408
M2_7360_XMM7360_REV_2.1_RPC_NAND 2019-May-29 11:40:45
*XG736ES21S5E20NAMAV2DEFA19223101408__M.2_7360_MR2_01.1920.00*"
"*"
"FAB-CODE:7*SDRAMVendor=0x08 (Winbond), SDRAMRevision=0x0000"

I don't see any firmware updates online.