In cros_typec_remove_partner(), we call
cros_typec_usb_disconnect_state() which sets the switches/muxes to be in
a disconnected state. This also happens in cros_typec_configure_mux().
However, unlike there, here the mux_flags variable hasn't been updated
to reflect that a disconnection has occurred. Update the flag here
accordingly.
Signed-off-by: Prashant Malani <[email protected]>
---
drivers/platform/chrome/cros_ec_typec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
index 164c82f537dd..ce37b6abe69f 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -228,6 +228,7 @@ static void cros_typec_remove_partner(struct cros_typec_data *typec,
cros_typec_unregister_altmodes(typec, port_num, true);
cros_typec_usb_disconnect_state(port);
+ port->mux_flags = USB_PD_MUX_NONE;
typec_unregister_partner(port->partner);
port->partner = NULL;
--
2.35.0.263.gb82422642f-goog
Hi Tzung-Bi,
Thanks for reviewing the series.
On Mon, Feb 7, 2022 at 9:38 PM Tzung-Bi Shih <[email protected]> wrote:
>
> On Mon, Feb 07, 2022 at 09:40:30PM +0000, Prashant Malani wrote:
> > In cros_typec_remove_partner(), we call
> > cros_typec_usb_disconnect_state() which sets the switches/muxes to be in
> > a disconnected state. This also happens in cros_typec_configure_mux().
> > However, unlike there, here the mux_flags variable hasn't been updated
> > to reflect that a disconnection has occurred. Update the flag here
> > accordingly.
>
> It is fine (at least to me) usually.
>
> Since you would need to respin the series anyway, s/Update/Updates/.
Again, "update" is fine. Please see:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes
Quoting from the above: " Describe your changes in imperative mood,"
So, imperative usage is actually preferred, and "updates/makes" is discouraged.
(I grabbed an older version of the documentation in my other replies,
but the description is the same).
Thanks!
On Mon, Feb 07, 2022 at 09:40:30PM +0000, Prashant Malani wrote:
> In cros_typec_remove_partner(), we call
> cros_typec_usb_disconnect_state() which sets the switches/muxes to be in
> a disconnected state. This also happens in cros_typec_configure_mux().
> However, unlike there, here the mux_flags variable hasn't been updated
> to reflect that a disconnection has occurred. Update the flag here
> accordingly.
It is fine (at least to me) usually.
Since you would need to respin the series anyway, s/Update/Updates/.
On Mon, Feb 07, 2022 at 10:15:12PM -0800, Prashant Malani wrote:
> On Mon, Feb 7, 2022 at 9:38 PM Tzung-Bi Shih <[email protected]> wrote:
> > On Mon, Feb 07, 2022 at 09:40:30PM +0000, Prashant Malani wrote:
> > > In cros_typec_remove_partner(), we call
> > > cros_typec_usb_disconnect_state() which sets the switches/muxes to be in
> > > a disconnected state. This also happens in cros_typec_configure_mux().
> > > However, unlike there, here the mux_flags variable hasn't been updated
> > > to reflect that a disconnection has occurred. Update the flag here
> > > accordingly.
> >
> > It is fine (at least to me) usually.
> >
> > Since you would need to respin the series anyway, s/Update/Updates/.
>
> Again, "update" is fine. Please see:
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes
>
> Quoting from the above: " Describe your changes in imperative mood,"
>
> So, imperative usage is actually preferred, and "updates/makes" is discouraged.
Ack, thanks for correcting my so-long-time misunderstanding.