All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Michael Hsu <mhsu@nvidia.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Ajay Gupta <ajayg@nvidia.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: [4/5] usb: typec: ucsi: Preliminary support for alternate modes
Date: Mon, 18 Feb 2019 16:11:40 +0200	[thread overview]
Message-ID: <20190218141140.GA1626@kuha.fi.intel.com> (raw)

Hi,

On Sat, Feb 16, 2019 at 01:36:05AM +0000, Michael Hsu wrote:
> > I think for clarity's sake I better fix the mode index issue now and send second
> > version of these patches so we can concentrate on the bigger problem, the two
> > connector DP alt modes.
> > 
> 
> Agreed.  Please update your patch for the mode index issue (being able to
> reliably match partner mode index with the connector mode index returned by
> UCSI).

I'll finish some other task before coming back to this. We shouldn't
be in any hurry with this. These are not going to v5.1 in any case.

> > > Here's a method of avoiding the above dilemma:
> > > - create partner sysfs alt mode nodes using UCSI GET_ALT_MODES (with
> > > recipient == connector)
> > > - also query UCSI GET_SUPPORTED_CAM
> > > - create partner sysfs alt modes only if GET_SUPPORT_CAM returns 1 bit
> > > for a particular connector alt mode index
> > 
> > No! We must not hide stuff like that from the user. Even if the connector does
> > not support a partner mode, we still show it to the user space.
> > 
> 
> OK, but this means the "active" sysfs node for a partner mode (which is not
> supported by GET_SUPPORTED_CAM) will always show "no".  And writing "yes"
> to it will silently fail...

They will not always say "no", but you can not change the value
without an alternate mode driver.

> Did this intentional?  Having some partner sysfs "active" nodes which do
> nothing without any warning to user that they don't work?

The key here is the driver. The user will know that partner alternate
mode can't be operated unless it has been bind to a driver. The ABI
for the alternate modes is defined for the typec bus, not the class.

So in real world the user space applications will not start doing
anything with an alternate mode, other than possible notifying the
user of its existence, until the user space sees kernel event
indicating that the alternate mode has been bind to a driver.


Br,

             reply	other threads:[~2019-02-18 14:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-18 14:11 Heikki Krogerus [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-02-16  1:36 [4/5] usb: typec: ucsi: Preliminary support for alternate modes Michael Hsu
2019-02-12 15:22 Heikki Krogerus
2019-02-11 23:43 Michael Hsu
2019-02-08 13:48 Heikki Krogerus
2019-02-07 22:01 Michael Hsu
2019-02-07 13:15 Heikki Krogerus
2019-02-06 22:36 Michael Hsu
2019-02-06  9:06 Heikki Krogerus
2019-02-06  8:30 Heikki Krogerus
2019-02-05 15:24 Heikki Krogerus
2019-02-05  2:20 Michael Hsu
2019-02-05  0:59 Ajay Gupta
2019-02-04 12:09 Heikki Krogerus
2019-02-01 22:02 Michael Hsu
2019-02-01 10:47 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=20190218141140.GA1626@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=ajayg@nvidia.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mhsu@nvidia.com \
    /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.