All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, stable@vger.kernel.org
Subject: usb: typec: Registering real device entries for the muxes
Date: Tue, 2 Apr 2019 15:47:47 +0300	[thread overview]
Message-ID: <20190402124747.GH9993@kuha.fi.intel.com> (raw)

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.

thanks,

WARNING: multiple messages have this Message-ID (diff)
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] usb: typec: Registering real device entries for the muxes
Date: Tue, 2 Apr 2019 15:47:47 +0300	[thread overview]
Message-ID: <20190402124747.GH9993@kuha.fi.intel.com> (raw)
In-Reply-To: <7a741768-af29-da82-4539-f97e49a17a56@redhat.com>

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.

thanks,

-- 
heikki

             reply	other threads:[~2019-04-02 12:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-02 12:47 Heikki Krogerus [this message]
2019-04-02 12:47 ` [PATCH] usb: typec: Registering real device entries for the muxes Heikki Krogerus
  -- strict thread matches above, loose matches on Subject: below --
2019-04-03 10:29 Heikki Krogerus
2019-04-03 10:29 ` [PATCH] " Heikki Krogerus
2019-04-02  7:35 kbuild test robot
2019-04-02  7:35 ` [PATCH] " kbuild test robot
2019-04-01 12:45 Hans de Goede
2019-04-01 12:45 ` [PATCH] " Hans de Goede
2019-04-01 12:40 Heikki Krogerus
2019-04-01 12:40 ` [PATCH] " Heikki Krogerus
2019-04-01 10:34 Greg Kroah-Hartman
2019-04-01 10:34 ` [PATCH] " Greg KH
2019-04-01 10:15 Heikki Krogerus
2019-04-01 10:15 ` [PATCH] " Heikki Krogerus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190402124747.GH9993@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.