scm_call2 is printing the input arguments if TZ ret value is < 0
leading to information leak. Remove printing input arguments.
Change-Id: I21dd6d83fa979aed2c79ebb2c9c8de63a247dded
CRs-Fixed: 1076407
Signed-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org>
Signed-off-by: Paresh Purabhiya <ppurab@codeaurora.org>
Signed-off-by: Runmin Wang <runminw@codeaurora.org>
Decrease the wait time from 5ms to 2ms when preparing a VDM
response to ensure that it gets sent out timely within
tSenderResponse (15ms). To avoid possible collision with an
incoming packet, check that there has not been any queued Rx
message just prior to sending a VDM. Also check the result of the
transmit and simply try again later if -EBUSY is returned.
While at it, fix a couple other miscellaneous timing issues.
Setting PD_ACTIVE=1 has considerable delay due to the charger's
voting mechanism, so move setting it to after starting the
SenderResponse timer when sending the Source Capabilities, and
similarly after sending a Request as a sink, in order to make
sure response timing is met. For source hard reset, increase the
tSrcRecover delay slightly from the spec minimum to account for
additional VBUS rise/fall delays before sending PS_RDY. Finally,
add a delay for VCONN_SWAP before sending PS_RDY for similar reason.
Change-Id: I5760fadb66cad6faf02e95a1e1bb975289ef8e9f
Signed-off-by: Jack Pham <jackp@codeaurora.org>
If an unexpected or delayed Type-C mode change notification
arrives from the charger driver, it could falsely kick the
state machine and could cause it to prematurely hard reset
since it preempted an expected message. This is particularly
true for the PR Swap operation in which the timing of PS_RDY
and resulting power negotiation is disrupted by the CC change
notification which is catching up. The previous way of handling
this by using the pd->in_pr_swap flag to mask the typec_mode
changes is quite fragile due to the uncertainty of when said
flag should be cleared.
Hence, demote the use of the in_pr_swap flag for only ignoring
the expected disconnect the happens in between the role change.
Then, for typec_mode changes, determine if current_pr is changed
or not to decide whether to kick the state machine. Finally,
since disconnect now is signaled by pd->current_pr==PR_NONE,
we'll need to keep track of whether VBUS had been enabled with
a separate flag rather than relying on pd->current_pr==PR_SRC.
Change-Id: I66be40091b75726d25c7be4478f1248a6af9ca3c
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Make sure to reset both Tx and Rx msgid counters when the
protocol layer needs to be reset. This occurs after hard/soft
reset as well as when starting up a new sink or source session.
Put this in a common function pd_reset_protocol().
Change-Id: I643a60a28e6498ca16b6f46293b8aa05eff40266
Signed-off-by: Jack Pham <jackp@codeaurora.org>
The current hard reset handling (most recently fixed with
commit 172cec3a2c ("usb: pd: Improve sink hard reset handling"))
is based on a maximum timeout for the longest possible (according
to spec) duration that VBUS may turn off and back on again, just
under 2s, before re-starting the sink and waiting for capabilities
again. However, this method is prone to timing errors, particularly
tTypeCSinkWaitCap, which should be based on when VBUS turns on.
Fix this by making use of the VBUS presence notification from the
charger (PROP_PRESENT). Keep track of this in the psy_changed()
callback and use the falling notification to determine when to
transition out of PE_SNK_TRANSITION_TO_DEFAULT into PE_SNK_STARTUP.
Bring back PE_SNK_DISCOVERY which is now used as a waiting state
until the VBUS rising notification comes and transition to
PE_SNK_WAIT_FOR_CAPABILITIES. And move setting of PROP_VOLTAGE_MAX
to PE_SNK_STARTUP after VBUS has turned off to avoid tripping
the charger's overvoltage detection.
Also since aforementioned commit, the CC HW is now able to handle
VBUS going away and not treating it as a false disconnect, so we
can remove the workaround as a disconnect can now be treated as
a disconnect.
Change-Id: I885f3f4c219e102758fd09c8aae9257d093ebb72
Signed-off-by: Jack Pham <jackp@codeaurora.org>
