usb: typec: tcpm: fix warning when handle discover_identity message

In the Linux kernel, the following vulnerability has been resolved:

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.