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

Andy Shevchenko
2019-04-11T12:34:47Z

On Wed, Apr 10, 2019 at 6:25 PM Heikki Krogerus
<heikki.krogerus@linux.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@gmail.com>

--
With Best Regards,
Andy Shevchenko