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

Groups > linux.kernel > #1330485 > unrolled thread

[PATCH 0/3] usb: USB Type-C Class and driver for UCSI

Started byHeikki Krogerus <heikki.krogerus@linux.intel.com>
First post2016-02-09 18:10 +0100
Last post2016-02-18 12:20 +0100
Articles 12 on this page of 52 — 10 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/3] usb: USB Type-C Class and driver for UCSI Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-09 18:10 +0100
    [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-09 18:10 +0100
      Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Greg KH <gregkh@linuxfoundation.org> - 2016-02-09 19:30 +0100
        Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-10 11:40 +0100
          Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Greg KH <gregkh@linuxfoundation.org> - 2016-02-10 18:30 +0100
            Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-11 15:10 +0100
              Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-15 16:40 +0100
                Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-16 10:30 +0100
                  Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-16 14:50 +0100
                    Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-17 09:00 +0100
                      Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-17 10:10 +0100
                        Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Felipe Balbi <balbif@gmail.com> - 2016-02-17 11:40 +0100
                          Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-17 11:40 +0100
                            Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-17 12:20 +0100
                              Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Felipe Balbi <balbi@kernel.org> - 2016-02-17 14:40 +0100
                                Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-17 15:30 +0100
                                  Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Peter Chen <hzpeterchen@gmail.com> - 2016-02-18 10:20 +0100
                                    Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-18 11:50 +0100
                                  Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Rajaram R <rajaram.officemail@gmail.com> - 2016-02-18 11:40 +0100
                                    Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-18 11:50 +0100
                                      Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Rajaram R <rajaram.officemail@gmail.com> - 2016-02-18 12:10 +0100
                            Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Felipe Balbi <balbi@kernel.org> - 2016-02-17 14:40 +0100
                              Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-17 15:00 +0100
                                Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Felipe Balbi <balbif@gmail.com> - 2016-02-18 08:10 +0100
                                  Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-18 11:30 +0100
                                    Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Felipe Balbi <balbif@gmail.com> - 2016-02-18 11:40 +0100
                                      Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-18 11:50 +0100
          Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Peter Chen <hzpeterchen@gmail.com> - 2016-02-18 10:40 +0100
            Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-18 10:50 +0100
      Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-10 12:30 +0100
        Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-10 13:10 +0100
      Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-02-10 13:00 +0100
        Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-10 14:30 +0100
          Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-02-10 15:10 +0100
            Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Bjørn Mork <bjorn@mork.no> - 2016-02-10 16:20 +0100
              Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-02-11 09:30 +0100
                Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Bjørn Mork <bjorn@mork.no> - 2016-02-11 10:10 +0100
        Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-10 15:20 +0100
          Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-02-10 15:30 +0100
            Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.de> - 2016-02-10 16:20 +0100
              Fwd: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-02-11 09:20 +0100
                Re: Fwd: [PATCH 2/3] usb: type-c: USB Type-C Connector System  Software Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-11 15:20 +0100
      Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-10 14:10 +0100
        Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-11 15:10 +0100
    [PATCH 3/3] usb: type-c: UCSI ACPI driver Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-09 18:10 +0100
      Re: [PATCH 3/3] usb: type-c: UCSI ACPI driver Greg KH <gregkh@linuxfoundation.org> - 2016-02-09 19:30 +0100
        Re: [PATCH 3/3] usb: type-c: UCSI ACPI driver Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-10 11:30 +0100
    Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI Oliver Neukum <oneukum@suse.com> - 2016-02-17 20:00 +0100
      Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-18 10:30 +0100
    Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI Rajaram R <rajaram.officemail@gmail.com> - 2016-02-17 20:40 +0100
      Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-18 12:10 +0100
        Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI Oliver Neukum <oneukum@suse.com> - 2016-02-18 12:20 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#1331721 — Fwd: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

FromAndy Shevchenko <andy.shevchenko@gmail.com>
Date2016-02-11 09:20 +0100
SubjectFwd: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface
Message-ID<r0UDL-692-1@gated-at.bofh.it>
In reply to#1331267
---------- Forwarded message ----------
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Thu, Feb 11, 2016 at 10:10 AM
Subject: Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System
Software Interface
To: Oliver Neukum <oneukum@suse.de>


On Wed, Feb 10, 2016 at 5:08 PM, Oliver Neukum <oneukum@suse.de> wrote:
> On Wed, 2016-02-10 at 16:24 +0200, Andy Shevchenko wrote:
>> On Wed, Feb 10, 2016 at 4:15 PM, Oliver Neukum <oneukum@suse.com> wrote:
>> > On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
>> >> > +err:
>> >> > +       if (i > 0)
>> >> > +               for (; i >= 0; i--, con--)
>> >> > +                       typec_unregister_port(con->port);
>> >>
>> >> Perhaps
>> >>
>> >> while (--i >= 0) {
>> >>  ...
>> >> }
>> >
>> > While we are at it. No we should not change the semantics
>> > of conditionals for the sake of appearance.
>>
>> I'm sorry I didn't get you.
>> How this more or less standard pattern to clean up stuff on error path
>> does with conditional semantics?
>
> You change a postdecrement to a predecrement. The highest
> number the loop is executed for is changed.

I still didn't get.
Variable i is just counter here,

And it seems there is a bug, since when i == 1, we will have

i = 1, con == connector[0]:
typec_unregister_port(con->port);

i = 0, con == connector[1]:
typec_unregister_port(con->port); <<< It wasn't registered yet!

The correct code should be something like
if (i > 0)
 for (--i; i >= 0; i--) {}

Which
a) makes conditional redundant;
b) classical pattern of while (--i >= 0) {}

So where am I wrong?

--
With Best Regards,
Andy Shevchenko


-- 
With Best Regards,
Andy Shevchenko

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

#1332014 — Re: Fwd: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

FromHeikki Krogerus <heikki.krogerus@linux.intel.com>
Date2016-02-11 15:20 +0100
SubjectRe: Fwd: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface
Message-ID<r10gb-1uu-37@gated-at.bofh.it>
In reply to#1331721
On Thu, Feb 11, 2016 at 10:13:11AM +0200, Andy Shevchenko wrote:
> ---------- Forwarded message ----------
> From: Andy Shevchenko <andy.shevchenko@gmail.com>
> Date: Thu, Feb 11, 2016 at 10:10 AM
> Subject: Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System
> Software Interface
> To: Oliver Neukum <oneukum@suse.de>
> 
> 
> On Wed, Feb 10, 2016 at 5:08 PM, Oliver Neukum <oneukum@suse.de> wrote:
> > On Wed, 2016-02-10 at 16:24 +0200, Andy Shevchenko wrote:
> >> On Wed, Feb 10, 2016 at 4:15 PM, Oliver Neukum <oneukum@suse.com> wrote:
> >> > On Wed, 2016-02-10 at 13:56 +0200, Andy Shevchenko wrote:
> >> >> > +err:
> >> >> > +       if (i > 0)
> >> >> > +               for (; i >= 0; i--, con--)
> >> >> > +                       typec_unregister_port(con->port);
> >> >>
> >> >> Perhaps
> >> >>
> >> >> while (--i >= 0) {
> >> >>  ...
> >> >> }
> >> >
> >> > While we are at it. No we should not change the semantics
> >> > of conditionals for the sake of appearance.
> >>
> >> I'm sorry I didn't get you.
> >> How this more or less standard pattern to clean up stuff on error path
> >> does with conditional semantics?
> >
> > You change a postdecrement to a predecrement. The highest
> > number the loop is executed for is changed.
> 
> I still didn't get.
> Variable i is just counter here,
> 
> And it seems there is a bug, since when i == 1, we will have
> 
> i = 1, con == connector[0]:
> typec_unregister_port(con->port);
> 
> i = 0, con == connector[1]:
> typec_unregister_port(con->port); <<< It wasn't registered yet!
> 
> The correct code should be something like
> if (i > 0)
>  for (--i; i >= 0; i--) {}
> 
> Which
> a) makes conditional redundant;
> b) classical pattern of while (--i >= 0) {}
> 
> So where am I wrong?

I think Andy has a point here.

Thanks,

-- 
heikki

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

#1331153 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

FromOliver Neukum <oneukum@suse.com>
Date2016-02-10 14:10 +0100
SubjectRe: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface
Message-ID<r0CGU-2BB-41@gated-at.bofh.it>
In reply to#1330489
On Tue, 2016-02-09 at 19:01 +0200, Heikki Krogerus wrote:
> +#define UCSI_CONSTAT_BC_NOT_CHARGING           0
> +#define UCSI_CONSTAT_BC_NOMINAL_CHARGING       1
> +#define UCSI_CONSTAT_BC_SLOW_CHARGING          2
> +#define UCSI_CONSTAT_BC_TRICLE_CHARGING                3

typo. It is spelled TRICKLE

	Regards
		Oliver

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

#1331983 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

FromHeikki Krogerus <heikki.krogerus@linux.intel.com>
Date2016-02-11 15:10 +0100
SubjectRe: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface
Message-ID<r106v-1qh-41@gated-at.bofh.it>
In reply to#1331153
On Wed, Feb 10, 2016 at 02:04:07PM +0100, Oliver Neukum wrote:
> On Tue, 2016-02-09 at 19:01 +0200, Heikki Krogerus wrote:
> > +#define UCSI_CONSTAT_BC_NOT_CHARGING           0
> > +#define UCSI_CONSTAT_BC_NOMINAL_CHARGING       1
> > +#define UCSI_CONSTAT_BC_SLOW_CHARGING          2
> > +#define UCSI_CONSTAT_BC_TRICLE_CHARGING                3
> 
> typo. It is spelled TRICKLE

Thanks! I'll fix it.

-- 
heikki

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

#1330494 — [PATCH 3/3] usb: type-c: UCSI ACPI driver

FromHeikki Krogerus <heikki.krogerus@linux.intel.com>
Date2016-02-09 18:10 +0100
Subject[PATCH 3/3] usb: type-c: UCSI ACPI driver
Message-ID<r0jXC-76q-49@gated-at.bofh.it>
In reply to#1330485
Driver for ACPI enumerated UCSI devices.

Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
---
 drivers/usb/type-c/Kconfig     |  10 ++++
 drivers/usb/type-c/Makefile    |   1 +
 drivers/usb/type-c/ucsi_acpi.c | 133 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 144 insertions(+)
 create mode 100644 drivers/usb/type-c/ucsi_acpi.c

diff --git a/drivers/usb/type-c/Kconfig b/drivers/usb/type-c/Kconfig
index 02abd74..72b002e 100644
--- a/drivers/usb/type-c/Kconfig
+++ b/drivers/usb/type-c/Kconfig
@@ -12,4 +12,14 @@ config TYPEC_UCSI
 	  registers and data structures used to interface with the USB Type-C
 	  connectors on a system.
 
+if TYPEC_UCSI
+
+config TYPEC_UCSI_ACPI
+	tristate "UCSI ACPI Driver"
+	depends on ACPI
+	help
+	  Driver for ACPI enumerated UCSI devices.
+
+endif
+
 endmenu
diff --git a/drivers/usb/type-c/Makefile b/drivers/usb/type-c/Makefile
index ab974ba..17933dc 100644
--- a/drivers/usb/type-c/Makefile
+++ b/drivers/usb/type-c/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_TYPEC)		+= typec.o
 obj-$(CONFIG_TYPEC_UCSI)	+= ucsi.o
+obj-$(CONFIG_TYPEC_UCSI_ACPI)	+= ucsi_acpi.o
diff --git a/drivers/usb/type-c/ucsi_acpi.c b/drivers/usb/type-c/ucsi_acpi.c
new file mode 100644
index 0000000..8445a7d
--- /dev/null
+++ b/drivers/usb/type-c/ucsi_acpi.c
@@ -0,0 +1,133 @@
+/*
+ * UCSI ACPI driver
+ *
+ * Copyright (C) 2016, Intel Corporation
+ * Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/acpi.h>
+
+#include "ucsi.h"
+
+struct ucsi_acpi {
+	struct device *dev;
+	struct ucsi *ucsi;
+	struct ucsi_ppm ppm;
+};
+
+static const u8 ucsi_uuid[] = {
+	0xc2, 0x98, 0x83, 0x6f,	0xa4, 0x7c, 0xe4, 0x11,
+	0xad, 0x36, 0x63, 0x10, 0x42, 0xb5, 0x00, 0x8f,
+};
+
+static int ucsi_acpi_cmd(struct ucsi_ppm *ppm)
+{
+	struct ucsi_acpi *ua = container_of(ppm, struct ucsi_acpi, ppm);
+	union acpi_object *obj;
+
+	obj = acpi_evaluate_dsm(ACPI_HANDLE(ua->dev), ucsi_uuid, 1, 1, NULL);
+	if (!obj) {
+		dev_err(ua->dev, "%s: failed to evaluate _DSM\n", __func__);
+		return -EIO;
+	}
+
+	ACPI_FREE(obj);
+	return 0;
+}
+
+static void ucsi_acpi_notify(acpi_handle handle, u32 event, void *data)
+{
+	struct ucsi_acpi *ua = data;
+
+	if (!ucsi_interrupt(ua->ucsi))
+		dev_err(ua->dev, "spurious ACPI notification\n");
+}
+
+static int ucsi_acpi_probe(struct platform_device *pdev)
+{
+	struct ucsi_acpi *ua;
+	struct resource *res;
+	acpi_status status;
+	int ret;
+
+	ua = devm_kzalloc(&pdev->dev, sizeof(*ua), GFP_KERNEL);
+	if (!ua)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(&pdev->dev, "missing memory resource\n");
+		return -ENODEV;
+	}
+
+	ua->ppm.data = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+	if (!ua->ppm.data)
+		return -ENOMEM;
+
+	ua->ppm.cmd = ucsi_acpi_cmd;
+	ua->dev = &pdev->dev;
+
+	ua->ucsi = ucsi_register_ppm(&pdev->dev, &ua->ppm);
+	if (IS_ERR(ua->ucsi))
+		return PTR_ERR(ua->ucsi);
+
+	status = acpi_install_notify_handler(ACPI_HANDLE(&pdev->dev),
+					     ACPI_DEVICE_NOTIFY,
+					     ucsi_acpi_notify, ua);
+	if (ACPI_FAILURE(status)) {
+		ret = -ENODEV;
+		goto err;
+	}
+
+	ret = ucsi_init(ua->ucsi);
+	if (ret) {
+		acpi_remove_notify_handler(ACPI_HANDLE(&pdev->dev),
+					   ACPI_DEVICE_NOTIFY,
+					   ucsi_acpi_notify);
+		goto err;
+	}
+
+	platform_set_drvdata(pdev, ua);
+	return 0;
+err:
+	ucsi_unregister_ppm(ua->ucsi);
+	return ret;
+}
+
+static int ucsi_acpi_remove(struct platform_device *pdev)
+{
+	struct ucsi_acpi *ua = platform_get_drvdata(pdev);
+
+	acpi_remove_notify_handler(ACPI_HANDLE(&pdev->dev),
+				   ACPI_DEVICE_NOTIFY, ucsi_acpi_notify);
+	ucsi_unregister_ppm(ua->ucsi);
+	return 0;
+}
+
+static const struct acpi_device_id ucsi_acpi_match[] = {
+	{ "PNP0CA0", 0 },
+	{ },
+};
+MODULE_DEVICE_TABLE(acpi, ucsi_acpi_match);
+
+static struct platform_driver ucsi_acpi_platform_driver = {
+	.driver = {
+		.name = "ucsi_acpi",
+		.acpi_match_table = ACPI_PTR(ucsi_acpi_match),
+	},
+	.probe = ucsi_acpi_probe,
+	.remove = ucsi_acpi_remove,
+};
+
+module_platform_driver(ucsi_acpi_platform_driver);
+
+MODULE_AUTHOR("Heikki Krogerus <heikki.krogerus@linux.intel.com>");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("UCSI ACPI driver");
-- 
2.7.0

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

#1330574 — Re: [PATCH 3/3] usb: type-c: UCSI ACPI driver

FromGreg KH <gregkh@linuxfoundation.org>
Date2016-02-09 19:30 +0100
SubjectRe: [PATCH 3/3] usb: type-c: UCSI ACPI driver
Message-ID<r0ld1-7On-27@gated-at.bofh.it>
In reply to#1330494
On Tue, Feb 09, 2016 at 07:01:23PM +0200, Heikki Krogerus wrote:
> Driver for ACPI enumerated UCSI devices.

What does this mean?

What does the driver do?  Why would we care?

> 
> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
>  drivers/usb/type-c/Kconfig     |  10 ++++
>  drivers/usb/type-c/Makefile    |   1 +
>  drivers/usb/type-c/ucsi_acpi.c | 133 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 144 insertions(+)
>  create mode 100644 drivers/usb/type-c/ucsi_acpi.c
> 
> diff --git a/drivers/usb/type-c/Kconfig b/drivers/usb/type-c/Kconfig
> index 02abd74..72b002e 100644
> --- a/drivers/usb/type-c/Kconfig
> +++ b/drivers/usb/type-c/Kconfig
> @@ -12,4 +12,14 @@ config TYPEC_UCSI
>  	  registers and data structures used to interface with the USB Type-C
>  	  connectors on a system.
>  
> +if TYPEC_UCSI
> +
> +config TYPEC_UCSI_ACPI
> +	tristate "UCSI ACPI Driver"
> +	depends on ACPI
> +	help
> +	  Driver for ACPI enumerated UCSI devices.

Worst help text ever :(

thanks,

greg k-h

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

#1331043 — Re: [PATCH 3/3] usb: type-c: UCSI ACPI driver

FromHeikki Krogerus <heikki.krogerus@linux.intel.com>
Date2016-02-10 11:30 +0100
SubjectRe: [PATCH 3/3] usb: type-c: UCSI ACPI driver
Message-ID<r0Ac4-VA-47@gated-at.bofh.it>
In reply to#1330574
On Tue, Feb 09, 2016 at 10:22:46AM -0800, Greg KH wrote:
> On Tue, Feb 09, 2016 at 07:01:23PM +0200, Heikki Krogerus wrote:
> > Driver for ACPI enumerated UCSI devices.
> 
> What does this mean?
> 
> What does the driver do?  Why would we care?
> 
> > 
> > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > ---
> >  drivers/usb/type-c/Kconfig     |  10 ++++
> >  drivers/usb/type-c/Makefile    |   1 +
> >  drivers/usb/type-c/ucsi_acpi.c | 133 +++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 144 insertions(+)
> >  create mode 100644 drivers/usb/type-c/ucsi_acpi.c
> > 
> > diff --git a/drivers/usb/type-c/Kconfig b/drivers/usb/type-c/Kconfig
> > index 02abd74..72b002e 100644
> > --- a/drivers/usb/type-c/Kconfig
> > +++ b/drivers/usb/type-c/Kconfig
> > @@ -12,4 +12,14 @@ config TYPEC_UCSI
> >  	  registers and data structures used to interface with the USB Type-C
> >  	  connectors on a system.
> >  
> > +if TYPEC_UCSI
> > +
> > +config TYPEC_UCSI_ACPI
> > +	tristate "UCSI ACPI Driver"
> > +	depends on ACPI
> > +	help
> > +	  Driver for ACPI enumerated UCSI devices.
> 
> Worst help text ever :(

I'm sorry for that. I was not planning to leave it like that. I was
more consearned with the class then these drivers, and forgot finish
these parts.


Thanks,

-- 
heikki

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

#1336659

FromOliver Neukum <oneukum@suse.com>
Date2016-02-17 20:00 +0100
Message-ID<r3fuq-1YZ-9@gated-at.bofh.it>
In reply to#1330485
On Tue, 2016-02-09 at 19:01 +0200, Heikki Krogerus wrote:
> Hi,
> 
> The OS, or more precisely the user space, needs to be able to control
> a few things regarding USB Type-C ports. The first thing that must be
> allowed to be controlled is the data role. USB Type-C ports will
> select the data role randomly with DRP ports. When USB PD is
> supported, also independent (from data role) power role swapping can
> be supported together with Alternate Mode control.

What about S4? We need to restore the alternate mode upon resume,
if we are the DFP and as that might involve storage devices it
needs to be done in kernel space.

	Regards
		Oliver

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

#1337187

FromHeikki Krogerus <heikki.krogerus@linux.intel.com>
Date2016-02-18 10:30 +0100
Message-ID<r3t4l-3rL-13@gated-at.bofh.it>
In reply to#1336659
On Wed, Feb 17, 2016 at 07:53:47PM +0100, Oliver Neukum wrote:
> On Tue, 2016-02-09 at 19:01 +0200, Heikki Krogerus wrote:
> > Hi,
> > 
> > The OS, or more precisely the user space, needs to be able to control
> > a few things regarding USB Type-C ports. The first thing that must be
> > allowed to be controlled is the data role. USB Type-C ports will
> > select the data role randomly with DRP ports. When USB PD is
> > supported, also independent (from data role) power role swapping can
> > be supported together with Alternate Mode control.
> 
> What about S4? We need to restore the alternate mode upon resume,
> if we are the DFP and as that might involve storage devices it
> needs to be done in kernel space.

That I'm expecting to be the responsibility of the drivers registering
the ports at them moment, because I'm afraid of all the possible
different kind of platform specific oddities that need to be
considered.

But I guess all we would need to do in the class is store the roles
and mode during suspend, and restore them during resuming with
dr_swap, pr_swap and set_alt_mode hooks if they changed.


Thanks,

-- 
heikki

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

#1336700

FromRajaram R <rajaram.officemail@gmail.com>
Date2016-02-17 20:40 +0100
Message-ID<r3g78-2uR-3@gated-at.bofh.it>
In reply to#1330485
On Tue, Feb 9, 2016 at 10:31 PM, Heikki Krogerus
<heikki.krogerus@linux.intel.com> wrote:
> Hi,
>
> The OS, or more precisely the user space, needs to be able to control
> a few things regarding USB Type-C ports. The first thing that must be
> allowed to be controlled is the data role. USB Type-C ports will
> select the data role randomly with DRP ports. When USB PD is
> supported, also independent (from data role) power role swapping can
> be supported together with Alternate Mode control.
>
> I'm proposing with this set a Class for the Type-C connectors that
> gives the user space control over those things on top of getting basic
> details about the USB Type-C connectors and also partners. The details
> include the capabilities of the port, the supported data and power
> roles, supported accessories (audio and debug), supported Alternate
> Modes, USB PD support and of course the type of the partner (USB, Alt
> Mode, Accessory or Charger), and more or less the same details about
> the partner.
>
> I'm not considering cables with this Class, and I have deliberately

Since we have capability details of ports in user space, I believe
cable capability is also necessary for policy decision(power, alt
mode). Is that something we are cautiously leaving out ? pls explain

> left out some more technical details, like cable orientation, firstly
> because I did not see much use for the user space from knowing that
> an secondly because that kind of details are not always available for
> example with UCSI.
>
> So the interface to the user space is kept as simple as I dared to
> make it.
>
> NOTE: In case there is somebody wondering, this is not adding USB PD
> support to Linux kernel. This is just about USB Type-C.
>
>
> Heikki Krogerus (3):
>   usb: USB Type-C Connector Class
>   usb: type-c: USB Type-C Connector System Software Interface
>   usb: type-c: UCSI ACPI driver
>
>  drivers/usb/Kconfig            |   2 +
>  drivers/usb/Makefile           |   2 +
>  drivers/usb/type-c/Kconfig     |  25 +++
>  drivers/usb/type-c/Makefile    |   3 +
>  drivers/usb/type-c/typec.c     | 446 ++++++++++++++++++++++++++++++++++++++++
>  drivers/usb/type-c/ucsi.c      | 450 +++++++++++++++++++++++++++++++++++++++++
>  drivers/usb/type-c/ucsi.h      | 219 ++++++++++++++++++++
>  drivers/usb/type-c/ucsi_acpi.c | 133 ++++++++++++
>  include/linux/usb/typec.h      | 114 +++++++++++
>  9 files changed, 1394 insertions(+)
>  create mode 100644 drivers/usb/type-c/Kconfig
>  create mode 100644 drivers/usb/type-c/Makefile
>  create mode 100644 drivers/usb/type-c/typec.c
>  create mode 100644 drivers/usb/type-c/ucsi.c
>  create mode 100644 drivers/usb/type-c/ucsi.h
>  create mode 100644 drivers/usb/type-c/ucsi_acpi.c
>  create mode 100644 include/linux/usb/typec.h
>
> --
> 2.7.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

#1337271

FromHeikki Krogerus <heikki.krogerus@linux.intel.com>
Date2016-02-18 12:10 +0100
Message-ID<r3uD7-4Bz-5@gated-at.bofh.it>
In reply to#1336700
Hi Rajaram,

On Thu, Feb 18, 2016 at 01:04:48AM +0530, Rajaram R wrote:
> On Tue, Feb 9, 2016 at 10:31 PM, Heikki Krogerus
> <heikki.krogerus@linux.intel.com> wrote:
> > Hi,
> >
> > The OS, or more precisely the user space, needs to be able to control
> > a few things regarding USB Type-C ports. The first thing that must be
> > allowed to be controlled is the data role. USB Type-C ports will
> > select the data role randomly with DRP ports. When USB PD is
> > supported, also independent (from data role) power role swapping can
> > be supported together with Alternate Mode control.
> >
> > I'm proposing with this set a Class for the Type-C connectors that
> > gives the user space control over those things on top of getting basic
> > details about the USB Type-C connectors and also partners. The details
> > include the capabilities of the port, the supported data and power
> > roles, supported accessories (audio and debug), supported Alternate
> > Modes, USB PD support and of course the type of the partner (USB, Alt
> > Mode, Accessory or Charger), and more or less the same details about
> > the partner.
> >
> > I'm not considering cables with this Class, and I have deliberately
> 
> Since we have capability details of ports in user space, I believe
> cable capability is also necessary for policy decision(power, alt
> mode). Is that something we are cautiously leaving out ? pls explain

Adding the cable control to this interface will make it more complex
from users perspective. However, nothing forces the user to control
also the cable.

I already decided to add vconn_swap support, so I'll try to add cable
alt mode control and capabilities as well.


Thanks,

-- 
heikki

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

#1337282

FromOliver Neukum <oneukum@suse.com>
Date2016-02-18 12:20 +0100
Message-ID<r3uMO-4Fh-19@gated-at.bofh.it>
In reply to#1337271
On Thu, 2016-02-18 at 13:05 +0200, Heikki Krogerus wrote:

> > Since we have capability details of ports in user space, I believe
> > cable capability is also necessary for policy decision(power, alt
> > mode). Is that something we are cautiously leaving out ? pls explain
> 
> Adding the cable control to this interface will make it more complex
> from users perspective. However, nothing forces the user to control
> also the cable.

But we would like to indicate to the user that we cannot run
an alternate mode because the cable is incapable as opposed to the
device.

	Regards
		Oliver

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web