UPSTREAM: usb: typec: tcpm: fix warning when handle discover_identity message
Since both source and sink device can send discover_identity message in PD3, kernel may dump below warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 169 at drivers/usb/typec/tcpm/tcpm.c:1446 tcpm_queue_vdm+0xe0/0xf0 Modules linked in: CPU: 0 PID: 169 Comm: 1-0050 Not tainted 6.1.1-00038-g6a3c36cf1da2-dirty #567 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : tcpm_queue_vdm+0xe0/0xf0 lr : tcpm_queue_vdm+0x2c/0xf0 sp : ffff80000c19bcd0 x29: ffff80000c19bcd0 x28: 0000000000000001 x27: ffff0000d11c8ab8 x26: ffff0000d11cc000 x25: 0000000000000000 x24: 00000000ff008081 x23: 0000000000000001 x22: 00000000ff00a081 x21: ffff80000c19bdbc x20: 0000000000000000 x19: ffff0000d11c8080 x18: ffffffffffffffff x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000d716f580 x14: 0000000000000001 x13: ffff0000d716f507 x12: 0000000000000001 x11: 0000000000000000 x10: 0000000000000020 x9 : 00000000000ee098 x8 : 00000000ffffffff x7 : 000000000000001c x6 : ffff0000d716f580 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff80000c19bdbc x1 : 00000000ff00a081 x0 : 0000000000000004 Call trace: tcpm_queue_vdm+0xe0/0xf0 tcpm_pd_rx_handler+0x340/0x1ab0 kthread_worker_fn+0xcc/0x18c kthread+0x10c/0x110 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- Below sequences may trigger this warning: tcpm_send_discover_work(work) tcpm_send_vdm(port, USB_SID_PD, CMD_DISCOVER_IDENT, NULL, 0); tcpm_queue_vdm(port, header, data, count); port->vdm_state = VDM_STATE_READY; vdm_state_machine_work(work); <-- received discover_identity from partner vdm_run_state_machine(port); port->vdm_state = VDM_STATE_SEND_MESSAGE; mod_vdm_delayed_work(port, x); tcpm_pd_rx_handler(work); tcpm_pd_data_request(port, msg); tcpm_handle_vdm_request(port, msg->payload, cnt); tcpm_queue_vdm(port, response[0], &response[1], rlen - 1); --> WARN_ON(port->vdm_state > VDM_STATE_DONE); For this case, the state machine could still send out discover identity message later if we skip current discover_identity message. So we should handle the received message firstly and override the pending discover_identity message without warning in this case. Then, a delayed send_discover work will send discover_identity message again. Bug: 254441685 Fixes: e00943e91678 ("usb: typec: tcpm: PD3.0 sinks can send Discover Identity even in device mode") cc: <stable@vger.kernel.org> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20230216031515.4151117-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit abfc4fa28f0160df61c7149567da4f6494dfb488) Signed-off-by: Lee Jones <joneslee@google.com> Change-Id: I6989a29a09a10393b97bc5a5d5e3c055bb397e05
This commit is contained in:
parent
72a7bbb4a3
commit
b155bf3086
@ -1444,10 +1444,18 @@ static int tcpm_ams_start(struct tcpm_port *port, enum tcpm_ams ams)
|
|||||||
static void tcpm_queue_vdm(struct tcpm_port *port, const u32 header,
|
static void tcpm_queue_vdm(struct tcpm_port *port, const u32 header,
|
||||||
const u32 *data, int cnt)
|
const u32 *data, int cnt)
|
||||||
{
|
{
|
||||||
|
u32 vdo_hdr = port->vdo_data[0];
|
||||||
|
|
||||||
WARN_ON(!mutex_is_locked(&port->lock));
|
WARN_ON(!mutex_is_locked(&port->lock));
|
||||||
|
|
||||||
/* Make sure we are not still processing a previous VDM packet */
|
/* If is sending discover_identity, handle received message first */
|
||||||
WARN_ON(port->vdm_state > VDM_STATE_DONE);
|
if (PD_VDO_SVDM(vdo_hdr) && PD_VDO_CMD(vdo_hdr) == CMD_DISCOVER_IDENT) {
|
||||||
|
port->send_discover = true;
|
||||||
|
mod_send_discover_delayed_work(port, SEND_DISCOVER_RETRY_MS);
|
||||||
|
} else {
|
||||||
|
/* Make sure we are not still processing a previous VDM packet */
|
||||||
|
WARN_ON(port->vdm_state > VDM_STATE_DONE);
|
||||||
|
}
|
||||||
|
|
||||||
port->vdo_count = cnt + 1;
|
port->vdo_count = cnt + 1;
|
||||||
port->vdo_data[0] = header;
|
port->vdo_data[0] = header;
|
||||||
@ -1964,11 +1972,13 @@ static void vdm_run_state_machine(struct tcpm_port *port)
|
|||||||
switch (PD_VDO_CMD(vdo_hdr)) {
|
switch (PD_VDO_CMD(vdo_hdr)) {
|
||||||
case CMD_DISCOVER_IDENT:
|
case CMD_DISCOVER_IDENT:
|
||||||
res = tcpm_ams_start(port, DISCOVER_IDENTITY);
|
res = tcpm_ams_start(port, DISCOVER_IDENTITY);
|
||||||
if (res == 0)
|
if (res == 0) {
|
||||||
port->send_discover = false;
|
port->send_discover = false;
|
||||||
else if (res == -EAGAIN)
|
} else if (res == -EAGAIN) {
|
||||||
|
port->vdo_data[0] = 0;
|
||||||
mod_send_discover_delayed_work(port,
|
mod_send_discover_delayed_work(port,
|
||||||
SEND_DISCOVER_RETRY_MS);
|
SEND_DISCOVER_RETRY_MS);
|
||||||
|
}
|
||||||
break;
|
break;
|
||||||
case CMD_DISCOVER_SVID:
|
case CMD_DISCOVER_SVID:
|
||||||
res = tcpm_ams_start(port, DISCOVER_SVIDS);
|
res = tcpm_ams_start(port, DISCOVER_SVIDS);
|
||||||
@ -2051,6 +2061,7 @@ static void vdm_run_state_machine(struct tcpm_port *port)
|
|||||||
unsigned long timeout;
|
unsigned long timeout;
|
||||||
|
|
||||||
port->vdm_retries = 0;
|
port->vdm_retries = 0;
|
||||||
|
port->vdo_data[0] = 0;
|
||||||
port->vdm_state = VDM_STATE_BUSY;
|
port->vdm_state = VDM_STATE_BUSY;
|
||||||
timeout = vdm_ready_timeout(vdo_hdr);
|
timeout = vdm_ready_timeout(vdo_hdr);
|
||||||
mod_vdm_delayed_work(port, timeout);
|
mod_vdm_delayed_work(port, timeout);
|
||||||
|
Loading…
Reference in New Issue
Block a user