On Thu, Mar 29, 2018 at 12:06:15AM +0800, Li Jun wrote:
> In case of drp toggling, we may need set correct cc value for role control
> after attach as it may never been set.
> 

Isn't CC set by the lower level driver in this case ? In other words, is it ever
necessary to call back into the low level driver to set CC again ? Doing that in
attached state seems a bit late.

It may make more sense to update port->cc_req when the state machine leaves
DRP_TOGGLING state, ie in _tcpm_cc_change(), and to do it without callback
into the low level driver (it should not be necessary).

Guenter

> Signed-off-by: Li Jun <jun...@nxp.com>
> ---
>  drivers/usb/typec/tcpm.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index 218c230..72d4232 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -2126,6 +2126,7 @@ static void tcpm_reset_port(struct tcpm_port *port)
>       tcpm_set_attached_state(port, false);
>       port->try_src_count = 0;
>       port->try_snk_count = 0;
> +     port->cc_req = 0;
>  }
>  
>  static void tcpm_detach(struct tcpm_port *port)
> @@ -2361,6 +2362,8 @@ static void run_state_machine(struct tcpm_port *port)
>               break;
>  
>       case SRC_ATTACHED:
> +             if (!port->cc_req)
> +                     tcpm_set_cc(port, tcpm_rp_cc(port));
>               ret = tcpm_src_attach(port);
>               tcpm_set_state(port, SRC_UNATTACHED,
>                              ret < 0 ? 0 : PD_T_PS_SOURCE_ON);
> @@ -2531,6 +2534,8 @@ static void run_state_machine(struct tcpm_port *port)
>               tcpm_set_state(port, SNK_UNATTACHED, PD_T_PD_DEBOUNCE);
>               break;
>       case SNK_ATTACHED:
> +             if (!port->cc_req)
> +                     tcpm_set_cc(port, TYPEC_CC_RD);
>               ret = tcpm_snk_attach(port);
>               if (ret < 0)
>                       tcpm_set_state(port, SNK_UNATTACHED, 0);
> -- 
> 2.7.4
> 
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to