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.
Thanks and Regards
--
Suniel Mahesh
Embedded Linux and Kernel Engineer
Amarula Solutions India
Unfortunately this seems to just be the behavior of many wall
chargers, triggered by either an excessive delay between first drawing
power and beginning PD communication, or by an incorrect sequence
number. From what I've heard, this is a workaround for a bug in the
earliest USB-C MacBooks, but it unfortunately makes those chargers
unusable for powering anything that doesn't have an internal battery.
Suniel Mahesh <[email protected]> ezt írta (időpont: 2024.
jan. 9., K, 8:17):
>
> 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.
>
> Thanks and Regards
> --
> Suniel Mahesh
> Embedded Linux and Kernel Engineer
> Amarula Solutions India
>
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