All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Oliver Neukum <oneukum@suse.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCHv14 2/3] usb: USB Type-C connector class
Date: Wed, 11 Jan 2017 13:05:32 +0200	[thread overview]
Message-ID: <20170111110532.GE18258@kuha.fi.intel.com> (raw)
In-Reply-To: <20170110173542.GA29970@roeck-us.net>

Hi Guenter,

On Tue, Jan 10, 2017 at 09:35:42AM -0800, Guenter Roeck wrote:
> > I guess we might as well then split the VDO into header, cert stat and
> > product parts. What do you think?
> > 
> > If it's OK, then should we change that file to "identity" and dump the
> > whole response from Discover Identity command in hex (minus VDM
> > Header), separate the parts in the output, or simply provide separate
> > attribute files for each part?
> > 
> Makes me wonder what you expect in the vdo attribute today. Right now
> I copy the value from the identity header into it.
> 
> Personally I would prefer separate attributes. identity, cert_stat,
> product, maybe ?

OK.

I'm sorry for bringing this up so late, but I'm still a bit concerned
about having those attributes because we can't provide a value for
them in every system even when USB power delivery is supported. This
will be the case with at least with UCSI systems.

So what I'll do is, I'll group them into separate directory that will
not be visible unless those values can actually be made available. We
will have "supports_usb_power_delivery" attribute out side that
directory.

We can name that directory "identity" or we can call it for example
"usb_power_delivery" and have something else usb pd specific in it as
well if you like, like attribute for capability. Let me know what you
think.

I proposed putting the usb pd details into separate directory already
at one point, but not everybody liked the idea if I remember
correctly. I don't think there were any real arguments against it, so
this time I'll add the group unless you disagree.


Thanks,

-- 
heikki

  reply	other threads:[~2017-01-11 11:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-05 11:01 [PATCHv14 0/3] USB Type-C Connector class Heikki Krogerus
2017-01-05 11:01 ` [PATCHv14 1/3] lib/string: add sysfs_match_string helper Heikki Krogerus
2017-01-05 11:01 ` [PATCHv14 2/3] usb: USB Type-C connector class Heikki Krogerus
2017-01-05 15:54   ` Mika Westerberg
2017-01-05 16:40     ` Greg KH
2017-01-06 10:54     ` Heikki Krogerus
2017-01-06 15:47       ` Guenter Roeck
2017-01-10 10:08       ` Oliver Neukum
2017-01-11  7:57         ` Heikki Krogerus
2017-01-11  9:05           ` Oliver Neukum
2017-01-09 16:59   ` Guenter Roeck
2017-01-10  8:54     ` Heikki Krogerus
2017-01-10 13:50       ` Guenter Roeck
2017-01-10 14:46         ` Heikki Krogerus
2017-01-10 17:35           ` Guenter Roeck
2017-01-11 11:05             ` Heikki Krogerus [this message]
2017-01-05 11:01 ` [PATCHv14 3/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY 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=20170111110532.GE18258@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mika.westerberg@linux.intel.com \
    --cc=oneukum@suse.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.