On 1/8/24 23:17, Suniel Mahesh wrote:
Hi Guenter/Heikki/Greg and all, This email is a narrowed version of the earlier discussion at: https://lore.kernel.org/all/CAM+7aWt7hJSmJQ78Fes0jMcrF9E8yhN=sDgYuU-hBxO0+1Uj0g@xxxxxxxxxxxxxx/T/ Please guide/suggest on why the FUSB302B port controller on a target board is getting reset(hard reset) on reception of a 0x0 packet from source(PD Wall charger 100W - 20V@5A). log when reset: [ 1.599049] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83 [ 1.602836] FUSB302: IRQ: 0x00, a: 0x40, b: 0x00, status0: 0x83 [ 1.606210] TCPM: tcpm_pd_event_handler: in TCPM_CC_EVENT [ 1.968179] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83 [ 2.133140] FUSB302: IRQ: 0x41, a: 0x04, b: 0x00, status0: 0x93 [ 2.133704] FUSB302: IRQ: PD tx success [ 2.136046] FUSB302: PD message header: 161 [ 2.136392] FUSB302: PD message len: 0 [ 2.136845] TCPM: PD TX complete, status: 0 [ 2.139382] FUSB302: IRQ: 0x51, a: 0x00, b: 0x00, status0: 0x93 [ 2.142192] FUSB302: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93 [ 2.142804] FUSB302: IRQ: PD sent good CRC [ 2.145274] FUSB302: PD message header: 1a3 [ 2.145674] FUSB302: PD message len: 0 [ 2.146072] FUSB302: fusb302_pd_read_message: to tcpm_pd_receive [ 2.146478] TCPM: PD RX, header: 0x1a3 [1] [ 2.147042] TCPM: tcpm_pd_ctrl_request: type:0x3 [ 2.147435] TCPM: tcpm_pd_ctrl_request: case PD_CTRL_ACCEPT [ 2.146309] TCPM: tcpm_pd_ctrl_request: case SOFT_RESET_SEND [ 2.148266] TCPM: tcpm_pd_rx_handler: done [ 2.158196] FUSB302: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93 [ 2.158600] FUSB302: IRQ: PD sent good CRC [ 2.161283] FUSB302: PD message header: 0 [ 2.161710] FUSB302: PD message len: 0 [ 2.162092] FUSB302: fusb302_pd_read_message: to tcpm_pd_receive [ 2.162608] TCPM: PD RX, header: 0x0 [1] [ 2.163181] TCPM: tcpm_pd_rx_handler: done [ 2.179843] FUSB302: IRQ: 0x41, a: 0x01, b: 0x00, status0: 0x83 [ 2.180314] FUSB302: IRQ: PD received hardreset: interrupta: 1 [ 2.181125] FUSB302: fusb302_pd_reset: [ 2.182597] TCPM: tcpm_pd_event_handler: [ 2.182937] TCPM: tcpm_pd_event_handler: TCPM_RESET_EVENT [ 2.183292] TCPM: _tcpm_pd_hard_reset: Received hard reset [ 2.183770] TCPM: _tcpm_pd_hard_reset: Let me know if you need anymore details.
AFAICS the wall charger sends a hard reset request, which is honored. This seems to work as intended to me. What is interesting though is that I don't see a "Unrecognized extended message type" in the log, suggesting that the message id is 0 and matches the previous message ID. This would cause the message to be ignored. I don't really know what do do with this. All I can say is that the charger should not send a message with header==0x0. It looks like there is no response sent to this message, which is possibly the reason why the charger sends the hard reset request. But that doesn't give us a hint what we should or even could do in this situation. Guenter
