Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1527540 > unrolled thread

[PATCHv12 0/3] USB Type-C Connector class

Started byHeikki Krogerus <heikki.krogerus@linux.intel.com>
First post2016-11-22 15:20 +0100
Last post2016-11-24 11:00 +0100
Articles 4 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCHv12 0/3] USB Type-C Connector class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-11-22 15:20 +0100
    Re: [PATCHv12 0/3] USB Type-C Connector class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-11-23 16:10 +0100
    Re: [PATCHv12 2/3] usb: USB Type-C connector class Guenter Roeck <linux@roeck-us.net> - 2016-11-24 06:20 +0100
      Re: [PATCHv12 2/3] usb: USB Type-C connector class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-11-24 11:00 +0100

#1527540 — [PATCHv12 0/3] USB Type-C Connector class

FromHeikki Krogerus <heikki.krogerus@linux.intel.com>
Date2016-11-22 15:20 +0100
Subject[PATCHv12 0/3] USB Type-C Connector class
Message-ID<sGk5r-8hE-11@gated-at.bofh.it>
The USB Type-C class is meant to provide unified interface to the
userspace to present the USB Type-C ports in a system.

Changes since v11:
- The port drivers are responsible of removing the alternate
  modes (just like the documentation already said).

Changes since v10:
- Using ATTRIBUTE_GROUPS and DEVICE_ATTR marcos everywhere
- Moved sysfs_match_string to lib/string.c
- Rationalized uevents
- Calling ida_destroy

Changes since v9:
- Minor typec_wcove.c cleanup as proposed by Guenter Roeck. No
  function affect.

Changes since v8:
- checking sysfs_streq() result correctly in sysfs_strmatch
- fixed accessory check in supported_accessory_mode
- using "none" as the only string that can clear the preferred role

Changes since v7:
- Removed "type" attribute from partners
- Added supports_usb_power_delivery attribute for partner and cable

Changes since v6:
- current_vconn_role attr renamed to vconn_source (no API changes)
- Small documentation improvements proposed by Vincent Palatin

Changes since v5:
- Only updating the roles based on driver notifications
- Added MODULE_ALIAS for the WhiskeyCove module
- Including the patch that creates the actual platform device for the
  WhiskeyCove Type-C PHY in this series.

Changes since v4:
- Remove the port lock completely

Changes since v3:
- Documentation cleanup as proposed by Roger Quadros
- Setting partner altmodes member to NULL on removal and fixing a
  warning, as proposed by Guenter Roeck
- Added the following attributes for partners and cables:
  * supports_usb_power_delivery
  * id_header_vdo
- "id_header_vdo" is visible only when the partner or cable supports
  USB Power Delivery communication.
- Partner attribute "accessory" is hidden when the partner type is not
  "Accessory".

Changes since v2:
- Notification on role and alternate mode changes
- cleanups

Changes since v1:
- Completely rewrote alternate mode support
- Patners, cables and cable plugs presented as devices.


Heikki Krogerus (3):
  lib/string: add sysfs_match_string helper
  usb: USB Type-C connector class
  usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY

 Documentation/ABI/testing/sysfs-class-typec |  222 ++++++
 Documentation/usb/typec.txt                 |  103 +++
 MAINTAINERS                                 |    9 +
 drivers/usb/Kconfig                         |    2 +
 drivers/usb/Makefile                        |    2 +
 drivers/usb/typec/Kconfig                   |   21 +
 drivers/usb/typec/Makefile                  |    2 +
 drivers/usb/typec/typec.c                   | 1013 +++++++++++++++++++++++++++
 drivers/usb/typec/typec_wcove.c             |  372 ++++++++++
 include/linux/string.h                      |   10 +
 include/linux/usb/typec.h                   |  252 +++++++
 lib/string.c                                |   26 +
 12 files changed, 2034 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-typec
 create mode 100644 Documentation/usb/typec.txt
 create mode 100644 drivers/usb/typec/Kconfig
 create mode 100644 drivers/usb/typec/Makefile
 create mode 100644 drivers/usb/typec/typec.c
 create mode 100644 drivers/usb/typec/typec_wcove.c
 create mode 100644 include/linux/usb/typec.h

-- 
2.10.2

[toc] | [next] | [standalone]


#1528473

FromHeikki Krogerus <heikki.krogerus@linux.intel.com>
Date2016-11-23 16:10 +0100
Message-ID<sGHln-6uU-3@gated-at.bofh.it>
In reply to#1527540
Hi Guenter,

On Tue, Nov 22, 2016 at 04:11:44PM +0200, Heikki Krogerus wrote:
> The USB Type-C class is meant to provide unified interface to the
> userspace to present the USB Type-C ports in a system.
> 
> Changes since v11:
> - The port drivers are responsible of removing the alternate
>   modes (just like the documentation already said).

Can you check these, and give your ACK again if they OK.


Thanks,

-- 
heikki

[toc] | [prev] | [next] | [standalone]


#1528993 — Re: [PATCHv12 2/3] usb: USB Type-C connector class

FromGuenter Roeck <linux@roeck-us.net>
Date2016-11-24 06:20 +0100
SubjectRe: [PATCHv12 2/3] usb: USB Type-C connector class
Message-ID<sGUBX-6tB-1@gated-at.bofh.it>
In reply to#1527540
Hello Heikki,

On 11/22/2016 06:11 AM, Heikki Krogerus wrote:
[ ... ]
> +
> +struct typec_port *typec_register_port(struct device *dev,
> +				       const struct typec_capability *cap)
> +{
> +	struct typec_port *port;
> +	int ret;
> +	int id;
> +
> +	port = kzalloc(sizeof(*port), GFP_KERNEL);
> +	if (!port)
> +		return ERR_PTR(-ENOMEM);
> +
> +	id = ida_simple_get(&typec_index_ida, 0, 0, GFP_KERNEL);
> +	if (id < 0) {
> +		kfree(port);
> +		return ERR_PTR(id);
> +	}
> +
> +	port->prefer_role = TYPEC_NO_PREFERRED_ROLE;
> +

Following up on this:

In our implementation, the default preferred role is determined by the
low level driver (as, in my understanding, is suggested by the standard).
This means that the ABI will report "no preferred role", unless user space
overwrites it, even though there _is_ in fact a preferred role, and the
low level driver will execute try.src or try.snk based on that role.

It might make sense to add the preferred role to struct typec_capability
and get the initial value from there. If a low level driver does not want
to specify it, it can easily set its value to TYPEC_NO_PREFERRED_ROLE.

Thanks,
Guenter

[toc] | [prev] | [next] | [standalone]


#1529117 — Re: [PATCHv12 2/3] usb: USB Type-C connector class

FromHeikki Krogerus <heikki.krogerus@linux.intel.com>
Date2016-11-24 11:00 +0100
SubjectRe: [PATCHv12 2/3] usb: USB Type-C connector class
Message-ID<sGYYV-Vx-5@gated-at.bofh.it>
In reply to#1528993
On Wed, Nov 23, 2016 at 09:12:04PM -0800, Guenter Roeck wrote:
> Hello Heikki,
> 
> On 11/22/2016 06:11 AM, Heikki Krogerus wrote:
> [ ... ]
> > +
> > +struct typec_port *typec_register_port(struct device *dev,
> > +				       const struct typec_capability *cap)
> > +{
> > +	struct typec_port *port;
> > +	int ret;
> > +	int id;
> > +
> > +	port = kzalloc(sizeof(*port), GFP_KERNEL);
> > +	if (!port)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	id = ida_simple_get(&typec_index_ida, 0, 0, GFP_KERNEL);
> > +	if (id < 0) {
> > +		kfree(port);
> > +		return ERR_PTR(id);
> > +	}
> > +
> > +	port->prefer_role = TYPEC_NO_PREFERRED_ROLE;
> > +
> 
> Following up on this:
> 
> In our implementation, the default preferred role is determined by the
> low level driver (as, in my understanding, is suggested by the standard).
> This means that the ABI will report "no preferred role", unless user space
> overwrites it, even though there _is_ in fact a preferred role, and the
> low level driver will execute try.src or try.snk based on that role.

I'm not sure which standard are you referring? Try.SNK and Try.SRC are
optional mechanisms for *policy-based* role preference according to
the USB Type-C spec. The policy really should always come from the
user space in our case, but I don't think that rules out for example
initial role preferences coming from the lower level drivers.

We will need a way the OS can set the initial preference for every
port. Note that once we can support that, what ever the lower level
drivers request will be overridden by it. So if for example the
platform has preference for an initial role, we will simply ignore it
if the policy says otherwise.

> It might make sense to add the preferred role to struct typec_capability
> and get the initial value from there. If a low level driver does not want
> to specify it, it can easily set its value to TYPEC_NO_PREFERRED_ROLE.

Well, ideally the port drivers would not need to do anything if there
is no preference, but I don't think it's a problem. Since this is API,
I guess we can even change this later if we come up with a better way
of doing this. I'll add it.


Thanks,

-- 
heikki

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web