Re: [PATCH] HID: usbhid: enable NO_INIT_REPORTS quirk for Semico USB Keykoard2

[Jiri Kosina]

On Thu, 10 Mar 2016, Daniel Bristot de Oliveira wrote:

> The device which identifies itself as a "USB Keykoard" (no typo)

Yeah, Semico is apparently very careful and perfectionist about their 
hardware. This is a second device from them that has typo in the 
descriptor :)

One more, and we'll probably apply the quirk to all devices from these 
guys that we identify to be of a keyboard type.

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs

--
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] HID: usbhid: enable NO_INIT_REPORTS quirk for Semico USB Keykoard2

[Daniel Bristot de Oliveira]

The device which identifies itself as a "USB Keykoard" (no typo)
with VID:PID 1a2c:0027 does not seem to be handling the reports
initialization very well.

This results in a "usb_submit_urb(ctrl) failed: -1" message from the
kernel when connected, and a delay before its initialization. It can
also cause the hang the system.

This patch adds the  quirk for this device, which causes the delay
to disappear. It is named as "USB Keykoard2" because the "USB Keykoard"
already exists.

Signed-off-by: Daniel Bristot de Oliveira 
---
 drivers/hid/hid-ids.h   | 1 +
 drivers/hid/usbhid/hid-quirks.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index b6ff6e7..cae8f01 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -839,6 +839,7 @@
 
 #define USB_VENDOR_ID_SEMICO   0x1a2c
 #define USB_DEVICE_ID_SEMICO_USB_KEYKOARD  0x0023
+#define USB_DEVICE_ID_SEMICO_USB_KEYKOARD2 0x0027
 
 #define USB_VENDOR_ID_SENNHEISER   0x1395
 #define USB_DEVICE_ID_SENNHEISER_BTD500USB 0x002c
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 7dd0953..d289264 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -140,6 +140,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_PENSKETCH_M912, 
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_DUOSENSE, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_SEMICO, USB_DEVICE_ID_SEMICO_USB_KEYKOARD, 
HID_QUIRK_NO_INIT_REPORTS },
+   { USB_VENDOR_ID_SEMICO, USB_DEVICE_ID_SEMICO_USB_KEYKOARD2, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_LTS1, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_LTS2, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_HD, 
HID_QUIRK_NO_INIT_REPORTS },
-- 
2.5.0

--
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 -target tree] usb: gadget: f_tcm: use after free

[Andrzej Pietrasiewicz]

Hi Nicholas,

W dniu 10.03.2016 o 06:19, Nicholas A. Bellinger pisze:

Hi Andrzej,

On Wed, 2016-03-09 at 13:53 +0100, Andrzej Pietrasiewicz wrote:

Hi Nicholas,







Applying the following patch to re-add the missing assingment
as a proper alloc_session callback.

diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index e352a31..348140c 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -1570,6 +1570,16 @@ out:
 return ret;
  }

+static int usbg_alloc_sess_cb(struct se_portal_group *se_tpg,
+ struct se_session *se_sess, void *p)
+{
+   struct usbg_tpg *tpg = container_of(se_tpg,
+   struct usbg_tpg, se_tpg);
+
+   tpg->tpg_nexus = p;
+   return 0;
+}
+
  static int tcm_usbg_make_nexus(struct usbg_tpg *tpg, char *name)
  {
 struct tcm_usbg_nexus *tv_nexus;
@@ -1591,7 +1601,7 @@ static int tcm_usbg_make_nexus(struct usbg_tpg *tpg, char 
*name)
 tv_nexus->tvn_se_sess = target_alloc_session(>se_tpg, 128,
  sizeof(struct usbg_cmd),
  TARGET_PROT_NORMAL, name,
-tv_nexus, NULL);
+tv_nexus, 
usbg_alloc_sess_cb);
 if (IS_ERR(tv_nexus->tvn_se_sess)) {
  #define MAKE_NEXUS_MSG "core_tpg_check_initiator_node_acl() failed for %s\n"
 pr_debug(MAKE_NEXUS_MSG, name);







Mmmm, usbg_get_cmd() was missing an explicit memset() after tag lookup.

How about the following..?

diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index e352a31..d4e8a91 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -1078,6 +1078,7 @@ static struct usbg_cmd *usbg_get_cmd(struct f_uas *fu,
 return ERR_PTR(-ENOMEM);

 cmd = &((struct usbg_cmd *)se_sess->sess_cmd_map)[tag];
+   memset(cmd, 0, sizeof(*cmd));
 cmd->se_cmd.map_tag = tag;
 cmd->se_cmd.tag = cmd->tag = scsi_tag;
 cmd->fu = fu;





I tested it. Works for me.

AP
--
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 v2 1/2] usb:dwc3: Enable support for 64-bit system

[Felipe Balbi]

Hi,

"Thang Q. Nguyen"  writes:
> [ text/plain ]
> Hi,
> I would like to ask if I need to update anything else for this change?

seems like I don't have original patch in my inbox. Please resend.

-- 
balbi


signature.asc
Description: PGP signature

RE: [PATCH v2 1/2] usb:dwc3: Enable support for 64-bit system

[Thang Q. Nguyen]

Thanks Felipe for your feedback.
I will re-generate patches and resend.

Regards,
Thang Q. Nguyen -
-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
Sent: Thursday, March 10, 2016 3:15 PM
To: Thang Q. Nguyen; Thang Q. Nguyen; Felipe Balbi; Greg Kroah-Hartman;
linux-usb@vger.kernel.org; linux-o...@vger.kernel.org;
linux-ker...@vger.kernel.org; linux-...@lists.infradead.org
Cc: Phong Vo; Loc Ho; patches
Subject: RE: [PATCH v2 1/2] usb:dwc3: Enable support for 64-bit system


Hi,

"Thang Q. Nguyen"  writes:
> [ text/plain ]
> Hi,
> I would like to ask if I need to update anything else for this change?

seems like I don't have original patch in my inbox. Please resend.

-- 
balbi
--
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] watchdog: add driver for StreamLabs USB watchdog device

[Oliver Neukum]

On Thu, 2016-03-10 at 02:29 +, Alexey Klimov wrote:
> This patch creates new driver that supports StreamLabs usb watchdog
> device. This device plugs into 9-pin usb header and connects to
> reset pin and reset button on common PC.

Hi,

a few remarks.

Regards
Oliver

> 
> USB commands used to communicate with device were reverse
> engineered using usbmon.
> 
> Signed-off-by: Alexey Klimov 
> ---
>  drivers/watchdog/Kconfig  |  15 ++
>  drivers/watchdog/Makefile |   1 +
>  drivers/watchdog/streamlabs_wdt.c | 370 
> ++
>  3 files changed, 386 insertions(+)
>  create mode 100644 drivers/watchdog/streamlabs_wdt.c
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 80825a7..95d8f72 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -1705,4 +1705,19 @@ config USBPCWATCHDOG
>  
> Most people will say N.
>  
> +config USB_STREAMLABS_WATCHDOG
> + tristate "StreamLabs USB watchdog driver"
> + depends on USB
> + ---help---
> +   This is the driver for the USB Watchdog dongle from StreamLabs.
> +   If you correctly connect reset pins to motherboard Reset pin and
> +   to Reset button then this device will simply watch your kernel to make
> +   sure it doesn't freeze, and if it does, it reboots your computer
> +   after a certain amount of time.
> +
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called streamlabs_wdt.
> +
> +   Most people will say N. Say yes or M if you want to use such usb 
> device.
>  endif # WATCHDOG
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index f6a6a38..d54fd31 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_WDTPCI) += wdt_pci.o
>  
>  # USB-based Watchdog Cards
>  obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
> +obj-$(CONFIG_USB_STREAMLABS_WATCHDOG) += streamlabs_wdt.o
>  
>  # ALPHA Architecture
>  
> diff --git a/drivers/watchdog/streamlabs_wdt.c 
> b/drivers/watchdog/streamlabs_wdt.c
> new file mode 100644
> index 000..031dbc35
> --- /dev/null
> +++ b/drivers/watchdog/streamlabs_wdt.c
> @@ -0,0 +1,370 @@
> +/*
> + * StreamLabs USB Watchdog driver
> + *
> + * Copyright (c) 2016 Alexey Klimov 
> + *
> + * This program is free software; you may redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * USB Watchdog device from Streamlabs
> + * http://www.stream-labs.com/products/devices/watchdog/
> + *
> + * USB commands have been reverse engineered using usbmon.
> + */
> +
> +#define DRIVER_AUTHOR "Alexey Klimov "
> +#define DRIVER_DESC "StreamLabs USB watchdog driver"
> +#define DRIVER_NAME "usb_streamlabs_wdt"
> +
> +MODULE_AUTHOR(DRIVER_AUTHOR);
> +MODULE_DESCRIPTION(DRIVER_DESC);
> +MODULE_LICENSE("GPL");
> +
> +#define USB_STREAMLABS_WATCHDOG_VENDOR   0x13c0
> +#define USB_STREAMLABS_WATCHDOG_PRODUCT  0x0011
> +
> +/* one buffer is used for communication, however transmitted message is only
> + * 32 bytes long */
> +#define BUFFER_TRANSFER_LENGTH   32
> +#define BUFFER_LENGTH64
> +#define USB_TIMEOUT  350
> +
> +#define STREAMLABS_CMD_START 0
> +#define STREAMLABS_CMD_STOP  1
> +
> +#define STREAMLABS_WDT_MIN_TIMEOUT   1
> +#define STREAMLABS_WDT_MAX_TIMEOUT   46
> +
> +struct streamlabs_wdt {
> + struct watchdog_device wdt_dev;
> + struct usb_device *usbdev;

You can always deduce the device from the interface. There's
no need to store it.

> + struct usb_interface *intf;
> +
> + struct kref kref;
> + struct mutex lock;
> + u8 *buffer;
> +};
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +
> +static int usb_streamlabs_wdt_validate_response(u8 *buf)
> +{
> + /* If watchdog device understood the command it will acknowledge
> +  * with values 1,2,3,4 at indexes 10, 11, 12, 13 in response message.
> +  */
> + if (buf[10] != 1 || buf[11] != 2 || buf[12] != 3 || buf[13] != 4)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int usb_streamlabs_wdt_command(struct watchdog_device *wdt_dev, int 
> cmd)
> +{
> + struct streamlabs_wdt *streamlabs_wdt = watchdog_get_drvdata(wdt_dev);
> + int retval;
> + int size;
> + unsigned long timeout_msec;
> + int retry_counter 

Re: [RFC Patch 1/3] USB: add descriptors from USB Power Delivery spec

[Felipe Balbi]

Hi,

Oliver Neukum  writes:
> [ text/plain ]
> Adding the descriptors of chapter 9.2 of the Power Delivery spec.
>
> Signed-off-by: Oliver Neukum 
> ---
>  include/uapi/linux/usb/ch9.h | 94 
> 
>  1 file changed, 94 insertions(+)
>
> diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
> index 252ac16..c9f2bc2 100644
> --- a/include/uapi/linux/usb/ch9.h
> +++ b/include/uapi/linux/usb/ch9.h
> @@ -913,6 +913,100 @@ struct usb_ssp_cap_descriptor {
>  } __attribute__((packed));
>  
>  /*
> + * USB Power Delivery Capability Descriptor:
> + * Defines capabilities for PD
> + */
> +#define USB_PD_POWER_DELIVERY_CAPABILITY (0x06)  /* Defines the various 
> PD Capabilities of this device */
> +#define USB_PD_BATTERY_INFO_CAPABILITY   (0x07)  /* Provides 
> information on each battery supported by the device */
> +#define USB_PD_PD_CONSUMER_PORT_CAPABILITY   (0x08)  /* The Consumer 
> characteristics of a Port on the device */
> +#define USB_PD_PD_PROVIDER_PORT_CAPABILITY   (0x09)  /* The provider 
> characteristics of a Port on the device */

any chance you can avoid the extra long lines ?

> +struct usb_pd_cap_descriptor {
> + __u8  bLength;
> + __u8  bDescriptorType;
> + __u8  bDevCapabilityType; /* set to USB_PD_POWER_DELIVERY_CAPABILITY */
> + __u8  bReserved;
> + __le32 bmAttributes;
> +#define uSB_PD_CAP_BATTERY_CHARGING  ( 1 << 1 ) /* supports Battery Charging 
> specification */
> +#define uSB_PD_CAP_USB_PD( 1 << 2 ) /* supports USB Power 
> Delivery specification */
> +#define uSB_PD_CAP_PROVIDER  ( 1 << 3 ) /* can provide power */
> +#define uSB_PD_CAP_CONSUMER  ( 1 << 4 ) /* can consume power */
> +#define uSB_PD_CAP_CHARGING_POLICY   ( 1 << 5 ) /* supports CHARGING_POLICY 
> feature */
> +#define uSB_PD_CAP_TYPE_C_CURRENT( 1 << 6 ) /* supports power 
> capabilities defined in the USB Type-C Specification */
> +
> +#define uSB_PD_CAP_PWR_AC( 1 << 8 )
> +#define uSB_PD_CAP_PWR_BAT   ( 1 << 9 )
> +#define uSB_PD_CAP_PWR_USE_V_BUS ( 1 << 14 )

why the extra spaces inside () ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [RFC Patch 1/3] USB: add descriptors from USB Power Delivery spec

[Ruslan Bilovol]

Hi,

On Thu, Mar 10, 2016 at 12:45 PM, Felipe Balbi
 wrote:
>
> Hi,
>
> Oliver Neukum  writes:
>> [ text/plain ]
>> Adding the descriptors of chapter 9.2 of the Power Delivery spec.
>>
>> Signed-off-by: Oliver Neukum 
>> ---
>>  include/uapi/linux/usb/ch9.h | 94 
>> 
>>  1 file changed, 94 insertions(+)
>>
>> diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
>> index 252ac16..c9f2bc2 100644
>> --- a/include/uapi/linux/usb/ch9.h
>> +++ b/include/uapi/linux/usb/ch9.h
>> @@ -913,6 +913,100 @@ struct usb_ssp_cap_descriptor {
>>  } __attribute__((packed));
>>
>>  /*
>> + * USB Power Delivery Capability Descriptor:
>> + * Defines capabilities for PD
>> + */
>> +#define USB_PD_POWER_DELIVERY_CAPABILITY (0x06)  /* Defines the various 
>> PD Capabilities of this device */
>> +#define USB_PD_BATTERY_INFO_CAPABILITY   (0x07)  /* Provides 
>> information on each battery supported by the device */
>> +#define USB_PD_PD_CONSUMER_PORT_CAPABILITY   (0x08)  /* The Consumer 
>> characteristics of a Port on the device */
>> +#define USB_PD_PD_PROVIDER_PORT_CAPABILITY   (0x09)  /* The provider 
>> characteristics of a Port on the device */
>
> any chance you can avoid the extra long lines ?
>
>> +struct usb_pd_cap_descriptor {
>> + __u8  bLength;
>> + __u8  bDescriptorType;
>> + __u8  bDevCapabilityType; /* set to USB_PD_POWER_DELIVERY_CAPABILITY */
>> + __u8  bReserved;
>> + __le32 bmAttributes;
>> +#define uSB_PD_CAP_BATTERY_CHARGING  ( 1 << 1 ) /* supports Battery 
>> Charging specification */
>> +#define uSB_PD_CAP_USB_PD( 1 << 2 ) /* supports USB Power 
>> Delivery specification */
>> +#define uSB_PD_CAP_PROVIDER  ( 1 << 3 ) /* can provide power */
>> +#define uSB_PD_CAP_CONSUMER  ( 1 << 4 ) /* can consume power */
>> +#define uSB_PD_CAP_CHARGING_POLICY   ( 1 << 5 ) /* supports CHARGING_POLICY 
>> feature */
>> +#define uSB_PD_CAP_TYPE_C_CURRENT( 1 << 6 ) /* supports power 
>> capabilities defined in the USB Type-C Specification */
>> +
>> +#define uSB_PD_CAP_PWR_AC( 1 << 8 )
>> +#define uSB_PD_CAP_PWR_BAT   ( 1 << 9 )
>> +#define uSB_PD_CAP_PWR_USE_V_BUS ( 1 << 14 )
>
> why the extra spaces inside () ?

Also it's not clear why these macro start with lowercase letter (e.g.
why uSB_XXX instead of USB_XXX), looks like a typo.

>
> --
> balbi

-- 
Best regards,
Ruslan
--
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: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Felipe Ferreri Tonello]

Hi Steve,

On 09/03/16 22:43, Steve Calfee wrote:
> On Wed, Mar 9, 2016 at 11:39 AM, Felipe F. Tonello  
> wrote:
>> buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
>> devices.
>>
>> That caused the OUT endpoint to freeze if the host send any data packet of
>> length greater than 256 bytes.
>>
>> This is an example dump of what happended on that enpoint:
>> HOST:   [DATA][Length=260][...]
>> DEVICE: [NAK]
>> HOST:   [PING]
>> DEVICE: [NAK]
>> HOST:   [PING]
>> DEVICE: [NAK]
>> ...
>> HOST:   [PING]
>> DEVICE: [NAK]
>>
>> This patch fixes this problem by setting the minimum usb_request's buffer 
>> size
>> for the OUT endpoint as its wMaxPacketSize.
>>
>> Signed-off-by: Felipe F. Tonello 
>> ---
>>  drivers/usb/gadget/function/f_midi.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c 
>> b/drivers/usb/gadget/function/f_midi.c
>> index 8475e3dc82d4..826ba641f29d 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -366,7 +366,9 @@ static int f_midi_set_alt(struct usb_function *f, 
>> unsigned intf, unsigned alt)
>> /* allocate a bunch of read buffers and queue them all at once. */
>> for (i = 0; i < midi->qlen && err == 0; i++) {
>> struct usb_request *req =
>> -   midi_alloc_ep_req(midi->out_ep, midi->buflen);
>> +   midi_alloc_ep_req(midi->out_ep,
>> +   max_t(unsigned, midi->buflen,
>> +   bulk_out_desc.wMaxPacketSize));
>> if (req == NULL)
>> return -ENOMEM;
>>
> Won't you get a buffer overrun if midi->buflen is less than wMaxPacketSize?
> 

No, because of the *max_t(unsigned, midi->buflen,
bulk_out_desc.wMaxPacketSize)*.

Maybe that's not the most clear indentation but I had to break it in
order to avoid passing 80 columns.

-- 
Felipe


0x92698E6A.asc
Description: application/pgp-keys

Re: [PATCH 5/5 v9] usb: musb: da8xx: Add DT support for the DA8xx driver

[Petr Kulhavy]

On 09.03.2016 12:53, Sergei Shtylyov wrote:

Hello.

On 3/9/2016 12:25 PM, Petr Kulhavy wrote:


This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver

Signed-off-by: Petr Kulhavy 
Tested-by: Petr Kulhavy 

[...]


diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index b03d3b8..aabd33a 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c

[...]

@@ -134,6 +139,55 @@ static inline void phy_off(void)
  __raw_writel(cfgchip2, CFGCHIP2);
  }

+static inline int get_phy_refclk_cfg(struct device_node *np)
+{
+u32 freq;
+
+if (of_property_read_u32(np, "ti,usb2-phy-refclock-hz", ))
+return -EINVAL;


Shouldn't the frequency be retrieved thru the clk API, like we do 
it for the power, BTW?


Bin, what do you think about it? I prefer the pragmatic approach leaving 
it as a parameter ;-)

Then the clock selection would be needed as well, etc. I'd keep it simple.


+
+switch (freq) {
+case 1200:
+return CFGCHIP2_REFFREQ_12MHZ;
+case 1300:
+return CFGCHIP2_REFFREQ_13MHZ;
+case 1920:
+return CFGCHIP2_REFFREQ_19_2MHZ;
+case 2000:
+return CFGCHIP2_REFFREQ_20MHZ;
+case 2400:
+return CFGCHIP2_REFFREQ_24MHZ;
+case 2600:
+return CFGCHIP2_REFFREQ_26MHZ;
+case 3840:
+return CFGCHIP2_REFFREQ_38_4MHZ;
+case 4000:
+return CFGCHIP2_REFFREQ_40MHZ;
+case 4800:
+return CFGCHIP2_REFFREQ_48MHZ;
+default:
+return -EINVAL;
+}
+}
+
+static inline u8 get_vbus_power(struct device *dev)
+{
+struct regulator *vbus_supply;
+int current_uA;
+
+vbus_supply = regulator_get(dev, "vbus");
+if (IS_ERR(vbus_supply))
+return 255;
+
+current_uA = regulator_get_current_limit(vbus_supply);
+regulator_put(vbus_supply);
+
+if (current_uA <= 0 || current_uA > 51)
+return 255;
+
+return current_uA / 1000;
+}


   Wait, the platform data expects that in 2 mA units, you forgot to 
divide by 2!



Argh, yes indeed!

Regards
Petr
--
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 1/1] sd: do not let LBPME bit stop the VPDs speak

[Tom Yan]

On 10 March 2016 at 12:36, Tom Yan  wrote:
>
> Both `blkdiscard` with a patched kernel and `sg_unmap` appeared to
> have gone well (checked with `hexdump`).
>
Actually, `blkdiscard` didn't quite actually go well. It seems last
time it just ended quickly with only error on kernel messages, so I
thought it worked.

But apparently it's NOT because of the device itself but has something
to do with the kernel. It will only get into trouble if I set a "step"
(`-p`) larger than "discard_max_bytes" (and/or
"discard_max_hw_bytes"?).

For example, if I use an UNPATCHED kernel and use `echo -n unmap` to
change the "provisioning_mode" sysfs file (this way,
"discard_max_bytes" and "discard_max_hw_bytes" are set to 4294966784),
these work:

[tom@localhost ~]$ time sudo blkdiscard -v -p 33521664 /dev/sdc
/dev/sdc: Discarded 7542374400 bytes from the offset 0
/dev/sdc: Discarded 38415826944 bytes from the offset 7542374400
/dev/sdc: Discarded 37711872000 bytes from the offset 45958201344
/dev/sdc: Discarded 37242568704 bytes from the offset 83670073344
/dev/sdc: Discarded 37577785344 bytes from the offset 120912642048
/dev/sdc: Discarded 37544263680 bytes from the offset 158490427392
/dev/sdc: Discarded 38348783616 bytes from the offset 196034691072
/dev/sdc: Discarded 5673934848 bytes from the offset 234383474688

real0m6.522s
user0m0.007s
sys0m0.097s

[tom@localhost ~]$ time sudo blkdiscard -v -p 4294966784 /dev/sdc
/dev/sdc: Discarded 12884900352 bytes from the offset 0
/dev/sdc: Discarded 55834568192 bytes from the offset 12884900352
/dev/sdc: Discarded 55834568192 bytes from the offset 68719468544
/dev/sdc: Discarded 55834568192 bytes from the offset 124554036736
/dev/sdc: Discarded 55834568192 bytes from the offset 180388604928
/dev/sdc: Discarded 3834236416 bytes from the offset 236223173120

real0m4.335s
user0m0.010s
sys0m0.007s

I even did three trials each, all completed without error:

Mar 10 16:54:46 localhost sudo[435]:  tom : TTY=pts/2 ;
PWD=/home/tom ; USER=root ; COMMAND=/usr/bin/bash -c echo -n unmap >
/sys/devices/pci:00/:00:14.0/usb4/4-6/4-6:1.0/host7/target7:0:0/7:0:0:0/scsi_disk/7:0:0:0/provisioning_mode
Mar 10 16:54:46 localhost sudo[435]: pam_unix(sudo:session): session
opened for user root by (uid=0)
Mar 10 16:54:46 localhost sudo[435]: pam_unix(sudo:session): session
closed for user root
Mar 10 16:56:03 localhost sudo[459]:  tom : TTY=pts/1 ;
PWD=/home/tom ; USER=root ; COMMAND=/usr/bin/blkdiscard -v -p 33521664
/dev/sdc
Mar 10 16:56:03 localhost sudo[459]: pam_unix(sudo:session): session
opened for user root by (uid=0)
Mar 10 16:56:09 localhost sudo[459]: pam_unix(sudo:session): session
closed for user root
Mar 10 16:56:11 localhost sudo[463]:  tom : TTY=pts/1 ;
PWD=/home/tom ; USER=root ; COMMAND=/usr/bin/blkdiscard -v -p 33521664
/dev/sdc
Mar 10 16:56:11 localhost sudo[463]: pam_unix(sudo:session): session
opened for user root by (uid=0)
Mar 10 16:56:18 localhost sudo[463]: pam_unix(sudo:session): session
closed for user root
Mar 10 16:56:21 localhost sudo[467]:  tom : TTY=pts/1 ;
PWD=/home/tom ; USER=root ; COMMAND=/usr/bin/blkdiscard -v -p 33521664
/dev/sdc
Mar 10 16:56:21 localhost sudo[467]: pam_unix(sudo:session): session
opened for user root by (uid=0)
Mar 10 16:56:28 localhost sudo[467]: pam_unix(sudo:session): session
closed for user root
Mar 10 16:56:36 localhost sudo[471]:  tom : TTY=pts/1 ;
PWD=/home/tom ; USER=root ; COMMAND=/usr/bin/blkdiscard -v -p
4294966784 /dev/sdc
Mar 10 16:56:36 localhost sudo[471]: pam_unix(sudo:session): session
opened for user root by (uid=0)
Mar 10 16:56:40 localhost sudo[471]: pam_unix(sudo:session): session
closed for user root
Mar 10 16:56:42 localhost sudo[475]:  tom : TTY=pts/1 ;
PWD=/home/tom ; USER=root ; COMMAND=/usr/bin/blkdiscard -v -p
4294966784 /dev/sdc
Mar 10 16:56:42 localhost sudo[475]: pam_unix(sudo:session): session
opened for user root by (uid=0)
Mar 10 16:56:46 localhost sudo[475]: pam_unix(sudo:session): session
closed for user root
Mar 10 16:56:48 localhost sudo[479]:  tom : TTY=pts/1 ;
PWD=/home/tom ; USER=root ; COMMAND=/usr/bin/blkdiscard -v -p
4294966784 /dev/sdc
Mar 10 16:56:48 localhost sudo[479]: pam_unix(sudo:session): session
opened for user root by (uid=0)
Mar 10 16:56:53 localhost sudo[479]: pam_unix(sudo:session): session
closed for user root

However, if I use a patched kernel, the kernel will read the VPD of my
bridge set the files accordingly to 33521664 instead, then only
`blkdiscard -p 33521664` works but not `blkdiscard -p 4294966784`
anymore. It will (usually) be stalled and with errors repeated in
kernel message:

...
Mar 10 18:23:25 localhost kernel: sd 7:0:0:0: [sdc] tag#7
uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT
Mar 10 18:23:25 localhost kernel: sd 7:0:0:0: [sdc] tag#7 CDB:
opcode=0x42 42 00 00 00 00 00 00 00 18 00
Mar 10 18:23:25 localhost kernel: sd 7:0:0:0: [sdc] tag#6
uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT

[RFC PATCH 2/3] USB: PD: define specific requests

[Oliver Neukum]

This takes the definitions of requests from chapter 9.3.1
of the USB Power Delivery spec.

Signed-off-by: Oliver Neukum 
---
 include/uapi/linux/usb/ch9.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index c9f2bc2..bf6c1cd 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -105,6 +105,13 @@
 #define USB_REQ_LOOPBACK_DATA_READ 0x16
 #define USB_REQ_SET_INTERFACE_DS   0x17
 
+/* specific requests for USB Power Delivery */
+#define USB_REQ_GET_PARTNER_PDO20
+#define USB_REQ_GET_BATTERY_STATUS 21
+#define USB_REQ_SET_PDO22
+#define USB_REQ_GET_VDM23
+#define USB_REQ_SEND_VDM   24
+
 /* The Link Power Management (LPM) ECN defines USB_REQ_TEST_AND_SET command,
  * used by hubs to put ports into a new L1 suspend state, except that it
  * forgot to define its number ...
-- 
2.1.4

--
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 5/5 v9] usb: musb: da8xx: Add DT support for the DA8xx driver

[Petr Kulhavy]

On 09.03.2016 21:00, Bin Liu wrote:

Hi,

On Wed, Mar 09, 2016 at 10:25:27AM +0100, Petr Kulhavy wrote:
  
+static inline int get_phy_refclk_cfg(struct device_node *np)

+{
+   u32 freq;
+
+   if (of_property_read_u32(np, "ti,usb2-phy-refclock-hz", ))
+   return -EINVAL;
+
+   switch (freq) {
+   case 1200:
+   return CFGCHIP2_REFFREQ_12MHZ;
+   case 1300:
+   return CFGCHIP2_REFFREQ_13MHZ;
+   case 1920:
+   return CFGCHIP2_REFFREQ_19_2MHZ;
+   case 2000:
+   return CFGCHIP2_REFFREQ_20MHZ;
+   case 2400:
+   return CFGCHIP2_REFFREQ_24MHZ;
+   case 2600:
+   return CFGCHIP2_REFFREQ_26MHZ;
+   case 3840:
+   return CFGCHIP2_REFFREQ_38_4MHZ;
+   case 4000:
+   return CFGCHIP2_REFFREQ_40MHZ;
+   case 4800:
+   return CFGCHIP2_REFFREQ_48MHZ;
+   default:
+   return -EINVAL;
+   }
+}

Should this be wrapped with CONFIG_OF? Have you tried to build it with
OF disabled?


Hi Bin,

apart of the fact that the ARCH_DAVINCI requires the DT the 
usb/musb/da8xx.c compiles without errors if CONFIG_OF is disabled.

Other drivers like Ethernet fail however.

Regards
Petr
--
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 3/3] dm9601: add support ethtool style utility

[Joseph CHANG]

Add function dm9601_set_eeprom which tested good with ethtool
utility, include the eeprom words dump and the eeprom byte write.

Signed-off-by: Joseph CHANG 
---
 drivers/net/usb/dm9601.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/drivers/net/usb/dm9601.c b/drivers/net/usb/dm9601.c
index 50095df..a6904f4 100644
--- a/drivers/net/usb/dm9601.c
+++ b/drivers/net/usb/dm9601.c
@@ -61,6 +61,7 @@
 #define DM_RX_OVERHEAD 7   /* 3 byte header + 4 byte crc tail */
 #define DM_TIMEOUT 1000
 #defineDM_EP3I_VAL 0x07
+#defineMD96XX_EEPROM_MAGIC 0x9620
 
 static int dm_read(struct usbnet *dev, u8 reg, u16 length, void *data)
 {
@@ -289,6 +290,43 @@ static int dm9601_get_eeprom(struct net_device *net,
return 0;
 }
 
+static int dm9601_set_eeprom(struct net_device *net,
+struct ethtool_eeprom *eeprom, u8 *data)
+{
+   struct usbnet *dev = netdev_priv(net);
+   int offset = eeprom->offset;
+   int len = eeprom->len;
+   int done;
+
+   if (eeprom->magic != MD96XX_EEPROM_MAGIC) {
+   netdev_dbg(dev->net, "EEPROM: magic value mismatch, magic = 
0x%x",
+  eeprom->magic);
+   return -EINVAL;
+   }
+
+   while (len > 0) {
+   if (len & 1 || offset & 1) {
+   int which = offset & 1;
+   u8 tmp[2];
+
+   dm_read_eeprom_word(dev, offset / 2, tmp);
+   tmp[which] = *data;
+   dm_write_eeprom_word(dev, offset / 2,
+tmp[0] | tmp[1] << 8);
+   mdelay(10);
+   done = 1;
+   } else {
+   dm_write_eeprom_word(dev, offset / 2,
+data[0] | data[1] << 8);
+   done = 2;
+   }
+   data += done;
+   offset += done;
+   len -= done;
+   }
+   return 0;
+}
+
 static int dm9601_mdio_read(struct net_device *netdev, int phy_id, int loc)
 {
struct usbnet *dev = netdev_priv(netdev);
@@ -354,6 +392,7 @@ static const struct ethtool_ops dm9601_ethtool_ops = {
.set_msglevel   = usbnet_set_msglevel,
.get_eeprom_len = dm9601_get_eeprom_len,
.get_eeprom = dm9601_get_eeprom,
+   .set_eeprom = dm9601_set_eeprom,
.get_settings   = usbnet_get_settings,
.set_settings   = usbnet_set_settings,
.nway_reset = usbnet_nway_reset,
-- 
2.1.4

--
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 2/3] dm9601: manage eeprom to assure the chip for correct operation

[Joseph CHANG]

Add to maintain variant eeprom adapters which may have not right
dm962x's format.

Signed-off-by: Joseph CHANG 
---
 drivers/net/usb/dm9601.c | 72 
 1 file changed, 72 insertions(+)

diff --git a/drivers/net/usb/dm9601.c b/drivers/net/usb/dm9601.c
index 520de4f..50095df 100644
--- a/drivers/net/usb/dm9601.c
+++ b/drivers/net/usb/dm9601.c
@@ -60,6 +60,7 @@
 #define DM_TX_OVERHEAD 2   /* 2 byte header */
 #define DM_RX_OVERHEAD 7   /* 3 byte header + 4 byte crc tail */
 #define DM_TIMEOUT 1000
+#defineDM_EP3I_VAL 0x07
 
 static int dm_read(struct usbnet *dev, u8 reg, u16 length, void *data)
 {
@@ -193,6 +194,75 @@ static int dm_read_eeprom_word(struct usbnet *dev, u8 
offset, void *value)
return dm_read_shared_word(dev, 0, offset, value);
 }
 
+static void dm_write_eeprom_word(struct usbnet *dev, u8 offset, __le16 data)
+{
+   dm_write_shared_word(dev, 0, offset, data);
+}
+
+static int dm_render_write(struct usbnet *dev, u8 wordoffset, u16 mask_word,
+  u16 orset_word, u16 *pmd)
+{
+   u16 srom;
+
+   dm_read_eeprom_word(dev, wordoffset, );
+   if ((srom & mask_word) == orset_word)
+   return 0;
+
+   srom &= ~mask_word;
+   srom |= orset_word;
+
+   dm_write_eeprom_word(dev, wordoffset, srom);
+   *pmd = srom;
+   return 1;
+}
+
+static void dm_render_report(struct usbnet *dev, u8 wordoffset, u16 md)
+{
+   int i = 0;
+   u16 srom;
+
+   do {
+   i++;
+   usleep_range(100, 200);
+   dm_read_eeprom_word(dev, wordoffset, );
+   if (i == 8)
+   break;
+   } while (srom != md);
+
+   if (srom == md) {
+   netdev_info(dev->net, "set eeprom word%d 0x%04x\n",
+   wordoffset, md);
+   } else {
+   netdev_info(dev->net, "warning - set eeprom word%d 0x%04x\n",
+   wordoffset, md);
+   netdev_info(dev->net, "warning - fail as eeprom word%d 
0x%04x\n",
+   wordoffset, srom);
+   }
+}
+
+static void dm_eeprom_render(struct usbnet *dev, u8 wordoffset,
+u16 orset_word, u16 mask_word)
+{
+   u16 m;
+
+   if (!dm_render_write(dev, wordoffset, mask_word, orset_word, ))
+   return;
+
+   dm_render_report(dev, wordoffset, m);
+}
+
+static void dm_render_begin(struct usbnet *dev)
+{
+   /* Render eeprom if need, WORD3 render, set D[15:14] 01b */
+   dm_eeprom_render(dev, 3, 0x4000, 0xc000);
+   /* Render eeprom if need, WORD7 render, clear D[10] */
+   dm_eeprom_render(dev, 7, 0x, 0x0400);
+   /* Render eeprom if need, WORD11 render, need 0x005a */
+   dm_eeprom_render(dev, 11, 0x005a, 0x);
+   /* Render eeprom if need, WORD12 render, need 0x0007 */
+   dm_eeprom_render(dev, 12, DM_EP3I_VAL, 0x);
+}
+
 
 
 static int dm9601_get_eeprom_len(struct net_device *dev)
@@ -420,6 +490,8 @@ static int dm9601_bind(struct usbnet *dev, struct 
usb_interface *intf)
 
/* Always return 8-bytes data to host per interrupt-interval */
dm_write_reg(dev, DM_USB_CTRL, USB_CTRL_EP3ACK);
+
+   dm_render_begin(dev);
}
 
/* power up phy */
-- 
2.1.4

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

Re: [PATCH 2/6] usb: xhci-mtk: use __maybe_unused to hide pm functions

[Mathias Nyman]

On 04.03.2016 18:33, Matthias Brugger wrote:



On 02/03/16 16:24, Arnd Bergmann wrote:

The mediatek XHCI glue driver uses SET_SYSTEM_SLEEP_PM_OPS() to
conditionally set the correct suspend/resume options, and
also puts both the dev_pm_ops and the functions inside of
an #ifdef testing for CONFIG_PM_SLEEP, but those functions
then call other code that becomes unused:

drivers/usb/host/xhci-mtk.c:135:12: error: 'xhci_mtk_host_disable' defined but 
not used [-Werror=unused-function]
drivers/usb/host/xhci-mtk.c:313:13: error: 'usb_wakeup_enable' defined but not 
used [-Werror=unused-function]
drivers/usb/host/xhci-mtk.c:321:13: error: 'usb_wakeup_disable' defined but not 
used [-Werror=unused-function]

This replaces the #ifdef with __maybe_unused annotations so the
compiler knows it can silently drop them instead of warning.

For the DEV_PM_OPS definition, we can use an IS_ENABLED() check
to avoid defining the structure when CONFIG_PM is not set without
the #ifdef.

Signed-off-by: Arnd Bergmann 
---


Reviewed-by: Matthias Brugger 



Acked-by: Mathias Nyman 

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

[RFC Patch 1/3] USB: add descriptors from USB Power Delivery spec

[Oliver Neukum]

Adding the descriptors of chapter 9.2 of the Power Delivery spec.

Signed-off-by: Oliver Neukum 
---
 include/uapi/linux/usb/ch9.h | 94 
 1 file changed, 94 insertions(+)

diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index 252ac16..c9f2bc2 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -913,6 +913,100 @@ struct usb_ssp_cap_descriptor {
 } __attribute__((packed));
 
 /*
+ * USB Power Delivery Capability Descriptor:
+ * Defines capabilities for PD
+ */
+#define USB_PD_POWER_DELIVERY_CAPABILITY   (0x06)  /* Defines the various 
PD Capabilities of this device */
+#define USB_PD_BATTERY_INFO_CAPABILITY (0x07)  /* Provides information 
on each battery supported by the device */
+#define USB_PD_PD_CONSUMER_PORT_CAPABILITY (0x08)  /* The Consumer 
characteristics of a Port on the device */
+#define USB_PD_PD_PROVIDER_PORT_CAPABILITY (0x09)  /* The provider 
characteristics of a Port on the device */
+
+struct usb_pd_cap_descriptor {
+   __u8  bLength;
+   __u8  bDescriptorType;
+   __u8  bDevCapabilityType; /* set to USB_PD_POWER_DELIVERY_CAPABILITY */
+   __u8  bReserved;
+   __le32 bmAttributes;
+#define uSB_PD_CAP_BATTERY_CHARGING( 1 << 1 ) /* supports Battery Charging 
specification */
+#define uSB_PD_CAP_USB_PD  ( 1 << 2 ) /* supports USB Power 
Delivery specification */
+#define uSB_PD_CAP_PROVIDER( 1 << 3 ) /* can provide power */
+#define uSB_PD_CAP_CONSUMER( 1 << 4 ) /* can consume power */
+#define uSB_PD_CAP_CHARGING_POLICY ( 1 << 5 ) /* supports CHARGING_POLICY 
feature */
+#define uSB_PD_CAP_TYPE_C_CURRENT  ( 1 << 6 ) /* supports power 
capabilities defined in the USB Type-C Specification */
+
+#define uSB_PD_CAP_PWR_AC  ( 1 << 8 )
+#define uSB_PD_CAP_PWR_BAT ( 1 << 9 )
+#define uSB_PD_CAP_PWR_USE_V_BUS   ( 1 << 14 )
+
+   __le16 bmProviderPorts; /* Bit zero refers to the UFP of the device */
+   __le16 bmConsumerPorts;
+   __le16 bcdBCVersion;
+   __le16 bcdPDVersion;
+   __le16 bcdUSBTypeCVersion;
+} __attribute__((packed));
+
+struct usb_pd_cap_battery_info_descriptor {
+   __u8 bLength;
+   __u8 bDescriptorType;
+   __u8 bDevCapabilityType;
+   /* Index of string descriptor shall contain the user friendly name for 
this battery */
+   __u8 iBattery;
+   /* Index of string descriptor shall contain the Serial Number String 
for this battery */
+   __u8 iSerial;
+   __u8 iManufacturer;
+   __u8 bBatteryId; /* uniquely identifies this battery in status Messages 
*/
+   __u8 bReserved;
+   /*
+* Shall contain the Battery Charge value above which this
+* battery is considered to be fully charged but not necessarily
+* “topped off.”
+*/
+   __le32 dwChargedThreshold; /* in mWh */
+   /*
+* Shall contain the minimum charge level of this battery such
+* that above this threshold, a device can be assured of being
+* able to power up successfully (see Battery Charging 1.2).
+*/
+   __le32 dwWeakThreshold; /* in mWh */
+   __le32 dwBatteryDesignCapacity; /* in mWh */
+   __le32 dwBatteryLastFullchargeCapacity; /* in mWh */
+} __attribute__((packed));
+
+struct usb_pd_cap_consumer_port_descriptor {
+   __u8 bLength;
+   __u8 bDescriptorType;
+   __u8 bDevCapabilityType;
+   __u8 bReserved;
+   __u8 bmCapabilities;
+/* port will oerate under: */
+#define uSB_PD_CAP_CONSUMER_BC ( 1 << 0 ) /* BC */
+#define uSB_PD_CAP_CONSUMER_PD ( 1 << 1 ) /* PD */
+#define uSB_PD_CAP_CONSUMER_TYPE_C ( 1 << 2 ) /* USB Type-C Current */
+   __le16 wMinVoltage; /* in 50mV units */
+   __le16 wMaxVoltage; /* in 50mV units */
+   __u16 wReserved;
+   __le32 dwMaxOperatingPower; /* in 10 mW - operating at steady state */
+   __le32 dwMaxPeakPower; /* in 10mW units - operating at peak power */
+   __le32 dwMaxPeakPowerTime; /* in 100ms units - duration of peak */
+#define uSB_PD_CAP_CONSUMER_UNKNOWN_PEAK_POWER_TIME 0x
+} __attribute__((packed));
+
+struct usb_pd_cap_provider_port_descriptor {
+   __u8 bLength;
+   __u8 bDescriptorType;
+   __u8 bDevCapabilityType;
+   __u8 bReserved1;
+   __u8 bmCapabilities;
+/* port will oerate under: */
+#define uSB_PD_CAP_PROVIDER_BC ( 1 << 0 ) /* BC */
+#define uSB_PD_CAP_PROVIDER_PD ( 1 << 1 ) /* PD */
+#define uSB_PD_CAP_PROVIDER_TYPE_C ( 1 << 2 ) /* USB Type-C Current */
+   __u8 bNumOfPDObjects;
+   __u8 bReserved2;
+   __le32 wPowerDataObject[];
+} __attribute__((packed));
+
+/*
  * Precision time measurement capability descriptor: advertised by devices and
  * hubs that support PTM
  */
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message 

adding definitions for USB PD to headers

[Oliver Neukum]

This patch set adds to definitions from chapter 9 of
the Power Delivery spec to the header files so that they can be better
used. It is a conservative selection and adds only a minimum.

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

[RFC PATCH 3/3] USB: PD: additional feature selectors

[Oliver Neukum]

This adds the feature selectors from Table 9-8

Signed-off-by: Oliver Neukum 
---
 include/uapi/linux/usb/ch9.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index bf6c1cd..9d3cdae 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -172,6 +172,22 @@
 #define USB_DEV_STAT_U2_ENABLED3   /* transition into U2 
state */
 #define USB_DEV_STAT_LTM_ENABLED   4   /* Latency tolerance messages */
 
+/*
+ * Feature selectors from Table 9-8 USB Power Delivery spec
+ */
+#define USB_DEVICE_BATTERY_WAKE_MASK   40
+#define USB_DEVICE_OS_IS_PD_AWARE  41
+#define USB_DEVICE_POLICY_MODE 42
+#define USB_PORT_PR_SWAP   43
+#define USB_PORT_GOTO_MIN  44
+#define USB_PORT_RETURN_POWER  45
+#define USB_PORT_ACCEPT_PD_REQUEST 46
+#define USB_PORT_REJECT_PD_REQUEST 47
+#define USB_PORT_PORT_PD_RESET 48
+#define USB_PORT_C_PORT_PD_CHANGE  49
+#define USB_PORT_CABLE_PD_RESET50
+#define USB_DEVICE_CHARGING_POLICY 54
+
 /**
  * struct usb_ctrlrequest - SETUP data for a USB device control request
  * @bRequestType: matches the USB bmRequestType field
-- 
2.1.4

--
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 3/3] dm9601: add support ethtool style utility

[Ben Hutchings]

The subject line on this is very vague; it should say which ethtool
operation you're implementing.

On Thu, 2016-03-10 at 19:24 +0800, Joseph CHANG wrote:

> Add function dm9601_set_eeprom which tested good with ethtool
> utility, include the eeprom words dump and the eeprom byte write.
> 
> Signed-off-by: Joseph CHANG 
> ---
>  drivers/net/usb/dm9601.c | 39 +++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/drivers/net/usb/dm9601.c b/drivers/net/usb/dm9601.c
> index 50095df..a6904f4 100644
> --- a/drivers/net/usb/dm9601.c
> +++ b/drivers/net/usb/dm9601.c
> @@ -61,6 +61,7 @@
>  #define DM_RX_OVERHEAD   7   /* 3 byte header + 4 byte crc tail */
>  #define DM_TIMEOUT   1000
>  #define  DM_EP3I_VAL 0x07
> +#define  MD96XX_EEPROM_MAGIC 0x9620

The get_eeprom operation needs to be changed, to set eeprom->magic to
this value.

>  static int dm_read(struct usbnet *dev, u8 reg, u16 length, void *data)
>  {
> @@ -289,6 +290,43 @@ static int dm9601_get_eeprom(struct net_device *net,
>   return 0;
>  }
>  
> +static int dm9601_set_eeprom(struct net_device *net,
> +  struct ethtool_eeprom *eeprom, u8 *data)
> +{
> + struct usbnet *dev = netdev_priv(net);
> + int offset = eeprom->offset;
> + int len = eeprom->len;
> + int done;
> +
> + if (eeprom->magic != MD96XX_EEPROM_MAGIC) {
> + netdev_dbg(dev->net, "EEPROM: magic value mismatch, magic = 
> 0x%x",
> +    eeprom->magic);
> + return -EINVAL;
> + }
> +
> + while (len > 0) {
> + if (len & 1 || offset & 1) {

Given that the get_eeprom operation only handles word-aligned reads, is
it really important to support misaligned writes in set_eeprom?

Also, this test should be 'if (len == 1 || offset & 1)'.  Consider a
write with offset = 2, len = 3.  You want to write a word on the first
iteration, then a byte on the second iteration.

> + int which = offset & 1;
> + u8 tmp[2];
> +
> + dm_read_eeprom_word(dev, offset / 2, tmp);
> + tmp[which] = *data;
> + dm_write_eeprom_word(dev, offset / 2,
> +  tmp[0] | tmp[1] << 8);
> + mdelay(10);

Why is a delay required here, but not in the other case?

> + done = 1;
> + } else {
> + dm_write_eeprom_word(dev, offset / 2,
> +  data[0] | data[1] << 8);
> + done = 2;
> + }
> + data += done;
> + offset += done;
> + len -= done;
> + }
> + return 0;
> +}
[...]

Ben.

-- 
Ben Hutchings
To err is human; to really foul things up requires a computer.

signature.asc
Description: This is a digitally signed message part

[PATCH 1/3] dm9601: enable EP3 interrupt

[Joseph CHANG]

Enable chip's EP3 interrupt to get the link-up notify soon
immediately.

Signed-off-by: Joseph CHANG 
---
 drivers/net/usb/dm9601.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/usb/dm9601.c b/drivers/net/usb/dm9601.c
index 0b4bdd3..520de4f 100644
--- a/drivers/net/usb/dm9601.c
+++ b/drivers/net/usb/dm9601.c
@@ -46,6 +46,9 @@
 #define DM_GPR_DATA0x1f
 #define DM_CHIP_ID 0x2c
 #define DM_MODE_CTRL   0x91/* only on dm9620 */
+#defineDM_USB_CTRL 0xf4
+
+#defineUSB_CTRL_EP3ACK 0x20
 
 /* chip id values */
 #define ID_DM9601  0
@@ -414,6 +417,9 @@ static int dm9601_bind(struct usbnet *dev, struct 
usb_interface *intf)
goto out;
}
dm_write_reg(dev, DM_MODE_CTRL, mode & 0x7f);
+
+   /* Always return 8-bytes data to host per interrupt-interval */
+   dm_write_reg(dev, DM_USB_CTRL, USB_CTRL_EP3ACK);
}
 
/* power up phy */
-- 
2.1.4

--
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: xhci: merge xhci_queue_bulk_tx and queue_bulk_sg_tx functions

[Alexandr Ivanov]

In drivers/usb/host/xhci-ring.c there are two functions
(xhci_queue_bulk_tx and queue_bulk_sg_tx) that are very similar,
so a lot of code duplication.
This patch merges these functions into to one xhci_queue_bulk_tx.
Also counting the needed TRBs is merged and refactored.

Signed-off-by: Alexandr Ivanov 
---
 drivers/usb/host/xhci-ring.c | 406 +--
 drivers/usb/host/xhci.h  |   3 +
 2 files changed, 121 insertions(+), 288 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 7cf6621..2a1bb76 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2938,46 +2938,55 @@ static int prepare_transfer(struct xhci_hcd *xhci,
return 0;
 }
 
-static unsigned int count_sg_trbs_needed(struct xhci_hcd *xhci, struct urb 
*urb)
+static unsigned int count_trbs(u64 addr, u64 len)
+{
+   unsigned int num_trbs;
+
+   num_trbs = DIV_ROUND_UP(len + (addr & (TRB_MAX_BUFF_SIZE - 1)),
+   TRB_MAX_BUFF_SIZE);
+   if (num_trbs == 0)
+   num_trbs++;
+
+   return num_trbs;
+}
+
+static inline unsigned int count_trbs_needed(struct urb *urb)
+{
+   return count_trbs(urb->transfer_dma, urb->transfer_buffer_length);
+}
+
+static unsigned int count_sg_trbs_needed(struct urb *urb)
 {
-   int num_sgs, num_trbs, running_total, temp, i;
struct scatterlist *sg;
+   unsigned int i, len, full_len, num_trbs = 0;
 
-   sg = NULL;
-   num_sgs = urb->num_mapped_sgs;
-   temp = urb->transfer_buffer_length;
+   full_len = urb->transfer_buffer_length;
 
-   num_trbs = 0;
-   for_each_sg(urb->sg, sg, num_sgs, i) {
-   unsigned int len = sg_dma_len(sg);
-
-   /* Scatter gather list entries may cross 64KB boundaries */
-   running_total = TRB_MAX_BUFF_SIZE -
-   (sg_dma_address(sg) & (TRB_MAX_BUFF_SIZE - 1));
-   running_total &= TRB_MAX_BUFF_SIZE - 1;
-   if (running_total != 0)
-   num_trbs++;
-
-   /* How many more 64KB chunks to transfer, how many more TRBs? */
-   while (running_total < sg_dma_len(sg) && running_total < temp) {
-   num_trbs++;
-   running_total += TRB_MAX_BUFF_SIZE;
-   }
-   len = min_t(int, len, temp);
-   temp -= len;
-   if (temp == 0)
+   for_each_sg(urb->sg, sg, urb->num_mapped_sgs, i) {
+   len = sg_dma_len(sg);
+   num_trbs += count_trbs(sg_dma_address(sg), len);
+   len = min_t(unsigned int, len, full_len);
+   full_len -= len;
+   if (full_len == 0)
break;
}
+
return num_trbs;
 }
 
-static void check_trb_math(struct urb *urb, int num_trbs, int running_total)
+static unsigned int count_isoc_trbs_needed(struct urb *urb, int i)
+{
+   u64 addr, len;
+
+   addr = (u64) (urb->transfer_dma + urb->iso_frame_desc[i].offset);
+   len = urb->iso_frame_desc[i].length;
+
+   return count_trbs(addr, len);
+}
+
+static void check_trb_math(struct urb *urb, int running_total)
 {
-   if (num_trbs != 0)
-   dev_err(>dev->dev, "%s - ep %#x - Miscalculated number of "
-   "TRBs, %d left\n", __func__,
-   urb->ep->desc.bEndpointAddress, num_trbs);
-   if (running_total != urb->transfer_buffer_length)
+   if (unlikely(running_total != urb->transfer_buffer_length))
dev_err(>dev->dev, "%s - ep %#x - Miscalculated tx length, 
"
"queued %#x (%d), asked for %#x (%d)\n",
__func__,
@@ -3086,44 +3095,47 @@ static u32 xhci_td_remainder(struct xhci_hcd *xhci, int 
transferred,
return (total_packet_count - ((transferred + trb_buff_len) / maxp));
 }
 
-
-static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
+/* This is very similar to what ehci-q.c qtd_fill() does */
+int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
struct urb *urb, int slot_id, unsigned int ep_index)
 {
struct xhci_ring *ep_ring;
-   unsigned int num_trbs;
struct urb_priv *urb_priv;
struct xhci_td *td;
-   struct scatterlist *sg;
-   int num_sgs;
-   int trb_buff_len, this_sg_len, running_total, ret;
-   unsigned int total_packet_count;
+   struct xhci_generic_trb *start_trb;
+   struct scatterlist *sg = NULL;
+   bool more_trbs_coming;
bool zero_length_needed;
-   bool first_trb;
-   int last_trb_num;
+   unsigned int num_trbs, last_trb_num, i;
+   unsigned int start_cycle, num_sgs = 0;
+   unsigned int running_total, block_len, trb_buff_len;
+   unsigned int full_len;
+   int ret;
+   u32 field, length_field, remainder;
u64 

Re: [PATCH 1/3] usb: fix endpoint descriptor buffer size decrement

[Mathias Nyman]

On 18.02.2016 20:29, Alan Stern wrote:

On Thu, 18 Feb 2016, Mathias Nyman wrote:


An endpoint descriptor may be followed by both SuperSpeed and
SuperSpeedPlus Isoc endpoint companion descriptors.
These descriptors are all stored one after another in a buffer.

The new SuperSpeedPlus Isoc endpoint companion parsing incorrectly
decreased the the remaining buffer size before comparing the size with the
expected length of the descriptor.

This lead to possible failure in reading the SuperSpeed endpoint companion
descriptor of the last endpoint, displaying an message like:

"No SuperSpeed endpoint companion for config 1 interface 0 altsetting 0
  ep 129: using minimum values"

Fix it by decreasing the size after comparing it.

Signed-off-by: Mathias Nyman 
---
  drivers/usb/core/config.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 5eb1a87..47fb58c 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -76,7 +76,6 @@ static void usb_parse_ss_endpoint_companion(struct device 
*ddev, int cfgno,
 */
desc = (struct usb_ss_ep_comp_descriptor *) buffer;
buffer += desc->bLength;
-   size -= desc->bLength;

if (desc->bDescriptorType != USB_DT_SS_ENDPOINT_COMP ||
size < USB_DT_SS_EP_COMP_SIZE) {
@@ -101,6 +100,7 @@ static void usb_parse_ss_endpoint_companion(struct device 
*ddev, int cfgno,
return;
}

+   size -= desc->bLength;
memcpy(>ss_ep_comp, desc, USB_DT_SS_EP_COMP_SIZE);

/* Check the various values */


It's generally better to change the two variables (buffer and size) at
the same time.  At least, that's what people expect to see.  How about
moving both statements down?

Also, wouldn't it be better in the original patch to call
usb_parse_ssp_isoc_endpoint_companion() after all the SS endpoint
companion stuff is finished, instead of in the middle?



I completely missed this mail (subject didn't contain "xhci". I need to fix my 
filters)

All points are valid, I'll resend

-Mathias
--
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 v3 3/7] usb: mux: add common code for Intel dual role port mux

[Oliver Neukum]

On Tue, 2016-03-08 at 15:53 +0800, Lu Baolu wrote:

> diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
> b/Documentation/ABI/testing/sysfs-bus-platform
> index 5172a61..a2261cb 100644
> --- a/Documentation/ABI/testing/sysfs-bus-platform
> +++ b/Documentation/ABI/testing/sysfs-bus-platform
> @@ -18,3 +18,18 @@ Description:
>   devices to opt-out of driver binding using a driver_override
>   name such as "none".  Only a single driver may be specified in
>   the override, there is no support for parsing delimiters.
> +
> +What:/sys/bus/platform/devices/.../intel_mux

Hi,

is there any reason to call this "intel_mux"? We want a common interface
for such things. So how about "role_mux" or "master_slave_mux"?

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: [RFC Patch 1/3] USB: add descriptors from USB Power Delivery spec

[Sergei Shtylyov]

Hello.

On 3/10/2016 1:32 PM, Oliver Neukum wrote:


Adding the descriptors of chapter 9.2 of the Power Delivery spec.

Signed-off-by: Oliver Neukum 
---
  include/uapi/linux/usb/ch9.h | 94 
  1 file changed, 94 insertions(+)

diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index 252ac16..c9f2bc2 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -913,6 +913,100 @@ struct usb_ssp_cap_descriptor {
  } __attribute__((packed));

  /*
+ * USB Power Delivery Capability Descriptor:
+ * Defines capabilities for PD
+ */
+#define USB_PD_POWER_DELIVERY_CAPABILITY   (0x06)  /* Defines the various 
PD Capabilities of this device */
+#define USB_PD_BATTERY_INFO_CAPABILITY (0x07)  /* Provides information 
on each battery supported by the device */
+#define USB_PD_PD_CONSUMER_PORT_CAPABILITY (0x08)  /* The Consumer 
characteristics of a Port on the device */
+#define USB_PD_PD_PROVIDER_PORT_CAPABILITY (0x09)  /* The provider 
characteristics of a Port on the device */


   Parens not needed.


+
+struct usb_pd_cap_descriptor {
+   __u8  bLength;
+   __u8  bDescriptorType;
+   __u8  bDevCapabilityType; /* set to USB_PD_POWER_DELIVERY_CAPABILITY */
+   __u8  bReserved;
+   __le32 bmAttributes;
+#define uSB_PD_CAP_BATTERY_CHARGING( 1 << 1 ) /* supports Battery Charging 
specification */
+#define uSB_PD_CAP_USB_PD  ( 1 << 2 ) /* supports USB Power 
Delivery specification */
+#define uSB_PD_CAP_PROVIDER( 1 << 3 ) /* can provide power */
+#define uSB_PD_CAP_CONSUMER( 1 << 4 ) /* can consume power */
+#define uSB_PD_CAP_CHARGING_POLICY ( 1 << 5 ) /* supports CHARGING_POLICY 
feature */
+#define uSB_PD_CAP_TYPE_C_CURRENT  ( 1 << 6 ) /* supports power 
capabilities defined in the USB Type-C Specification */
+
+#define uSB_PD_CAP_PWR_AC  ( 1 << 8 )
+#define uSB_PD_CAP_PWR_BAT ( 1 << 9 )
+#define uSB_PD_CAP_PWR_USE_V_BUS   ( 1 << 14 )


   Remove spaces after ( and before ) please.

[...]

+struct usb_pd_cap_consumer_port_descriptor {
+   __u8 bLength;
+   __u8 bDescriptorType;
+   __u8 bDevCapabilityType;
+   __u8 bReserved;
+   __u8 bmCapabilities;
+/* port will oerate under: */
+#define uSB_PD_CAP_CONSUMER_BC ( 1 << 0 ) /* BC */
+#define uSB_PD_CAP_CONSUMER_PD ( 1 << 1 ) /* PD */
+#define uSB_PD_CAP_CONSUMER_TYPE_C ( 1 << 2 ) /* USB Type-C Current */


   Likewise.


+   __le16 wMinVoltage; /* in 50mV units */
+   __le16 wMaxVoltage; /* in 50mV units */
+   __u16 wReserved;
+   __le32 dwMaxOperatingPower; /* in 10 mW - operating at steady state */
+   __le32 dwMaxPeakPower; /* in 10mW units - operating at peak power */
+   __le32 dwMaxPeakPowerTime; /* in 100ms units - duration of peak */
+#define uSB_PD_CAP_CONSUMER_UNKNOWN_PEAK_POWER_TIME 0x
+} __attribute__((packed));
+
+struct usb_pd_cap_provider_port_descriptor {
+   __u8 bLength;
+   __u8 bDescriptorType;
+   __u8 bDevCapabilityType;
+   __u8 bReserved1;
+   __u8 bmCapabilities;
+/* port will oerate under: */
+#define uSB_PD_CAP_PROVIDER_BC ( 1 << 0 ) /* BC */
+#define uSB_PD_CAP_PROVIDER_PD ( 1 << 1 ) /* PD */
+#define uSB_PD_CAP_PROVIDER_TYPE_C ( 1 << 2 ) /* USB Type-C Current */


   Likewise.

[...]

MBR, Sergei

--
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 3/3] dm9601: add support ethtool style utility

[Ben Hutchings]

On Thu, 2016-03-10 at 20:51 +0800, Joseph Chang wrote:
> I did verify to dump EEPROM data and also write EEPROM by per byte.
> 
> 1.Plug dm9601/dm9621 adapter and has get dm9601.ko be 'insmod' to have 'eht0',
> 2.Run ethtool v3.7 (as attached executable file and it's help display.)
> 3. Commands:
>    ./ethtool -e eth0  (dump EEPROM data for all the .get_eeprom_len )
>    ./ethtool -E eth0 magic 0x9620 offset 0 value 0xf1  (write 0xf1 to eeprom 
> byte0)
>    ./ethtool -E eth0 magic 0x9620 offset 1 value 0xf2  (write 0xf2 to eeprom 
> byte1)
>    ./ethtool -E eth0 magic 0x9620 offset 2 value 0xf3  (write 0xf3 to eeprom 
> byte2)
[...]

So you only tested writing 1 byte at a time.  Try again with 3 bytes
and you'll see how it goes wrong.

Ben.

-- 
Ben Hutchings
To err is human; to really foul things up requires a computer.

signature.asc
Description: This is a digitally signed message part

[PATCHv2 2/3] USB: PD: define specific requests

[Oliver Neukum]

This takes the definitions of requests from chapter 9.3.1
of the USB Power Delivery spec.

Signed-off-by: Oliver Neukum 
---
 include/uapi/linux/usb/ch9.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index 118a47b..25c882a 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -105,6 +105,13 @@
 #define USB_REQ_LOOPBACK_DATA_READ 0x16
 #define USB_REQ_SET_INTERFACE_DS   0x17
 
+/* specific requests for USB Power Delivery */
+#define USB_REQ_GET_PARTNER_PDO20
+#define USB_REQ_GET_BATTERY_STATUS 21
+#define USB_REQ_SET_PDO22
+#define USB_REQ_GET_VDM23
+#define USB_REQ_SEND_VDM   24
+
 /* The Link Power Management (LPM) ECN defines USB_REQ_TEST_AND_SET command,
  * used by hubs to put ports into a new L1 suspend state, except that it
  * forgot to define its number ...
-- 
2.1.4

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

[v2] adding definitions for USB PD to headers

[Oliver Neukum]

This patch set adds to definitions from chapter 9 of
the Power Delivery spec to the header files so that they can be better
used. It is a conservative selection and adds only a minimum.
--
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

[PATCHv2 3/3] USB: PD: additional feature selectors

[Oliver Neukum]

This adds the feature selectors from Table 9-8

Signed-off-by: Oliver Neukum 
---
 include/uapi/linux/usb/ch9.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index 25c882a..dab542e 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -172,6 +172,22 @@
 #define USB_DEV_STAT_U2_ENABLED3   /* transition into U2 
state */
 #define USB_DEV_STAT_LTM_ENABLED   4   /* Latency tolerance messages */
 
+/*
+ * Feature selectors from Table 9-8 USB Power Delivery spec
+ */
+#define USB_DEVICE_BATTERY_WAKE_MASK   40
+#define USB_DEVICE_OS_IS_PD_AWARE  41
+#define USB_DEVICE_POLICY_MODE 42
+#define USB_PORT_PR_SWAP   43
+#define USB_PORT_GOTO_MIN  44
+#define USB_PORT_RETURN_POWER  45
+#define USB_PORT_ACCEPT_PD_REQUEST 46
+#define USB_PORT_REJECT_PD_REQUEST 47
+#define USB_PORT_PORT_PD_RESET 48
+#define USB_PORT_C_PORT_PD_CHANGE  49
+#define USB_PORT_CABLE_PD_RESET50
+#define USB_DEVICE_CHARGING_POLICY 54
+
 /**
  * struct usb_ctrlrequest - SETUP data for a USB device control request
  * @bRequestType: matches the USB bmRequestType field
-- 
2.1.4

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

[PATCHv2 1/3] USB: add descriptors from USB Power Delivery spec

[Oliver Neukum]

Adding the descriptors of chapter 9.2 of the Power Delivery spec.

Signed-off-by: Oliver Neukum 
---
 include/uapi/linux/usb/ch9.h | 98 
 1 file changed, 98 insertions(+)

diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index 06d6c62..118a47b 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -914,6 +914,104 @@ struct usb_ssp_cap_descriptor {
 } __attribute__((packed));
 
 /*
+ * USB Power Delivery Capability Descriptor:
+ * Defines capabilities for PD
+ */
+/* Defines the various PD Capabilities of this device */
+#define USB_PD_POWER_DELIVERY_CAPABILITY   (0x06)
+/* Provides information on each battery supported by the device */
+#define USB_PD_BATTERY_INFO_CAPABILITY (0x07)
+/* The Consumer characteristics of a Port on the device */
+#define USB_PD_PD_CONSUMER_PORT_CAPABILITY (0x08)
+/* The provider characteristics of a Port on the device */
+#define USB_PD_PD_PROVIDER_PORT_CAPABILITY (0x09)
+
+struct usb_pd_cap_descriptor {
+   __u8  bLength;
+   __u8  bDescriptorType;
+   __u8  bDevCapabilityType; /* set to USB_PD_POWER_DELIVERY_CAPABILITY */
+   __u8  bReserved;
+   __le32 bmAttributes;
+#define USB_PD_CAP_BATTERY_CHARGING(1 << 1) /* supports Battery Charging 
specification */
+#define USB_PD_CAP_USB_PD  (1 << 2) /* supports USB Power Delivery 
specification */
+#define USB_PD_CAP_PROVIDER(1 << 3) /* can provide power */
+#define USB_PD_CAP_CONSUMER(1 << 4) /* can consume power */
+#define USB_PD_CAP_CHARGING_POLICY (1 <<  ) /* supports CHARGING_POLICY 
feature */
+#define USB_PD_CAP_TYPE_C_CURRENT  (1 << 6) /* supports power capabilities 
defined in the USB Type-C Specification */
+
+#define USB_PD_CAP_PWR_AC  (1 << 8 )
+#define USB_PD_CAP_PWR_BAT (1 << 9)
+#define USB_PD_CAP_PWR_USE_V_BUS   (1 << 14)
+
+   __le16 bmProviderPorts; /* Bit zero refers to the UFP of the device */
+   __le16 bmConsumerPorts;
+   __le16 bcdBCVersion;
+   __le16 bcdPDVersion;
+   __le16 bcdUSBTypeCVersion;
+} __attribute__((packed));
+
+struct usb_pd_cap_battery_info_descriptor {
+   __u8 bLength;
+   __u8 bDescriptorType;
+   __u8 bDevCapabilityType;
+   /* Index of string descriptor shall contain the user friendly name for 
this battery */
+   __u8 iBattery;
+   /* Index of string descriptor shall contain the Serial Number String 
for this battery */
+   __u8 iSerial;
+   __u8 iManufacturer;
+   __u8 bBatteryId; /* uniquely identifies this battery in status Messages 
*/
+   __u8 bReserved;
+   /*
+* Shall contain the Battery Charge value above which this
+* battery is considered to be fully charged but not necessarily
+* “topped off.”
+*/
+   __le32 dwChargedThreshold; /* in mWh */
+   /*
+* Shall contain the minimum charge level of this battery such
+* that above this threshold, a device can be assured of being
+* able to power up successfully (see Battery Charging 1.2).
+*/
+   __le32 dwWeakThreshold; /* in mWh */
+   __le32 dwBatteryDesignCapacity; /* in mWh */
+   __le32 dwBatteryLastFullchargeCapacity; /* in mWh */
+} __attribute__((packed));
+
+struct usb_pd_cap_consumer_port_descriptor {
+   __u8 bLength;
+   __u8 bDescriptorType;
+   __u8 bDevCapabilityType;
+   __u8 bReserved;
+   __u8 bmCapabilities;
+/* port will oerate under: */
+#define uSB_PD_CAP_CONSUMER_BC ( 1 << 0 ) /* BC */
+#define uSB_PD_CAP_CONSUMER_PD ( 1 << 1 ) /* PD */
+#define uSB_PD_CAP_CONSUMER_TYPE_C ( 1 << 2 ) /* USB Type-C Current */
+   __le16 wMinVoltage; /* in 50mV units */
+   __le16 wMaxVoltage; /* in 50mV units */
+   __u16 wReserved;
+   __le32 dwMaxOperatingPower; /* in 10 mW - operating at steady state */
+   __le32 dwMaxPeakPower; /* in 10mW units - operating at peak power */
+   __le32 dwMaxPeakPowerTime; /* in 100ms units - duration of peak */
+#define uSB_PD_CAP_CONSUMER_UNKNOWN_PEAK_POWER_TIME 0x
+} __attribute__((packed));
+
+struct usb_pd_cap_provider_port_descriptor {
+   __u8 bLength;
+   __u8 bDescriptorType;
+   __u8 bDevCapabilityType;
+   __u8 bReserved1;
+   __u8 bmCapabilities;
+/* port will oerate under: */
+#define uSB_PD_CAP_PROVIDER_BC ( 1 << 0 ) /* BC */
+#define uSB_PD_CAP_PROVIDER_PD ( 1 << 1 ) /* PD */
+#define uSB_PD_CAP_PROVIDER_TYPE_C ( 1 << 2 ) /* USB Type-C Current */
+   __u8 bNumOfPDObjects;
+   __u8 bReserved2;
+   __le32 wPowerDataObject[];
+} __attribute__((packed));
+
+/*
  * Precision time measurement capability descriptor: advertised by devices and
  * hubs that support PTM
  */
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to 

Re: [PATCH v3 1/3] USB: add descriptors from USB Power Delivery spec

[Ruslan Bilovol]

On Thu, Mar 10, 2016 at 3:59 PM, Oliver Neukum  wrote:
> Adding the descriptors of chapter 9.2 of the Power Delivery spec.
>
> Signed-off-by: Oliver Neukum 
> ---
>  include/uapi/linux/usb/ch9.h | 98 
> 
>  1 file changed, 98 insertions(+)
>
> diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
> index 06d6c62..1046c55 100644
> --- a/include/uapi/linux/usb/ch9.h
> +++ b/include/uapi/linux/usb/ch9.h
> @@ -914,6 +914,104 @@ struct usb_ssp_cap_descriptor {
>  } __attribute__((packed));
>
>  /*
> + * USB Power Delivery Capability Descriptor:
> + * Defines capabilities for PD
> + */
> +/* Defines the various PD Capabilities of this device */
> +#define USB_PD_POWER_DELIVERY_CAPABILITY   0x06
> +/* Provides information on each battery supported by the device */
> +#define USB_PD_BATTERY_INFO_CAPABILITY 0x07
> +/* The Consumer characteristics of a Port on the device */
> +#define USB_PD_PD_CONSUMER_PORT_CAPABILITY 0x08
> +/* The provider characteristics of a Port on the device */
> +#define USB_PD_PD_PROVIDER_PORT_CAPABILITY 0x09
> +
> +struct usb_pd_cap_descriptor {
> +   __u8  bLength;
> +   __u8  bDescriptorType;
> +   __u8  bDevCapabilityType; /* set to USB_PD_POWER_DELIVERY_CAPABILITY 
> */
> +   __u8  bReserved;
> +   __le32 bmAttributes;
> +#define USB_PD_CAP_BATTERY_CHARGING(1 << 1) /* supports Battery Charging 
> specification */
> +#define USB_PD_CAP_USB_PD  (1 << 2) /* supports USB Power 
> Delivery specification */
> +#define USB_PD_CAP_PROVIDER(1 << 3) /* can provide power */
> +#define USB_PD_CAP_CONSUMER(1 << 4) /* can consume power */
> +#define USB_PD_CAP_CHARGING_POLICY (1 << 5) /* supports CHARGING_POLICY 
> feature */
> +#define USB_PD_CAP_TYPE_C_CURRENT  (1 << 6) /* supports power 
> capabilities defined in the USB Type-C Specification */
> +
> +#define USB_PD_CAP_PWR_AC  (1 << 8)
> +#define USB_PD_CAP_PWR_BAT (1 << 9)
> +#define USB_PD_CAP_PWR_USE_V_BUS   (1 << 14)

Thank you for fixing uSB_xxx here

> +
> +   __le16 bmProviderPorts; /* Bit zero refers to the UFP of the device */
> +   __le16 bmConsumerPorts;
> +   __le16 bcdBCVersion;
> +   __le16 bcdPDVersion;
> +   __le16 bcdUSBTypeCVersion;
> +} __attribute__((packed));
> +
> +struct usb_pd_cap_battery_info_descriptor {
> +   __u8 bLength;
> +   __u8 bDescriptorType;
> +   __u8 bDevCapabilityType;
> +   /* Index of string descriptor shall contain the user friendly name 
> for this battery */
> +   __u8 iBattery;
> +   /* Index of string descriptor shall contain the Serial Number String 
> for this battery */
> +   __u8 iSerial;
> +   __u8 iManufacturer;
> +   __u8 bBatteryId; /* uniquely identifies this battery in status 
> Messages */
> +   __u8 bReserved;
> +   /*
> +* Shall contain the Battery Charge value above which this
> +* battery is considered to be fully charged but not necessarily
> +* “topped off.”
> +*/
> +   __le32 dwChargedThreshold; /* in mWh */
> +   /*
> +* Shall contain the minimum charge level of this battery such
> +* that above this threshold, a device can be assured of being
> +* able to power up successfully (see Battery Charging 1.2).
> +*/
> +   __le32 dwWeakThreshold; /* in mWh */
> +   __le32 dwBatteryDesignCapacity; /* in mWh */
> +   __le32 dwBatteryLastFullchargeCapacity; /* in mWh */
> +} __attribute__((packed));
> +
> +struct usb_pd_cap_consumer_port_descriptor {
> +   __u8 bLength;
> +   __u8 bDescriptorType;
> +   __u8 bDevCapabilityType;
> +   __u8 bReserved;
> +   __u8 bmCapabilities;
> +/* port will oerate under: */
> +#define uSB_PD_CAP_CONSUMER_BC (1 << 0) /* BC */
> +#define uSB_PD_CAP_CONSUMER_PD (1 << 1) /* PD */
> +#define uSB_PD_CAP_CONSUMER_TYPE_C (1 << 2) /* USB Type-C Current */

However, this typo still exists here ^

> +   __le16 wMinVoltage; /* in 50mV units */
> +   __le16 wMaxVoltage; /* in 50mV units */
> +   __u16 wReserved;
> +   __le32 dwMaxOperatingPower; /* in 10 mW - operating at steady state */
> +   __le32 dwMaxPeakPower; /* in 10mW units - operating at peak power */
> +   __le32 dwMaxPeakPowerTime; /* in 100ms units - duration of peak */
> +#define uSB_PD_CAP_CONSUMER_UNKNOWN_PEAK_POWER_TIME 0x

and here ^

> +} __attribute__((packed));
> +
> +struct usb_pd_cap_provider_port_descriptor {
> +   __u8 bLength;
> +   __u8 bDescriptorType;
> +   __u8 bDevCapabilityType;
> +   __u8 bReserved1;
> +   __u8 bmCapabilities;
> +/* port will oerate under: */
> +#define uSB_PD_CAP_PROVIDER_BC (1 << 0) /* BC */
> +#define uSB_PD_CAP_PROVIDER_PD (1 << 1) /* PD */
> +#define uSB_PD_CAP_PROVIDER_TYPE_C (1 << 2) /* USB Type-C 

[PATCH v2] adding definitions for USB PD to headers

[Oliver Neukum]

This patch set adds to definitions from chapter 9 of
the Power Delivery spec to the header files so that they can be better
used. It is a conservative selection and adds only a minimum.

--
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 v3 3/3] USB: PD: additional feature selectors

[Oliver Neukum]

This adds the feature selectors from Table 9-8

Signed-off-by: Oliver Neukum 
---
 include/uapi/linux/usb/ch9.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index 78e95ca..4c03a17 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -172,6 +172,22 @@
 #define USB_DEV_STAT_U2_ENABLED3   /* transition into U2 
state */
 #define USB_DEV_STAT_LTM_ENABLED   4   /* Latency tolerance messages */
 
+/*
+ * Feature selectors from Table 9-8 USB Power Delivery spec
+ */
+#define USB_DEVICE_BATTERY_WAKE_MASK   40
+#define USB_DEVICE_OS_IS_PD_AWARE  41
+#define USB_DEVICE_POLICY_MODE 42
+#define USB_PORT_PR_SWAP   43
+#define USB_PORT_GOTO_MIN  44
+#define USB_PORT_RETURN_POWER  45
+#define USB_PORT_ACCEPT_PD_REQUEST 46
+#define USB_PORT_REJECT_PD_REQUEST 47
+#define USB_PORT_PORT_PD_RESET 48
+#define USB_PORT_C_PORT_PD_CHANGE  49
+#define USB_PORT_CABLE_PD_RESET50
+#define USB_DEVICE_CHARGING_POLICY 54
+
 /**
  * struct usb_ctrlrequest - SETUP data for a USB device control request
  * @bRequestType: matches the USB bmRequestType field
-- 
2.1.4

--
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 v3 1/3] USB: add descriptors from USB Power Delivery spec

[Oliver Neukum]

Adding the descriptors of chapter 9.2 of the Power Delivery spec.

Signed-off-by: Oliver Neukum 
---
 include/uapi/linux/usb/ch9.h | 98 
 1 file changed, 98 insertions(+)

diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index 06d6c62..1046c55 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -914,6 +914,104 @@ struct usb_ssp_cap_descriptor {
 } __attribute__((packed));
 
 /*
+ * USB Power Delivery Capability Descriptor:
+ * Defines capabilities for PD
+ */
+/* Defines the various PD Capabilities of this device */
+#define USB_PD_POWER_DELIVERY_CAPABILITY   0x06
+/* Provides information on each battery supported by the device */
+#define USB_PD_BATTERY_INFO_CAPABILITY 0x07
+/* The Consumer characteristics of a Port on the device */
+#define USB_PD_PD_CONSUMER_PORT_CAPABILITY 0x08
+/* The provider characteristics of a Port on the device */
+#define USB_PD_PD_PROVIDER_PORT_CAPABILITY 0x09
+
+struct usb_pd_cap_descriptor {
+   __u8  bLength;
+   __u8  bDescriptorType;
+   __u8  bDevCapabilityType; /* set to USB_PD_POWER_DELIVERY_CAPABILITY */
+   __u8  bReserved;
+   __le32 bmAttributes;
+#define USB_PD_CAP_BATTERY_CHARGING(1 << 1) /* supports Battery Charging 
specification */
+#define USB_PD_CAP_USB_PD  (1 << 2) /* supports USB Power Delivery 
specification */
+#define USB_PD_CAP_PROVIDER(1 << 3) /* can provide power */
+#define USB_PD_CAP_CONSUMER(1 << 4) /* can consume power */
+#define USB_PD_CAP_CHARGING_POLICY (1 << 5) /* supports CHARGING_POLICY 
feature */
+#define USB_PD_CAP_TYPE_C_CURRENT  (1 << 6) /* supports power capabilities 
defined in the USB Type-C Specification */
+
+#define USB_PD_CAP_PWR_AC  (1 << 8)
+#define USB_PD_CAP_PWR_BAT (1 << 9)
+#define USB_PD_CAP_PWR_USE_V_BUS   (1 << 14)
+
+   __le16 bmProviderPorts; /* Bit zero refers to the UFP of the device */
+   __le16 bmConsumerPorts;
+   __le16 bcdBCVersion;
+   __le16 bcdPDVersion;
+   __le16 bcdUSBTypeCVersion;
+} __attribute__((packed));
+
+struct usb_pd_cap_battery_info_descriptor {
+   __u8 bLength;
+   __u8 bDescriptorType;
+   __u8 bDevCapabilityType;
+   /* Index of string descriptor shall contain the user friendly name for 
this battery */
+   __u8 iBattery;
+   /* Index of string descriptor shall contain the Serial Number String 
for this battery */
+   __u8 iSerial;
+   __u8 iManufacturer;
+   __u8 bBatteryId; /* uniquely identifies this battery in status Messages 
*/
+   __u8 bReserved;
+   /*
+* Shall contain the Battery Charge value above which this
+* battery is considered to be fully charged but not necessarily
+* “topped off.”
+*/
+   __le32 dwChargedThreshold; /* in mWh */
+   /*
+* Shall contain the minimum charge level of this battery such
+* that above this threshold, a device can be assured of being
+* able to power up successfully (see Battery Charging 1.2).
+*/
+   __le32 dwWeakThreshold; /* in mWh */
+   __le32 dwBatteryDesignCapacity; /* in mWh */
+   __le32 dwBatteryLastFullchargeCapacity; /* in mWh */
+} __attribute__((packed));
+
+struct usb_pd_cap_consumer_port_descriptor {
+   __u8 bLength;
+   __u8 bDescriptorType;
+   __u8 bDevCapabilityType;
+   __u8 bReserved;
+   __u8 bmCapabilities;
+/* port will oerate under: */
+#define uSB_PD_CAP_CONSUMER_BC (1 << 0) /* BC */
+#define uSB_PD_CAP_CONSUMER_PD (1 << 1) /* PD */
+#define uSB_PD_CAP_CONSUMER_TYPE_C (1 << 2) /* USB Type-C Current */
+   __le16 wMinVoltage; /* in 50mV units */
+   __le16 wMaxVoltage; /* in 50mV units */
+   __u16 wReserved;
+   __le32 dwMaxOperatingPower; /* in 10 mW - operating at steady state */
+   __le32 dwMaxPeakPower; /* in 10mW units - operating at peak power */
+   __le32 dwMaxPeakPowerTime; /* in 100ms units - duration of peak */
+#define uSB_PD_CAP_CONSUMER_UNKNOWN_PEAK_POWER_TIME 0x
+} __attribute__((packed));
+
+struct usb_pd_cap_provider_port_descriptor {
+   __u8 bLength;
+   __u8 bDescriptorType;
+   __u8 bDevCapabilityType;
+   __u8 bReserved1;
+   __u8 bmCapabilities;
+/* port will oerate under: */
+#define uSB_PD_CAP_PROVIDER_BC (1 << 0) /* BC */
+#define uSB_PD_CAP_PROVIDER_PD (1 << 1) /* PD */
+#define uSB_PD_CAP_PROVIDER_TYPE_C (1 << 2) /* USB Type-C Current */
+   __u8 bNumOfPDObjects;
+   __u8 bReserved2;
+   __le32 wPowerDataObject[];
+} __attribute__((packed));
+
+/*
  * Precision time measurement capability descriptor: advertised by devices and
  * hubs that support PTM
  */
-- 
2.1.4

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

[PATCH v3 2/3] USB: PD: define specific requests

[Oliver Neukum]

This takes the definitions of requests from chapter 9.3.1
of the USB Power Delivery spec.

Signed-off-by: Oliver Neukum 
---
 include/uapi/linux/usb/ch9.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index 1046c55..78e95ca 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -105,6 +105,13 @@
 #define USB_REQ_LOOPBACK_DATA_READ 0x16
 #define USB_REQ_SET_INTERFACE_DS   0x17
 
+/* specific requests for USB Power Delivery */
+#define USB_REQ_GET_PARTNER_PDO20
+#define USB_REQ_GET_BATTERY_STATUS 21
+#define USB_REQ_SET_PDO22
+#define USB_REQ_GET_VDM23
+#define USB_REQ_SEND_VDM   24
+
 /* The Link Power Management (LPM) ECN defines USB_REQ_TEST_AND_SET command,
  * used by hubs to put ports into a new L1 suspend state, except that it
  * forgot to define its number ...
-- 
2.1.4

--
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 v2] adding definitions for USB PD to headers

[Felipe Balbi]

Hi,

Oliver Neukum  writes:
> [ text/plain ]
> This patch set adds to definitions from chapter 9 of
> the Power Delivery spec to the header files so that they can be better
> used. It is a conservative selection and adds only a minimum.

For the entire series:

Reviewed-by: Felipe Balbi 
Signed-off-by: Felipe Balbi 

assuming Greg still wants to take this for this merge window. Otherwise
I'll take all patches once v4.6-rc1 is tagged.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Steve Calfee]

On Thu, Mar 10, 2016 at 1:23 AM, Felipe Ferreri Tonello
 wrote:

>>> --- a/drivers/usb/gadget/function/f_midi.c
>>> +++ b/drivers/usb/gadget/function/f_midi.c
>>> @@ -366,7 +366,9 @@ static int f_midi_set_alt(struct usb_function *f, 
>>> unsigned intf, unsigned alt)
>>> /* allocate a bunch of read buffers and queue them all at once. */
>>> for (i = 0; i < midi->qlen && err == 0; i++) {
>>> struct usb_request *req =
>>> -   midi_alloc_ep_req(midi->out_ep, midi->buflen);
>>> +   midi_alloc_ep_req(midi->out_ep,
>>> +   max_t(unsigned, midi->buflen,
>>> +   bulk_out_desc.wMaxPacketSize));
>>> if (req == NULL)
>>> return -ENOMEM;
>>>
>> Won't you get a buffer overrun if midi->buflen is less than wMaxPacketSize?
>>
>
> No, because of the *max_t(unsigned, midi->buflen,
> bulk_out_desc.wMaxPacketSize)*.
>
> Maybe that's not the most clear indentation but I had to break it in
> order to avoid passing 80 columns.
>
Yes, I understood that code. It is a little confusing that gadgets use
OUT endpoints to receive data.

I think we are talking about different buffers. I meant that if you
ever received data into your enlarged ep buffer, will you not copy it
into your midi buffer? If the code checks, I guess you will truncate
the received data? If not, it could be a midi buffer overrun.

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

Re: [PATCH 2/3] dm9601: manage eeprom to assure the chip for correct operation

[Peter Korsgaard]

> "Joseph" == Joseph CHANG  writes:

 > Add to maintain variant eeprom adapters which may have not right
 > dm962x's format.

 > Signed-off-by: Joseph CHANG 

> +static void dm_render_begin(struct usbnet *dev)
 > +{
 > +/* Render eeprom if need, WORD3 render, set D[15:14] 01b */
 > +dm_eeprom_render(dev, 3, 0x4000, 0xc000);
 > +/* Render eeprom if need, WORD7 render, clear D[10] */
 > +dm_eeprom_render(dev, 7, 0x, 0x0400);
 > +/* Render eeprom if need, WORD11 render, need 0x005a */
 > +dm_eeprom_render(dev, 11, 0x005a, 0x);
 > +/* Render eeprom if need, WORD12 render, need 0x0007 */
 > +dm_eeprom_render(dev, 12, DM_EP3I_VAL, 0x);

With render I guess you mean something like fixup? I'm not sure we want
to do this automatically without an explicit action from the user.

How common are these adapters without valid eeprom? What happens if the
eeprom content isn't fixed?

Do we need to reset the device once the eeprom is updated?

-- 
Bye, Peter Korsgaard
--
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: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"

[John Youn]

On 3/9/2016 11:06 AM, Doug Anderson wrote:
> Stefan,
> 
> On Wed, Mar 9, 2016 at 11:01 AM, Stefan Wahren  wrote:
>>
>>> Doug Anderson  hat am 7. März 2016 um 22:30
>>> geschrieben:
>>>
>>>
>>> Stefan,
>>>
>>> On Mon, Mar 7, 2016 at 10:40 AM, Stefan Wahren  
>>> wrote:
 Hi Doug,

> Douglas Anderson  hat am 4. März 2016 um 19:23
> geschrieben:
>
>
> This reverts commit 192cb07f7928 ("usb: dwc2: Fix probe problem on
> bcm2835") now that we've found the root cause. See the change
> titled ("usb: dwc2: Add a 10 ms delay to dwc2_core_reset()").

 adding a delay of 10 ms after a core reset might be a idea, but applying
 both
 patches breaks USB support on RPi :-(

 I'm getting the wrong register values ...
>>>
>>> Ugh. :(
>>>
>>> Just out of curiosity, if you loop and time long it takes for the
>>> registers to get to the right state after reset, what do you get?
>>> AKA, pick:
>>>
>>> https://chromium-review.googlesource.com/331260
>>>
>>> ...and let me know what it prints out.
>>
>> On my Raspberry Pi B i get the following:
>>
>> [2.084411] dwc2 2098.usb: mapped PA 2098 to VA cc88
>> [2.084461] dwc2 2098.usb: cannot get otg clock
>> [2.084549] dwc2 2098.usb: registering common handler for irq33
>> [2.084713] dwc2 2098.usb: Configuration mismatch. dr_mode forced to 
>> host
>> [2.153965] dwc2 2098.usb: Waited 49996 us, 0x00201000 => 0x01001000,
>> 0x => 0x02002000
>> [2.174930] dwc2 2098.usb: Forcing mode to host
>>
>> So i changed the delay in patch #1 to msleep(50) and then both patches work 
>> like
>> a charm.
> 
> Great news!  :-)
> 
> John: it's pretty clear that there's something taking almost exactly
> 10ms on my system and almost exactly 50ms on Stefan's system.  Is
> there some register we could poll to see when this process is done?
> ...or can we look at the dwc2 revision number / feature register and
> detect how long to delay?
> 

Hi Doug,

I'll have to ask around to see if anyone knows about this. And I'll
run some tests on the platforms I have available to me as well.

Regards,
John
--
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 v3 1/2] usb:dwc3: Enable support for 64-bit system

[Thang Q. Nguyen]

From: "Thang Q. Nguyen" 

Add 64-bit DMA operation support to the USB DWC3 driver.
First attempt to set the coherent DMA mask for 64-bit DMA.
If that failed, attempt again with 32-bit DMA.

Changes from v2:
- None.

Changes from v1:
- Remove WARN_ON if dma_mask is NULL

Signed-off-by: Thang Q. Nguyen 
---
 drivers/usb/dwc3/core.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index de5e01f..2479c24 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -831,6 +831,21 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->mem = mem;
dwc->dev = dev;
 
+   /* Try to set 64-bit DMA first */
+   if (!pdev->dev.dma_mask)
+   /* Platform did not initialize dma_mask */
+   ret = dma_coerce_mask_and_coherent(>dev,
+  DMA_BIT_MASK(64));
+   else
+   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(64));
+
+   /* If seting 64-bit DMA mask fails, fall back to 32-bit DMA mask */
+   if (ret) {
+   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
+   }
+
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(dev, "missing IRQ\n");
-- 
2.2.0

--
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 v3 2/2] usb:dwc3: pass arch data to xhci-hcd child

[Thang Q. Nguyen]

From: "Thang Q. Nguyen" 

The xhci-hcd child node needs to inherit archdata attribute to use
dma_ops functions and attributes. This patch enables the USB DWC3
driver to pass archdata attributes to its xhci-hcd child node.

Changes from v2:
- None

Changes from v1:
- None

Signed-off-by: Thang Q. Nguyen 
---

 drivers/usb/dwc3/host.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index c679f63..661fbae 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -37,6 +37,7 @@ int dwc3_host_init(struct dwc3 *dwc)
xhci->dev.parent= dwc->dev;
xhci->dev.dma_mask  = dwc->dev->dma_mask;
xhci->dev.dma_parms = dwc->dev->dma_parms;
+   xhci->dev.archdata  = dwc->dev->archdata;
 
dwc->xhci = xhci;
 
-- 
2.2.0

--
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 v3 0/2] usb:dwc3: Enable USB DWC3 support for 64-bit system

[Thang Q. Nguyen]

From: "Thang Q. Nguyen" 

When CONFIG_DMA_CMA is not set, the coherent mask is not set.
These patches enable the USB DWC3 driver to set the coherent mask
correctly by first set coherent DMA mask to 64-bit. If this
failed, attempt again with 32-bit.
In addition, pass the archdata to the xhci-hcd child so that
xhci-hcd can configure DMA operations correctly.

Thang Q. Nguyen (2):
  usb:dwc3: Enable support for 64-bit system
  usb:dwc3: pass arch data to xhci-hcd child

 drivers/usb/dwc3/core.c | 15 +++
 drivers/usb/dwc3/host.c |  1 +
 2 files changed, 16 insertions(+)

-- 
2.2.0

--
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: Bug ID: 114111

[Peter Maciejko]

Guys, I guess I found workaround.

System: Fedora 23.
Kernel: 4.4.3-300 (Fedora repo).

Firstable, I am not be able to shutdown my computer without quirks. I
have to add:

xhci_hcd.quirks=270336 (XHCI_SPURIOUS_WAKEUP and XHCI_SPURIOUS_REBOOT quirks)

or

xhci_hcd.quirks=262144 (XHCI_SPURIOUS_WAKEUP)

to GRUB_CMDLINE_LINUX.

xhci_hcd.quirks=8192 (XHCI_SPURIOUS_REBOOT quirks) does not work.

But this is not enough, I had to prepare script that I put into
/lib/systemd/system-shutdown/ as unbind-xhci-devices.shutdown. Power
off works fine now, but I still think that this is serious bug, which
should be fixed as fast as possible. Power off does not work if I try
use only quirks or only script. It does not matter which quirks(270336
or 262144) I use with my script, power off works fine. BTW, after this
trick, mouse clicking no longer initiate boot process until monitor is
enabled after proper shutdown, as well.

The script has following content: http://pastebin.com/QNGVXHkP

Do you need anything else, except lsusb, lspci and lsusb -t that I
have already sent to you?

Best regards,
PM

On Wed, Mar 9, 2016 at 9:09 PM, Peter Maciejko  wrote:
> The problem is a bit complicated, that is why I put a video containing
> a description of the problem on kernel bug tracker.
>
> Motherboard: ASRock H87 PRO 4
> Processor: Intel Core i5 4570 Haswell
>
> If USB 3.0 controller is enabled in UEFI Setup then three, maybe four
> seconds after shutdown, my computer starts boot process by itself.
> After reboot, which is initiated by me through command line or
> graphical environment - it doesnt matter - poweroff works fine but
> only once. Besides, even if poweroff works fine, until my monitor is
> enabled after proper shutdown, I can start boot process by clicking
> left mouse button/right mouse button/scroll. If I disable my monitor
> and then enable it again, then obviously I cant boot computer by
> clicking. All "Power on" options are disabled in UEFI.
>
> If USB 3.0 controller is disabled in UEFI Setup then poweroff works
> fine, but after proper shutdown, until monitor is enabled, I can light
> up my mouse's and keyboard's leds by clicking same as I described
> above.
>
>
> My mouse and keyboard are connected to the computer through monitor's USB 
> ports.
>
>
> Monitor: Dell U2414H
> Mouse: SteelSeries Rival
> Keyboard: CM Storm Quickfire Rapid-I
>
> Sry for my bad english, I hope you will understand me, if not - then
> watch movie pls.
>
> Link to the movie:
> https://www.dropbox.com/s/isr9i0yojgnlb6n/20160309_133125.mp4?dl=0
> lsusb: http://pastebin.com/uhGAnCLU
> lsusb -t: http://pastebin.com/iY1HZrER
> lspci: http://pastebin.com/phz6if1U
>
> I have tried:
> xhci_hcd.quirks=270336 //XHCI_SPURIOUS_WAKEUP and XHCI_SPURIOUS_REBOOT
> xhci_hcd.quirks=8192 //XHCI_SPURIOUS_REBOOT
> xhci_hcd.quirks=262144 //XHCI_SPURIOUS_WAKEUP
>
> Nothing helped, computer keeps rebooting after shutdown. I cant
> remember when my rig works fine last time - it is very frustrating, I
> am a little bit tired of this :)
> I have now Fedora 23 with 4.4.3 kernel, but I have also tried
> branded/vanilla 4.4.4 and obviously it didnt help.
> On Ubuntu 14.04 and the latest 3.16, bug persists too - my girlfriend
> has same rig and same issue.
>
> There is two situations when poweroff works ALMOST fine:
> 1. Keyboard/Remote Power On and Mouse Power On is enabled in uefi, but
> then poweroff process hangs for few seconds and I can boot computer by
> clicking, until monitor is enabled after shutdown.
> 2. USB 3.0 Controller is disabled (still can light up
> keyboard's/mouse's leds until monitor is enabled after shutdown).
>
> Best regards guys and thanks for your effort,
> PM
>
> On Wed, Mar 9, 2016 at 6:40 PM, Felipe Ferreri Tonello
>  wrote:
>> Hi,
>>
>> On 09/03/16 17:12, Greg KH wrote:
>>> On Wed, Mar 09, 2016 at 05:47:00PM +0100, Peter Maciejko wrote:
 https://bugzilla.kernel.org/show_bug.cgi?id=114111

 Bug ID: 114111
 Summary: Reboot after shutdown, when USB 3.0 controller is enabled
>>>
>>> Please send us the full details so we don't have to dig them out on the
>>> website...
>>
>> There is absolutely no description of the bug besides the Summary, which
>> by itself is not saying much.
>>
>> Peter, can you describe exactly was is going on?
>>
>> --
>> Felipe
--
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 v4 1/3] USB: add descriptors from USB Power Delivery spec

[Oliver Neukum]

Adding the descriptors of chapter 9.2 of the Power Delivery spec.

Signed-off-by: Oliver Neukum 
---
 include/uapi/linux/usb/ch9.h | 98 
 1 file changed, 98 insertions(+)

diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index 06d6c62..b98fc05 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -914,6 +914,104 @@ struct usb_ssp_cap_descriptor {
 } __attribute__((packed));
 
 /*
+ * USB Power Delivery Capability Descriptor:
+ * Defines capabilities for PD
+ */
+/* Defines the various PD Capabilities of this device */
+#define USB_PD_POWER_DELIVERY_CAPABILITY   0x06
+/* Provides information on each battery supported by the device */
+#define USB_PD_BATTERY_INFO_CAPABILITY 0x07
+/* The Consumer characteristics of a Port on the device */
+#define USB_PD_PD_CONSUMER_PORT_CAPABILITY 0x08
+/* The provider characteristics of a Port on the device */
+#define USB_PD_PD_PROVIDER_PORT_CAPABILITY 0x09
+
+struct usb_pd_cap_descriptor {
+   __u8  bLength;
+   __u8  bDescriptorType;
+   __u8  bDevCapabilityType; /* set to USB_PD_POWER_DELIVERY_CAPABILITY */
+   __u8  bReserved;
+   __le32 bmAttributes;
+#define USB_PD_CAP_BATTERY_CHARGING(1 << 1) /* supports Battery Charging 
specification */
+#define USB_PD_CAP_USB_PD  (1 << 2) /* supports USB Power Delivery 
specification */
+#define USB_PD_CAP_PROVIDER(1 << 3) /* can provide power */
+#define USB_PD_CAP_CONSUMER(1 << 4) /* can consume power */
+#define USB_PD_CAP_CHARGING_POLICY (1 << 5) /* supports CHARGING_POLICY 
feature */
+#define USB_PD_CAP_TYPE_C_CURRENT  (1 << 6) /* supports power capabilities 
defined in the USB Type-C Specification */
+
+#define USB_PD_CAP_PWR_AC  (1 << 8)
+#define USB_PD_CAP_PWR_BAT (1 << 9)
+#define USB_PD_CAP_PWR_USE_V_BUS   (1 << 14)
+
+   __le16 bmProviderPorts; /* Bit zero refers to the UFP of the device */
+   __le16 bmConsumerPorts;
+   __le16 bcdBCVersion;
+   __le16 bcdPDVersion;
+   __le16 bcdUSBTypeCVersion;
+} __attribute__((packed));
+
+struct usb_pd_cap_battery_info_descriptor {
+   __u8 bLength;
+   __u8 bDescriptorType;
+   __u8 bDevCapabilityType;
+   /* Index of string descriptor shall contain the user friendly name for 
this battery */
+   __u8 iBattery;
+   /* Index of string descriptor shall contain the Serial Number String 
for this battery */
+   __u8 iSerial;
+   __u8 iManufacturer;
+   __u8 bBatteryId; /* uniquely identifies this battery in status Messages 
*/
+   __u8 bReserved;
+   /*
+* Shall contain the Battery Charge value above which this
+* battery is considered to be fully charged but not necessarily
+* “topped off.”
+*/
+   __le32 dwChargedThreshold; /* in mWh */
+   /*
+* Shall contain the minimum charge level of this battery such
+* that above this threshold, a device can be assured of being
+* able to power up successfully (see Battery Charging 1.2).
+*/
+   __le32 dwWeakThreshold; /* in mWh */
+   __le32 dwBatteryDesignCapacity; /* in mWh */
+   __le32 dwBatteryLastFullchargeCapacity; /* in mWh */
+} __attribute__((packed));
+
+struct usb_pd_cap_consumer_port_descriptor {
+   __u8 bLength;
+   __u8 bDescriptorType;
+   __u8 bDevCapabilityType;
+   __u8 bReserved;
+   __u8 bmCapabilities;
+/* port will oerate under: */
+#define USB_PD_CAP_CONSUMER_BC (1 << 0) /* BC */
+#define USB_PD_CAP_CONSUMER_PD (1 << 1) /* PD */
+#define USB_PD_CAP_CONSUMER_TYPE_C (1 << 2) /* USB Type-C Current */
+   __le16 wMinVoltage; /* in 50mV units */
+   __le16 wMaxVoltage; /* in 50mV units */
+   __u16 wReserved;
+   __le32 dwMaxOperatingPower; /* in 10 mW - operating at steady state */
+   __le32 dwMaxPeakPower; /* in 10mW units - operating at peak power */
+   __le32 dwMaxPeakPowerTime; /* in 100ms units - duration of peak */
+#define USB_PD_CAP_CONSUMER_UNKNOWN_PEAK_POWER_TIME 0x
+} __attribute__((packed));
+
+struct usb_pd_cap_provider_port_descriptor {
+   __u8 bLength;
+   __u8 bDescriptorType;
+   __u8 bDevCapabilityType;
+   __u8 bReserved1;
+   __u8 bmCapabilities;
+/* port will oerate under: */
+#define USB_PD_CAP_PROVIDER_BC (1 << 0) /* BC */
+#define USB_PD_CAP_PROVIDER_PD (1 << 1) /* PD */
+#define USB_PD_CAP_PROVIDER_TYPE_C (1 << 2) /* USB Type-C Current */
+   __u8 bNumOfPDObjects;
+   __u8 bReserved2;
+   __le32 wPowerDataObject[];
+} __attribute__((packed));
+
+/*
  * Precision time measurement capability descriptor: advertised by devices and
  * hubs that support PTM
  */
-- 
2.1.4

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

[PATCH v4 2/3] USB: PD: define specific requests

[Oliver Neukum]

This takes the definitions of requests from chapter 9.3.1
of the USB Power Delivery spec.

Signed-off-by: Oliver Neukum 
---
 include/uapi/linux/usb/ch9.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index b98fc05..4abd964 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -105,6 +105,13 @@
 #define USB_REQ_LOOPBACK_DATA_READ 0x16
 #define USB_REQ_SET_INTERFACE_DS   0x17
 
+/* specific requests for USB Power Delivery */
+#define USB_REQ_GET_PARTNER_PDO20
+#define USB_REQ_GET_BATTERY_STATUS 21
+#define USB_REQ_SET_PDO22
+#define USB_REQ_GET_VDM23
+#define USB_REQ_SEND_VDM   24
+
 /* The Link Power Management (LPM) ECN defines USB_REQ_TEST_AND_SET command,
  * used by hubs to put ports into a new L1 suspend state, except that it
  * forgot to define its number ...
-- 
2.1.4

--
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 v4 3/3] USB: PD: additional feature selectors

[Oliver Neukum]

This adds the feature selectors from Table 9-8

Signed-off-by: Oliver Neukum 
---
 include/uapi/linux/usb/ch9.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index 4abd964..08104bc 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -172,6 +172,22 @@
 #define USB_DEV_STAT_U2_ENABLED3   /* transition into U2 
state */
 #define USB_DEV_STAT_LTM_ENABLED   4   /* Latency tolerance messages */
 
+/*
+ * Feature selectors from Table 9-8 USB Power Delivery spec
+ */
+#define USB_DEVICE_BATTERY_WAKE_MASK   40
+#define USB_DEVICE_OS_IS_PD_AWARE  41
+#define USB_DEVICE_POLICY_MODE 42
+#define USB_PORT_PR_SWAP   43
+#define USB_PORT_GOTO_MIN  44
+#define USB_PORT_RETURN_POWER  45
+#define USB_PORT_ACCEPT_PD_REQUEST 46
+#define USB_PORT_REJECT_PD_REQUEST 47
+#define USB_PORT_PORT_PD_RESET 48
+#define USB_PORT_C_PORT_PD_CHANGE  49
+#define USB_PORT_CABLE_PD_RESET50
+#define USB_DEVICE_CHARGING_POLICY 54
+
 /**
  * struct usb_ctrlrequest - SETUP data for a USB device control request
  * @bRequestType: matches the USB bmRequestType field
-- 
2.1.4

--
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 v4]adding definitions for USB PD to headers

[Oliver Neukum]

This patch set adds to definitions from chapter 9 of
the Power Delivery spec to the header files so that they can be better
used. It is a conservative selection and adds only a minimum.
--
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: Bug ID: 114111

[Peter Maciejko]

Wrong link address, sry.

The script has following content: http://pastebin.com/isyaWeVP

Best regards,
PM

On Thu, Mar 10, 2016 at 4:32 PM, Peter Maciejko  wrote:
> Guys, I guess I found workaround.
>
> System: Fedora 23.
> Kernel: 4.4.3-300 (Fedora repo).
>
> Firstable, I am not be able to shutdown my computer without quirks. I
> have to add:
>
> xhci_hcd.quirks=270336 (XHCI_SPURIOUS_WAKEUP and XHCI_SPURIOUS_REBOOT quirks)
>
> or
>
> xhci_hcd.quirks=262144 (XHCI_SPURIOUS_WAKEUP)
>
> to GRUB_CMDLINE_LINUX.
>
> xhci_hcd.quirks=8192 (XHCI_SPURIOUS_REBOOT quirks) does not work.
>
> But this is not enough, I had to prepare script that I put into
> /lib/systemd/system-shutdown/ as unbind-xhci-devices.shutdown. Power
> off works fine now, but I still think that this is serious bug, which
> should be fixed as fast as possible. Power off does not work if I try
> use only quirks or only script. It does not matter which quirks(270336
> or 262144) I use with my script, power off works fine. BTW, after this
> trick, mouse clicking no longer initiate boot process until monitor is
> enabled after proper shutdown, as well.
>
> The script has following content: http://pastebin.com/QNGVXHkP
>
> Do you need anything else, except lsusb, lspci and lsusb -t that I
> have already sent to you?
>
> Best regards,
> PM
>
> On Wed, Mar 9, 2016 at 9:09 PM, Peter Maciejko  wrote:
>> The problem is a bit complicated, that is why I put a video containing
>> a description of the problem on kernel bug tracker.
>>
>> Motherboard: ASRock H87 PRO 4
>> Processor: Intel Core i5 4570 Haswell
>>
>> If USB 3.0 controller is enabled in UEFI Setup then three, maybe four
>> seconds after shutdown, my computer starts boot process by itself.
>> After reboot, which is initiated by me through command line or
>> graphical environment - it doesnt matter - poweroff works fine but
>> only once. Besides, even if poweroff works fine, until my monitor is
>> enabled after proper shutdown, I can start boot process by clicking
>> left mouse button/right mouse button/scroll. If I disable my monitor
>> and then enable it again, then obviously I cant boot computer by
>> clicking. All "Power on" options are disabled in UEFI.
>>
>> If USB 3.0 controller is disabled in UEFI Setup then poweroff works
>> fine, but after proper shutdown, until monitor is enabled, I can light
>> up my mouse's and keyboard's leds by clicking same as I described
>> above.
>>
>>
>> My mouse and keyboard are connected to the computer through monitor's USB 
>> ports.
>>
>>
>> Monitor: Dell U2414H
>> Mouse: SteelSeries Rival
>> Keyboard: CM Storm Quickfire Rapid-I
>>
>> Sry for my bad english, I hope you will understand me, if not - then
>> watch movie pls.
>>
>> Link to the movie:
>> https://www.dropbox.com/s/isr9i0yojgnlb6n/20160309_133125.mp4?dl=0
>> lsusb: http://pastebin.com/uhGAnCLU
>> lsusb -t: http://pastebin.com/iY1HZrER
>> lspci: http://pastebin.com/phz6if1U
>>
>> I have tried:
>> xhci_hcd.quirks=270336 //XHCI_SPURIOUS_WAKEUP and XHCI_SPURIOUS_REBOOT
>> xhci_hcd.quirks=8192 //XHCI_SPURIOUS_REBOOT
>> xhci_hcd.quirks=262144 //XHCI_SPURIOUS_WAKEUP
>>
>> Nothing helped, computer keeps rebooting after shutdown. I cant
>> remember when my rig works fine last time - it is very frustrating, I
>> am a little bit tired of this :)
>> I have now Fedora 23 with 4.4.3 kernel, but I have also tried
>> branded/vanilla 4.4.4 and obviously it didnt help.
>> On Ubuntu 14.04 and the latest 3.16, bug persists too - my girlfriend
>> has same rig and same issue.
>>
>> There is two situations when poweroff works ALMOST fine:
>> 1. Keyboard/Remote Power On and Mouse Power On is enabled in uefi, but
>> then poweroff process hangs for few seconds and I can boot computer by
>> clicking, until monitor is enabled after shutdown.
>> 2. USB 3.0 Controller is disabled (still can light up
>> keyboard's/mouse's leds until monitor is enabled after shutdown).
>>
>> Best regards guys and thanks for your effort,
>> PM
>>
>> On Wed, Mar 9, 2016 at 6:40 PM, Felipe Ferreri Tonello
>>  wrote:
>>> Hi,
>>>
>>> On 09/03/16 17:12, Greg KH wrote:
 On Wed, Mar 09, 2016 at 05:47:00PM +0100, Peter Maciejko wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=114111
>
> Bug ID: 114111
> Summary: Reboot after shutdown, when USB 3.0 controller is enabled

 Please send us the full details so we don't have to dig them out on the
 website...
>>>
>>> There is absolutely no description of the bug besides the Summary, which
>>> by itself is not saying much.
>>>
>>> Peter, can you describe exactly was is going on?
>>>
>>> --
>>> Felipe
--
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: ftdi_sio: Add support for ICP DAS I-756xU devices

[Josh Boyer]

A Fedora user reports that the ftdi_sio driver works properly for the
ICP DAS I-7561U device.  Further, the user manual for these devices
instructs users to load the driver and add the ids using the sysfs
interface.

Add support for these in the driver directly so that the devices work
out of the box instead of needing manual configuration.

Reported-by: 
CC: stable 
Signed-off-by: Josh Boyer 
---
 drivers/usb/serial/ftdi_sio.c | 4 
 drivers/usb/serial/ftdi_sio_ids.h | 8 
 2 files changed, 12 insertions(+)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 8c660ae401d8..b61f12160d37 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1004,6 +1004,10 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, CHETCO_SEASMART_DISPLAY_PID) },
{ USB_DEVICE(FTDI_VID, CHETCO_SEASMART_LITE_PID) },
{ USB_DEVICE(FTDI_VID, CHETCO_SEASMART_ANALOG_PID) },
+   /* ICP DAS I-756xU devices */
+   { USB_DEVICE(ICPDAS_VID, ICPDAS_I7560U_PID) },
+   { USB_DEVICE(ICPDAS_VID, ICPDAS_I7561U_PID) },
+   { USB_DEVICE(ICPDAS_VID, ICPDAS_I7563U_PID) },
{ } /* Terminating entry */
 };
 
diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
b/drivers/usb/serial/ftdi_sio_ids.h
index a84df2513994..a4ec24ce6a11 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -872,6 +872,14 @@
 #define NOVITUS_BONO_E_PID 0x6010
 
 /*
+ * ICPDAS I-756*U devices
+ */
+#define ICPDAS_VID 0x1b5c
+#define ICPDAS_I7560U_PID  0x0103
+#define ICPDAS_I7561U_PID  0x0104
+#define ICPDAS_I7563U_PID  0x0105
+
+/*
  * RT Systems programming cables for various ham radios
  */
 #define RTSYSTEMS_VID  0x2100  /* Vendor ID */
-- 
2.5.0

--
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 1/3] dm9601: enable EP3 interrupt

[Peter Korsgaard]

> "Joseph" == Joseph CHANG  writes:

 > Enable chip's EP3 interrupt to get the link-up notify soon
 > immediately.

Sorry, what do you mean about 'soon immediately'?

 > +
 > +/* Always return 8-bytes data to host per interrupt-interval */
 > +dm_write_reg(dev, DM_USB_CTRL, USB_CTRL_EP3ACK);

Why would we want to do that instead of the current setup that afaik
only returns data when the link status changes?

-- 
Bye, Peter Korsgaard
--
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: [RFC 7/7] USB: usbatm: avoid fragile and inefficient snprintf use

[Greg Kroah-Hartman]

On Tue, Mar 08, 2016 at 01:01:09PM -0800, Joe Perches wrote:
> On Tue, 2016-03-08 at 21:40 +0100, Rasmus Villemoes wrote:
> > Passing overlapping source and destination is fragile, and in this
> > case we can even simplify the code and avoid the huge stack buffer by
> > using the %p extension for printing a small hex dump.
> []
> > diff --git a/drivers/usb/atm/usbatm.c b/drivers/usb/atm/usbatm.c
> []
> > @@ -1331,15 +1331,12 @@ MODULE_VERSION(DRIVER_VERSION);
> >  static int usbatm_print_packet(struct usbatm_data *instance,
> >        const unsigned char *data, int len)
> >  {
> > -   unsigned char buffer[256];
> > -   int i = 0, j = 0;
> > +   int i, j;
> >  
> >     for (i = 0; i < len;) {
> > -   buffer[0] = '\0';
> > -   sprintf(buffer, "%.3d :", i);
> > -   for (j = 0; (j < 16) && (i < len); j++, i++)
> > -   sprintf(buffer, "%s %2.2x", buffer, data[i]);
> > -   dev_dbg(>usb_intf->dev, "%s", buffer);
> > +   j = min(16, len-i);
> > +   dev_dbg(>usb_intf->dev, "%.3d : %*ph", i, j, data + 
> > i);
> > +   i += j;
> >     }
> >     return i;
> >  }
> 
> Maybe use print_dump_hex_debug()

Yes, please use that instead.
--
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 v3 3/7] usb: mux: add common code for Intel dual role port mux

[Greg Kroah-Hartman]

On Thu, Mar 10, 2016 at 01:39:43PM +0100, Oliver Neukum wrote:
> On Tue, 2016-03-08 at 15:53 +0800, Lu Baolu wrote:
> 
> > diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
> > b/Documentation/ABI/testing/sysfs-bus-platform
> > index 5172a61..a2261cb 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-platform
> > +++ b/Documentation/ABI/testing/sysfs-bus-platform
> > @@ -18,3 +18,18 @@ Description:
> > devices to opt-out of driver binding using a driver_override
> > name such as "none".  Only a single driver may be specified in
> > the override, there is no support for parsing delimiters.
> > +
> > +What:  /sys/bus/platform/devices/.../intel_mux
> 
> Hi,
> 
> is there any reason to call this "intel_mux"? We want a common interface
> for such things. So how about "role_mux" or "master_slave_mux"?

I agree, don't make this intel specific, as it shouldn't be.

--
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 v3 3/7] usb: mux: add common code for Intel dual role port mux

[Greg Kroah-Hartman]

On Tue, Mar 08, 2016 at 03:53:44PM +0800, Lu Baolu wrote:
> Several Intel PCHs and SOCs have an internal mux that is used to
> share one USB port between device controller and host controller.
> 
> A usb port mux could be abstracted as the following elements:
> 1) mux state: HOST or PERIPHERAL;
> 2) an extcon cable which triggers the change of mux state between
>HOST and PERIPHERAL;
> 3) The required action to do the real port switch.
> 
> This patch adds the common code to handle usb port mux. With this
> common code, the individual mux driver, which always is platform
> dependent, could focus on the real operation of mux switch.
> 
> Signed-off-by: Lu Baolu 
> Reviewed-by: Heikki Krogerus 
> Reviewed-by: Felipe Balbi 
> ---
>  Documentation/ABI/testing/sysfs-bus-platform |  15 +++
>  MAINTAINERS  |   7 ++
>  drivers/usb/Kconfig  |   2 +
>  drivers/usb/Makefile |   1 +
>  drivers/usb/mux/Kconfig  |   9 ++
>  drivers/usb/mux/Makefile |   4 +
>  drivers/usb/mux/intel-mux.c  | 166 
> +++
>  include/linux/usb/intel-mux.h|  47 
>  8 files changed, 251 insertions(+)
>  create mode 100644 drivers/usb/mux/Kconfig
>  create mode 100644 drivers/usb/mux/Makefile
>  create mode 100644 drivers/usb/mux/intel-mux.c
>  create mode 100644 include/linux/usb/intel-mux.h
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
> b/Documentation/ABI/testing/sysfs-bus-platform
> index 5172a61..a2261cb 100644
> --- a/Documentation/ABI/testing/sysfs-bus-platform
> +++ b/Documentation/ABI/testing/sysfs-bus-platform
> @@ -18,3 +18,18 @@ Description:
>   devices to opt-out of driver binding using a driver_override
>   name such as "none".  Only a single driver may be specified in
>   the override, there is no support for parsing delimiters.
> +
> +What:/sys/bus/platform/devices/.../intel_mux
> +Date:Febuary 2016
> +Contact: Lu Baolu 
> +Description:
> + In some platforms, a single USB port is shared between a USB 
> host
> + controller and a device controller. A USB mux driver is needed 
> to
> + handle the port mux. intel_mux attribute shows and stores the 
> mux
> + state.
> + For read:
> + 'peripheral' - mux switched to PERIPHERAL controller;
> + 'host'   - mux switched to HOST controller.
> + For write:
> + 'peripheral' - mux will be switched to PERIPHERAL controller;
> + 'host'   - mux will be switched to HOST controller.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c55b37e..a93d26a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11400,6 +11400,13 @@ T:   git 
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
>  S:   Maintained
>  F:   drivers/usb/phy/
>  
> +USB PORT MUX DRIVER
> +M:   Lu Baolu 
> +L:   linux-usb@vger.kernel.org
> +S:   Supported
> +F:   drivers/usb/mux/intel-mux.c
> +F:   include/linux/usb/intel-mux.h
> +
>  USB PRINTER DRIVER (usblp)
>  M:   Pete Zaitcev 
>  L:   linux-usb@vger.kernel.org
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 8ed451d..dbd6620 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -149,6 +149,8 @@ endif # USB
>  
>  source "drivers/usb/phy/Kconfig"
>  
> +source "drivers/usb/mux/Kconfig"
> +
>  source "drivers/usb/gadget/Kconfig"
>  
>  config USB_LED_TRIG
> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
> index dca7856..9a92338 100644
> --- a/drivers/usb/Makefile
> +++ b/drivers/usb/Makefile
> @@ -6,6 +6,7 @@
>  
>  obj-$(CONFIG_USB)+= core/
>  obj-$(CONFIG_USB_SUPPORT)+= phy/
> +obj-$(CONFIG_USB_SUPPORT)+= mux/
>  
>  obj-$(CONFIG_USB_DWC3)   += dwc3/
>  obj-$(CONFIG_USB_DWC2)   += dwc2/
> diff --git a/drivers/usb/mux/Kconfig b/drivers/usb/mux/Kconfig
> new file mode 100644
> index 000..8fedc4f
> --- /dev/null
> +++ b/drivers/usb/mux/Kconfig
> @@ -0,0 +1,9 @@
> +#
> +# USB port mux driver configuration
> +#
> +menu "USB Port MUX drivers"
> +config INTEL_USB_MUX
> + select EXTCON
> + def_bool n

No help text?

> +
> +endmenu
> diff --git a/drivers/usb/mux/Makefile b/drivers/usb/mux/Makefile
> new file mode 100644
> index 000..84f0ae8
> --- /dev/null
> +++ b/drivers/usb/mux/Makefile
> @@ -0,0 +1,4 @@
> +#
> +# Makefile for USB port mux drivers
> +#
> +obj-$(CONFIG_INTEL_USB_MUX)  += intel-mux.o
> diff --git a/drivers/usb/mux/intel-mux.c b/drivers/usb/mux/intel-mux.c
> new file mode 100644
> index 000..b243758
> --- /dev/null
> +++ b/drivers/usb/mux/intel-mux.c
> @@ -0,0 +1,166 @@
> +/**
> + * mux.c - USB Port Mux 

Re: [PATCH v3 0/7] usb: add support for Intel dual role port mux

[Greg Kroah-Hartman]

On Tue, Mar 08, 2016 at 03:53:41PM +0800, Lu Baolu wrote:
> Intel SOC chips are featured with USB dual role. The host role is
> provided by Intel xHCI IP, and the gadget role is provided by IP
> from designware. Tablet platform designs always share a single
> port for both host and gadget controllers. There is a mux to
> switch the port to the right controller according to the cable
> type. OS needs to provide the callback to control the mux when
> a plug-in event raises. The method to control the mux is platform
> dependent. At least three types of implementation can be found
> across current devices. 1) GPIO pins; 2) a unit which can be
> controlled by memory mapped registers; 3) ACPI ASL code.
> 
> This patch series adds supports for Intel dual role port mux.
> It includes:
> (1) A helper layer on top of extcon for individual mux driver.
> It listens to the USB-HOST extcon cable and call the switch
> call-back when the cable state changes.
> (2) Drivers for GPIO controlled port mux which could be found on
> Baytrail devices. A mfd driver is used to split the GPIOs into
> USB gpio extcon device and a USB mux device. Driver for USB
> gpio extcon device is already in upstream Linux. This patch
> series includes a driver for GPIO USB mux.
> (3) Drivers for USB port mux controlled through memory mapped
> registers and the logic to create the mux device. This type
> of dual role port mux could be found in Cherry Trail and
> Broxton devices.
> 
> Lu Baolu (7):
>   extcon: usb-gpio: add device binding for platform device
>   extcon: usb-gpio: add support for ACPI gpio interface
>   usb: mux: add common code for Intel dual role port mux
>   usb: mux: add driver for Intel gpio controlled port mux
>   usb: mux: add driver for Intel drcfg controlled port mux
>   usb: pci-quirks: add Intel USB drcfg mux device
>   mfd: intel_vuport: Add Intel virtual USB port MFD Driver

You don't describe here what you changed from v2, or even from v1.
Please always be specific, we don't remember what your last submissions
looked like at all...

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 v3 0/7] usb: add support for Intel dual role port mux

[Lu Baolu]

On 03/11/2016 08:03 AM, Greg Kroah-Hartman wrote:
> On Tue, Mar 08, 2016 at 03:53:41PM +0800, Lu Baolu wrote:
>> Intel SOC chips are featured with USB dual role. The host role is
>> provided by Intel xHCI IP, and the gadget role is provided by IP
>> from designware. Tablet platform designs always share a single
>> port for both host and gadget controllers. There is a mux to
>> switch the port to the right controller according to the cable
>> type. OS needs to provide the callback to control the mux when
>> a plug-in event raises. The method to control the mux is platform
>> dependent. At least three types of implementation can be found
>> across current devices. 1) GPIO pins; 2) a unit which can be
>> controlled by memory mapped registers; 3) ACPI ASL code.
>>
>> This patch series adds supports for Intel dual role port mux.
>> It includes:
>> (1) A helper layer on top of extcon for individual mux driver.
>> It listens to the USB-HOST extcon cable and call the switch
>> call-back when the cable state changes.
>> (2) Drivers for GPIO controlled port mux which could be found on
>> Baytrail devices. A mfd driver is used to split the GPIOs into
>> USB gpio extcon device and a USB mux device. Driver for USB
>> gpio extcon device is already in upstream Linux. This patch
>> series includes a driver for GPIO USB mux.
>> (3) Drivers for USB port mux controlled through memory mapped
>> registers and the logic to create the mux device. This type
>> of dual role port mux could be found in Cherry Trail and
>> Broxton devices.
>>
>> Lu Baolu (7):
>>   extcon: usb-gpio: add device binding for platform device
>>   extcon: usb-gpio: add support for ACPI gpio interface
>>   usb: mux: add common code for Intel dual role port mux
>>   usb: mux: add driver for Intel gpio controlled port mux
>>   usb: mux: add driver for Intel drcfg controlled port mux
>>   usb: pci-quirks: add Intel USB drcfg mux device
>>   mfd: intel_vuport: Add Intel virtual USB port MFD Driver
> You don't describe here what you changed from v2, or even from v1.
> Please always be specific, we don't remember what your last submissions
> looked like at all...

I am sorry. I put the change log after file change summary.
I will move it up here next time.

Best regards,
Baolu

>
> 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 v3 0/7] usb: add support for Intel dual role port mux

[Greg Kroah-Hartman]

On Fri, Mar 11, 2016 at 08:20:43AM +0800, Lu Baolu wrote:
> 
> 
> On 03/11/2016 08:03 AM, Greg Kroah-Hartman wrote:
> > On Tue, Mar 08, 2016 at 03:53:41PM +0800, Lu Baolu wrote:
> >> Intel SOC chips are featured with USB dual role. The host role is
> >> provided by Intel xHCI IP, and the gadget role is provided by IP
> >> from designware. Tablet platform designs always share a single
> >> port for both host and gadget controllers. There is a mux to
> >> switch the port to the right controller according to the cable
> >> type. OS needs to provide the callback to control the mux when
> >> a plug-in event raises. The method to control the mux is platform
> >> dependent. At least three types of implementation can be found
> >> across current devices. 1) GPIO pins; 2) a unit which can be
> >> controlled by memory mapped registers; 3) ACPI ASL code.
> >>
> >> This patch series adds supports for Intel dual role port mux.
> >> It includes:
> >> (1) A helper layer on top of extcon for individual mux driver.
> >> It listens to the USB-HOST extcon cable and call the switch
> >> call-back when the cable state changes.
> >> (2) Drivers for GPIO controlled port mux which could be found on
> >> Baytrail devices. A mfd driver is used to split the GPIOs into
> >> USB gpio extcon device and a USB mux device. Driver for USB
> >> gpio extcon device is already in upstream Linux. This patch
> >> series includes a driver for GPIO USB mux.
> >> (3) Drivers for USB port mux controlled through memory mapped
> >> registers and the logic to create the mux device. This type
> >> of dual role port mux could be found in Cherry Trail and
> >> Broxton devices.
> >>
> >> Lu Baolu (7):
> >>   extcon: usb-gpio: add device binding for platform device
> >>   extcon: usb-gpio: add support for ACPI gpio interface
> >>   usb: mux: add common code for Intel dual role port mux
> >>   usb: mux: add driver for Intel gpio controlled port mux
> >>   usb: mux: add driver for Intel drcfg controlled port mux
> >>   usb: pci-quirks: add Intel USB drcfg mux device
> >>   mfd: intel_vuport: Add Intel virtual USB port MFD Driver
> > You don't describe here what you changed from v2, or even from v1.
> > Please always be specific, we don't remember what your last submissions
> > looked like at all...
> 
> I am sorry. I put the change log after file change summary.
> I will move it up here next time.

Ah, totally missed it, sorry about that am not expecting that below a
diffstat.

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 v3 3/7] usb: mux: add common code for Intel dual role port mux

[Lu Baolu]

On 03/11/2016 07:57 AM, Greg Kroah-Hartman wrote:
> On Thu, Mar 10, 2016 at 01:39:43PM +0100, Oliver Neukum wrote:
>> On Tue, 2016-03-08 at 15:53 +0800, Lu Baolu wrote:
>>
>>> diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
>>> b/Documentation/ABI/testing/sysfs-bus-platform
>>> index 5172a61..a2261cb 100644
>>> --- a/Documentation/ABI/testing/sysfs-bus-platform
>>> +++ b/Documentation/ABI/testing/sysfs-bus-platform
>>> @@ -18,3 +18,18 @@ Description:
>>> devices to opt-out of driver binding using a driver_override
>>> name such as "none".  Only a single driver may be specified in
>>> the override, there is no support for parsing delimiters.
>>> +
>>> +What:  /sys/bus/platform/devices/.../intel_mux
>> Hi,
>>
>> is there any reason to call this "intel_mux"? We want a common interface
>> for such things. So how about "role_mux" or "master_slave_mux"?
> I agree, don't make this intel specific, as it shouldn't be.

Sure. I will change it to "port_mux".

>
>

--
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 v2 1/2] usb: host: xhci: add a new quirk XHCI_CLEAR_AC64

[Felipe Balbi]

Hi,

Yoshihiro Shimoda  writes:
> [ text/plain ]
> On some xHCI controllers (e.g. R-Car SoCs), the AC64 bit (bit 0) of
> HCCPARAMS1 is set to 1. However, the xHCs don't support 64-bit
> address memory pointers actually. So, in this case, this driver should
> call dma_set_coherent_mask(dev, DMA_BIT_MASK(32)) in xhci_gen_setup().
> Otherwise, the xHCI controller will be died after a usb device is
> connected if it runs on above 4GB physical memory environment.
>
> So, this patch adds a new quirk XHCI_CLEAR_AC64 to resolve such an issue.
>
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/usb/host/xhci.c | 10 ++
>  drivers/usb/host/xhci.h |  1 +
>  2 files changed, 11 insertions(+)
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index d51ee0c..4b5e979 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -4948,6 +4948,16 @@ int xhci_gen_setup(struct usb_hcd *hcd, 
> xhci_get_quirks_t get_quirks)
>   return retval;
>   xhci_dbg(xhci, "Reset complete\n");
>  
> + /*
> +  * On some xHCI controllers (e.g. R-Car SoCs), the AC64 bit (bit 0)
> +  * of HCCPARAMS1 is set to 1. However, the xHCs don't support 64-bit
> +  * address memory pointers actually. So, this driver clears the AC64
> +  * bit of xhci->hcc_params to call dma_set_coherent_mask(dev,
> +  * DMA_BIT_MASK(32)) in this xhci_gen_setup().
> +  */
> + if (xhci->quirks & XHCI_CLEAR_AC64)
> + xhci->hcc_params &= ~BIT(0);
> +
>   /* Set dma_mask and coherent_dma_mask to 64-bits,
>* if xHC supports 64-bit addressing */
>   if (HCC_64BIT_ADDR(xhci->hcc_params) &&
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index e293e09..1963148 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1641,6 +1641,7 @@ struct xhci_hcd {
>  #define XHCI_PME_STUCK_QUIRK (1 << 20)
>  #define XHCI_MTK_HOST(1 << 21)
>  #define XHCI_SSIC_PORT_UNUSED(1 << 22)
> +#define XHCI_CLEAR_AC64  (1 << 23)

hmm, the quirk isn't really CLEAR_AC64, that's the workaround. How about
calling this XHCI_NO_64BIT_SUPPORT ? or something along those lines.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] usb: host: xhci-plat: fix cannot work if R-Car Gen2/3 run on above 4GB phys

[Felipe Balbi]

Yoshihiro Shimoda  writes:

> [ text/plain ]
> This patch fixes an issue that cannot work if R-Car Gen2/3 run on
> above 4GB physical memory environment to use a quirk XHCI_CLEAR_AC64.
>
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/usb/host/xhci-plat.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 5c15e9b..4dbd56f 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -39,12 +39,19 @@ static const struct xhci_driver_overrides 
> xhci_plat_overrides __initconst = {
>  
>  static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
>  {
> + struct usb_hcd *hcd = xhci_to_hcd(xhci);
> +
>   /*
>* As of now platform drivers don't provide MSI support so we ensure
>* here that the generic code does not try to make a pci_dev from our
>* dev struct in order to setup MSI
>*/
>   xhci->quirks |= XHCI_PLAT;
> +
> + /* Please refer to the xhci.c about the detail of this quirk */

this is an odd comment. It should be okay to state here that RCAR
GEN2/GEN3 lack proper 64BIT support even though register says otherwise.

-- 
balbi


signature.asc
Description: PGP signature

Re: [patch -target tree] usb: gadget: f_tcm: use after free

[Nicholas A. Bellinger]

On Thu, 2016-03-10 at 09:34 +0100, Andrzej Pietrasiewicz wrote:
> Hi Nicholas,
> 
> W dniu 10.03.2016 o 06:19, Nicholas A. Bellinger pisze:
> > Hi Andrzej,
> >
> > On Wed, 2016-03-09 at 13:53 +0100, Andrzej Pietrasiewicz wrote:
> >> Hi Nicholas,
> >>



> >
> > Mmmm, usbg_get_cmd() was missing an explicit memset() after tag lookup.
> >
> > How about the following..?
> >
> > diff --git a/drivers/usb/gadget/function/f_tcm.c 
> > b/drivers/usb/gadget/function/f_tcm.c
> > index e352a31..d4e8a91 100644
> > --- a/drivers/usb/gadget/function/f_tcm.c
> > +++ b/drivers/usb/gadget/function/f_tcm.c
> > @@ -1078,6 +1078,7 @@ static struct usbg_cmd *usbg_get_cmd(struct f_uas *fu,
> >  return ERR_PTR(-ENOMEM);
> >
> >  cmd = &((struct usbg_cmd *)se_sess->sess_cmd_map)[tag];
> > +   memset(cmd, 0, sizeof(*cmd));
> >  cmd->se_cmd.map_tag = tag;
> >  cmd->se_cmd.tag = cmd->tag = scsi_tag;
> >  cmd->fu = fu;
> >
> >
> >
> 
> I tested it. Works for me.

Folding this missing memset() into usb-gadget's percpu_ida conversion
for -v4.

Thanks Andrzej!

--
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] configfs: switch ->default groups to a linked list

[Doug Ledford]

On 02/27/2016 06:22 PM, Nicholas A. Bellinger wrote:
> On Fri, 2016-02-26 at 13:33 +0100, Christoph Hellwig wrote:
>> Replace the current NULL-terminated array of default groups with a linked
>> list.  This gets rid of lots of nasty code to size and/or dynamically
>> allocate the array.
>>
>> While we're at it also provide a conveniant helper to remove the default
>> groups.
>>
>> Signed-off-by: Christoph Hellwig 
>> ---
>>  Documentation/filesystems/configfs/configfs.txt |  11 +-
>>  drivers/infiniband/core/cma_configfs.c  |  31 ++--
>>  drivers/target/iscsi/iscsi_target_configfs.c|  75 +++--
>>  drivers/target/target_core_configfs.c   | 203 
>> +---
>>  drivers/target/target_core_fabric_configfs.c| 194 ++
>>  drivers/target/target_core_internal.h   |   1 -
>>  drivers/target/target_core_stat.c   |  41 ++---
>>  drivers/usb/gadget/configfs.c   |  36 ++---
>>  drivers/usb/gadget/function/f_mass_storage.c|   6 +-
>>  drivers/usb/gadget/function/f_rndis.c   |   1 -
>>  drivers/usb/gadget/function/uvc_configfs.c  | 198 
>> +--
>>  fs/configfs/dir.c   |  44 +++--
>>  fs/configfs/item.c  |   1 +
>>  fs/dlm/config.c |  38 +
>>  fs/ocfs2/cluster/nodemanager.c  |  22 +--
>>  include/linux/configfs.h|  11 +-
>>  include/target/target_core_base.h   |   3 -
>>  17 files changed, 284 insertions(+), 632 deletions(-)
>>
> 
> This is a very nice simplification to drop the long-standing fixed size
> ->default_groups[] usage tree-wide for configfs consumers.
> 
> For the target parts:
> 
> Acked-by: Nicholas Bellinger 

For the (minor) RDMA parts:

Acked-by: Doug Ledford 

> Also, this applies cleanly to target-pending/for-next, so I don't see a
> problem merging it up via your new configfs tree.
> 
> Otherwise let me know, and I'll be happy to merge via target-pending.

Given that it touches target more than anything else, I'm happy to see
it merged through your tree.


-- 
Doug Ledford 
  GPG KeyID: 0E572FDD




signature.asc
Description: OpenPGP digital signature

[PATCH] xhci: fix typo in babble endpoint handling comment

[Rajesh Bhagat]

The 0.95 xHCI spec says that non-control endpoints will be halted if a
babble is detected on a transfer.  The 0.96 xHCI spec says all types of
endpoints will be halted when a babble is detected.  Some hardware that
claims to be 0.95 compliant halts the control endpoint anyway.

Reference: http://www.spinics.net/lists/linux-usb/msg21755.html

Signed-off-by: Rajesh Bhagat 
---
 drivers/usb/host/xhci-ring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 3915657..59841a9 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1768,7 +1768,7 @@ static int xhci_requires_manual_halt_cleanup(struct 
xhci_hcd *xhci,
if (trb_comp_code == COMP_TX_ERR ||
trb_comp_code == COMP_BABBLE ||
trb_comp_code == COMP_SPLIT_ERR)
-   /* The 0.96 spec says a babbling control endpoint
+   /* The 0.95 spec says a babbling control endpoint
 * is not halted. The 0.96 spec says it is.  Some HW
 * claims to be 0.95 compliant, but it halts the control
 * endpoint anyway.  Check if a babble halted the
-- 
2.6.2.198.g614a2ac

--
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] xhci: fix typo in babble endpoint handling comment

[Felipe Balbi]

Rajesh Bhagat  writes:

> [ text/plain ]
> The 0.95 xHCI spec says that non-control endpoints will be halted if a
> babble is detected on a transfer.  The 0.96 xHCI spec says all types of
> endpoints will be halted when a babble is detected.  Some hardware that
> claims to be 0.95 compliant halts the control endpoint anyway.
>
> Reference: http://www.spinics.net/lists/linux-usb/msg21755.html
>
> Signed-off-by: Rajesh Bhagat 

Reviewed-by: Felipe Balbi 

> ---
>  drivers/usb/host/xhci-ring.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 3915657..59841a9 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -1768,7 +1768,7 @@ static int xhci_requires_manual_halt_cleanup(struct 
> xhci_hcd *xhci,
>   if (trb_comp_code == COMP_TX_ERR ||
>   trb_comp_code == COMP_BABBLE ||
>   trb_comp_code == COMP_SPLIT_ERR)
> - /* The 0.96 spec says a babbling control endpoint
> + /* The 0.95 spec says a babbling control endpoint
>* is not halted. The 0.96 spec says it is.  Some HW
>* claims to be 0.95 compliant, but it halts the control
>* endpoint anyway.  Check if a babble halted the
> -- 
> 2.6.2.198.g614a2ac
>
> --
> 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

-- 
balbi


signature.asc
Description: PGP signature