From: Guenter Roeck <linux@roeck-us.net>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Vincent Palatin <vpalatin@chromium.org>,
Greg KH <gregkh@linuxfoundation.org>,
Oliver Neukum <oneukum@suse.com>,
Felipe Balbi <felipe.balbi@linux.intel.com>,
Bin Gao <bin.gao@linux.intel.com>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCHv6 1/3] usb: USB Type-C connector class
Date: Mon, 29 Aug 2016 11:50:49 -0700 [thread overview]
Message-ID: <20160829185049.GA7316@roeck-us.net> (raw)
In-Reply-To: <20160829140739.GA10151@kuha.fi.intel.com>
Hello Heikki,
On Mon, Aug 29, 2016 at 05:07:39PM +0300, Heikki Krogerus wrote:
> Hi Guenter,
>
> > > Overall this is quite vague and, especially for chargers, most of the time
> > > misses the point.
> > >
> > > I would really prefer if we could stay closer to the specification in this
> > > case, and not try to merge multiple orthogonal attributes into one.
> >
> > OK. So what would you propose?
>
> I'm actually only conserned about the accessory case, as there we are
> really not a source/sink/DRP, nor are we DPF/UFP/DRD. Should we use
> this attribute to only express if the type of the partner is "normal"
> or an accessory?
>
We currently have three attributes to cover accessory modes.
supported_accessory_modes
Lists the Accessory Modes, defined in the USB Type-C
specification, the port supports.
[ This is a bit vague. I think we should list the actual strings.
The modes are called "Audio Adapter Accessory Mode" and "Debug
Accessory Mode", yet the reported text is "Audio" and "Debug".
Also, "Digital Audio" isn't supported as of specification revision
1.2. So the strings doesn't exactly follow the specification. ]
accessory
Shows the name of the Accessory Mode. The Accessory Modes are
defined in USB Type-C Specification.
type
Shows the type of the partner.
One of the possible accessory modes is TYPEC_ACCESSORY_NONE.
If you are only interested in accessory mode support, maybe we don't need
the 'type' attribute at all. We could make the 'accessory' attribute always
visible and display one of "none", "Audio", "Debug", or "Digital Audio".
It might also make sense to rename the attribute to "accessory_mode".
On a side note, while looking into this, I noticed the following:
+ if (port->cap->accessory)
+ for (accessory = port->cap->accessory, i = 0;
+ i < port->cap->num_accessory; accessory++, i++)
+ ret += sprintf(buf, "%s\n",
+ typec_accessory_modes[*accessory]);
This means the list of supported accessories always starts with ", ".
Thanks,
Guenter
next prev parent reply other threads:[~2016-08-29 20:05 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-22 12:05 [PATCHv6 0/3] USB Type-C Connector class Heikki Krogerus
2016-08-22 12:05 ` [PATCHv6 1/3] usb: USB Type-C connector class Heikki Krogerus
2016-08-24 14:08 ` Vincent Palatin
2016-08-25 11:59 ` Heikki Krogerus
2016-08-26 13:16 ` Vincent Palatin
2016-08-26 14:07 ` Heikki Krogerus
2016-08-29 13:04 ` Guenter Roeck
2016-08-29 13:43 ` Heikki Krogerus
2016-08-29 14:07 ` Heikki Krogerus
2016-08-29 18:50 ` Guenter Roeck [this message]
2016-08-30 8:22 ` Heikki Krogerus
2016-08-30 15:28 ` Guenter Roeck
2016-08-30 17:00 ` Guenter Roeck
2016-08-22 12:05 ` [PATCHv6 2/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY Heikki Krogerus
2016-08-22 12:06 ` [PATCHv6 3/3] mfd: intel_soc_pmic_bxtwc: add support for USB Type-C PHY on WhiskeyCove Heikki Krogerus
-- strict thread matches above, loose matches on Subject: below --
2016-08-29 12:36 [PATCHv6 0/3] USB Type-C Connector class Heikki Krogerus
2016-08-29 12:36 ` [PATCHv6 1/3] usb: USB Type-C connector class Heikki Krogerus
2016-08-29 13:06 ` Vincent Palatin
2016-08-30 9:32 ` Oliver Neukum
2016-08-30 10:04 ` Heikki Krogerus
2016-08-30 11:16 ` Oliver Neukum
2016-08-30 11:49 ` Heikki Krogerus
2016-08-30 13:11 ` Heikki Krogerus
2016-08-30 13:47 ` Guenter Roeck
2016-08-31 11:09 ` Heikki Krogerus
2016-08-31 13:18 ` Guenter Roeck
2016-08-30 13:46 ` Guenter Roeck
2016-08-30 14:13 ` Heikki Krogerus
2016-08-30 15:40 ` Guenter Roeck
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=20160829185049.GA7316@roeck-us.net \
--to=linux@roeck-us.net \
--cc=bin.gao@linux.intel.com \
--cc=felipe.balbi@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=oneukum@suse.com \
--cc=vpalatin@chromium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).