RE: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

[Yang, Wenyou]

Hi Alan,

Sorry for late answer.

> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: 2016年5月13日 2:11
> To: Yang, Wenyou 
> Cc: Greg Kroah-Hartman ; Ferre, Nicolas
> ; linux-usb@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending
> 
> On Thu, 12 May 2016, Wenyou Yang wrote:
> 
> > In order to get lower consumption, as a workaround, suspend the USB
> > PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI Interrupt
> > Configuration Register while OHCI USB suspending.
> 
> What does this mean?  What does suspending a port do?  Is it the same as a
> normal USB port suspend?

The usb controller from Synopsis does not managed correctly the suspend mode 
for the EHCI. 
There is no way to have the VDDUTMII (USB device and host UTMI interface) 
suspend without any device connected to it. 

That's why we added this specific control to fix this issue. Namely, by setting 
some bits of one of the special function registers to fix this issue outside 
the usb controller. 

And the suspend mode works in OHCI mode.

It is not same as a normal USB port suspend.

> 
> If it is the same, why doesn't the USB_PORT_FEAT_SUSPEND subcase of the
> SetPortFeature case in ohci_hub_control() already take care of this?
> 
> > This suspend operation must be done before stopping the USB clock,
> > resume after the USB clock enabled.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> 
> > @@ -132,6 +135,17 @@ static void at91_stop_hc(struct platform_device
> > *pdev)
> >
> >
> > /*
> > -*/
> >
> > +struct regmap *at91_dt_syscon_sfr(void) {
> > +   struct regmap *regmap;
> > +
> > +   regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
> > +   if (IS_ERR(regmap))
> > +   return NULL;
> 
> If you get an error, the regmap pointer is set to NULL...
> 
> > @@ -197,6 +211,8 @@ static int usb_hcd_at91_probe(const struct hc_driver
> *driver,
> > goto err;
> > }
> >
> > +   ohci_at91->sfr_regmap = at91_dt_syscon_sfr();
> 
> With no other error checking...
> 
> > +
> > board = hcd->self.controller->platform_data;
> > ohci = hcd_to_ohci(hcd);
> > ohci->num_ports = board->ports;
> 
> > +static int ohci_at91_port_ctrl(struct regmap *regmap, bool enable) {
> > +   u32 regval;
> > +   int ret;
> > +
> > +   if (IS_ERR(regmap))
> > +   return PTR_ERR(regmap);
> > +
> > +   ret = regmap_read(regmap, SFR_OHCIICR, );
> 
> And now what happens if regmap is NULL?  Hint: It won't be pretty...
> 
> Alan Stern


Best Regards,
Wenyou Yang

Re: [PATCH] usb: serial: update CH34x driver in drivers/usb/serial

[Greg KH]

On Thu, Jun 23, 2016 at 06:47:54PM -0700, t...@winchiphead.com wrote:
> The old driver for usb-serial chips ch34x which submitted by kernel volunteer
> Frank A Kingswood  is too old to use, and 
> the
> driver has bugs when receiving chracters, thus after communicating with the 
> author 
> we decide to revoke the old driver ch341.c and submit the new one ch34x.c.

"revoke"?  Why not just fix the bugs in the existing one instead?  That
would be a much smaller patch, and much easier to review.

> Add the relevant details to Documentation/usb/usb-serial.txt.
> Change the relevant files Kconfig and Makefile in drivers/usb/serial.
> 
> Signed-off-by: WCH Tech Group 

This has to be a person, it can not be a company, or any other anonymous
email address, sorry.  Same with your "From:" address.

thanks,

greg k-h
--
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] usb: serial: update CH34x driver in drivers/usb/serial

[Greg KH]

On Thu, Jun 23, 2016 at 06:47:54PM -0700, t...@winchiphead.com wrote:
> The old driver for usb-serial chips ch34x which submitted by kernel volunteer
> Frank A Kingswood  is too old to use, and 
> the
> driver has bugs when receiving chracters, thus after communicating with the 
> author 
> we decide to revoke the old driver ch341.c and submit the new one ch34x.c.
> 
> Add the relevant details to Documentation/usb/usb-serial.txt.
> Change the relevant files Kconfig and Makefile in drivers/usb/serial.
> 
> Signed-off-by: WCH Tech Group 
> 
> ---
>  Documentation/usb/usb-serial.txt |  27 +-
>  drivers/usb/serial/Kconfig   |   8 +-
>  drivers/usb/serial/Makefile  |   2 +-
>  drivers/usb/serial/ch341.c   | 580 ---
>  drivers/usb/serial/ch34x.c   | 985 
> +++
>  5 files changed, 1008 insertions(+), 594 deletions(-)
>  delete mode 100644 drivers/usb/serial/ch341.c
>  create mode 100644 drivers/usb/serial/ch34x.c
> 
> diff --git a/Documentation/usb/usb-serial.txt 
> b/Documentation/usb/usb-serial.txt
> index 349f310..c21437b 100644
> --- a/Documentation/usb/usb-serial.txt
> +++ b/Documentation/usb/usb-serial.txt
> @@ -1,4 +1,4 @@
> -INTRODUCTION
> +INTRODUCTION

You also don't need to change this line :)

--
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

[PATCH] usb: serial: update CH34x driver in drivers/usb/serial

[tech]

The old driver for usb-serial chips ch34x which submitted by kernel volunteer
Frank A Kingswood  is too old to use, and the
driver has bugs when receiving chracters, thus after communicating with the 
author 
we decide to revoke the old driver ch341.c and submit the new one ch34x.c.

Add the relevant details to Documentation/usb/usb-serial.txt.
Change the relevant files Kconfig and Makefile in drivers/usb/serial.

Signed-off-by: WCH Tech Group 

---
 Documentation/usb/usb-serial.txt |  27 +-
 drivers/usb/serial/Kconfig   |   8 +-
 drivers/usb/serial/Makefile  |   2 +-
 drivers/usb/serial/ch341.c   | 580 ---
 drivers/usb/serial/ch34x.c   | 985 +++
 5 files changed, 1008 insertions(+), 594 deletions(-)
 delete mode 100644 drivers/usb/serial/ch341.c
 create mode 100644 drivers/usb/serial/ch34x.c

diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt
index 349f310..c21437b 100644
--- a/Documentation/usb/usb-serial.txt
+++ b/Documentation/usb/usb-serial.txt
@@ -1,4 +1,4 @@
-INTRODUCTION
+???INTRODUCTION
 
   The USB serial driver currently supports a number of different USB to
   serial converter products, as well as some devices that use a serial
@@ -430,15 +430,24 @@ Options supported:
   See http://www.uuhaus.de/linux/palmconnect.html for up-to-date
   information on this driver.
 
-Winchiphead CH341 Driver
-
-  This driver is for the Winchiphead CH341 USB-RS232 Converter. This chip
-  also implements an IEEE 1284 parallel port, I2C and SPI, but that is not
-  supported by the driver. The protocol was analyzed from the behaviour
-  of the Windows driver, no datasheet is available at present.
-  The manufacturer's website: http://www.winchiphead.com/.
+WCH CH34x Driver
+
+  CH340 and CH341 are USB bus convert chips, CH340 can realize USB convert to
+  serial interface, IrDA infrared and printer interface.
+  CH341 can realize USB convert to serial interface, printer interface, 
parallel
+  port interface which suppots EPP and MEM, I2C and SPI.
+  But this driver only supports USB-SERIAL function, the manufacturer's 
website:
+  http://www.wch.cn and http://www.winchiphead.com.
+  You can visit it for CH34x datasheets and more drivers on the chips.
+  In serial interface mode, CH340 and CH341 supply common MODEM liaison signal,
+  used to enlarge asynchronous serial interface of computer or upgrade the 
common
+  serial device to USB bus directly.
   For any questions or problems with this driver, please contact
-  fr...@kingswood-consulting.co.uk.
+  WCH Tech Group.
+
+  TODO:
+- support more features
+- checkpatch.pl fixes
 
 Moschip MCS7720, MCS7715 driver
 
diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 56ecb8b..b98041f 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -99,14 +99,14 @@ config USB_SERIAL_BELKIN
  To compile this driver as a module, choose M here: the
  module will be called belkin_sa.
 
-config USB_SERIAL_CH341
-   tristate "USB Winchiphead CH341 Single Port Serial Driver"
+config USB_SERIAL_CH34x
+   tristate "USB Winchiphead CH34x Single Port Serial Driver"
help
- Say Y here if you want to use a Winchiphead CH341 single port
+ Say Y here if you want to use a Winchiphead CH34x single port
  USB to serial adapter.
 
  To compile this driver as a module, choose M here: the
- module will be called ch341.
+ module will be called ch34x.
 
 config USB_SERIAL_WHITEHEAT
tristate "USB ConnectTech WhiteHEAT Serial Driver"
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index 349d9df..51095e7 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -13,7 +13,7 @@ usbserial-$(CONFIG_USB_SERIAL_CONSOLE)+= console.o
 obj-$(CONFIG_USB_SERIAL_AIRCABLE)  += aircable.o
 obj-$(CONFIG_USB_SERIAL_ARK3116)   += ark3116.o
 obj-$(CONFIG_USB_SERIAL_BELKIN)+= belkin_sa.o
-obj-$(CONFIG_USB_SERIAL_CH341) += ch341.o
+obj-$(CONFIG_USB_SERIAL_CH34x) += ch34x.o
 obj-$(CONFIG_USB_SERIAL_CP210X)+= cp210x.o
 obj-$(CONFIG_USB_SERIAL_CYBERJACK) += cyberjack.o
 obj-$(CONFIG_USB_SERIAL_CYPRESS_M8)+= cypress_m8.o
diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
deleted file mode 100644
index f139488..000
--- a/drivers/usb/serial/ch341.c
+++ /dev/null
@@ -1,580 +0,0 @@
-/*
- * Copyright 2007, Frank A Kingswood 
- * Copyright 2007, Werner Cornelius 
- * Copyright 2009, Boris Hajduk 
- *
- * ch341.c implements a serial port driver for the Winchiphead CH341.
- *
- * The CH341 device can be used to implement an RS232 asynchronous
- 

[PATCH] usb-gadget/f_hid: add dev to configfs

[Johannes Berg]

Even if the /dev/hidg* chardev is automatically created, one
has to guess which one belongs to which function. In the case
of multiple HID functions, or maybe even multiple peripherals,
this becomes difficult.

Add the dev (with major and minor number) to configfs to allow
looking up (or even creating) the right device node for each
function. This file is read-only.

Signed-off-by: Johannes Berg 
---
 drivers/usb/gadget/function/f_hid.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/gadget/function/f_hid.c 
b/drivers/usb/gadget/function/f_hid.c
index 51980c50546d..4cd486600a9b 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -809,11 +809,21 @@ end:
 
 CONFIGFS_ATTR(f_hid_opts_, report_desc);
 
+static ssize_t f_hid_opts_dev_show(struct config_item *item, char *page)
+{
+   struct f_hid_opts *opts = to_f_hid_opts(item);
+
+   return sprintf(page, "%d:%d\n", major, opts->minor);
+}
+
+CONFIGFS_ATTR_RO(f_hid_opts_, dev);
+
 static struct configfs_attribute *hid_attrs[] = {
_hid_opts_attr_subclass,
_hid_opts_attr_protocol,
_hid_opts_attr_report_length,
_hid_opts_attr_report_desc,
+   _hid_opts_attr_dev,
NULL,
 };
 
-- 
2.8.1

--
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

[PATCH] USB: don't free bandwidth_mutex too early

[Alan Stern]

The USB core contains a bug that can show up when a USB-3 host
controller is removed.  If the primary (USB-2) hcd structure is
released before the shared (USB-3) hcd, the core will try to do a
double-free of the common bandwidth_mutex.

The problem was described in graphical form by Chung-Geol Kim, who
first reported it:

=
 At *remove USB(3.0) Storage
 sequence <1> --> <5> ((Problem Case))
=
  VOLD
|
 (uevent)
|_
   |<1>   |
   |dwc3_otg_sm_work  |
   |usb_put_hcd   |
   |peer_hcd(kref=2)|
   |__|
|_ 
   |<2>   |
   |New USB BUS #2|
   |  |
   |peer_hcd(kref=1)  |
   |  |
 --(Link)-bandXX_mutex|
 | |__|
 |
___  |
   |<3>| |
   |dwc3_otg_sm_work   | |
   |usb_put_hcd| |
   |primary_hcd(kref=1)| |
   |___| |
_|_  |
   |<4>| |
   |New USB BUS #1 | |
   |hcd_release| |
   |primary_hcd(kref=0)| |
   |   | |
   |bandXX_mutex(free) |<-
   |___|
   (( VOLD ))
__|___
   |<5>   |
   |  SCSI|
   |usb_put_hcd   |
   |peer_hcd(kref=0)  |
   |*hcd_release  |
   |bandXX_mutex(free*)|<- double free
   |__|

=

This happens because hcd_release() frees the bandwidth_mutex whenever
it sees a primary hcd being released (which is not a very good idea
in any case), but in the course of releasing the primary hcd, it
changes the pointers in the shared hcd in such a way that the shared
hcd will appear to be primary when it gets released.

This patch fixes the problem by changing hcd_release() so that it
deallocates the bandwidth_mutex only when the _last_ hcd structure
referencing it is released.  The patch also removes an unnecessary
test, so that when an hcd is released, both the shared_hcd and
primary_hcd pointers in the hcd's peer will be cleared.

Signed-off-by: Alan Stern 
Reported-by: Chung-Geol Kim 
Tested-by: Chung-Geol Kim 
CC: 

---


[as1805]


 drivers/usb/core/hcd.c |   14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

Index: usb-4.x/drivers/usb/core/hcd.c
===
--- usb-4.x.orig/drivers/usb/core/hcd.c
+++ usb-4.x/drivers/usb/core/hcd.c
@@ -2588,24 +2588,22 @@ EXPORT_SYMBOL_GPL(usb_create_hcd);
  * Don't deallocate the bandwidth_mutex until the last shared usb_hcd is
  * deallocated.
  *
- * Make sure to only deallocate the bandwidth_mutex when the primary HCD is
- * freed.  When hcd_release() is called for either hcd in a peer set
- * invalidate the peer's ->shared_hcd and ->primary_hcd pointers to
- * block new peering attempts
+ * Make sure to deallocate the bandwidth_mutex only when the last HCD is
+ * freed.  When hcd_release() is called for either hcd in a peer set,
+ * invalidate the peer's ->shared_hcd and ->primary_hcd pointers.
  */
 static void hcd_release(struct kref *kref)
 {
struct usb_hcd *hcd = container_of (kref, struct usb_hcd, kref);
 
mutex_lock(_port_peer_mutex);
-   if (usb_hcd_is_primary_hcd(hcd))
-   kfree(hcd->bandwidth_mutex);
if (hcd->shared_hcd) {
struct usb_hcd *peer = hcd->shared_hcd;
 
peer->shared_hcd = NULL;
-   if (peer->primary_hcd == hcd)
-   peer->primary_hcd = NULL;
+   peer->primary_hcd = NULL;
+   } else {
+   kfree(hcd->bandwidth_mutex);
}
mutex_unlock(_port_peer_mutex);
kfree(hcd);

--
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: USB: EHCI: declare hostpc register as zero-length array

[Alan Stern]

Greg:

Sorry, the Subject line of the original email left out "[PATCH]" at the 
beginning.  Will it still work with your scripts?

Alan Stern


On Thu, 23 Jun 2016, Alan Stern wrote:

> The HOSTPC extension registers found in some EHCI implementations form
> a variable-length array, with one element for each port.  Therefore
> the hostpc field in struct ehci_regs should be declared as a
> zero-length array, not a single-element array.
> 
> This fixes a problem reported by UBSAN.
> 
> Signed-off-by: Alan Stern 
> Reported-by: Wilfried Klaebe 
> Tested-by: Wilfried Klaebe 
> CC: 
> 
> ---
> 
> 
> [as1803]
> 
> 
>  include/linux/usb/ehci_def.h |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Index: usb-4.x/include/linux/usb/ehci_def.h
> ===
> --- usb-4.x.orig/include/linux/usb/ehci_def.h
> +++ usb-4.x/include/linux/usb/ehci_def.h
> @@ -180,11 +180,11 @@ struct ehci_regs {
>   * PORTSCx
>   */
>   /* HOSTPC: offset 0x84 */
> - u32 hostpc[1];  /* HOSTPC extension */
> + u32 hostpc[0];  /* HOSTPC extension */
>  #define HOSTPC_PHCD  (1<<22) /* Phy clock disable */
>  #define HOSTPC_PSPD  (3<<25) /* Port speed detection */
>  
> - u32 reserved5[16];
> + u32 reserved5[17];
>  
>   /* USBMODE_EX: offset 0xc8 */
>   u32 usbmode_ex; /* USB Device mode extension */

--
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

USB: EHCI: declare hostpc register as zero-length array

[Alan Stern]

The HOSTPC extension registers found in some EHCI implementations form
a variable-length array, with one element for each port.  Therefore
the hostpc field in struct ehci_regs should be declared as a
zero-length array, not a single-element array.

This fixes a problem reported by UBSAN.

Signed-off-by: Alan Stern 
Reported-by: Wilfried Klaebe 
Tested-by: Wilfried Klaebe 
CC: 

---


[as1803]


 include/linux/usb/ehci_def.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: usb-4.x/include/linux/usb/ehci_def.h
===
--- usb-4.x.orig/include/linux/usb/ehci_def.h
+++ usb-4.x/include/linux/usb/ehci_def.h
@@ -180,11 +180,11 @@ struct ehci_regs {
  * PORTSCx
  */
/* HOSTPC: offset 0x84 */
-   u32 hostpc[1];  /* HOSTPC extension */
+   u32 hostpc[0];  /* HOSTPC extension */
 #define HOSTPC_PHCD(1<<22) /* Phy clock disable */
 #define HOSTPC_PSPD(3<<25) /* Port speed detection */
 
-   u32 reserved5[16];
+   u32 reserved5[17];
 
/* USBMODE_EX: offset 0xc8 */
u32 usbmode_ex; /* USB Device mode extension */

--
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] usb: xhci: handle uPD720201 and uPD720202 w/o ROM

[Christian Lamparter]

Hello,

On Tuesday, June 21, 2016 05:56:58 AM Yoshihiro Shimoda wrote:
> > From: Christian Lamparter
> > Sent: Tuesday, June 21, 2016 12:32 AM
> > 
> > On Wednesday, June 08, 2016 12:14:57 AM Christian Lamparter wrote:
> > > This patch adds a firmware check for the uPD720201K8-711-BAC-A
> > > and uPD720202K8-711-BAA-A variant. Both of these chips are listed
> > > in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as
> > > devices which need a firmware in order to work as they do not have
> > > support to load the firmware from an external ROM.
> > >
> > > Currently, the xhci-pci driver is unable to initialize the hcd in
> > > this case. Instead it will wait for 30 seconds and cause a timeout
> > > in xhci_handshake() and fails.
> > >
> > > [5.116990] xhci_hcd :45:00.0: new USB bus registered ...
> > > [   32.335215] xhci_hcd :45:00.0: can't setup: -110
> > > [   32.340179] xhci_hcd :45:00.0: USB bus 2 deregistered
> > > [   32.345587] xhci_hcd :45:00.0: init :45:00.0 fail, -110
> > > [   32.351496] xhci_hcd: probe of :45:00.0 failed with error -110
> > >
> > > Cc: Yoshihiro Shimoda 
> > > Signed-off-by: Christian Lamparter 
> > Hello?
> > 
> > Are there any news on this? Or is there anything else that I'm missing
> > which blocks this patch? If it's because the device won't be working
> > either with this patch, then please let me know.
> 
> Thank you for the patch with CC me.
> However, I'm afraid but I don't know the detail of the Renesas xHCI PCI 
> controller.
> (My job is for R-Car environment for now.)
Oh. I see. Still, I would like to thank you for your input. I looked at
the rcar loader and firmware: The firmware header (aa55 + firmware version
pointer at 0x14) are carbon-copies of the pci parts (or vice versa?). I guess
I shouldn't be surprised, I bet the rcar and uPD both have a similar SuperH.
The firmware upload mechanism itself seems to be a bit different though, the
spec for the pci devices lists much more stuff to check and verify. Also, the
pci variant uploades 2 x 32bit packages at a time (via data0 and data1 in the
pci config space). However, the procedure is still somewhat identical.

Anyway, if you want to take a look: I went ahead and wrote a firmware loader
for the uPD720201 and uPD720202: I have attached in the patch below. The device
now works for this APM82181 (PowerPC 464 - Big Endian).

xhci_hcd :45:00.0: xHCI Host Controller
xhci_hcd :45:00.0: new USB bus registered, assigned bus number 2
xhci_hcd :45:00.0: hcc params 0x014051cf hci version 0x100 quirks 0x0190
xhci_hcd :45:00.0: xHCI Host Controller
xhci_hcd :45:00.0: new USB bus registered, assigned bus number 3
usb usb3: We don't know the algorithms for LPM for this host, disabling LPM.
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
usb 3-1: new SuperSpeed USB device number 2 using xhci_hcd
usb-storage 3-1:1.0: USB Mass Storage device detected
scsi host1: usb-storage 3-1:1.0
scsi 1:0:0:0: Direct-Access Intenso  Slim LinePMAP PQ: 0 ANSI: 6
sd 1:0:0:0: [sdb] 15466496 512-byte logical blocks: (7.92 GB/7.38 GiB)
...

> By the way, the issue seems similar with R-Car environment though :)
> http://thread.gmane.org/gmane.linux.kernel.stable/175457/focus=140699
> 
> and fix patch for it:
> http://thread.gmane.org/gmane.linux.kernel.stable/177524
Yes :). Same thing here. Load the firmware and the device is happy.
I know this is a big ask: Do you know or can you give me a lead
to whom would be willing to help/support the uPD720201/2? It would
be great if the firmware could be added to linux-firmware.git.

Note: This is one way to do it. But there are many more... I think adding
a pci_enable quirk to drivers/usb/host/pci-quirk.c is the least invasive
way... unless of course, someone knows a even better method... So please:
let me know!

Regards,
Christian
---
>From a0dc613140bab907a3d5787a7ae7b0638bf674d0 Mon Sep 17 00:00:00 2001
From: Christian Lamparter 
Date: Thu, 23 Jun 2016 20:28:20 +0200
Subject: [PATCH] usb: xhci: add firmware loader quirk for  uPD720201 and
 uPD720202

This patch adds a firmware loader for the uPD720201K8-711-BAC-A
and uPD720202K8-711-BAA-A variant. Both of these chips are listed
in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as
devices which need a firmware in order to work as they do not have
support to load the firmware from an external ROM.

Currently, the xhci-pci driver is unable to initialize the hcd in
this case. Instead it will wait for 30 seconds and cause a timeout
in xhci_handshake() and fail.

[5.116990] xhci_hcd :45:00.0: new USB bus registered ...
[   32.335215] xhci_hcd :45:00.0: can't setup: -110
[   32.340179] xhci_hcd :45:00.0: USB bus 2 deregistered
[   32.345587] xhci_hcd :45:00.0: init :45:00.0 fail, -110
[   32.351496] xhci_hcd: probe of :45:00.0 failed with error -110

With the firmware 

Re: [PATCH v2] input: tablet: pegasus_notetaker: USB PM fixes

[Dmitry Torokhov]

Hi Martin,

On Tue, Jun 14, 2016 at 01:20:15PM +0200, Martin Kepplinger wrote:
>  static int pegasus_reset_resume(struct usb_interface *intf)
>  {
> + struct pegasus *pegasus = usb_get_intfdata(intf);
> +
> + if (pegasus->dev->users)
> + pegasus_set_mode(pegasus, PEN_MODE_XY, NOTETAKER_LED_MOUSE);
> +
>   return pegasus_resume(intf);

Hmm, we need to take input mutex when using pegasus->dev->users, how
about the version below instead?

Thanks.

-- 
Dmitry

Input: pegasus_notetake - USB PM fixes

From: Martin Kepplinger 

* Fix usb_autopm calls to be balanced
 * In reset_resume() we need to set the device mode
 * In suspend() we must cancel the workqueue's work

Signed-off-by: Martin Kepplinger 
Signed-off-by: Dmitry Torokhov 
---
 drivers/input/tablet/pegasus_notetaker.c |   46 --
 1 file changed, 31 insertions(+), 15 deletions(-)

diff --git a/drivers/input/tablet/pegasus_notetaker.c 
b/drivers/input/tablet/pegasus_notetaker.c
index 805afe3..d20ea06 100644
--- a/drivers/input/tablet/pegasus_notetaker.c
+++ b/drivers/input/tablet/pegasus_notetaker.c
@@ -80,7 +80,7 @@ struct pegasus {
struct work_struct init;
 };
 
-static void pegasus_control_msg(struct pegasus *pegasus, u8 *data, int len)
+static int pegasus_control_msg(struct pegasus *pegasus, u8 *data, int len)
 {
const int sizeof_buf = len + 2;
int result;
@@ -88,7 +88,7 @@ static void pegasus_control_msg(struct pegasus *pegasus, u8 
*data, int len)
 
cmd_buf = kmalloc(sizeof_buf, GFP_KERNEL);
if (!cmd_buf)
-   return;
+   return -ENOMEM;
 
cmd_buf[0] = NOTETAKER_REPORT_ID;
cmd_buf[1] = len;
@@ -101,17 +101,23 @@ static void pegasus_control_msg(struct pegasus *pegasus, 
u8 *data, int len)
 0, 0, cmd_buf, sizeof_buf,
 USB_CTRL_SET_TIMEOUT);
 
-   if (result != sizeof_buf)
-   dev_err(>usbdev->dev, "control msg error\n");
+   if (result != sizeof_buf) {
+   if (result >= 0)
+   result = -EIO;
+   dev_err(>usbdev->dev, "control msg error: %d\n",
+   result);
+   }
 
kfree(cmd_buf);
+
+   return result;
 }
 
-static void pegasus_set_mode(struct pegasus *pegasus, u8 mode, u8 led)
+static int pegasus_set_mode(struct pegasus *pegasus, u8 mode, u8 led)
 {
u8 cmd[] = { NOTETAKER_SET_CMD, NOTETAKER_SET_MODE, led, mode };
 
-   pegasus_control_msg(pegasus, cmd, sizeof(cmd));
+   return pegasus_control_msg(pegasus, cmd, sizeof(cmd));
 }
 
 static void pegasus_parse_packet(struct pegasus *pegasus)
@@ -205,27 +211,24 @@ static int pegasus_open(struct input_dev *dev)
return retval;
 
pegasus->irq->dev = pegasus->usbdev;
-   if (usb_submit_urb(pegasus->irq, GFP_KERNEL))
+   if (usb_submit_urb(pegasus->irq, GFP_KERNEL)) {
retval = -EIO;
+   goto out;
+   }
 
-   pegasus_set_mode(pegasus, PEN_MODE_XY, NOTETAKER_LED_MOUSE);
+   retval = pegasus_set_mode(pegasus, PEN_MODE_XY, NOTETAKER_LED_MOUSE);
 
+out:
usb_autopm_put_interface(pegasus->intf);
-
return retval;
 }
 
 static void pegasus_close(struct input_dev *dev)
 {
struct pegasus *pegasus = input_get_drvdata(dev);
-   int autopm_error;
 
-   autopm_error = usb_autopm_get_interface(pegasus->intf);
usb_kill_urb(pegasus->irq);
cancel_work_sync(>init);
-
-   if (!autopm_error)
-   usb_autopm_put_interface(pegasus->intf);
 }
 
 static int pegasus_probe(struct usb_interface *intf,
@@ -373,6 +376,7 @@ static int pegasus_suspend(struct usb_interface *intf, 
pm_message_t message)
 
mutex_lock(>dev->mutex);
usb_kill_urb(pegasus->irq);
+   cancel_work_sync(>init);
mutex_unlock(>dev->mutex);
 
return 0;
@@ -393,7 +397,19 @@ static int pegasus_resume(struct usb_interface *intf)
 
 static int pegasus_reset_resume(struct usb_interface *intf)
 {
-   return pegasus_resume(intf);
+   struct pegasus *pegasus = usb_get_intfdata(intf);
+   int retval = 0;
+
+   mutex_lock(>dev->mutex);
+   if (pegasus->dev->users) {
+   retval = pegasus_set_mode(pegasus, PEN_MODE_XY,
+ NOTETAKER_LED_MOUSE);
+   if (!retval && usb_submit_urb(pegasus->irq, GFP_NOIO) < 0)
+   retval = -EIO;
+   }
+   mutex_unlock(>dev->mutex);
+
+   return retval;
 }
 
 static const struct usb_device_id pegasus_ids[] = {
--
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 v9] input: tablet: add Pegasus Notetaker tablet driver

[Martin Kepplinger]

Am 2016-06-15 um 15:01 schrieb Martin Kepplinger:
> This adds a driver for the Pegasus Notetaker Pen. When connected,
> this uses the Pen as an input tablet.
> 
> This device was sold in various different brandings, for example
>  "Pegasus Mobile Notetaker M210",
>  "Genie e-note The Notetaker",
>  "Staedtler Digital ballpoint pen 990 01",
>  "IRISnotes Express" or
>  "NEWLink Digital Note Taker".
> 
> Here's an example, so that you know what we are talking about:
> http://www.genie-online.de/genie-e-note-2/
> 
> https://pegatech.blogspot.com/ seems to be a remaining official resource.
> 
> This device can also transfer saved (offline recorded handwritten) data and
> there are userspace programs that do this, see https://launchpad.net/m210
> (Well, alternatively there are really fast scanners out there :)
> 
> It's *really* fun to use as an input tablet though! So let's support this
> for everybody.
> 
> Signed-off-by: Martin Kepplinger 
> ---
> Hi Dmitry. I append this just in case you want to replace the driver you
> took.
> 

Hi Dmitry,

This finishes up the driver for now. Any objections or advice from your
side?

thanks
  martin

--
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

[PATCH] Validate num_values for HIDIOCGUSAGES, HIDIOCSUSAGES commands.

[Scott Bauer]

This patch validates the num_values parameter from userland during
the HIDIOCGUSAGES and HIDIOCSUSAGES commands. Previously, if the
report id was set to HID_REPORT_ID_UNKNOWN, we would fail to
validate the num_values parameter leading to a heap overflow.

Signed-off-by: Scott Bauer 
---
 drivers/hid/usbhid/hiddev.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
index 2f1ddca..700145b 100644
--- a/drivers/hid/usbhid/hiddev.c
+++ b/drivers/hid/usbhid/hiddev.c
@@ -516,13 +516,13 @@ static noinline int hiddev_ioctl_usage(struct hiddev 
*hiddev, unsigned int cmd,
goto inval;
} else if (uref->usage_index >= field->report_count)
goto inval;
-
-   else if ((cmd == HIDIOCGUSAGES || cmd == HIDIOCSUSAGES) 
&&
-(uref_multi->num_values > HID_MAX_MULTI_USAGES 
||
- uref->usage_index + uref_multi->num_values > 
field->report_count))
-   goto inval;
}
 
+   if ((cmd == HIDIOCGUSAGES || cmd == HIDIOCSUSAGES) &&
+   (uref_multi->num_values > HID_MAX_MULTI_USAGES ||
+uref->usage_index + uref_multi->num_values > 
field->report_count))
+   goto inval;
+
switch (cmd) {
case HIDIOCGUSAGE:
uref->value = field->value[uref->usage_index];
-- 
1.9.1

--
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: [PATCHv3 1/2] usb: USB Type-C connector class

[Guenter Roeck]

On 06/23/2016 05:00 AM, Heikki Krogerus wrote:

Hi Oliver,

On Thu, Jun 23, 2016 at 10:38:58AM +0200, Oliver Neukum wrote:

On Thu, 2016-06-23 at 11:23 +0300, Heikki Krogerus wrote:

On Wed, Jun 22, 2016 at 06:44:18PM +0200, Oliver Neukum wrote:



No it's not. DRP means a port that can operate as _either_ Source
(host) or Sink (device), but not at the same time..


Yes, but it is unclear what you will be after a connection
and that's the point.


Which is a fact that we can do nothing about. The role after
connection with DRP ports will be dictated by the partner or selected
randomly in case the partner is also DRP. We can prefer a role, but
that in the end guarantees nothing. So if the role that we end up with
after connection (seen in current_data_role) does not satisfy us, all
we can do is try to swap it.

I'm not sure what is your point here.


And you can be able to become a host and be able to become a device.
But not at the same time. These ports are switchable.

The current API cannot express the difference.


I think you have misunderstood something. The only case where the port
can be dual-role is if it's set to be DRP. Otherwise it's Source only
OR Sink only.

The "Role Supported" bits only tell us how we can program for example
the ROLE_CONTROL registers. I guess the "Roles Supported" bits in
DEVICE_CAPABILITIES are not explained properly, so let's go over them
here:

000b = Source _or_ Sink only
001b = Source only
010b = Sink only
011b = Sink only with support for autonomously detected accessory modes
100b = DRP only, and this I believe mean we can not program the port
 to be Sink only or Source only


I think so, too.


101b = Source only OR Sink only OR DRP, plus ability to detect
 accessories and I guess also cables autonomously
110b = Source only OR Sink only OR DRP

So where the spec lists "Source, Sink", it actually should have said
"Source only OR Sink only".

But you still have only the following options for a port:
1) Source only (host)
2) Sink only (device)
3) DRP (device, host)


Yes, so you can map "000b = Source _or_ Sink only" to host or device
depending on the current setting. But then you lose the information
that it can be changed.


No it can't. The idea with the Roles Supported bits is for the driver
to be able to select the most appropriate role that fits the abilities
of the platform.

The configuration of the port after probing the port controller will
never change. If you have initially configured the port to be Sink
only (so device), it most likely means your platform can not act as
Source even if the port controller would.

And if you want to change the configuration of the port, for example
if your platform is capable of supporting Source and Sink modes, but
your port controller is not capable of supporting DRP (which would be
pretty messed up situation) but instead forces you to choose between
Sink and Source, you would in practice in any case have to unregister,
reconfigure and register the port again.

But in most cases the platform will not support all the capabilities
the port controller will be capable of. If for example on your
platform you have only USB host controller, it just means you will
have to have port controller that returns either 000b, 001b, 101b or
110b in the supported roles bits. Otherwise it will no be usable on
your platform.


So we throw away information.

And you map "100b = DRP only" and "101b" and "110b" to host, device


No I don't. If our platform can only support Sink mode, value "100b"
will not work and can not be ever registered, and values "101b" and
"110b" will report "device" in supported_data_roles.

And it is not the class that defines the capabilities of a port.
They are defined by the drivers that register the ports.


which again drops information.


There is no use in knowing details about the port controller
capabilities like if a port could be configured to be Source or Sink
only instead of just DRP from the typec class point of view. Those
details are port controller specific, and completely out side the
scope of the class driver. Not all USB Type-C PHYs will be port
controllers and not all ports registered with the class will even have
a PHY to deal with. This means we will not even always be able to read
the same kinds of details of the port like we are with port
controllers.

So if you want to get the capabilities of the port controller in use,
the port controller driver will have to expose them to user space, not
the class.


Agreed.

Guenter


--
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: [PATCHv3 1/2] usb: USB Type-C connector class

[Heikki Krogerus]

Hi Roger,

I'll fix all the typos you mention below...

On Thu, Jun 23, 2016 at 02:53:11PM +0300, Roger Quadros wrote:
> Hi Heikki,
> 
> On 21/06/16 17:51, Heikki Krogerus wrote:
> > The purpose of USB Type-C connector class is to provide
> > unified interface for the user space to get the status and
> > basic information about USB Type-C connectors on a system,
> > control over data role swapping, and when USB PD is
> 
> s/PD/PD (Power Delivery)
> 
> > available, also control over power role swapping and
> > Alternate Modes.
> > 
> > Signed-off-by: Heikki Krogerus 
> > ---
> >  Documentation/ABI/testing/sysfs-class-typec |  163 
> >  Documentation/usb/typec.txt |  101 +++
> >  MAINTAINERS |9 +
> >  drivers/usb/Kconfig |2 +
> >  drivers/usb/Makefile|2 +
> >  drivers/usb/typec/Kconfig   |7 +
> >  drivers/usb/typec/Makefile  |1 +
> >  drivers/usb/typec/typec.c   | 1173 
> > +++
> >  include/linux/usb/typec.h   |  255 ++
> >  9 files changed, 1713 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 include/linux/usb/typec.h
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-class-typec 
> > b/Documentation/ABI/testing/sysfs-class-typec
> > new file mode 100644
> > index 000..ce577f3
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-class-typec
> > @@ -0,0 +1,163 @@
> > +USB Type-C port devices (eg. /sys/class/typec/usbc0/)
> > +
> > +What:  /sys/class/typec//current_data_role
> > +Data:  June 2016
> 
> s/Data/Date everywhere in this patch.
> 
> > +Contact:   Heikki Krogerus 
> > +Description:
> > +   The current USB data role the port is operating in. This
> > +   attribute can be used for requestion data role swapping on th
> 
> s/requestion/requesting
> 
> s/th/the
> 
> > +   port.
> 
> Is it better to list all the values that can be here with a short note for 
> each?
> Same for all properties below?

Sure.

> Otherwise as a user I have no clue as to what all values I can set this to.
> 
> > +
> > +What:  /sys/class/typec//current_power_role
> > +Data:  June 2016
> > +Contact:   Heikki Krogerus 
> > +Description:
> > +   The current power role, source or sink, of the port. This
> > +   attribute can be used to request power role swap on the port
> > +   when USB Power Delivery is available.
> 
> So if it is not yet available, why add this now?

s/...when USB Power Delivery is available/...when the port supports
USB Power Delivery/

> > +
> > +What:  /sys/class/typec//current_vconn_role
> > +Data:  June 2016
> > +Contact:   Heikki Krogerus 
> > +Description:
> > +   Shows the current VCONN role, source or sink, of the port. This
> > +   attribute can be used to request vconn role swap on the port
> 
> s/vconn/VCONN
> 
> > +   when USB Power Delivery is available.
> 
> Why add if not yet available?
> 
> > +
> > +What:  /sys/class/typec//power_operation_mode
> > +Data:  June 2016
> > +Contact:   Heikki Krogerus 
> > +Description:
> > +   Shows the current power power mode the port is in. Reads as on
> 
> s/on/one
> 
> > +   of the following:
> > +   - USB - Normal power levels defined in USB specifications
> > +   - BC1.2 - Power levels defined in Battery Charging Specification
> > + v1.2
> > +   - USB Type-C 1.5A - Higher 1.5A current defined in USB Type-C
> > +   specification.
> > +   - USB Type-C 3.0A - Higher 3A current defined in USB Type-C
> > +   specification.
> > +- USB Power Delivery - The voltages and currents defined 
> > in USB
> > +  Power Delivery specification
> 
> What would it show when the port is disconnected?

USB. That is the default.

> Instead, is it somehow possible to list the actual negotiated current (in mA)
> here or in some other property, if you want to know the mode as well?

The current is not always going to be available for the port driver,
and in any case out side the scope of the class. Those details are
something that for example a USB Type-C PHY should always be able to
detect, except BC1.2... I think I'm dropping that one.

> > +
> > +What:  /sys/class/typec//preferred_role
> > +Data: 

Re: [PATCHv3 1/2] usb: USB Type-C connector class

[Heikki Krogerus]

On Thu, Jun 23, 2016 at 03:25:46PM +0300, Roger Quadros wrote:
> Hi,
> 
> On 23/06/16 15:00, Heikki Krogerus wrote:
> > Hi Oliver,
> > 
> > On Thu, Jun 23, 2016 at 10:38:58AM +0200, Oliver Neukum wrote:
> >> On Thu, 2016-06-23 at 11:23 +0300, Heikki Krogerus wrote:
> >>> On Wed, Jun 22, 2016 at 06:44:18PM +0200, Oliver Neukum wrote:
> >>
> >>> No it's not. DRP means a port that can operate as _either_ Source
> >>> (host) or Sink (device), but not at the same time..
> >>
> >> Yes, but it is unclear what you will be after a connection
> >> and that's the point.
> > 
> > Which is a fact that we can do nothing about. The role after
> > connection with DRP ports will be dictated by the partner or selected
> > randomly in case the partner is also DRP. We can prefer a role, but
> > that in the end guarantees nothing. So if the role that we end up with
> > after connection (seen in current_data_role) does not satisfy us, all
> > we can do is try to swap it.
> > 
> > I'm not sure what is your point here.
> 
> What if the application wants to know exactly what role the device is
> operating in at the current moment?
> 
> We need to have 2 distinct parameters.
> 
> 1) supported_modes : host, device, host or device
> 2) current_mode: host, device, disconnected

And we already do. But that is not the topic of this thread. Oliver I
believe feels that we are not presenting all the capabilities of the
ports.


Cheers,

-- 
heikki
--
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: [PATCHv3 1/2] usb: USB Type-C connector class

[Roger Quadros]

Hi,

On 23/06/16 15:00, Heikki Krogerus wrote:
> Hi Oliver,
> 
> On Thu, Jun 23, 2016 at 10:38:58AM +0200, Oliver Neukum wrote:
>> On Thu, 2016-06-23 at 11:23 +0300, Heikki Krogerus wrote:
>>> On Wed, Jun 22, 2016 at 06:44:18PM +0200, Oliver Neukum wrote:
>>
>>> No it's not. DRP means a port that can operate as _either_ Source
>>> (host) or Sink (device), but not at the same time..
>>
>> Yes, but it is unclear what you will be after a connection
>> and that's the point.
> 
> Which is a fact that we can do nothing about. The role after
> connection with DRP ports will be dictated by the partner or selected
> randomly in case the partner is also DRP. We can prefer a role, but
> that in the end guarantees nothing. So if the role that we end up with
> after connection (seen in current_data_role) does not satisfy us, all
> we can do is try to swap it.
> 
> I'm not sure what is your point here.

What if the application wants to know exactly what role the device is
operating in at the current moment?

We need to have 2 distinct parameters.

1) supported_modes : host, device, host or device
2) current_mode: host, device, disconnected

--
cheers,
-roger
--
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: [PATCHv3 1/2] usb: USB Type-C connector class

[Heikki Krogerus]

Hi Oliver,

On Thu, Jun 23, 2016 at 10:38:58AM +0200, Oliver Neukum wrote:
> On Thu, 2016-06-23 at 11:23 +0300, Heikki Krogerus wrote:
> > On Wed, Jun 22, 2016 at 06:44:18PM +0200, Oliver Neukum wrote:
> 
> > No it's not. DRP means a port that can operate as _either_ Source
> > (host) or Sink (device), but not at the same time..
> 
> Yes, but it is unclear what you will be after a connection
> and that's the point.

Which is a fact that we can do nothing about. The role after
connection with DRP ports will be dictated by the partner or selected
randomly in case the partner is also DRP. We can prefer a role, but
that in the end guarantees nothing. So if the role that we end up with
after connection (seen in current_data_role) does not satisfy us, all
we can do is try to swap it.

I'm not sure what is your point here.

> > > And you can be able to become a host and be able to become a device.
> > > But not at the same time. These ports are switchable.
> > > 
> > > The current API cannot express the difference.
> > 
> > I think you have misunderstood something. The only case where the port
> > can be dual-role is if it's set to be DRP. Otherwise it's Source only
> > OR Sink only.
> > 
> > The "Role Supported" bits only tell us how we can program for example
> > the ROLE_CONTROL registers. I guess the "Roles Supported" bits in
> > DEVICE_CAPABILITIES are not explained properly, so let's go over them
> > here:
> > 
> > 000b = Source _or_ Sink only
> > 001b = Source only
> > 010b = Sink only
> > 011b = Sink only with support for autonomously detected accessory modes
> > 100b = DRP only, and this I believe mean we can not program the port
> > to be Sink only or Source only
> 
> I think so, too.
> 
> > 101b = Source only OR Sink only OR DRP, plus ability to detect
> > accessories and I guess also cables autonomously
> > 110b = Source only OR Sink only OR DRP
> > 
> > So where the spec lists "Source, Sink", it actually should have said
> > "Source only OR Sink only".
> > 
> > But you still have only the following options for a port:
> > 1) Source only (host)
> > 2) Sink only (device)
> > 3) DRP (device, host)
> 
> Yes, so you can map "000b = Source _or_ Sink only" to host or device
> depending on the current setting. But then you lose the information
> that it can be changed. 

No it can't. The idea with the Roles Supported bits is for the driver
to be able to select the most appropriate role that fits the abilities
of the platform.

The configuration of the port after probing the port controller will
never change. If you have initially configured the port to be Sink
only (so device), it most likely means your platform can not act as
Source even if the port controller would.

And if you want to change the configuration of the port, for example
if your platform is capable of supporting Source and Sink modes, but
your port controller is not capable of supporting DRP (which would be
pretty messed up situation) but instead forces you to choose between
Sink and Source, you would in practice in any case have to unregister,
reconfigure and register the port again.

But in most cases the platform will not support all the capabilities
the port controller will be capable of. If for example on your
platform you have only USB host controller, it just means you will
have to have port controller that returns either 000b, 001b, 101b or
110b in the supported roles bits. Otherwise it will no be usable on
your platform.

> So we throw away information.
> 
> And you map "100b = DRP only" and "101b" and "110b" to host, device

No I don't. If our platform can only support Sink mode, value "100b"
will not work and can not be ever registered, and values "101b" and
"110b" will report "device" in supported_data_roles.

And it is not the class that defines the capabilities of a port.
They are defined by the drivers that register the ports.

> which again drops information.

There is no use in knowing details about the port controller
capabilities like if a port could be configured to be Source or Sink
only instead of just DRP from the typec class point of view. Those
details are port controller specific, and completely out side the
scope of the class driver. Not all USB Type-C PHYs will be port
controllers and not all ports registered with the class will even have
a PHY to deal with. This means we will not even always be able to read
the same kinds of details of the port like we are with port
controllers.

So if you want to get the capabilities of the port controller in use,
the port controller driver will have to expose them to user space, not
the class.


Br,

-- 
heikki
--
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: [PATCHv3 1/2] usb: USB Type-C connector class

[Roger Quadros]

Hi Heikki,

On 21/06/16 17:51, Heikki Krogerus wrote:
> The purpose of USB Type-C connector class is to provide
> unified interface for the user space to get the status and
> basic information about USB Type-C connectors on a system,
> control over data role swapping, and when USB PD is

s/PD/PD (Power Delivery)

> available, also control over power role swapping and
> Alternate Modes.
> 
> Signed-off-by: Heikki Krogerus 
> ---
>  Documentation/ABI/testing/sysfs-class-typec |  163 
>  Documentation/usb/typec.txt |  101 +++
>  MAINTAINERS |9 +
>  drivers/usb/Kconfig |2 +
>  drivers/usb/Makefile|2 +
>  drivers/usb/typec/Kconfig   |7 +
>  drivers/usb/typec/Makefile  |1 +
>  drivers/usb/typec/typec.c   | 1173 
> +++
>  include/linux/usb/typec.h   |  255 ++
>  9 files changed, 1713 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 include/linux/usb/typec.h
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-typec 
> b/Documentation/ABI/testing/sysfs-class-typec
> new file mode 100644
> index 000..ce577f3
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-typec
> @@ -0,0 +1,163 @@
> +USB Type-C port devices (eg. /sys/class/typec/usbc0/)
> +
> +What:/sys/class/typec//current_data_role
> +Data:June 2016

s/Data/Date everywhere in this patch.

> +Contact: Heikki Krogerus 
> +Description:
> + The current USB data role the port is operating in. This
> + attribute can be used for requestion data role swapping on th

s/requestion/requesting

s/th/the

> + port.

Is it better to list all the values that can be here with a short note for each?
Same for all properties below?

Otherwise as a user I have no clue as to what all values I can set this to.

> +
> +What:/sys/class/typec//current_power_role
> +Data:June 2016
> +Contact: Heikki Krogerus 
> +Description:
> + The current power role, source or sink, of the port. This
> + attribute can be used to request power role swap on the port
> + when USB Power Delivery is available.

So if it is not yet available, why add this now?

> +
> +What:/sys/class/typec//current_vconn_role
> +Data:June 2016
> +Contact: Heikki Krogerus 
> +Description:
> + Shows the current VCONN role, source or sink, of the port. This
> + attribute can be used to request vconn role swap on the port

s/vconn/VCONN

> + when USB Power Delivery is available.

Why add if not yet available?

> +
> +What:/sys/class/typec//power_operation_mode
> +Data:June 2016
> +Contact: Heikki Krogerus 
> +Description:
> + Shows the current power power mode the port is in. Reads as on

s/on/one

> + of the following:
> + - USB - Normal power levels defined in USB specifications
> + - BC1.2 - Power levels defined in Battery Charging Specification
> +   v1.2
> + - USB Type-C 1.5A - Higher 1.5A current defined in USB Type-C
> + specification.
> + - USB Type-C 3.0A - Higher 3A current defined in USB Type-C
> + specification.
> +- USB Power Delivery - The voltages and currents defined in 
> USB
> +Power Delivery specification

What would it show when the port is disconnected?

Instead, is it somehow possible to list the actual negotiated current (in mA)
here or in some other property, if you want to know the mode as well?

> +
> +What:/sys/class/typec//preferred_role
> +Data:June 2016
> +Contact: Heikki Krogerus 
> +Description:
> + The user space can notify the driver about the preferred role.
> + It should be handled as enabling of Try.SRC or Try.SNK, as
> + defined in USB Type-C specification, in the port drivers.

What would be the default setting?

> +
> +What:/sys/class/typec//supported_accessory_modes
> +Data:June 2016
> +Contact: Heikki Krogerus 
> +Description:
> + Lists the Accessory Modes, defined in the USB Type-C
> + specification, the 

[PATCH 04/16] sisusb: remove dummy variables

[Jiri Slaby]

bytes_written parameter of sisusb_copy_memory and sisusb_read_memory
is an out parameter, but its value is never used. So remove it and
pass a dummy variable down to sisusb_read_mem_bulk.

Signed-off-by: Jiri Slaby 
Cc: Thomas Winischhofer 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/misc/sisusbvga/sisusb.c  | 28 +---
 drivers/usb/misc/sisusbvga/sisusb_con.c  | 28 ++--
 drivers/usb/misc/sisusbvga/sisusb_init.h |  2 +-
 3 files changed, 24 insertions(+), 34 deletions(-)

diff --git a/drivers/usb/misc/sisusbvga/sisusb.c 
b/drivers/usb/misc/sisusbvga/sisusb.c
index 15666ad7c772..02abfcdfbf7b 100644
--- a/drivers/usb/misc/sisusbvga/sisusb.c
+++ b/drivers/usb/misc/sisusbvga/sisusb.c
@@ -1285,18 +1285,22 @@ int sisusb_readb(struct sisusb_usb_data *sisusb, u32 
adr, u8 *data)
 }
 
 int sisusb_copy_memory(struct sisusb_usb_data *sisusb, char *src,
-   u32 dest, int length, size_t *bytes_written)
+   u32 dest, int length)
 {
+   size_t dummy;
+
return sisusb_write_mem_bulk(sisusb, dest, src, length,
-   NULL, 0, bytes_written);
+   NULL, 0, );
 }
 
 #ifdef SISUSBENDIANTEST
-int sisusb_read_memory(struct sisusb_usb_data *sisusb, char *dest,
-   u32 src, int length, size_t *bytes_written)
+static int sisusb_read_memory(struct sisusb_usb_data *sisusb, char *dest,
+   u32 src, int length)
 {
+   size_t dummy;
+
return sisusb_read_mem_bulk(sisusb, src, dest, length,
-   NULL, bytes_written);
+   NULL, );
 }
 #endif
 #endif
@@ -1306,16 +1310,14 @@ static void sisusb_testreadwrite(struct sisusb_usb_data 
*sisusb)
 {
static char srcbuffer[] = { 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77 };
char destbuffer[10];
-   size_t dummy;
int i, j;
 
-   sisusb_copy_memory(sisusb, srcbuffer, sisusb->vrambase, 7, );
+   sisusb_copy_memory(sisusb, srcbuffer, sisusb->vrambase, 7);
 
for (i = 1; i <= 7; i++) {
dev_dbg(>sisusb_dev->dev,
"sisusb: rwtest %d bytes\n", i);
-   sisusb_read_memory(sisusb, destbuffer, sisusb->vrambase,
-   i, );
+   sisusb_read_memory(sisusb, destbuffer, sisusb->vrambase, i);
for (j = 0; j < i; j++) {
dev_dbg(>sisusb_dev->dev,
"rwtest read[%d] = %x\n",
@@ -2276,7 +2278,6 @@ int sisusb_reset_text_mode(struct sisusb_usb_data 
*sisusb, int init)
const struct font_desc *myfont;
u8 *tempbuf;
u16 *tempbufb;
-   size_t written;
static const char bootstring[] =
"SiSUSB VGA text console, (C) 2005 Thomas Winischhofer.";
static const char bootlogo[] = "(o_ //\\ V_/_";
@@ -2343,18 +2344,15 @@ int sisusb_reset_text_mode(struct sisusb_usb_data 
*sisusb, int init)
*(tempbufb++) = 0x0700 | bootstring[i++];
 
ret |= sisusb_copy_memory(sisusb, tempbuf,
-   sisusb->vrambase, 8192, );
+   sisusb->vrambase, 8192);
 
vfree(tempbuf);
 
}
 
} else if (sisusb->scrbuf) {
-
ret |= sisusb_copy_memory(sisusb, (char *)sisusb->scrbuf,
-   sisusb->vrambase, sisusb->scrbuf_size,
-   );
-
+   sisusb->vrambase, sisusb->scrbuf_size);
}
 
if (sisusb->sisusb_cursor_size_from >= 0 &&
diff --git a/drivers/usb/misc/sisusbvga/sisusb_con.c 
b/drivers/usb/misc/sisusbvga/sisusb_con.c
index afa853209f1d..0ebbf49cd649 100644
--- a/drivers/usb/misc/sisusbvga/sisusb_con.c
+++ b/drivers/usb/misc/sisusbvga/sisusb_con.c
@@ -370,7 +370,6 @@ static void
 sisusbcon_putc(struct vc_data *c, int ch, int y, int x)
 {
struct sisusb_usb_data *sisusb;
-   ssize_t written;
 
sisusb = sisusb_get_sisusb_lock_and_check(c->vc_num);
if (!sisusb)
@@ -384,7 +383,7 @@ sisusbcon_putc(struct vc_data *c, int ch, int y, int x)
 
 
sisusb_copy_memory(sisusb, (char *)SISUSB_VADDR(x, y),
-   (long)SISUSB_HADDR(x, y), 2, );
+   (long)SISUSB_HADDR(x, y), 2);
 
mutex_unlock(>lock);
 }
@@ -395,7 +394,6 @@ sisusbcon_putcs(struct vc_data *c, const unsigned short *s,
 int count, int y, int x)
 {
struct sisusb_usb_data *sisusb;
-   ssize_t written;
u16 *dest;
int i;
 
@@ -420,7 +418,7 @@ sisusbcon_putcs(struct vc_data *c, const unsigned short *s,
}
 
sisusb_copy_memory(sisusb, (char *)SISUSB_VADDR(x, y),
-   (long)SISUSB_HADDR(x, y), count * 2, );
+   

[PATCH 05/16] tty: vt, consw->con_scrolldelta cleanup

[Jiri Slaby]

* allow NULL consw->con_scrolldelta (some consoles define an empty
  hook)
* => remove empty hooks now
* return value of consw->con_scrolldelta is never checked => make the
  function void
* document consw->con_scrolldelta a bit

Signed-off-by: Jiri Slaby 
Cc: Thomas Winischhofer 
Cc: linux-usb@vger.kernel.org
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: linux-par...@vger.kernel.org
---
 drivers/tty/vt/vt.c |  2 +-
 drivers/usb/misc/sisusbvga/sisusb_con.c | 11 +++
 drivers/video/console/dummycon.c|  1 -
 drivers/video/console/fbcon.c   | 16 +++-
 drivers/video/console/mdacon.c  |  6 --
 drivers/video/console/newport_con.c |  7 ---
 drivers/video/console/sticon.c  |  6 --
 drivers/video/console/vgacon.c  | 13 +
 include/linux/console.h |  8 +++-
 9 files changed, 23 insertions(+), 47 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index abc79ae19079..365a91d01a0e 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -2468,7 +2468,7 @@ static void console_callback(struct work_struct *ignored)
if (scrollback_delta) {
struct vc_data *vc = vc_cons[fg_console].d;
clear_selection();
-   if (vc->vc_mode == KD_TEXT)
+   if (vc->vc_mode == KD_TEXT && vc->vc_sw->con_scrolldelta)
vc->vc_sw->con_scrolldelta(vc, scrollback_delta);
scrollback_delta = 0;
}
diff --git a/drivers/usb/misc/sisusbvga/sisusb_con.c 
b/drivers/usb/misc/sisusbvga/sisusb_con.c
index 0ebbf49cd649..a8244ebeb7a7 100644
--- a/drivers/usb/misc/sisusbvga/sisusb_con.c
+++ b/drivers/usb/misc/sisusbvga/sisusb_con.c
@@ -717,24 +717,22 @@ sisusbcon_blank(struct vc_data *c, int blank, int 
mode_switch)
 }
 
 /* interface routine */
-static int
+static void
 sisusbcon_scrolldelta(struct vc_data *c, int lines)
 {
struct sisusb_usb_data *sisusb;
int margin = c->vc_size_row * 4;
int ul, we, p, st;
 
-   /* The return value does not seem to be used */
-
sisusb = sisusb_get_sisusb_lock_and_check(c->vc_num);
if (!sisusb)
-   return 0;
+   return;
 
/* sisusb->lock is down */
 
if (sisusb_is_inactive(c, sisusb)) {
mutex_unlock(>lock);
-   return 0;
+   return;
}
 
if (!lines) /* Turn scrollback off */
@@ -774,8 +772,6 @@ sisusbcon_scrolldelta(struct vc_data *c, int lines)
sisusbcon_set_start_address(sisusb, c);
 
mutex_unlock(>lock);
-
-   return 1;
 }
 
 /* Interface routine */
@@ -1433,7 +1429,6 @@ static const struct consw sisusb_dummy_con = {
.con_font_default = SISUSBCONDUMMY,
.con_font_copy =SISUSBCONDUMMY,
.con_set_palette =  SISUSBCONDUMMY,
-   .con_scrolldelta =  SISUSBCONDUMMY,
 };
 
 int
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index 0efc52f11ad0..9ce03b9aba88 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -72,6 +72,5 @@ const struct consw dummy_con = {
 .con_font_default =DUMMY,
 .con_font_copy =   DUMMY,
 .con_set_palette = DUMMY,
-.con_scrolldelta = DUMMY,
 };
 EXPORT_SYMBOL_GPL(dummy_con);
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index afd3301ac40c..eadc7bf62eb3 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -171,7 +171,6 @@ static void fbcon_bmove(struct vc_data *vc, int sy, int sx, 
int dy, int dx,
 static int fbcon_switch(struct vc_data *vc);
 static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch);
 static int fbcon_set_palette(struct vc_data *vc, const unsigned char *table);
-static int fbcon_scrolldelta(struct vc_data *vc, int lines);
 
 /*
  *  Internal routines
@@ -2765,7 +2764,7 @@ static void fbcon_invert_region(struct vc_data *vc, u16 * 
p, int cnt)
}
 }
 
-static int fbcon_scrolldelta(struct vc_data *vc, int lines)
+static void fbcon_scrolldelta(struct vc_data *vc, int lines)
 {
struct fb_info *info = registered_fb[con2fb_map[fg_console]];
struct fbcon_ops *ops = info->fbcon_par;
@@ -2774,9 +2773,9 @@ static int fbcon_scrolldelta(struct vc_data *vc, int 
lines)
 
if (softback_top) {
if (vc->vc_num != fg_console)
-   return 0;
+   return;
if (vc->vc_mode != KD_TEXT || !lines)
-   return 0;
+   return;
if (logo_shown >= 0) {
struct vc_data *conp2 = vc_cons[logo_shown].d;
 
@@ 

[PATCH 06/16] tty: vt, consw->con_set_palette cleanup

[Jiri Slaby]

* allow NULL consw->con_set_palette (some consoles define an empty
  hook)
* => remove empty hooks now
* return value of consw->con_set_palette is never checked => make the
  function void
* document consw->con_set_palette a bit

Signed-off-by: Jiri Slaby 
Cc: Thomas Winischhofer 
Cc: linux-usb@vger.kernel.org
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: linux-par...@vger.kernel.org
---
 drivers/tty/vt/vt.c |  2 +-
 drivers/usb/misc/sisusbvga/sisusb_con.c | 11 ---
 drivers/video/console/dummycon.c|  1 -
 drivers/video/console/fbcon.c   | 10 +-
 drivers/video/console/mdacon.c  |  6 --
 drivers/video/console/newport_con.c |  6 --
 drivers/video/console/sticon.c  |  6 --
 drivers/video/console/vgacon.c  |  7 ++-
 include/linux/console.h |  4 +++-
 9 files changed, 15 insertions(+), 38 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 365a91d01a0e..d5d906051613 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3978,7 +3978,7 @@ static void set_palette(struct vc_data *vc)
 {
WARN_CONSOLE_UNLOCKED();
 
-   if (vc->vc_mode != KD_GRAPHICS)
+   if (vc->vc_mode != KD_GRAPHICS && vc->vc_sw->con_set_palette)
vc->vc_sw->con_set_palette(vc, color_table);
 }
 
diff --git a/drivers/usb/misc/sisusbvga/sisusb_con.c 
b/drivers/usb/misc/sisusbvga/sisusb_con.c
index a8244ebeb7a7..4112835f4aed 100644
--- a/drivers/usb/misc/sisusbvga/sisusb_con.c
+++ b/drivers/usb/misc/sisusbvga/sisusb_con.c
@@ -595,7 +595,7 @@ sisusbcon_save_screen(struct vc_data *c)
 }
 
 /* interface routine */
-static int
+static void
 sisusbcon_set_palette(struct vc_data *c, const unsigned char *table)
 {
struct sisusb_usb_data *sisusb;
@@ -604,17 +604,17 @@ sisusbcon_set_palette(struct vc_data *c, const unsigned 
char *table)
/* Return value not used by vt */
 
if (!CON_IS_VISIBLE(c))
-   return -EINVAL;
+   return;
 
sisusb = sisusb_get_sisusb_lock_and_check(c->vc_num);
if (!sisusb)
-   return -EINVAL;
+   return;
 
/* sisusb->lock is down */
 
if (sisusb_is_inactive(c, sisusb)) {
mutex_unlock(>lock);
-   return -EINVAL;
+   return;
}
 
for (i = j = 0; i < 16; i++) {
@@ -629,8 +629,6 @@ sisusbcon_set_palette(struct vc_data *c, const unsigned 
char *table)
}
 
mutex_unlock(>lock);
-
-   return 0;
 }
 
 /* interface routine */
@@ -1428,7 +1426,6 @@ static const struct consw sisusb_dummy_con = {
.con_font_get = SISUSBCONDUMMY,
.con_font_default = SISUSBCONDUMMY,
.con_font_copy =SISUSBCONDUMMY,
-   .con_set_palette =  SISUSBCONDUMMY,
 };
 
 int
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index 9ce03b9aba88..0ef544ef5634 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -71,6 +71,5 @@ const struct consw dummy_con = {
 .con_font_get =DUMMY,
 .con_font_default =DUMMY,
 .con_font_copy =   DUMMY,
-.con_set_palette = DUMMY,
 };
 EXPORT_SYMBOL_GPL(dummy_con);
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index eadc7bf62eb3..9359b06377cf 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -170,7 +170,7 @@ static void fbcon_bmove(struct vc_data *vc, int sy, int sx, 
int dy, int dx,
int height, int width);
 static int fbcon_switch(struct vc_data *vc);
 static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch);
-static int fbcon_set_palette(struct vc_data *vc, const unsigned char *table);
+static void fbcon_set_palette(struct vc_data *vc, const unsigned char *table);
 
 /*
  *  Internal routines
@@ -2651,17 +2651,17 @@ static struct fb_cmap palette_cmap = {
0, 16, palette_red, palette_green, palette_blue, NULL
 };
 
-static int fbcon_set_palette(struct vc_data *vc, const unsigned char *table)
+static void fbcon_set_palette(struct vc_data *vc, const unsigned char *table)
 {
struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
int i, j, k, depth;
u8 val;
 
if (fbcon_is_inactive(vc, info))
-   return -EINVAL;
+   return;
 
if (!CON_IS_VISIBLE(vc))
-   return 0;
+   return;
 
depth = fb_get_color_depth(>var, >fix);
if (depth > 3) {
@@ -2683,7 +2683,7 @@ static int fbcon_set_palette(struct vc_data *vc, const 
unsigned char *table)
} else
fb_copy_cmap(fb_default_cmap(1 << depth), _cmap);
 
-   return 

[PATCH 07/16] tty: vt, remove consw->con_bmove

[Jiri Slaby]

It is never called since commit 81732c3b2fede (tty vt: Fix line
garbage in virtual console on command line edition) in 3.7. So remove
all the callbacks.

Signed-off-by: Jiri Slaby 
Cc: Thomas Winischhofer 
Cc: linux-usb@vger.kernel.org
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: linux-par...@vger.kernel.org
---
 drivers/usb/misc/sisusbvga/sisusb_con.c | 35 -
 drivers/video/console/dummycon.c|  1 -
 drivers/video/console/fbcon.c   |  1 -
 drivers/video/console/mdacon.c  | 33 ---
 drivers/video/console/newport_con.c | 29 ---
 drivers/video/console/sticon.c  | 17 
 drivers/video/console/vgacon.c  |  1 -
 include/linux/console.h |  1 -
 8 files changed, 118 deletions(-)

diff --git a/drivers/usb/misc/sisusbvga/sisusb_con.c 
b/drivers/usb/misc/sisusbvga/sisusb_con.c
index 4112835f4aed..52a6da991165 100644
--- a/drivers/usb/misc/sisusbvga/sisusb_con.c
+++ b/drivers/usb/misc/sisusbvga/sisusb_con.c
@@ -477,39 +477,6 @@ sisusbcon_clear(struct vc_data *c, int y, int x, int 
height, int width)
mutex_unlock(>lock);
 }
 
-/* Interface routine */
-static void
-sisusbcon_bmove(struct vc_data *c, int sy, int sx,
-int dy, int dx, int height, int width)
-{
-   struct sisusb_usb_data *sisusb;
-   int cols, length;
-
-   if (width <= 0 || height <= 0)
-   return;
-
-   sisusb = sisusb_get_sisusb_lock_and_check(c->vc_num);
-   if (!sisusb)
-   return;
-
-   /* sisusb->lock is down */
-
-   cols = sisusb->sisusb_num_columns;
-
-   if (sisusb_is_inactive(c, sisusb)) {
-   mutex_unlock(>lock);
-   return;
-   }
-
-   length = ((height * cols) - dx - (cols - width - dx)) * 2;
-
-
-   sisusb_copy_memory(sisusb, (unsigned char *)SISUSB_VADDR(dx, dy),
-   (long)SISUSB_HADDR(dx, dy), length);
-
-   mutex_unlock(>lock);
-}
-
 /* interface routine */
 static int
 sisusbcon_switch(struct vc_data *c)
@@ -1371,7 +1338,6 @@ static const struct consw sisusb_con = {
.con_putcs =sisusbcon_putcs,
.con_cursor =   sisusbcon_cursor,
.con_scroll =   sisusbcon_scroll,
-   .con_bmove =sisusbcon_bmove,
.con_switch =   sisusbcon_switch,
.con_blank =sisusbcon_blank,
.con_font_set = sisusbcon_font_set,
@@ -1419,7 +1385,6 @@ static const struct consw sisusb_dummy_con = {
.con_putcs =SISUSBCONDUMMY,
.con_cursor =   SISUSBCONDUMMY,
.con_scroll =   SISUSBCONDUMMY,
-   .con_bmove =SISUSBCONDUMMY,
.con_switch =   SISUSBCONDUMMY,
.con_blank =SISUSBCONDUMMY,
.con_font_set = SISUSBCONDUMMY,
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index 0ef544ef5634..9269d5685239 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -64,7 +64,6 @@ const struct consw dummy_con = {
 .con_putcs =   DUMMY,
 .con_cursor =  DUMMY,
 .con_scroll =  DUMMY,
-.con_bmove =   DUMMY,
 .con_switch =  DUMMY,
 .con_blank =   DUMMY,
 .con_font_set =DUMMY,
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 9359b06377cf..eef8a8b7274f 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -3334,7 +3334,6 @@ static const struct consw fb_con = {
.con_putcs  = fbcon_putcs,
.con_cursor = fbcon_cursor,
.con_scroll = fbcon_scroll,
-   .con_bmove  = fbcon_bmove,
.con_switch = fbcon_switch,
.con_blank  = fbcon_blank,
.con_font_set   = fbcon_set_font,
diff --git a/drivers/video/console/mdacon.c b/drivers/video/console/mdacon.c
index 1fe5245eb6dd..bacbb044d77c 100644
--- a/drivers/video/console/mdacon.c
+++ b/drivers/video/console/mdacon.c
@@ -444,38 +444,6 @@ static void mdacon_clear(struct vc_data *c, int y, int x,
}
 }
 
-static void mdacon_bmove(struct vc_data *c, int sy, int sx, 
-int dy, int dx, int height, int width)
-{
-   u16 *src, *dest;
-
-   if (width <= 0 || height <= 0)
-   return;
-   
-   if (sx==0 && dx==0 && width==mda_num_columns) {
-   scr_memmovew(MDA_ADDR(0,dy), MDA_ADDR(0,sy), height*width*2);
-
-   } else if (dy < sy || (dy == sy && dx < sx)) {
-   src  = MDA_ADDR(sx, sy);
-   dest 

[PATCH 14/16] tty: vt, convert more macros to functions

[Jiri Slaby]

Namely convert:
* IS_FG -> con_is_fg
* DO_UPDATE -> con_should_update
* CON_IS_VISIBLE -> con_is_visible

DO_UPDATE was a weird name for a yes/no answer, so the new name is
con_should_update.

Signed-off-by: Jiri Slaby 
Cc: Thomas Winischhofer 
Cc: Jean-Christophe Plagniol-Villard 
Cc: linux-usb@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
---
 drivers/tty/vt/vt.c | 62 ++---
 drivers/usb/misc/sisusbvga/sisusb_con.c |  4 +--
 drivers/video/console/fbcon.c   | 26 +++---
 drivers/video/console/vgacon.c  |  8 ++---
 include/linux/console_struct.h  |  5 ++-
 5 files changed, 57 insertions(+), 48 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 8ceabfd20561..26de5c0fc056 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -277,8 +277,15 @@ static void notify_update(struct vc_data *vc)
  * Low-Level Functions
  */
 
-#define IS_FG(vc)  ((vc)->vc_num == fg_console)
-#define DO_UPDATE(vc)  (CON_IS_VISIBLE(vc) && !console_blanked)
+static inline bool con_is_fg(const struct vc_data *vc)
+{
+   return vc->vc_num == fg_console;
+}
+
+static inline bool con_should_update(const struct vc_data *vc)
+{
+   return con_is_visible(vc) && !console_blanked;
+}
 
 static inline unsigned short *screenpos(struct vc_data *vc, int offset, int 
viewed)
 {
@@ -316,7 +323,7 @@ static void scrup(struct vc_data *vc, unsigned int t, 
unsigned int b, int nr)
nr = b - t - 1;
if (b > vc->vc_rows || t >= b || nr < 1)
return;
-   if (CON_IS_VISIBLE(vc) && vc->vc_sw->con_scroll(vc, t, b, SM_UP, nr))
+   if (con_is_visible(vc) && vc->vc_sw->con_scroll(vc, t, b, SM_UP, nr))
return;
d = (unsigned short *)(vc->vc_origin + vc->vc_size_row * t);
s = (unsigned short *)(vc->vc_origin + vc->vc_size_row * (t + nr));
@@ -334,7 +341,7 @@ static void scrdown(struct vc_data *vc, unsigned int t, 
unsigned int b, int nr)
nr = b - t - 1;
if (b > vc->vc_rows || t >= b || nr < 1)
return;
-   if (CON_IS_VISIBLE(vc) && vc->vc_sw->con_scroll(vc, t, b, SM_DOWN, nr))
+   if (con_is_visible(vc) && vc->vc_sw->con_scroll(vc, t, b, SM_DOWN, nr))
return;
s = (unsigned short *)(vc->vc_origin + vc->vc_size_row * t);
step = vc->vc_cols * nr;
@@ -390,7 +397,7 @@ void update_region(struct vc_data *vc, unsigned long start, 
int count)
 {
WARN_CONSOLE_UNLOCKED();
 
-   if (DO_UPDATE(vc)) {
+   if (con_should_update(vc)) {
hide_cursor(vc);
do_update_region(vc, start, count);
set_cursor(vc);
@@ -490,7 +497,7 @@ void invert_screen(struct vc_data *vc, int offset, int 
count, int viewed)
}
}
 
-   if (DO_UPDATE(vc))
+   if (con_should_update(vc))
do_update_region(vc, (unsigned long) p, count);
notify_update(vc);
 }
@@ -507,7 +514,7 @@ void complement_pos(struct vc_data *vc, int offset)
if (old_offset != -1 && old_offset >= 0 &&
old_offset < vc->vc_screenbuf_size) {
scr_writew(old, screenpos(vc, old_offset, 1));
-   if (DO_UPDATE(vc))
+   if (con_should_update(vc))
vc->vc_sw->con_putc(vc, old, oldy, oldx);
notify_update(vc);
}
@@ -522,7 +529,7 @@ void complement_pos(struct vc_data *vc, int offset)
old = scr_readw(p);
new = old ^ vc->vc_complement_mask;
scr_writew(new, p);
-   if (DO_UPDATE(vc)) {
+   if (con_should_update(vc)) {
oldx = (offset >> 1) % vc->vc_cols;
oldy = (offset >> 1) / vc->vc_cols;
vc->vc_sw->con_putc(vc, new, oldy, oldx);
@@ -538,7 +545,7 @@ static void insert_char(struct vc_data *vc, unsigned int nr)
scr_memmovew(p + nr, p, (vc->vc_cols - vc->vc_x - nr) * 2);
scr_memsetw(p, vc->vc_video_erase_char, nr * 2);
vc->vc_need_wrap = 0;
-   if (DO_UPDATE(vc))
+   if (con_should_update(vc))
do_update_region(vc, (unsigned long) p,
vc->vc_cols - vc->vc_x);
 }
@@ -551,7 +558,7 @@ static void delete_char(struct vc_data *vc, unsigned int nr)
scr_memsetw(p + vc->vc_cols - vc->vc_x - nr, vc->vc_video_erase_char,
nr * 2);
vc->vc_need_wrap = 0;
-   if (DO_UPDATE(vc))
+   if (con_should_update(vc))
do_update_region(vc, (unsigned long) p,
vc->vc_cols - vc->vc_x);
 }
@@ -571,7 +578,7 @@ static void add_softcursor(struct vc_data *vc)
if ((type & 0x20) && ((softcursor_original & 0x7000) == (i & 0x7000))) 
i ^= 0x7000;
if ((type & 0x40) && ((i & 0x700) == ((i & 0x7000) >> 4))) i ^= 0x0700;

[PATCH v13 2/4] usb: gadget: Support for the usb charger framework

[Baolin Wang]

For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.

It will report to the usb charger when the gadget state is changed,
then the usb charger can do the power things.

Signed-off-by: Baolin Wang 
Reviewed-by: Li Jun 
Tested-by: Li Jun 
---
 drivers/usb/gadget/udc/udc-core.c |   11 +++
 include/linux/usb/gadget.h|   11 +++
 2 files changed, 22 insertions(+)

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index 6e8300d..84c098c 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * struct usb_udc - describes one usb device controller
@@ -242,6 +243,9 @@ static void usb_gadget_state_work(struct work_struct *work)
struct usb_gadget *gadget = work_to_gadget(work);
struct usb_udc *udc = gadget->udc;
 
+   /* when the gadget state is changed, then report to USB charger */
+   usb_charger_plug_by_gadget(gadget, gadget->state);
+
if (udc)
sysfs_notify(>dev.kobj, NULL, "state");
 }
@@ -411,6 +415,10 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
if (ret)
goto err4;
 
+   ret = usb_charger_init(gadget);
+   if (ret)
+   goto err5;
+
usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
udc->vbus = true;
 
@@ -431,6 +439,8 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
 
return 0;
 
+err5:
+   device_del(>dev);
 err4:
list_del(>list);
mutex_unlock(_lock);
@@ -539,6 +549,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
kobject_uevent(>dev.kobj, KOBJ_REMOVE);
flush_work(>work);
device_unregister(>dev);
+   usb_charger_exit(gadget);
device_unregister(>dev);
 }
 EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 457651b..40390ec 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct usb_ep;
 
@@ -639,6 +640,8 @@ struct usb_gadget {
unsignedout_epnum;
unsignedin_epnum;
struct usb_otg_caps *otg_caps;
+   /* negotiate the power with the usb charger */
+   struct usb_charger  *charger;
 
unsignedsg_supported:1;
unsignedis_otg:1;
@@ -855,10 +858,18 @@ static inline int usb_gadget_vbus_connect(struct 
usb_gadget *gadget)
  * reporting how much power the device may consume.  For example, this
  * could affect how quickly batteries are recharged.
  *
+ * It will also notify the USB charger how much power the device may
+ * consume if there is a USB charger linking with the gadget.
+ *
  * Returns zero on success, else negative errno.
  */
 static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
 {
+   if (gadget->charger)
+   usb_charger_set_cur_limit_by_type(gadget->charger,
+ gadget->charger->type,
+ mA);
+
if (!gadget->ops->vbus_draw)
return -EOPNOTSUPP;
return gadget->ops->vbus_draw(gadget, mA);
-- 
1.7.9.5

--
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

[PATCH v13 4/4] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown 
Signed-off-by: Baolin Wang 
Acked-by: Lee Jones 
Acked-by: Charles Keepax 
Acked-by: Peter Chen 
Acked-by: Sebastian Reichel 
---
 drivers/power/wm831x_power.c |   69 ++
 include/linux/mfd/wm831x/pdata.h |3 ++
 2 files changed, 72 insertions(+)

diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
index 7082301..cef1812 100644
--- a/drivers/power/wm831x_power.c
+++ b/drivers/power/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_charger *usb_charger;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static enum power_supply_property wm831x_usb_props[] = {
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long limit, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   unsigned int i, best;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,8 +647,31 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   if (wm831x_pdata && wm831x_pdata->usb_gadget) {
+   power->usb_charger =
+   usb_charger_find_by_name(wm831x_pdata->usb_gadget);
+   if (IS_ERR(power->usb_charger)) {
+   ret = PTR_ERR(power->usb_charger);
+   dev_err(>dev,
+   "Failed to find USB gadget: %d\n", ret);
+   goto err_bat_irq;
+   }
+
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+
+   ret = usb_charger_register_notify(power->usb_charger,
+ >usb_notify);
+   if (ret != 0) {
+   dev_err(>dev,
+   "Failed to register notifier: %d\n", ret);
+   goto err_usb_charger;
+   }
+   }
+
return ret;
 
+err_usb_charger:
+   /* put_device on charger */
 err_bat_irq:
--i;
for (; i >= 0; i--) {
@@ -637,6 +700,12 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (wm831x_power->usb_charger) {
+   usb_charger_unregister_notify(wm831x_power->usb_charger,
+ _power->usb_notify);
+   /* Free charger */
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
diff --git a/include/linux/mfd/wm831x/pdata.h b/include/linux/mfd/wm831x/pdata.h
index dcc9631..5af8399 100644
--- a/include/linux/mfd/wm831x/pdata.h
+++ b/include/linux/mfd/wm831x/pdata.h
@@ -126,6 +126,9 @@ struct wm831x_pdata {
/** The driver should initiate a power off sequence during shutdown */
bool soft_shutdown;
 
+   /** dev_name of USB charger gadget to integrate with */
+   const char *usb_gadget;
+
int irq_base;
int gpio_base;
int gpio_defaults[WM831X_GPIO_NUM];
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe 

[PATCH v13 3/4] usb: gadget: Integrate with the usb gadget supporting for usb charger

[Baolin Wang]

When the usb gadget supporting for usb charger is ready, the usb charger
can implement the usb_charger_plug_by_gadget() function, usb_charger_exit()
function and dev_to_uchger() function by getting 'struct usb_charger' from
'struct gadget'.

Signed-off-by: Baolin Wang 
Reviewed-by: Li Jun 
Tested-by: Li Jun 
---
 drivers/usb/gadget/udc/charger.c |   62 --
 1 file changed, 60 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/charger.c b/drivers/usb/gadget/udc/charger.c
index a0dd0cf..e04273c 100644
--- a/drivers/usb/gadget/udc/charger.c
+++ b/drivers/usb/gadget/udc/charger.c
@@ -35,7 +35,9 @@ static unsigned int usb_charger_get_cur_limit(struct 
usb_charger *uchger);
 
 static struct usb_charger *dev_to_uchger(struct device *dev)
 {
-   return NULL;
+   struct usb_gadget *gadget = container_of(dev, struct usb_gadget, dev);
+
+   return gadget->charger;
 }
 
 /*
@@ -548,11 +550,55 @@ usb_charger_plug_by_extcon(struct notifier_block *nb,
 int usb_charger_plug_by_gadget(struct usb_gadget *gadget,
   unsigned long state)
 {
+   struct usb_charger *uchger = gadget->charger;
+   enum usb_charger_state uchger_state;
+
+   if (WARN(!uchger, "charger can not be NULL"))
+   return -EINVAL;
+
+   /*
+* Report event to power to setting the current limitation
+* for this usb charger when one usb charger state is changed
+* with detecting by usb gadget state.
+*/
+   if (uchger->old_gadget_state != state) {
+   uchger->old_gadget_state = state;
+
+   if (state >= USB_STATE_ATTACHED)
+   uchger_state = USB_CHARGER_PRESENT;
+   else if (state == USB_STATE_NOTATTACHED)
+   uchger_state = USB_CHARGER_REMOVE;
+   else
+   uchger_state = USB_CHARGER_DEFAULT;
+
+   usb_charger_notify_others(uchger, uchger_state);
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(usb_charger_plug_by_gadget);
 
 /*
+ * usb_charger_unregister() - Unregister a usb charger.
+ * @uchger - the usb charger to be unregistered.
+ */
+static int usb_charger_unregister(struct usb_charger *uchger)
+{
+   if (WARN(!uchger, "charger can not be NULL"))
+   return -EINVAL;
+
+   ida_simple_remove(_charger_ida, uchger->id);
+   sysfs_remove_groups(>gadget->dev.kobj, usb_charger_groups);
+
+   mutex_lock(_lock);
+   list_del(>list);
+   mutex_unlock(_lock);
+
+   kfree(uchger);
+   return 0;
+}
+
+/*
  * usb_charger_register() - Register a new usb charger.
  * @uchger - the new usb charger instance.
  */
@@ -635,6 +681,7 @@ int usb_charger_init(struct usb_gadget *ugadget)
 
/* register a notifier on a usb gadget device */
uchger->gadget = ugadget;
+   ugadget->charger = uchger;
uchger->old_gadget_state = USB_STATE_NOTATTACHED;
 
/* register a new usb charger */
@@ -657,7 +704,18 @@ fail:
 
 int usb_charger_exit(struct usb_gadget *ugadget)
 {
-   return 0;
+   struct usb_charger *uchger = ugadget->charger;
+
+   if (WARN(!uchger, "charger can not be NULL"))
+   return -EINVAL;
+
+   ugadget->charger = NULL;
+   if (uchger->extcon_dev)
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_USB,
+  >extcon_nb.nb);
+
+   return usb_charger_unregister(uchger);
 }
 
 MODULE_AUTHOR("Baolin Wang ");
-- 
1.7.9.5

--
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

[PATCH v13 1/4] usb: gadget: Introduce the usb charger framework

[Baolin Wang]

This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.

The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the usb gadget state change or
the extcon device state change, the usb charger will report to power
user to set the current limitation.

The usb charger will register notifiees on the usb gadget or the extcon
device to get notified the usb charger state. It also supplies the
notification mechanism to userspace When the usb charger state is changed.

Power user will register a notifiee on the usb charger to get notified
by status changes from the usb charger. It will report to power user
to set the current limitation when detecting the usb charger is added
or removed from extcon device state or usb gadget state.

This patch doesn't yet integrate with the gadget code, so some functions
which rely on the 'gadget' are not completed, that will be implemented
in the following patches.

Signed-off-by: Baolin Wang 
Reviewed-by: Li Jun 
Tested-by: Li Jun 
---
 drivers/usb/gadget/Kconfig   |8 +
 drivers/usb/gadget/udc/Makefile  |4 +-
 drivers/usb/gadget/udc/charger.c |  665 ++
 include/linux/usb/charger.h  |  166 ++
 include/uapi/linux/usb/charger.h |   31 ++
 5 files changed, 873 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/gadget/udc/charger.c
 create mode 100644 include/linux/usb/charger.h
 create mode 100644 include/uapi/linux/usb/charger.h

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 2057add..72e0419 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -134,6 +134,14 @@ config U_SERIAL_CONSOLE
help
   It supports the serial gadget can be used as a console.
 
+config USB_CHARGER
+   bool "USB charger support"
+   select EXTCON
+   help
+ The usb charger driver based on the usb gadget that makes an
+ enhancement to a power driver which can set the current limitation
+ when the usb charger is added or removed.
+
 source "drivers/usb/gadget/udc/Kconfig"
 
 #
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index dfee534..3bdfacd 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -1,7 +1,9 @@
 #
 # USB peripheral controller drivers
 #
-obj-$(CONFIG_USB_GADGET)   += udc-core.o
+obj-$(CONFIG_USB_GADGET)   += udc_core.o
+udc_core-y := udc-core.o
+udc_core-$(CONFIG_USB_CHARGER) += charger.o
 obj-$(CONFIG_USB_DUMMY_HCD)+= dummy_hcd.o
 obj-$(CONFIG_USB_NET2272)  += net2272.o
 obj-$(CONFIG_USB_NET2280)  += net2280.o
diff --git a/drivers/usb/gadget/udc/charger.c b/drivers/usb/gadget/udc/charger.c
new file mode 100644
index 000..a0dd0cf
--- /dev/null
+++ b/drivers/usb/gadget/udc/charger.c
@@ -0,0 +1,665 @@
+/*
+ * charger.c -- USB charger driver
+ *
+ * Copyright (C) 2015 Linaro Ltd.
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_SDP_CUR_LIMIT  500
+#define DEFAULT_SDP_CUR_LIMIT_SS   900
+#define DEFAULT_DCP_CUR_LIMIT  1500
+#define DEFAULT_CDP_CUR_LIMIT  1500
+#define DEFAULT_ACA_CUR_LIMIT  1500
+
+static DEFINE_IDA(usb_charger_ida);
+static LIST_HEAD(charger_list);
+static DEFINE_MUTEX(charger_lock);
+
+static unsigned int usb_charger_get_cur_limit(struct usb_charger *uchger);
+
+static struct usb_charger *dev_to_uchger(struct device *dev)
+{
+   return NULL;
+}
+
+/*
+ * charger_current_show() - Show the charger current limit.
+ */
+static ssize_t charger_current_show(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+
+   return sprintf(buf, "%u\n", usb_charger_get_cur_limit(uchger));
+}
+static DEVICE_ATTR_RO(charger_current);
+
+/*
+ * charger_type_show() - Show the charger type.
+ *
+ * It can be SDP/DCP/CDP/ACA type, else for unknown type.
+ */
+static ssize_t charger_type_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+   int cnt;
+
+   switch (uchger->type) {
+   case SDP_TYPE:
+   cnt = sprintf(buf, "%s\n", "SDP");
+   break;
+   case DCP_TYPE:
+   cnt = sprintf(buf, "%s\n", "DCP");
+   break;

[PATCH v13 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Currently the Linux kernel does not provide any standard integration of this
feature that integrates the USB subsystem with the system power regulation
provided by PMICs meaning that either vendors must add this in their kernels
or USB gadget devices based on Linux (such as mobile phones) may not behave
as they should. Thus provide a standard framework for doing this in kernel.

Now introduce one user with wm831x_power to support and test the usb charger,
which is pending testing. Moreover there may be other potential users will use
it in future.

Changes since v12:
 - Remove the class and device things.
 - Link usb charger to udc-core.ko.
 - Create one "charger" subdirectory which holds all charger-related attributes.

Changes since v11:
 - Reviewed and tested by Li Jun.

Changes since v10:
 - Introduce usb_charger_get_state() function to check charger state.
 - Remove the mutex lock in usb_charger_set_cur_limit_by_type() function
 in case will be issued in atomic context.

Baolin Wang (4):
  usb: gadget: Introduce the usb charger framework
  usb: gadget: Support for the usb charger framework
  usb: gadget: Integrate with the usb gadget supporting for usb charger
  power: wm831x_power: Support USB charger current limit management

 drivers/power/wm831x_power.c  |   69 
 drivers/usb/gadget/Kconfig|8 +
 drivers/usb/gadget/udc/Makefile   |4 +-
 drivers/usb/gadget/udc/charger.c  |  723 +
 drivers/usb/gadget/udc/udc-core.c |   11 +
 include/linux/mfd/wm831x/pdata.h  |3 +
 include/linux/usb/charger.h   |  166 +
 include/linux/usb/gadget.h|   11 +
 include/uapi/linux/usb/charger.h  |   31 ++
 9 files changed, 1025 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/gadget/udc/charger.c
 create mode 100644 include/linux/usb/charger.h
 create mode 100644 include/uapi/linux/usb/charger.h

-- 
1.7.9.5

--
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 v12 2/4] gadget: Support for the usb charger framework

[Baolin Wang]

Hi,

On 21 June 2016 at 18:27, Felipe Balbi  wrote:
>
> Hi,
>
> Baolin Wang  writes:
>> For supporting the usb charger, it adds the usb_charger_init() and
>> usb_charger_exit() functions for usb charger initialization and exit.
>>
>> It will report to the usb charger when the gadget state is changed,
>> then the usb charger can do the power things.
>>
>> Signed-off-by: Baolin Wang 
>> Reviewed-by: Li Jun 
>> Tested-by: Li Jun 
>
> Before anything, I must say that I really liked this patch. It's
> minimaly invasive to udc core and does all the necessary changes. If it
> wasn't for the extra charger class, this would've been perfect.
>
> Can't you just tie a charger to a UDC and avoid the charger class
> completely?
>
>>  static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned 
>> mA)
>>  {
>> + if (gadget->charger)
>
> I guess you could do this check inside
> usb_gadget_set_cur_limit_by_type() itself.

We will access the 'gadget->charger->type' member when issuing
usb_gadget_set_cur_limit_by_type(), so I think I should leave the
check here in next new version.

-- 
Baolin.wang
Best Regards
--
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: [PATCHv3 1/2] usb: USB Type-C connector class

[Oliver Neukum]

On Thu, 2016-06-23 at 11:23 +0300, Heikki Krogerus wrote:
> On Wed, Jun 22, 2016 at 06:44:18PM +0200, Oliver Neukum wrote:

> No it's not. DRP means a port that can operate as _either_ Source
> (host) or Sink (device), but not at the same time..

Yes, but it is unclear what you will be after a connection
and that's the point.

> > And you can be able to become a host and be able to become a device.
> > But not at the same time. These ports are switchable.
> > 
> > The current API cannot express the difference.
> 
> I think you have misunderstood something. The only case where the port
> can be dual-role is if it's set to be DRP. Otherwise it's Source only
> OR Sink only.
> 
> The "Role Supported" bits only tell us how we can program for example
> the ROLE_CONTROL registers. I guess the "Roles Supported" bits in
> DEVICE_CAPABILITIES are not explained properly, so let's go over them
> here:
> 
> 000b = Source _or_ Sink only
> 001b = Source only
> 010b = Sink only
> 011b = Sink only with support for autonomously detected accessory modes
> 100b = DRP only, and this I believe mean we can not program the port
> to be Sink only or Source only

I think so, too.

> 101b = Source only OR Sink only OR DRP, plus ability to detect
> accessories and I guess also cables autonomously
> 110b = Source only OR Sink only OR DRP
> 
> So where the spec lists "Source, Sink", it actually should have said
> "Source only OR Sink only".
> 
> But you still have only the following options for a port:
> 1) Source only (host)
> 2) Sink only (device)
> 3) DRP (device, host)

Yes, so you can map "000b = Source _or_ Sink only" to host or device
depending on the current setting. But then you lose the information
that it can be changed. It either will look like "001b" or "010b".
So we throw away information.

And you map "100b = DRP only" and "101b" and "110b" to host, device
which again drops information.

Regards
Oliver


--
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: [PATCHv3 1/2] usb: USB Type-C connector class

[Heikki Krogerus]

Hi,

On Wed, Jun 22, 2016 at 02:54:28PM -0700, Guenter Roeck wrote:
> Hi,
> 
> > +
> > +static void typec_remove_partner(struct typec_port *port)
> > +{
> > +   WARN_ON(port->partner->alt_modes);
> 
> You are setting partner->alt_modes in typec_register_altmodes(),
> but you don't clear it in typec_unregister_altmodes().
> 
> Does this work for you ? I always get the warning when I remove a cable.

Damn it.. I have managed to just ignore the warning.

Yeah, this has to be fixed. Sorry about that.


Thanks,

-- 
heikki
--
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: [PATCHv3 1/2] usb: USB Type-C connector class

[Heikki Krogerus]

On Wed, Jun 22, 2016 at 06:44:18PM +0200, Oliver Neukum wrote:
> On Wed, 2016-06-22 at 17:38 +0300, Heikki Krogerus wrote:
> > On Wed, Jun 22, 2016 at 03:47:03PM +0200, Oliver Neukum wrote:
> > > On Wed, 2016-06-22 at 14:44 +0300, Heikki Krogerus wrote:
> > > > If our port is DRD (which would be DRP in the port controller spec),
> > > > the supported_power_roles will list:
> > > > 
> > > > device, host
> > > > 
> > > > And the power role, if the port is Source only, the
> > > > supported_power_roles will list:
> > > > 
> > > > source
> > > > 
> > > > If the port is Sink only, the supported_power_roles will list:
> > > > 
> > > > sink
> > > > 
> > > > If our port is DRP, the supported_power_roles will list:
> > > > 
> > > > source, sink
> > > > 
> > > > What is there that is missing? We are able to express all the types of
> > > > "Roles Supported" that the DEVICE_CAPABILITIES define, no?
> > > 
> > > No, because these are distinct in time. Some ports are DRP so they
> > > support
> > > 
> > > device, host
> > > 
> > > at the same time. Some ports can be switched between DFP and UFP
> > > they then either support host or device. But you lose the information
> > > that the ports can be switched.
> > 
> > You can't ever be host and device at the same time. Just like you
> > can't ever be source and sink at the same time.
> 
> True, but you can be able to become host and device at the same time.

No you can't..

> That is the purpose of a DRP port.

No it's not. DRP means a port that can operate as _either_ Source
(host) or Sink (device), but not at the same time..

> And you can be able to become a host and be able to become a device.
> But not at the same time. These ports are switchable.
> 
> The current API cannot express the difference.

I think you have misunderstood something. The only case where the port
can be dual-role is if it's set to be DRP. Otherwise it's Source only
OR Sink only.

The "Role Supported" bits only tell us how we can program for example
the ROLE_CONTROL registers. I guess the "Roles Supported" bits in
DEVICE_CAPABILITIES are not explained properly, so let's go over them
here:

000b = Source _or_ Sink only
001b = Source only
010b = Sink only
011b = Sink only with support for autonomously detected accessory modes
100b = DRP only, and this I believe mean we can not program the port
to be Sink only or Source only
101b = Source only OR Sink only OR DRP, plus ability to detect
accessories and I guess also cables autonomously
110b = Source only OR Sink only OR DRP

So where the spec lists "Source, Sink", it actually should have said
"Source only OR Sink only".

But you still have only the following options for a port:
1) Source only (host)
2) Sink only (device)
3) DRP (device, host)


Thanks,

-- 
heikki
--
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 v11 08/14] usb: otg: add OTG/dual-role core

[Yoshihiro Shimoda]

Hi Roger-san,

< snip >
>  commit 11c011a5e777c83819078a18672543f04482b3ec
>  Author: Srinivas Kandagatla 
>  Date:   Thu May 19 11:12:56 2016 +0100
> 
>  usb: echi-hcd: Add ehci_setup check before echi_shutdown
> 
> 
> 
>  In some cases, the USB code (gadget/hcd->start/stop) needs to be called
>  during the role swap. For example, if you have mux driver, you may
>  need to call usb_remove_hcd when ID from 0 to 1. Without Roger's 
>  framework,
>  how can we do that?
> >>>
> >>> You don't really need to remove the gadget. Just mask its interrupts and
> >>> ignore any calls to any gadget_driver ops, right? Likewise for
> >>> XHCI. Just clear RUN/STOP and no events will ever reach XHCI. But, from
> >>> the point of view of dwc3, it's simpler to unregister the platform
> >>> device we create for xhci-plat.c. I need no changes in XHCI to do that
> >>> and driver model will make sure to call xhci-plat's ->remove() which
> >>> will handle everything for me correctly.
> >>>
> >>
> >> I admit it can do in a IP driver, eg both host and peripheral for the
> >> single IP, eg chipidea, dwc3, etc. But how can we clear RUN/STOP bit
> >> or what else for HCD at mux driver?
> >
> > dwc3's OTG block has control of that, however, what I'll do is
> > platform_device_del() xhci-plat's device. Not one line changes inside
> > XHCI.
> >
> 
> Let's talk about how non dwc3 based platforms can get it done.
> 
> Yoshihiro-san, could you please share your platform requirements from 
> dual-role
> perspective?

My platform requirements about dual-role are:
- Initial settings of all host, gadget and OTG IP registers are needed before 
enters [AB]-device recognition procedure.
- In the recognition procedures, a software needs:
 - to check ID pin related register in OTG
 - to set OTG IP registers to change the role
  - and then host or gadget can start.
- In the disconnect detection procedures, a software needs similar 
checkings/settings with the recognition.

Best regards,
Yoshihiro Shimoda

> cheers,
> -roger

--
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