On Tue, Apr 02, 2019 at 03:47:47PM +0300, Heikki Krogerus wrote:
On Mon, Apr 01, 2019 at 02:45:11PM +0200, Hans de Goede wrote:
HI,
On 01-04-19 14:40, Heikki Krogerus wrote:
On Mon, Apr 01, 2019 at 12:34:29PM +0200, Greg KH wrote:
On Mon, Apr 01, 2019 at 01:15:53PM +0300, Heikki Krogerus 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.
Fixes: 3e3b81965cbf ("usb: typec: mux: Take care of driver module reference counting") Cc: v4.19.x stable@vger.kernel.org # v4.19.x+ Signed-off-by: Heikki Krogerus heikki.krogerus@linux.intel.com
This looks good to me, nice work!
But, it would be nice if someone who has this hardware can test it to verify it does actually work :)
This alone does not work on Intel Cherrytrail platforms. I need to make the Intel Cherrytrail MFD driver (intel_cht_int33fe.c) to use the new device names that we now have for the muxes. Sorry for the mistake.
I'll resend this and include the needed modifications to intel_cht_int33fe.c. Hans should be able to test this once I do that. I hope he has time.
Yes I need to get back to the CherryTrail Type-C stuff we discussed a while back anyways. On which tree/branch should I test v2 of this patch(series) ?
Greg's usb-next.
I just realized that the potential NULL pointer dereference that this patch is meant to fix can't happen until my "software node reference" modifications [1] have been applied. I don't think this needs to be considered a fix.
I think the correct way to handle this patch is to make just it part of that series. I'll resend the series, and include this patch in it.
[1] https://lkml.org/lkml/2019/3/15/457
thanks,