All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tzung-Bi Shih <tzungbi@google.com>
To: Prashant Malani <pmalani@chromium.org>
Cc: linux-kernel@vger.kernel.org, Benson Leung <bleung@chromium.org>,
	Guenter Roeck <groeck@chromium.org>,
	"open list:CHROMEOS EC USB TYPE-C DRIVER"
	<chrome-platform@lists.linux.dev>
Subject: Re: [PATCH 3/4] platform/chrome: cros_ec_typec: Configure muxes at start of port update
Date: Tue, 8 Feb 2022 13:38:07 +0800	[thread overview]
Message-ID: <YgIBv2SQdwXm7RLt@google.com> (raw)
In-Reply-To: <20220207214026.1526151-4-pmalani@chromium.org>

On Mon, Feb 07, 2022 at 09:40:28PM +0000, Prashant Malani wrote:
> There are situations where the mux state reported by the Embedded
> Controller (EC), might lag the partner "connected" state. So, the mux
> state might still suggest that a partner is connected, while the PD
> "connected" state, being in Try.SNK (for example) suggests that the
> partner is disconnected.
> 
> In such a scenario, we will end up sending a disconnect command to the
> mux driver, followed by a connect command, since the mux is configured
> later. Avoid this by configuring the mux before
> registering/disconnecting a partner.

I failed to understand the description.  It looks like some protocol details.
Could you provide some brief explanation in the commit message?

On a related note, followed up the example scenario, which one of the
understanding is the most applicable:
1) The disconnect followed by a connect is suboptimal.  The patch cleans it.
2) The disconnect followed by a connect is a bug.  The patch fixes it.

> @@ -965,6 +965,11 @@ static int cros_typec_port_update(struct cros_typec_data *typec, int port_num)
>  	if (ret < 0)
>  		return ret;
>  
> +	/* Update the switches if they exist, according to requested state */
> +	ret = cros_typec_configure_mux(typec, port_num, &resp);
> +	if (ret)
> +		dev_warn(typec->dev, "Configure muxes failed, err = %d\n", ret);

It used the fact that the function returns `ret` at the end.  After the move,
the block is no longer the last thing before function returns.

Does it make more sense to return earlier if cros_typec_configure_mux() fails?
Does the rest of code need to be executed even if cros_typec_configure_mux()
fails?

> @@ -980,11 +985,6 @@ static int cros_typec_port_update(struct cros_typec_data *typec, int port_num)
>  	if (typec->typec_cmd_supported)
>  		cros_typec_handle_status(typec, port_num);
>  
> -	/* Update the switches if they exist, according to requested state */
> -	ret = cros_typec_configure_mux(typec, port_num, &resp);
> -	if (ret)
> -		dev_warn(typec->dev, "Configure muxes failed, err = %d\n", ret);
> -
>  	return ret;

If the function decides to return earlier, it can be `return 0;`.

  reply	other threads:[~2022-02-08  5:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-07 21:40 [PATCH 0/4] platform/chrome: cros_ec_typec: Reorganize mux configuration Prashant Malani
2022-02-07 21:40 ` [PATCH 1/4] platform/chrome: cros_ec_typec: Move mux flag checks Prashant Malani
2022-02-08  5:33   ` Tzung-Bi Shih
2022-02-08  6:03     ` Prashant Malani
2022-02-07 21:40 ` [PATCH 2/4] platform/chrome: cros_ec_typec: Get mux state inside configure_mux Prashant Malani
2022-02-08  5:35   ` Tzung-Bi Shih
2022-02-08  6:04     ` Prashant Malani
2022-02-07 21:40 ` [PATCH 3/4] platform/chrome: cros_ec_typec: Configure muxes at start of port update Prashant Malani
2022-02-08  5:38   ` Tzung-Bi Shih [this message]
2022-02-08  6:12     ` Prashant Malani
2022-02-08 11:15       ` Tzung-Bi Shih
2022-02-08 18:35         ` Prashant Malani
2022-02-08 22:58           ` Prashant Malani
2022-02-09  3:31             ` Tzung-Bi Shih
2022-02-09  3:41               ` Prashant Malani
2022-02-07 21:40 ` [PATCH 4/4] platform/chrome: cros_ec_typec: Update mux flags during partner removal Prashant Malani
2022-02-08  5:38   ` Tzung-Bi Shih
2022-02-08  6:15     ` Prashant Malani
2022-02-08 11:15       ` Tzung-Bi Shih

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YgIBv2SQdwXm7RLt@google.com \
    --to=tzungbi@google.com \
    --cc=bleung@chromium.org \
    --cc=chrome-platform@lists.linux.dev \
    --cc=groeck@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmalani@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.