ucsi: ucsi_glink: Fix message handling in ucsi_qti_notify()

Currently, ucsi_qti_notify() is checking the received data from
charger firmware (PPM) to see if there is any connector status
response with partner accessory information (e.g. analog audio).
It does this based on setting a flag (cmd_requested_flags) when
UCSI_GET_CONNECTOR_STATUS command is sent from UCSI framework to
PPM so that the response for that command can be read and clients
registered for getting notification on partner accessory can get
notified. However, in a certain scenario, multiple response for
different commands can be received from PPM. See a possible
example below.

1. UCSI framework sends UCSI_GET_CONNECTOR_STATUS command
2. ucsi_glink driver sets cmd_requested_flags, waits for response
3. UCSI framework sends UCSI_GET_CURRENT_CAM command
4. ucsi_glink driver gets a response for UCSI_GET_CONNECTOR_STATUS
   and schedules notify_work since ucsi_qti_notify() is called
   with cmd_requested_flags set.
5. ucsi_glink driver gets a response for UCSI_GET_CURRENT_CAM and
   this can end up reading "flags" because cmd_requested_flags is
   not cleared yet. However, this causes a buffer overflow because
   ucsi_qti_read() passes "val" pointer passed from UCSI framework
   which is of 1 byte length and ucsi_qti_notify() ends up reading
   "flags" which is at an offset 2 of length 9 bytes.
6. ucsi_qti_notify_work() clears cmd_requested_flags.

Fix this by checking the message length in ucsi_qti_notify()
to ensure that status->flags is read only when a response is
received for UCSI_GET_CONNECTOR_STATUS. Also, relocate the
clearing of "cmd_requested_flags" flag.

CRs-Fixed: 2678391
Change-Id: Iac1d5c58e1ed2fd0f3bc153da23cddf0700cc097
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>