linux-kernel - Re: [PATCH] platform/chrome: Avoid fetching the type-C parameters again

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACeCKad1suBNrpPOtKnHaLZmLEpgV4ExA53ermqv50viSSnLdA@mail.gmail.com>
Date:   Mon, 6 Feb 2023 11:55:57 -0800
From:   Prashant Malani <pmalani@...omium.org>
To:     Rajat Khandelwal <rajat.khandelwal@...ux.intel.com>
Cc:     bleung@...omium.org, groeck@...omium.org,
        chrome-platform@...ts.linux.dev, linux-kernel@...r.kernel.org,
        rajat.khandelwal@...el.com
Subject: Re: [PATCH] platform/chrome: Avoid fetching the type-C parameters again

Hi Rajat,

Please use the right header in the commit message. There are plenty of
examples in the git log.

On Sun, Feb 5, 2023 at 11:34 PM Rajat Khandelwal
<rajat.khandelwal@...ux.intel.com> wrote:
>
> The struct 'cros_typec_port' incorporates three type-C parameters,
> 'ori_sw', 'retimer', and 'mux'.
> These parameters in the struct 'typec_port' are being already
> configured when 'typec_register_port' is being called.
>
> The bigger picture - 'typec_register_port' can return an error and
> the type-C parameters could go unconfigured. However, the callback
> will return EPROBE_DEFER and the driver will again be getting probed
> trying to configure them again.
> However, currently, they are again tried to get fetched for the
> 'cros_typec_port' struct, which sometimes could result in an error
> and these parameters could go unconfigured (no provision of deferring
> the probe in this case, so we are left with unconfigured parameters).

This is by design. If the switch handles cannot be obtained for any reason
other that -EPROBE_DEFER, we will not re-attempt to acquire them, and
should continue driver probe and carry on with limited functionality.

If there is a sporadic error other than -EPROBE_DEFER, that points to a
deeper issue in firmware which should be investigated.

>
> Hence, assign the parameters to the corresponding ones in the struct
> 'typec_port' after they are fetched in 'typec_register_port'.
>
> Signed-off-by: Rajat Khandelwal <rajat.khandelwal@...ux.intel.com>
> ---
>  drivers/platform/chrome/cros_ec_typec.c | 58 ++++++++++---------------
>  1 file changed, 22 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
> index 001b0de95a46..0265c0d38bd6 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -24,6 +24,8 @@
>  #include <linux/usb/typec_tbt.h>
>  #include <linux/usb/role.h>
>
> +#include "../../usb/typec/class.h"

That is a local header. We cannot use it outside of drivers/usb/typec/

> +
>  #define DRV_NAME "cros-ec-typec"
>
>  #define DP_PORT_VDO    (DP_CONF_SET_PIN_ASSIGN(BIT(DP_PIN_ASSIGN_C) | BIT(DP_PIN_ASSIGN_D)) | \
> @@ -141,47 +143,17 @@ static int cros_typec_parse_port_props(struct typec_capability *cap,
>         return 0;
>  }
>
> -static int cros_typec_get_switch_handles(struct cros_typec_port *port,
> -                                        struct fwnode_handle *fwnode,
> -                                        struct device *dev)
> +static int cros_typec_get_role_switch_handle(struct cros_typec_port *port,
> +                                            struct fwnode_handle *fwnode,
> +                                            struct device *dev)
>  {
> -       port->mux = fwnode_typec_mux_get(fwnode, NULL);
> -       if (IS_ERR(port->mux)) {
> -               dev_dbg(dev, "Mux handle not found.\n");
> -               goto mux_err;
> -       }
> -
> -       port->retimer = fwnode_typec_retimer_get(fwnode);
> -       if (IS_ERR(port->retimer)) {
> -               dev_dbg(dev, "Retimer handle not found.\n");
> -               goto retimer_sw_err;
> -       }
> -
> -       port->ori_sw = fwnode_typec_switch_get(fwnode);
> -       if (IS_ERR(port->ori_sw)) {
> -               dev_dbg(dev, "Orientation switch handle not found.\n");
> -               goto ori_sw_err;
> -       }
> -
>         port->role_sw = fwnode_usb_role_switch_get(fwnode);
>         if (IS_ERR(port->role_sw)) {
>                 dev_dbg(dev, "USB role switch handle not found.\n");
> -               goto role_sw_err;
> +               return -ENODEV;
>         }
>
>         return 0;
> -
> -role_sw_err:
> -       typec_switch_put(port->ori_sw);
> -       port->ori_sw = NULL;
> -ori_sw_err:
> -       typec_retimer_put(port->retimer);
> -       port->retimer = NULL;
> -retimer_sw_err:
> -       typec_mux_put(port->mux);
> -       port->mux = NULL;
> -mux_err:
> -       return -ENODEV;
>  }
>
>  static int cros_typec_add_partner(struct cros_typec_data *typec, int port_num,
> @@ -363,6 +335,18 @@ static int cros_typec_register_port_altmodes(struct cros_typec_data *typec,
>         return 0;
>  }
>
> +static void cros_typec_copy_port_params(struct cros_typec_port *cros_port)
> +{
> +       struct typec_port *port = cros_port->port;
> +
> +       if (IS_ERR_OR_NULL(port))
> +               return;
> +
> +       cros_port->mux = port->mux;
> +       cros_port->retimer = port->retimer;
> +       cros_port->ori_sw = port->sw;
> +}

Sorry, but this is not the right approach. These handles are
ref-counted. We intentionally
take extra references to these using the provided API. Please don't
use raw references like this.

Also, if the fwnode_*_get() functions are failing, why are we to
assume that they worked for the
Type-C class code (that code uses the same functions) [1] ?

This approach is not right.

BR,

-Prashant


[1] https://elixir.bootlin.com/linux/v6.2-rc7/source/drivers/usb/typec/class.c#L2317