linux-kernel - Re: [PATCH v2 08/12] usb: typec: Registering real device entries for the muxes

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 11 Apr 2019 15:34:33 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Hans de Goede <hdegoede@...hat.com>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>
Subject: Re: [PATCH v2 08/12] usb: typec: Registering real device entries for
 the muxes

On Wed, Apr 10, 2019 at 6:25 PM Heikki Krogerus
<heikki.krogerus@...ux.intel.com> wrote:
>
> Registering real device entries (struct device) for the mode
> muxes as well as for the orientation switches.
>
> The Type-C mux code was deliberately attempting to avoid
> creation of separate device entries for the orientation
> switch and the mode switch (alternate modes) because they
> are not physical devices. They are functions of a single
> physical multiplexer/demultiplexer switch device.
>
> Unfortunately because of the dependency we still have on the
> underlying mux device driver, we had to put in hacks like
> the one in the commit 3e3b81965cbf ("usb: typec: mux: Take
> care of driver module reference counting") to make sure the
> driver does not disappear from underneath us. Even with
> those hacks we were still left with a potential NUll pointer
> dereference scenario, so just creating the device entries,
> and letting the core take care of the dependencies. No more
> hacks needed.

>  drivers/platform/x86/intel_cht_int33fe.c |   4 +-

> diff --git a/drivers/platform/x86/intel_cht_int33fe.c b/drivers/platform/x86/intel_cht_int33fe.c
> index 6fa3cced6f8e..657b8d61554c 100644
> --- a/drivers/platform/x86/intel_cht_int33fe.c
> +++ b/drivers/platform/x86/intel_cht_int33fe.c
> @@ -173,10 +173,10 @@ static int cht_int33fe_probe(struct platform_device *pdev)
>         }
>
>         data->connections[0].endpoint[0] = "port0";
> -       data->connections[0].endpoint[1] = "i2c-pi3usb30532";
> +       data->connections[0].endpoint[1] = "i2c-pi3usb30532-switch";
>         data->connections[0].id = "orientation-switch";
>         data->connections[1].endpoint[0] = "port0";
> -       data->connections[1].endpoint[1] = "i2c-pi3usb30532";
> +       data->connections[1].endpoint[1] = "i2c-pi3usb30532-mux";
>         data->connections[1].id = "mode-switch";
>         data->connections[2].endpoint[0] = "i2c-fusb302";
>         data->connections[2].endpoint[1] = "intel_xhci_usb_sw-role-switch";

Reviewed-by: Andy Shevchenko <andy.shevchenko@...il.com>

-- 
With Best Regards,
Andy Shevchenko