Re: [PATCH 2/3] usb: typec: Add support for UCSI interface

2017-06-03 Thread Greg KH 
On Thu, May 25, 2017 at 06:20:16AM -0700, Guenter Roeck wrote:
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> Any preference in usb about alphabetic order of include files ?

Nope, whatever order the author wants to put them in is fine with me.
I'm not _that_ pedantic :)

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] usb: typec: Add support for UCSI interface

2017-05-29 Thread Guenter Roeck 

On 05/29/2017 05:33 AM, Heikki Krogerus wrote:

On Fri, May 26, 2017 at 06:26:01AM -0700, Guenter Roeck wrote:

What happens if trace is not enabled ? If I recall discussions around CLANG
correctly, it complains about unused static inline functions.


Nothing happens if trace is not enable. Everything continues to
compile just like before.

Maybe you were trying to define the tracepoints in C code? That won't
work.


Anyway, is it really necessary to have an include file for this instead of
keeping the code in trace.c ? I am somewhat wary of variable declarations
in include files - include twice and there will be two instances.


The tracepoint documentation actually states that you need to place the
definitions of the tracepoints in a header. I have the trace.c file only
because it was a convenient place to put the tracepoint statement in.

I don't know the inner workings of tracepoints, but they do work fine
for me. In case you want more info on the topic, I never read these
articles, but they were mentioned in Documentation/trace/tracepoints.txt:

http://lwn.net/Articles/379903
http://lwn.net/Articles/381064
http://lwn.net/Articles/383362

I believe they provide at least some kind of description on how
tracepoints actually work.


Sorry for not being clear; that was a question about your code, not mine.
If it builds without warnings with trace disabled, no problem.


Ah, of course. Silly me. Sorry about that.


+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


Any preference in usb about alphabetic order of include files ?


I don't see any mention of it in the documentation, so this is
probable just matter of taste in the end. One likes the mother, one
likes the daughter.



I like alphabetic because it makes life easier later on, if/when additional
include files are added, and it is easier to find a specific include file in
an alphabetic list. Some upstream maintainers ask for it nowadays (including me 
:-).


It's good to keep the headers in some order just for the sake of being
organized, but I don't see how alphabetical order is any better then
for example descending.



Now we are really down to bikeshedding, which is where I tend to sign off.


I normally would not care about this topic and I would have just
ordered the headers alphabetically if anybody asked for it, but I've
actually proposed ordering the headers alphabetically myself ones, and
this is what the upstream maintainer said: "Can we stick to serious
critiques"

I think some maintainers do not see the need to dictate styling rules
on everything, and leave some things to be decided by the developer. I
kind of like that.

But if you still feel strongly about this, I'll change the style, but
for now, I'll keep it the way it is. Actually, I'll move the last one
on top.



I am not the maintainer, so, no, I don't have a strong opinion.

Guenter


+/**
+ * ucsi_notify - PPM notification handler
+ * @ucsi: Source UCSI Interface for the notifications
+ *
+ * Handle notifications from PPM of @ucsi.
+ */
+void ucsi_notify(struct ucsi *ucsi)
+{
+   struct ucsi_cci *cci;
+
+   /* There is no requirement to sync here, so only warning if it fails */
+   if (ucsi_sync(ucsi))
+   dev_warn(ucsi->dev, "%s: sync failed\n", __func__);
+

Why even a warning if it is not a requirement ?


It still should not "ever" fail. Why not create the warning? It is
after all indication that something is really wrong, and we probable
want to know about it.


Your call, of course. I just dislike noisy drivers, and I am always concerned
about flooding the kernel log.


Fair enough, I'll remove the warning.


+static int
+ucsi_dr_swap(const struct typec_capability *cap, enum typec_data_role role)
+{
+   struct ucsi_connector *con = to_ucsi_connector(cap);
+   struct ucsi_control ctrl;
+   int ret = 0;
+
+   if (!con->partner)
+   return -EAGAIN;


Doesn't this result in an immediate retry by user space ?


Isn't that what tcpm.c reports? Maybe I misunderstood the code.
I'll change that to something else.


Good point; tcpm returns -EAGAIN if the port is not in a READY state.
Maybe I should change the tcpm code ? No idea what error to use instead,
though.


I'll use -ENOTCONN for now. Let me know if it's not good.


+/**
+ * ucsi_register_ppm - Register UCSI PPM Interface
+ * @dev: Device interface to the PPM
+ * @ppm: The PPM interface
+ *
+ * Allocates UCSI instance, associates it with @ppm and returns it to the
+ * caller, and schedules initialization of the interface.
+ */
+struct ucsi *ucsi_register_ppm(struct device *dev, struct ucsi_ppm *ppm)
+{
+   struct ucsi *ucsi;
+
+   ucsi = kzalloc(sizeof(*ucsi), GFP_KERNEL);
+   if (!ucsi)
+   return ERR_PTR(-ENOMEM);
+
+   INIT_WORK(>work, ucsi_init);
+   init_completion(>complete);
+   mutex_init(>ppm_lock);
+
+   ucsi->dev = dev;
+   ucsi->ppm = ppm;
+
+   queue_work(system_long_wq, >work);

Re: [PATCH 2/3] usb: typec: Add support for UCSI interface

2017-05-29 Thread Heikki Krogerus 
On Fri, May 26, 2017 at 06:26:01AM -0700, Guenter Roeck wrote:
> > > What happens if trace is not enabled ? If I recall discussions around 
> > > CLANG
> > > correctly, it complains about unused static inline functions.
> > 
> > Nothing happens if trace is not enable. Everything continues to
> > compile just like before.
> > 
> > Maybe you were trying to define the tracepoints in C code? That won't
> > work.
> > 
> > > Anyway, is it really necessary to have an include file for this instead of
> > > keeping the code in trace.c ? I am somewhat wary of variable declarations
> > > in include files - include twice and there will be two instances.
> > 
> > The tracepoint documentation actually states that you need to place the
> > definitions of the tracepoints in a header. I have the trace.c file only
> > because it was a convenient place to put the tracepoint statement in.
> > 
> > I don't know the inner workings of tracepoints, but they do work fine
> > for me. In case you want more info on the topic, I never read these
> > articles, but they were mentioned in Documentation/trace/tracepoints.txt:
> > 
> > http://lwn.net/Articles/379903
> > http://lwn.net/Articles/381064
> > http://lwn.net/Articles/383362
> > 
> > I believe they provide at least some kind of description on how
> > tracepoints actually work.
> > 
> Sorry for not being clear; that was a question about your code, not mine.
> If it builds without warnings with trace disabled, no problem.

Ah, of course. Silly me. Sorry about that.

> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > 
> > > Any preference in usb about alphabetic order of include files ?
> > 
> > I don't see any mention of it in the documentation, so this is
> > probable just matter of taste in the end. One likes the mother, one
> > likes the daughter.
> > 
> 
> I like alphabetic because it makes life easier later on, if/when additional
> include files are added, and it is easier to find a specific include file in
> an alphabetic list. Some upstream maintainers ask for it nowadays (including 
> me :-).

It's good to keep the headers in some order just for the sake of being
organized, but I don't see how alphabetical order is any better then
for example descending.

I normally would not care about this topic and I would have just
ordered the headers alphabetically if anybody asked for it, but I've
actually proposed ordering the headers alphabetically myself ones, and
this is what the upstream maintainer said: "Can we stick to serious
critiques"

I think some maintainers do not see the need to dictate styling rules
on everything, and leave some things to be decided by the developer. I
kind of like that.

But if you still feel strongly about this, I'll change the style, but
for now, I'll keep it the way it is. Actually, I'll move the last one
on top.

> > > > +/**
> > > > + * ucsi_notify - PPM notification handler
> > > > + * @ucsi: Source UCSI Interface for the notifications
> > > > + *
> > > > + * Handle notifications from PPM of @ucsi.
> > > > + */
> > > > +void ucsi_notify(struct ucsi *ucsi)
> > > > +{
> > > > +   struct ucsi_cci *cci;
> > > > +
> > > > +   /* There is no requirement to sync here, so only warning if it 
> > > > fails */
> > > > +   if (ucsi_sync(ucsi))
> > > > +   dev_warn(ucsi->dev, "%s: sync failed\n", __func__);
> > > > +
> > > Why even a warning if it is not a requirement ?
> > 
> > It still should not "ever" fail. Why not create the warning? It is
> > after all indication that something is really wrong, and we probable
> > want to know about it.
> > 
> Your call, of course. I just dislike noisy drivers, and I am always concerned
> about flooding the kernel log.

Fair enough, I'll remove the warning.

> > > > +static int
> > > > +ucsi_dr_swap(const struct typec_capability *cap, enum typec_data_role 
> > > > role)
> > > > +{
> > > > +   struct ucsi_connector *con = to_ucsi_connector(cap);
> > > > +   struct ucsi_control ctrl;
> > > > +   int ret = 0;
> > > > +
> > > > +   if (!con->partner)
> > > > +   return -EAGAIN;
> > > 
> > > Doesn't this result in an immediate retry by user space ?
> > 
> > Isn't that what tcpm.c reports? Maybe I misunderstood the code.
> > I'll change that to something else.
> > 
> Good point; tcpm returns -EAGAIN if the port is not in a READY state.
> Maybe I should change the tcpm code ? No idea what error to use instead,
> though.

I'll use -ENOTCONN for now. Let me know if it's not good.

> > > > +/**
> > > > + * ucsi_register_ppm - Register UCSI PPM Interface
> > > > + * @dev: Device interface to the PPM
> > > > + * @ppm: The PPM interface
> > > > + *
> > > > + * Allocates UCSI instance, associates it with @ppm and returns it to 
> > > > the
> > > > + * caller, and schedules initialization of the interface.
> > > > + */
> > > > +struct ucsi *ucsi_register_ppm(struct device *dev, struct ucsi_ppm

Re: [PATCH 2/3] usb: typec: Add support for UCSI interface

2017-05-26 Thread Guenter Roeck 

On 05/26/2017 04:02 AM, Heikki Krogerus wrote:

Hi,

On Thu, May 25, 2017 at 06:20:16AM -0700, Guenter Roeck wrote:

On 05/16/2017 05:26 AM, Heikki Krogerus wrote:

UCSI - USB Type-C Connector System Software Interface - is a
specification that defines set of registers and data
structures for controlling the USB Type-C ports. It's
designed for systems where an embedded controller (EC) is in
charge of the USB Type-C PHY or USB Power Delivery
controller. It is designed for systems with EC, but it is
not limited to them, and for example some USB Power Delivery
controllers will use it as their direct control interface.

With UCSI the EC (or USB PD controller) acts as the port
manager, implementing all USB Type-C and Power Delivery state
machines. The OS can use the interfaces for reading the
status of the ports and controlling basic operations like
role swapping.

The UCSI specification highlights the fact that it does not
define the interface method (PCI/I2C/ACPI/etc.).
Therefore the driver is implemented as library and every
supported interface method needs its own driver. Driver for
ACPI is provided in separate patch following this one.

The initial driver includes support for all required
features from UCSI specification version 1.0 (getting
connector capabilities and status, and support for power and
data role swapping), but none of the optional UCSI features
(alternate modes, power source capabilities, and cable
capabilities).

Signed-off-by: Heikki Krogerus 
---
   drivers/usb/typec/Kconfig   |   2 +
   drivers/usb/typec/Makefile  |   1 +
   drivers/usb/typec/ucsi/Kconfig  |  22 ++
   drivers/usb/typec/ucsi/Makefile |   7 +
   drivers/usb/typec/ucsi/debug.h  |  64 
   drivers/usb/typec/ucsi/trace.c  |   2 +
   drivers/usb/typec/ucsi/trace.h  | 143 
   drivers/usb/typec/ucsi/ucsi.c   | 770 

   drivers/usb/typec/ucsi/ucsi.h   | 329 +
   9 files changed, 1340 insertions(+)
   create mode 100644 drivers/usb/typec/ucsi/Kconfig
   create mode 100644 drivers/usb/typec/ucsi/Makefile
   create mode 100644 drivers/usb/typec/ucsi/debug.h
   create mode 100644 drivers/usb/typec/ucsi/trace.c
   create mode 100644 drivers/usb/typec/ucsi/trace.h
   create mode 100644 drivers/usb/typec/ucsi/ucsi.c
   create mode 100644 drivers/usb/typec/ucsi/ucsi.h

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index dfcfe459b7cf..bc1b7745f1d4 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -19,4 +19,6 @@ config TYPEC_WCOVE
  To compile this driver as module, choose M here: the module will be
  called typec_wcove
+source "drivers/usb/typec/ucsi/Kconfig"
+
   endmenu
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index b9cb862221af..bc214f15f1b5 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1,2 +1,3 @@
   obj-$(CONFIG_TYPEC)  += typec.o
   obj-$(CONFIG_TYPEC_WCOVE)+= typec_wcove.o
+obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
diff --git a/drivers/usb/typec/ucsi/Kconfig b/drivers/usb/typec/ucsi/Kconfig
new file mode 100644
index ..679ba6648396
--- /dev/null
+++ b/drivers/usb/typec/ucsi/Kconfig
@@ -0,0 +1,22 @@
+config TYPEC_UCSI
+   tristate "USB Type-C Connector System Software Interface driver"
+   select TYPEC
+   help
+ USB Type-C Connector System Software Interface (UCSI) is a
+ specification for an interface that allows the operating system to
+ control the USB Type-C ports. On UCSI system the USB Type-C ports
+ function autonomously by default, but in order to get the status of
+ the ports and support basic operations like role swapping, the driver
+ is required. UCSI is available on most of the new Intel based systems
+ that are equipped with Embedded Controller and USB Type-C ports.
+
+ UCSI specification does not define the interface method, so depending
+ on the platform, ACPI, PCI, I2C, etc. may be used. Therefore this
+ driver only provides the core part, and separate drivers are needed
+ for every supported interface method.
+
+ The UCSI specification can be downloaded from:
+ 
http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
+
+ To compile the driver as a module, choose M here: the module will be
+ called typec_ucsi.
diff --git a/drivers/usb/typec/ucsi/Makefile b/drivers/usb/typec/ucsi/Makefile
new file mode 100644
index ..87dd6ee6c9f3
--- /dev/null
+++ b/drivers/usb/typec/ucsi/Makefile
@@ -0,0 +1,7 @@
+CFLAGS_trace.o := -I$(src)
+
+obj-$(CONFIG_TYPEC_UCSI)   += typec_ucsi.o
+
+typec_ucsi-y   := ucsi.o
+
+typec_ucsi-$(CONFIG_FTRACE)+= trace.o
diff --git a/drivers/usb/typec/ucsi/debug.h b/drivers/usb/typec/ucsi/debug.h
new file mode 100644
index

Re: [PATCH 2/3] usb: typec: Add support for UCSI interface

2017-05-26 Thread Heikki Krogerus 
Hi,

On Thu, May 25, 2017 at 06:20:16AM -0700, Guenter Roeck wrote:
> On 05/16/2017 05:26 AM, Heikki Krogerus wrote:
> > UCSI - USB Type-C Connector System Software Interface - is a
> > specification that defines set of registers and data
> > structures for controlling the USB Type-C ports. It's
> > designed for systems where an embedded controller (EC) is in
> > charge of the USB Type-C PHY or USB Power Delivery
> > controller. It is designed for systems with EC, but it is
> > not limited to them, and for example some USB Power Delivery
> > controllers will use it as their direct control interface.
> > 
> > With UCSI the EC (or USB PD controller) acts as the port
> > manager, implementing all USB Type-C and Power Delivery state
> > machines. The OS can use the interfaces for reading the
> > status of the ports and controlling basic operations like
> > role swapping.
> > 
> > The UCSI specification highlights the fact that it does not
> > define the interface method (PCI/I2C/ACPI/etc.).
> > Therefore the driver is implemented as library and every
> > supported interface method needs its own driver. Driver for
> > ACPI is provided in separate patch following this one.
> > 
> > The initial driver includes support for all required
> > features from UCSI specification version 1.0 (getting
> > connector capabilities and status, and support for power and
> > data role swapping), but none of the optional UCSI features
> > (alternate modes, power source capabilities, and cable
> > capabilities).
> > 
> > Signed-off-by: Heikki Krogerus 
> > ---
> >   drivers/usb/typec/Kconfig   |   2 +
> >   drivers/usb/typec/Makefile  |   1 +
> >   drivers/usb/typec/ucsi/Kconfig  |  22 ++
> >   drivers/usb/typec/ucsi/Makefile |   7 +
> >   drivers/usb/typec/ucsi/debug.h  |  64 
> >   drivers/usb/typec/ucsi/trace.c  |   2 +
> >   drivers/usb/typec/ucsi/trace.h  | 143 
> >   drivers/usb/typec/ucsi/ucsi.c   | 770 
> > 
> >   drivers/usb/typec/ucsi/ucsi.h   | 329 +
> >   9 files changed, 1340 insertions(+)
> >   create mode 100644 drivers/usb/typec/ucsi/Kconfig
> >   create mode 100644 drivers/usb/typec/ucsi/Makefile
> >   create mode 100644 drivers/usb/typec/ucsi/debug.h
> >   create mode 100644 drivers/usb/typec/ucsi/trace.c
> >   create mode 100644 drivers/usb/typec/ucsi/trace.h
> >   create mode 100644 drivers/usb/typec/ucsi/ucsi.c
> >   create mode 100644 drivers/usb/typec/ucsi/ucsi.h
> > 
> > diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
> > index dfcfe459b7cf..bc1b7745f1d4 100644
> > --- a/drivers/usb/typec/Kconfig
> > +++ b/drivers/usb/typec/Kconfig
> > @@ -19,4 +19,6 @@ config TYPEC_WCOVE
> >   To compile this driver as module, choose M here: the module will be
> >   called typec_wcove
> > +source "drivers/usb/typec/ucsi/Kconfig"
> > +
> >   endmenu
> > diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
> > index b9cb862221af..bc214f15f1b5 100644
> > --- a/drivers/usb/typec/Makefile
> > +++ b/drivers/usb/typec/Makefile
> > @@ -1,2 +1,3 @@
> >   obj-$(CONFIG_TYPEC)   += typec.o
> >   obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o
> > +obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
> > diff --git a/drivers/usb/typec/ucsi/Kconfig b/drivers/usb/typec/ucsi/Kconfig
> > new file mode 100644
> > index ..679ba6648396
> > --- /dev/null
> > +++ b/drivers/usb/typec/ucsi/Kconfig
> > @@ -0,0 +1,22 @@
> > +config TYPEC_UCSI
> > +   tristate "USB Type-C Connector System Software Interface driver"
> > +   select TYPEC
> > +   help
> > + USB Type-C Connector System Software Interface (UCSI) is a
> > + specification for an interface that allows the operating system to
> > + control the USB Type-C ports. On UCSI system the USB Type-C ports
> > + function autonomously by default, but in order to get the status of
> > + the ports and support basic operations like role swapping, the driver
> > + is required. UCSI is available on most of the new Intel based systems
> > + that are equipped with Embedded Controller and USB Type-C ports.
> > +
> > + UCSI specification does not define the interface method, so depending
> > + on the platform, ACPI, PCI, I2C, etc. may be used. Therefore this
> > + driver only provides the core part, and separate drivers are needed
> > + for every supported interface method.
> > +
> > + The UCSI specification can be downloaded from:
> > + 
> > http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
> > +
> > + To compile the driver as a module, choose M here: the module will be
> > + called typec_ucsi.
> > diff --git a/drivers/usb/typec/ucsi/Makefile 
> > b/drivers/usb/typec/ucsi/Makefile
> > new file mode 100644
> > index ..87dd6ee6c9f3
> > --- /dev/null
> > +++ b/drivers/usb/typec/ucsi/Makefile
> > @@ -0,0 +1,7 @@
> > +CFLAGS_trace.o

Re: [PATCH 2/3] usb: typec: Add support for UCSI interface

2017-05-25 Thread Guenter Roeck 

On 05/16/2017 05:26 AM, Heikki Krogerus wrote:

UCSI - USB Type-C Connector System Software Interface - is a
specification that defines set of registers and data
structures for controlling the USB Type-C ports. It's
designed for systems where an embedded controller (EC) is in
charge of the USB Type-C PHY or USB Power Delivery
controller. It is designed for systems with EC, but it is
not limited to them, and for example some USB Power Delivery
controllers will use it as their direct control interface.

With UCSI the EC (or USB PD controller) acts as the port
manager, implementing all USB Type-C and Power Delivery state
machines. The OS can use the interfaces for reading the
status of the ports and controlling basic operations like
role swapping.

The UCSI specification highlights the fact that it does not
define the interface method (PCI/I2C/ACPI/etc.).
Therefore the driver is implemented as library and every
supported interface method needs its own driver. Driver for
ACPI is provided in separate patch following this one.

The initial driver includes support for all required
features from UCSI specification version 1.0 (getting
connector capabilities and status, and support for power and
data role swapping), but none of the optional UCSI features
(alternate modes, power source capabilities, and cable
capabilities).

Signed-off-by: Heikki Krogerus 
---
  drivers/usb/typec/Kconfig   |   2 +
  drivers/usb/typec/Makefile  |   1 +
  drivers/usb/typec/ucsi/Kconfig  |  22 ++
  drivers/usb/typec/ucsi/Makefile |   7 +
  drivers/usb/typec/ucsi/debug.h  |  64 
  drivers/usb/typec/ucsi/trace.c  |   2 +
  drivers/usb/typec/ucsi/trace.h  | 143 
  drivers/usb/typec/ucsi/ucsi.c   | 770 
  drivers/usb/typec/ucsi/ucsi.h   | 329 +
  9 files changed, 1340 insertions(+)
  create mode 100644 drivers/usb/typec/ucsi/Kconfig
  create mode 100644 drivers/usb/typec/ucsi/Makefile
  create mode 100644 drivers/usb/typec/ucsi/debug.h
  create mode 100644 drivers/usb/typec/ucsi/trace.c
  create mode 100644 drivers/usb/typec/ucsi/trace.h
  create mode 100644 drivers/usb/typec/ucsi/ucsi.c
  create mode 100644 drivers/usb/typec/ucsi/ucsi.h

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index dfcfe459b7cf..bc1b7745f1d4 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -19,4 +19,6 @@ config TYPEC_WCOVE
  To compile this driver as module, choose M here: the module will be
  called typec_wcove
  
+source "drivers/usb/typec/ucsi/Kconfig"

+
  endmenu
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index b9cb862221af..bc214f15f1b5 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1,2 +1,3 @@
  obj-$(CONFIG_TYPEC)   += typec.o
  obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o
+obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
diff --git a/drivers/usb/typec/ucsi/Kconfig b/drivers/usb/typec/ucsi/Kconfig
new file mode 100644
index ..679ba6648396
--- /dev/null
+++ b/drivers/usb/typec/ucsi/Kconfig
@@ -0,0 +1,22 @@
+config TYPEC_UCSI
+   tristate "USB Type-C Connector System Software Interface driver"
+   select TYPEC
+   help
+ USB Type-C Connector System Software Interface (UCSI) is a
+ specification for an interface that allows the operating system to
+ control the USB Type-C ports. On UCSI system the USB Type-C ports
+ function autonomously by default, but in order to get the status of
+ the ports and support basic operations like role swapping, the driver
+ is required. UCSI is available on most of the new Intel based systems
+ that are equipped with Embedded Controller and USB Type-C ports.
+
+ UCSI specification does not define the interface method, so depending
+ on the platform, ACPI, PCI, I2C, etc. may be used. Therefore this
+ driver only provides the core part, and separate drivers are needed
+ for every supported interface method.
+
+ The UCSI specification can be downloaded from:
+ 
http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
+
+ To compile the driver as a module, choose M here: the module will be
+ called typec_ucsi.
diff --git a/drivers/usb/typec/ucsi/Makefile b/drivers/usb/typec/ucsi/Makefile
new file mode 100644
index ..87dd6ee6c9f3
--- /dev/null
+++ b/drivers/usb/typec/ucsi/Makefile
@@ -0,0 +1,7 @@
+CFLAGS_trace.o := -I$(src)
+
+obj-$(CONFIG_TYPEC_UCSI)   += typec_ucsi.o
+
+typec_ucsi-y   := ucsi.o
+
+typec_ucsi-$(CONFIG_FTRACE)+= trace.o
diff --git a/drivers/usb/typec/ucsi/debug.h b/drivers/usb/typec/ucsi/debug.h
new file mode 100644
index ..87d0cd20597a
--- /dev/null
+++ b/drivers/usb/typec/ucsi/debug.h
@@ -0,0 +1,64 @@
+#ifndef __UCSI_DEBUG_H
+#define __UCSI_DEBUG_H
+