* Re: [PATCH] platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags
2020-11-06 2:03 [PATCH] platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags Prashant Malani
@ 2020-11-17 19:09 ` Prashant Malani
2020-11-20 7:32 ` Heikki Krogerus
2020-12-10 21:19 ` Benson Leung
2 siblings, 0 replies; 5+ messages in thread
From: Prashant Malani @ 2020-11-17 19:09 UTC (permalink / raw)
To: linux-kernel, heikki.krogerus
Cc: Keith Short, Benson Leung, Enric Balletbo i Serra, Guenter Roeck
Including Heikki, who I forgot to add in the original patch email.
On Thu, Nov 05, 2020 at 06:03:05PM -0800, Prashant Malani wrote:
> On occasion, the Chrome Embedded Controller (EC) can send a mux
> configuration which doesn't map to a particular data mode. For instance,
> dedicated Type C chargers, when connected, may cause only
> USB_PD_MUX_POLARITY_INVERTED to be set. This is a valid flag combination
> and should not lead to a driver abort.
>
> Modify the mux configuration handling to not return an error when an
> unrecognized mux flag combination is encountered. Concordantly, make the
> ensuing print a debug level print so as to not pollute the kernel logs.
>
> Cc: Keith Short <keithshort@chromium.org>
> Signed-off-by: Prashant Malani <pmalani@chromium.org>
> ---
> drivers/platform/chrome/cros_ec_typec.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
> index ce031a10eb1b..5b8db02ab84a 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -537,10 +537,9 @@ static int cros_typec_configure_mux(struct cros_typec_data *typec, int port_num,
> port->state.mode = TYPEC_STATE_USB;
> ret = typec_mux_set(port->mux, &port->state);
> } else {
> - dev_info(typec->dev,
> - "Unsupported mode requested, mux flags: %x\n",
> - mux_flags);
> - ret = -ENOTSUPP;
> + dev_dbg(typec->dev,
> + "Unrecognized mode requested, mux flags: %x\n",
> + mux_flags);
> }
>
> return ret;
> --
> 2.29.1.341.ge80a0c044ae-goog
>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags
2020-11-06 2:03 [PATCH] platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags Prashant Malani
2020-11-17 19:09 ` Prashant Malani
@ 2020-11-20 7:32 ` Heikki Krogerus
2020-12-05 1:09 ` Prashant Malani
2020-12-10 21:19 ` Benson Leung
2 siblings, 1 reply; 5+ messages in thread
From: Heikki Krogerus @ 2020-11-20 7:32 UTC (permalink / raw)
To: Prashant Malani
Cc: linux-kernel, Keith Short, Benson Leung, Enric Balletbo i Serra,
Guenter Roeck
On Thu, Nov 05, 2020 at 06:03:05PM -0800, Prashant Malani wrote:
> On occasion, the Chrome Embedded Controller (EC) can send a mux
> configuration which doesn't map to a particular data mode. For instance,
> dedicated Type C chargers, when connected, may cause only
> USB_PD_MUX_POLARITY_INVERTED to be set. This is a valid flag combination
> and should not lead to a driver abort.
>
> Modify the mux configuration handling to not return an error when an
> unrecognized mux flag combination is encountered. Concordantly, make the
> ensuing print a debug level print so as to not pollute the kernel logs.
>
> Cc: Keith Short <keithshort@chromium.org>
> Signed-off-by: Prashant Malani <pmalani@chromium.org>
FWIW:
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> drivers/platform/chrome/cros_ec_typec.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
> index ce031a10eb1b..5b8db02ab84a 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -537,10 +537,9 @@ static int cros_typec_configure_mux(struct cros_typec_data *typec, int port_num,
> port->state.mode = TYPEC_STATE_USB;
> ret = typec_mux_set(port->mux, &port->state);
> } else {
> - dev_info(typec->dev,
> - "Unsupported mode requested, mux flags: %x\n",
> - mux_flags);
> - ret = -ENOTSUPP;
> + dev_dbg(typec->dev,
> + "Unrecognized mode requested, mux flags: %x\n",
> + mux_flags);
> }
>
> return ret;
> --
> 2.29.1.341.ge80a0c044ae-goog
thanks,
--
heikki
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags
2020-11-20 7:32 ` Heikki Krogerus
@ 2020-12-05 1:09 ` Prashant Malani
0 siblings, 0 replies; 5+ messages in thread
From: Prashant Malani @ 2020-12-05 1:09 UTC (permalink / raw)
To: Heikki Krogerus
Cc: Linux Kernel Mailing List, Keith Short, Benson Leung,
Enric Balletbo i Serra, Guenter Roeck
Friendly ping. If there are not other reservations, can we pick this
patch? It doesn't depend on any other patch series.
Thanks,
On Thu, Nov 19, 2020 at 11:32 PM Heikki Krogerus
<heikki.krogerus@linux.intel.com> wrote:
>
> On Thu, Nov 05, 2020 at 06:03:05PM -0800, Prashant Malani wrote:
> > On occasion, the Chrome Embedded Controller (EC) can send a mux
> > configuration which doesn't map to a particular data mode. For instance,
> > dedicated Type C chargers, when connected, may cause only
> > USB_PD_MUX_POLARITY_INVERTED to be set. This is a valid flag combination
> > and should not lead to a driver abort.
> >
> > Modify the mux configuration handling to not return an error when an
> > unrecognized mux flag combination is encountered. Concordantly, make the
> > ensuing print a debug level print so as to not pollute the kernel logs.
> >
> > Cc: Keith Short <keithshort@chromium.org>
> > Signed-off-by: Prashant Malani <pmalani@chromium.org>
>
> FWIW:
>
> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>
> > ---
> > drivers/platform/chrome/cros_ec_typec.c | 7 +++----
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
> > index ce031a10eb1b..5b8db02ab84a 100644
> > --- a/drivers/platform/chrome/cros_ec_typec.c
> > +++ b/drivers/platform/chrome/cros_ec_typec.c
> > @@ -537,10 +537,9 @@ static int cros_typec_configure_mux(struct cros_typec_data *typec, int port_num,
> > port->state.mode = TYPEC_STATE_USB;
> > ret = typec_mux_set(port->mux, &port->state);
> > } else {
> > - dev_info(typec->dev,
> > - "Unsupported mode requested, mux flags: %x\n",
> > - mux_flags);
> > - ret = -ENOTSUPP;
> > + dev_dbg(typec->dev,
> > + "Unrecognized mode requested, mux flags: %x\n",
> > + mux_flags);
> > }
> >
> > return ret;
> > --
> > 2.29.1.341.ge80a0c044ae-goog
>
> thanks,
>
> --
> heikki
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags
2020-11-06 2:03 [PATCH] platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags Prashant Malani
2020-11-17 19:09 ` Prashant Malani
2020-11-20 7:32 ` Heikki Krogerus
@ 2020-12-10 21:19 ` Benson Leung
2 siblings, 0 replies; 5+ messages in thread
From: Benson Leung @ 2020-12-10 21:19 UTC (permalink / raw)
To: Prashant Malani, linux-kernel
Cc: Enric Balletbo i Serra, Keith Short, Guenter Roeck
[-- Attachment #1: Type: text/plain, Size: 912 bytes --]
On Thu, 5 Nov 2020 18:03:05 -0800, Prashant Malani wrote:
> On occasion, the Chrome Embedded Controller (EC) can send a mux
> configuration which doesn't map to a particular data mode. For instance,
> dedicated Type C chargers, when connected, may cause only
> USB_PD_MUX_POLARITY_INVERTED to be set. This is a valid flag combination
> and should not lead to a driver abort.
>
> Modify the mux configuration handling to not return an error when an
> unrecognized mux flag combination is encountered. Concordantly, make the
> ensuing print a debug level print so as to not pollute the kernel logs.
Applied, thanks!
[1/1] platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags
commit: 6ae9b5ffcaeba64c290dfb8bd7b0194b1fdf0c92
Best regards,
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung@google.com
Chromium OS Project
bleung@chromium.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread