linux-kernel - Re: USB PD TYPEC - FUSB302B port controller hard reset issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5004d63d-905b-4297-aa8e-23c9ccaa3444@roeck-us.net>
Date: Tue, 9 Jan 2024 07:47:39 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Suniel Mahesh <sunil@...rulasolutions.com>,
 Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 linux-kernel@...r.kernel.org, USB list <linux-usb@...r.kernel.org>
Cc: Jagan Teki <jagan@...rulasolutions.com>, Da Xue <da.xue@...retech.co>,
 Da Xue <da@...sconfused.com>, Da Xue <da@...re.computer>,
 Kyle Tso <kyletso@...gle.com>, RD Babiera <rdbabiera@...gle.com>
Subject: Re: USB PD TYPEC - FUSB302B port controller hard reset issue

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@mail.gmail.com/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