Re: [PATCH] net: qmi_wwan: Add ID for Telewell TW-LTE 4G v2

[Bjørn Mork]

Bernd Wachter  writes:

> There's a new version of the Telewell 4G modem working with, but not
> recognized by this driver. 
>
> Signed-off-by: Bernd Wachter 
> ---
> --- linux-3.15.3/drivers/net/usb/qmi_wwan.c.orig  2014-07-01 
> 21:31:07.0 +0300
> +++ linux-3.15.3/drivers/net/usb/qmi_wwan.c   2014-07-01 20:39:30.0 
> +0300
> @@ -741,6 +741,7 @@ static const struct usb_device_id produc
>   {QMI_FIXED_INTF(0x19d2, 0x1424, 2)},
>   {QMI_FIXED_INTF(0x19d2, 0x1425, 2)},
>   {QMI_FIXED_INTF(0x19d2, 0x1426, 2)},/* ZTE MF91 */
> + {QMI_FIXED_INTF(0x19d2, 0x1428, 2)},/* Telewell TW-LTE 4G v2 */
>   {QMI_FIXED_INTF(0x19d2, 0x2002, 4)},/* ZTE (Vodafone) K3765-Z */
>   {QMI_FIXED_INTF(0x0f3d, 0x68a2, 8)},/* Sierra Wireless MC7700 */
>   {QMI_FIXED_INTF(0x114f, 0x68a2, 8)},/* Sierra Wireless MC7750 */

Acked-by: Bjørn Mork 

Please queue this for stable as well.  Thanks.


Bjørn
--
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 v7 3/3] usb: dwc3: qcom: Add device tree binding

[Ivan T. Ivanov]

Hi, 

On Tue, 2014-07-01 at 14:47 -0500, Rob Herring wrote:
> On Tue, Jul 1, 2014 at 1:01 PM, Andy Gross  wrote:
> > On Tue, Jul 01, 2014 at 12:04:35AM -0500, Rob Herring wrote:



> > 
> >
> >> > +
> >> > +   ranges;
> >> > +
> >> > +   status = "disabled";
> >> > +
> >> > +   dwc3@1100 {
> >> > +   compatible = "snps,dwc3";
> >>
> >> This sub-node is just wrong. Why can't you have a single node with '
> >> "qcom,dwc3", "snps,dwc3" ' for the compatible property? All you are
> >> adding here is clocks. Does the Synopsys block have no clocks?
> >>
> >> I guess this is copied from other broken dwc3 bindings... That doesn't
> >> mean you have to copy it.
> >
> > The dwc3 core does not deal with clocks.  That is why everyone has a 
> > wrapper.
> > That, in addition to pm, has to be handled from the wrapper.  That's my take
> > anyway.  I am sure Felipe can speak more to this.
> 
> That is a Linux driver issue which is irrelevant to the binding.

DWC3 IP core from Synopsys is the same across SoC's (OMAP, Exynos..),
vendors are adding glue IP to provide necessary clocks and voltages. 
I think that the DT bindings properly reflect this fact.

Regards,
Ivan 

> 
> Rob


--
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/2 v2] HID: leds: Use attribute-groups in MSI GT683R driver

[Jiri Kosina]

On Tue, 1 Jul 2014, Bryan Wu wrote:

> Great, I just cherry-picked and applied to my tree
> http://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/commit/?h=for-next&id=f471d9480275796dea2ac7ec249b050e70a2888d

Ok, perfect, thanks. I am marking my 'for-3.17/hid-gt683r' so that it 
wouldn't be contained in the for-linus merge window pile.

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

Re: [PATCH] USB: remove CONFIG_USB_PERSIST from Documentation

[Paul Bolle]

On Tue, 2014-06-24 at 13:19 -0400, Alan Stern wrote:
> On Tue, 24 Jun 2014, Paul Bolle wrote:
> > On Tue, 2014-06-24 at 10:25 -0400, Alan Stern wrote:
> > > Also, that "Later kernels" thing has already arrived.  I believe it was 
> > > implemented in 2.6.35.
> > 
> > How does the kernel currently call the disconnect method? I can't yet
> > say for sure, and it seems silly to send a v2 dropping those lines
> > without actually knowing why they can be dropped.
> 
> In drivers/usb/core/driver.c:usb_resume_complete(), which is called 
> during the final "complete" phase of system suspend, interfaces that 
> were marked for rebinding (because their drivers didn't have proper PM 
> support) get rebound.
> 
> Is that what you wanted to know?

I haven't yet discovered what the link is between rebinding and the
"disconnect" method. I'll have to study that. This is far from urgent,
so that might take me quite some time.

Thanks anyway,


Paul Bolle

--
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: option: Add ID for Telewell TW-LTE 4G v2

[Bernd Wachter]

Add ID of the Telewell 4G v2 hardware to option driver to get legacy
serial interface working


Signed-off-by: Bernd Wachter 
---
--- linux-3.15.3/drivers/usb/serial/option.c.orig   2014-07-02 
12:23:28.0 +0300
+++ linux-3.15.3/drivers/usb/serial/option.c2014-07-02 12:25:16.0 
+0300
@@ -1480,6 +1480,8 @@ static const struct usb_device_id option
.driver_info = (kernel_ulong_t)&net_intf2_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1426, 0xff, 0xff, 
0xff),  /* ZTE MF91 */
.driver_info = (kernel_ulong_t)&net_intf2_blacklist },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1428, 0xff, 0xff, 
0xff),  /* Telewell TW-LTE 4G v2 */
+   .driver_info = (kernel_ulong_t)&net_intf2_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1533, 0xff, 0xff, 
0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1534, 0xff, 0xff, 
0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1535, 0xff, 0xff, 
0xff) },

--
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: use multi input quirk for 22b9:2968

[Wen-chien Jesse Sung]

This device generates ABS_Z and ABS_RX events instead of ABS_X and
ABS_Y.

Signed-off-by: Wen-chien Jesse Sung 
---
 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 6d00bb9..ef1d567 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -323,6 +323,7 @@
 
 #define USB_VENDOR_ID_ETURBOTOUCH  0x22b9
 #define USB_DEVICE_ID_ETURBOTOUCH  0x0006
+#define USB_DEVICE_ID_ETOUBOTOUCH_2968 0x2968
 
 #define USB_VENDOR_ID_EZKEY0x0518
 #define USB_DEVICE_ID_BTC_8193 0x0002
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 59badc1..9c9e4a3 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -49,6 +49,7 @@ static const struct hid_blacklist {
 
{ USB_VENDOR_ID_EMS, USB_DEVICE_ID_EMS_TRIO_LINKER_PLUS_II, 
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_ETURBOTOUCH, USB_DEVICE_ID_ETURBOTOUCH, 
HID_QUIRK_MULTI_INPUT },
+   { USB_VENDOR_ID_ETURBOTOUCH, USB_DEVICE_ID_ETOUBOTOUCH_2968, 
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_GREENASIA, USB_DEVICE_ID_GREENASIA_DUAL_USB_JOYPAD, 
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_PANTHERLORD, 
USB_DEVICE_ID_PANTHERLORD_TWIN_USB_JOYSTICK, HID_QUIRK_MULTI_INPUT | 
HID_QUIRK_SKIP_OUTPUT_REPORTS },
{ USB_VENDOR_ID_PLAYDOTCOM, USB_DEVICE_ID_PLAYDOTCOM_EMS_USBII, 
HID_QUIRK_MULTI_INPUT },
-- 
1.9.1

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

[PATCH v2] Documentation: sysfs-bus-usb: update power/persist description

[Paul Bolle]

There's no power/persist file for hubs. And CONFIG_USB_PERSIST was
removed in v2.6.26. Update the description of power/persist accordingly.
Also remove the line on its default value. It is not entirely correct, as
CONFIG_USB_DEFAULT_PERSIST and the USB_QUIRK_RESET flag influence the
default. It is not needed to understand this file anyhow.

Signed-off-by: Paul Bolle 
---
v2: incorporate Alan's feedback. The clearest way to do that was to not
mention the default value at all. Trying to do handle the default
correctly made the text way too complicated. I hope Alan agrees.

Perhaps the line on hubs should not be added, as the text now states
that device directories "can" contain this file.

 Documentation/ABI/stable/sysfs-bus-usb | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/ABI/stable/sysfs-bus-usb 
b/Documentation/ABI/stable/sysfs-bus-usb
index a6b685724740..e2bc700a6f9c 100644
--- a/Documentation/ABI/stable/sysfs-bus-usb
+++ b/Documentation/ABI/stable/sysfs-bus-usb
@@ -3,13 +3,13 @@ Date: May 2007
 KernelVersion: 2.6.23
 Contact:   Alan Stern 
 Description:
-   If CONFIG_USB_PERSIST is set, then each USB device directory
-   will contain a file named power/persist.  The file holds a
-   boolean value (0 or 1) indicating whether or not the
-   "USB-Persist" facility is enabled for the device.  Since the
-   facility is inherently dangerous, it is disabled by default
-   for all devices except hubs.  For more information, see
-   Documentation/usb/persist.txt.
+   USB device directories can contain a file named power/persist.
+   The file holds a boolean value (0 or 1) indicating whether or
+   not the "USB-Persist" facility is enabled for the device.  For
+   hubs this facility is always enabled and their device
+   directories will not contain this file.
+
+   For more information, see Documentation/usb/persist.txt.
 
 What:  /sys/bus/usb/devices/.../power/autosuspend
 Date:  March 2007
-- 
1.9.3

--
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: DMA over USB

[Peter Stuge]

Raghavendra wrote:
> I have a query regarding DMA(Direct Memory Access) for the usb devices.

USB devices never do DMA.

> As far as Linux is concerned, how the DMA action being taking place for
> USB devices.

It doesn't take place.

> As per my understanding, the USB host controller is taking care of
> the DMA operations.

That's correct. When an URB is submitted by host software the host
controller asks the device for data, and when data arrives from the
device the host controller writes the data into memory using DMA.

> But I require a little more insight into it.

I recommend to study chapters 5 and 8 of the USB 2.0 specification:
http://www.usb.org/developers/docs/usb_20_070113.zip

> Further more, if it is possible for the USB devices, then can this
> support be also extended towards low-end protocols such as I2C or SPI?

Not in the general case. It is possible to develop an I²C or SPI bus
master which is capable of DMA toward the host memory, and to create
a protocol on top of I²C or SPI which allows devices to remote control
the DMA engine in the master, but I'd say that's quite an artificial case.


//Peter
--
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: gadget: f_fs: OS descriptors support

[Andrzej Pietrasiewicz]

Add support for OS descriptors. The new format of descriptors is used,
because the "flags" field is required for extensions. os_count gives
the number of OSDesc[] elements.
The format of descriptors is given in include/uapi/linux/usb/functionfs.h.

For extended properties descriptor the usb_ext_prop_desc structure covers
only a part of a descriptor, because the wPropertyNameLength is unknown
up front.

Signed-off-by: Andrzej Pietrasiewicz 
---
Rebased onto Felipe's testing/next with gadget directory cleanup patches
applied:

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

This is meant for 3.17.

@Michal: I kindly ask for your review. Your comments will be very valuable.

 drivers/usb/gadget/function/f_fs.c  | 345 +++-
 drivers/usb/gadget/function/u_fs.h  |   7 +
 include/uapi/linux/usb/functionfs.h |  87 -
 3 files changed, 432 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 88d6fa2..55c0db7 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -34,6 +34,7 @@
 
 #include "u_fs.h"
 #include "u_f.h"
+#include "u_os_desc.h"
 #include "configfs.h"
 
 #define FUNCTIONFS_MAGIC   0xa647361 /* Chosen by a honest dice roll ;) */
@@ -1644,11 +1645,18 @@ enum ffs_entity_type {
FFS_DESCRIPTOR, FFS_INTERFACE, FFS_STRING, FFS_ENDPOINT
 };
 
+enum ffs_os_desc_type {
+   FFS_OS_DESC, FFS_OS_DESC_EXT_COMPAT, FFS_OS_DESC_EXT_PROP
+};
+
 typedef int (*ffs_entity_callback)(enum ffs_entity_type entity,
   u8 *valuep,
   struct usb_descriptor_header *desc,
   void *priv);
 
+typedef int (*ffs_os_desc_callback)(enum ffs_os_desc_type entity,
+   u8 *valuep, void *data, void *priv);
+
 static int __must_check ffs_do_desc(char *data, unsigned len,
ffs_entity_callback entity, void *priv)
 {
@@ -1855,11 +1863,190 @@ static int __ffs_data_do_entity(enum ffs_entity_type 
type,
return 0;
 }
 
+/*
+ * Process all extended compatibility/extended property descriptors
+ * of a feature descriptor
+ */
+static int __must_check ffs_do_os_desc(char *data, unsigned len, u8 *valuep,
+  u16 feature_count,
+  ffs_os_desc_callback entity, void *priv,
+  struct usb_os_desc_header *desc)
+{
+   int ret;
+   enum ffs_os_desc_type *type = (enum ffs_os_desc_type *)valuep;
+   const unsigned _len = len;
+
+   ENTER();
+
+   /* loop over all ext compat/ext prop descriptors */
+   while (feature_count--) {
+   ret = entity(*type, (u8 *)desc, (void *)data, priv);
+   if (unlikely(ret < 0)) {
+   pr_debug("bad OS descriptor, type: %d\n", *valuep);
+   return ret;
+   }
+   data += ret;
+   len -= ret;
+   }
+   return _len - len;
+}
+
+/* Process a number of complete Feature Descriptors (Ext Compat or Ext Prop) */
+static int __must_check ffs_do_os_descs(unsigned count,
+   char *data, unsigned len,
+   ffs_os_desc_callback entity, void *priv)
+{
+   const unsigned _len = len;
+   unsigned long num = 0;
+
+   ENTER();
+
+   for (;;) {
+   int ret;
+   enum ffs_os_desc_type type;
+   u16 feature_count;
+   struct usb_os_desc_header *desc = (void *)data;
+
+   if (num == count)
+   return _len - len;
+
+   /* Record "descriptor" entity */
+   /*
+* Process dwLength, bcdVersion, wIndex,
+* get b/wCount.
+* Move the data pointer to the beginning of
+* extended compatibilities proper or
+* extended properties proper portions of the
+* data
+*/
+   ret = entity(FFS_OS_DESC, (u8 *)&type, desc, priv);
+   if (unlikely(ret < 0)) {
+   pr_debug("entity OS_DESCRIPTOR(%02lx); ret = %d\n",
+num, ret);
+   return ret;
+   }
+   if (type == FFS_OS_DESC_EXT_COMPAT) {
+   struct usb_ext_compat_desc_header *h =
+   (struct usb_ext_compat_desc_header *)data;
+   feature_count = h->bCount;
+   } else if (type == FFS_OS_DESC_EXT_PROP) {
+   struct usb_ext_prop_desc_header *h = (void *)data;
+
+   feature_count = le16_to_cpu(h->wCount);
+   } else {
+   return -EINVAL;
+   }
+   len -= (ret + 2);
+   da

Re: [PATCH] usb: gadget: f_fs: OS descriptors support

[Peter Stuge]

Andrzej Pietrasiewicz wrote:
> +++ b/include/uapi/linux/usb/functionfs.h
> @@ -33,6 +32,42 @@ struct usb_endpoint_descriptor_no_audio {
..
> +/* MS OS Extended Compatibility Descriptor header */
> +struct usb_ext_compat_desc_header {
> + struct  usb_os_desc_header header;
> + __u8bCount;
> + __u8Reserved;
> +} __attribute__((packed));
> +
> +struct usb_ext_compat_desc {
> + __u8bFirstInterfaceNumber;
> + __u8Reserved1;
> + __u8CompatibleID[8];
> + __u8SubCompatibleID[8];
> + __u8Reserved2[6];
> +};

Shouldn't usb_ext_compat_desc be packed too, like all the others?


//Peter
--
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_fs: OS descriptors support

[Andrzej Pietrasiewicz]

W dniu 02.07.2014 13:04, Peter Stuge pisze:

Andrzej Pietrasiewicz wrote:

+++ b/include/uapi/linux/usb/functionfs.h
@@ -33,6 +32,42 @@ struct usb_endpoint_descriptor_no_audio {

..

+/* MS OS Extended Compatibility Descriptor header */
+struct usb_ext_compat_desc_header {
+   struct  usb_os_desc_header header;
+   __u8bCount;
+   __u8Reserved;
+} __attribute__((packed));
+
+struct usb_ext_compat_desc {
+   __u8bFirstInterfaceNumber;
+   __u8Reserved1;
+   __u8CompatibleID[8];
+   __u8SubCompatibleID[8];
+   __u8Reserved2[6];
+};


Shouldn't usb_ext_compat_desc be packed too, like all the others?


Good catch, thanks!

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 v3 5/7] ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss

[Roger Quadros]

Sekhar,

On 06/18/2014 02:19 PM, Rajendra Nayak wrote:
> On Wednesday 18 June 2014 04:40 PM, Roger Quadros wrote:
>> + Nishant and Rajendra for review.
>>
>> On 05/05/2014 12:54 PM, Roger Quadros wrote:
>>> Add the sysconfig class bits for the Super Speed USB
>>> controllers
>>>
>>> CC: Paul Walmsley 
>>> Signed-off-by: Roger Quadros 
> 
> verified against TRM version vP, looks good to me.
> Reviewed-by: Rajendra Nayak 

Could you please give your Tested-by tag for this? Then we can take this into 
3.16-rc.
Thanks.

cheers,
-roger

> 
>>> ---
>>>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 12 
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
>>> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> index 810c205..067d322 100644
>>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> @@ -1731,8 +1731,20 @@ static struct omap_hwmod dra7xx_uart6_hwmod = {
>>>   *
>>>   */
>>>  
>>> +static struct omap_hwmod_class_sysconfig dra7xx_usb_otg_ss_sysc = {
>>> +   .rev_offs   = 0x,
>>> +   .sysc_offs  = 0x0010,
>>> +   .sysc_flags = (SYSC_HAS_DMADISABLE | SYSC_HAS_MIDLEMODE |
>>> +  SYSC_HAS_SIDLEMODE),
>>> +   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
>>> +  SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
>>> +  MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
>>> +   .sysc_fields= &omap_hwmod_sysc_type2,
>>> +};
>>> +
>>>  static struct omap_hwmod_class dra7xx_usb_otg_ss_hwmod_class = {
>>> .name   = "usb_otg_ss",
>>> +   .sysc   = &dra7xx_usb_otg_ss_sysc,
>>>  };
>>>  
>>>  /* usb_otg_ss1 */
>>>
>>
> 

--
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: [PATCHv2 0/6] phy: simplified phy lookup

[Kishon Vijay Abraham I]

Hi,

On Thursday 05 June 2014 06:51 PM, Vivek Gautam wrote:
> Hi Heikki,
> 
> 
> On Thu, Jun 5, 2014 at 6:22 PM, Heikki Krogerus
>  wrote:
>> Hi,
>>
>> So the idea with these is that they should help to make it possible to
>> request phys without caring about how they are mapped to the
>> consumers, meaning, was is the mapping done in DT, ACPI, etc. Mapping
>> phys to consumers can be now done with lookups similarly how clocks
>> can be mapped in clkdev.c.
>>
>> Vivek needs to handle the phys of dwc3 also in xhci driver on
>> Exynos5420 SoC, so I'm resending these now.
> 
> Thank you so much for your efforts.
> This will greatly help me in preparing the patches for PHY tuning.

Can I get Tested-by please?

Cheers
Kishon
--
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: DMA over USB

[Raghavendra]

Thank you for responding Peter,

Raghavendra wrote:

I have a query regarding DMA(Direct Memory Access) for the usb devices.

USB devices never do DMA.


As far as Linux is concerned, how the DMA action being taking place for
USB devices.

It doesn't take place.


As per my understanding, the USB host controller is taking care of
the DMA operations.

That's correct. When an URB is submitted by host software the host
controller asks the device for data, and when data arrives from the
device the host controller writes the data into memory using DMA.
As I understand, the USB host controllers(on x86) are basically PCI 
devices and PCI devices are capable of bus mastering, thus performing DMA.
But, if we take the case of a non x86 platform (say ARM), the USB host 
controller may or may not be capable of performing DMA. In that case how 
far the cases are valid if we try to push the data from the USB device 
through DMA
For example, if we take the case of a simple USB mouse 
driver(usbmouse.c), it uses DMA to obtain the data. What if this driver 
is associated with a host controller which doesn’t have the support for 
DMA. What will happen in that scenario?


Is there any mechanism to check that?



But I require a little more insight into it.

I recommend to study chapters 5 and 8 of the USB 2.0 specification:
http://www.usb.org/developers/docs/usb_20_070113.zip


Further more, if it is possible for the USB devices, then can this
support be also extended towards low-end protocols such as I2C or SPI?

Not in the general case. It is possible to develop an I²C or SPI bus
master which is capable of DMA toward the host memory, and to create
a protocol on top of I²C or SPI which allows devices to remote control
the DMA engine in the master, but I'd say that's quite an artificial case.


//Peter



---
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
---

--
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 5/6] phy: omap-usb2: Balance pm_runtime_enable() on probe failure

[Roger Quadros]

If probe fails then we need to call pm_runtime_disable() to balance
out the previous pm_runtime_enable() call. Else it will cause
unbalanced pm_runtime_enable() call in the succeding probe call.

This anomaly was observed when the call to devm_phy_create() failed
with -EPROBE_DEFER.

Signed-off-by: Roger Quadros 
---
 drivers/phy/phy-omap-usb2.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 7007c11..c6f9809 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -265,15 +265,19 @@ static int omap_usb2_probe(struct platform_device *pdev)
pm_runtime_enable(phy->dev);
 
generic_phy = devm_phy_create(phy->dev, &ops, NULL);
-   if (IS_ERR(generic_phy))
+   if (IS_ERR(generic_phy)) {
+   pm_runtime_disable(phy->dev);
return PTR_ERR(generic_phy);
+   }
 
phy_set_drvdata(generic_phy, phy);
 
phy_provider = devm_of_phy_provider_register(phy->dev,
of_phy_simple_xlate);
-   if (IS_ERR(phy_provider))
+   if (IS_ERR(phy_provider)) {
+   pm_runtime_disable(phy->dev);
return PTR_ERR(phy_provider);
+   }
 
phy->wkupclk = devm_clk_get(phy->dev, "wkupclk");
if (IS_ERR(phy->wkupclk)) {
-- 
1.8.3.2

--
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 6/6] ARM: dts: dra7-evm: Add regulator information to USB2 PHYs

[Roger Quadros]

The ldousb_reg regulator provides power to the USB1 and USB2
High Speed PHYs.

Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/dra7-evm.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 8308954..50f8022 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -496,3 +496,11 @@
};
};
 };
+
+&usb2_phy1 {
+   phy-supply = <&ldousb_reg>;
+};
+
+&usb2_phy2 {
+   phy-supply = <&ldousb_reg>;
+};
-- 
1.8.3.2

--
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/6] phy: core: Fix error path in phy_create()

[Roger Quadros]

Prevent resources from being freed twice in case device_add() call
fails within phy_create(). Also use ida_simple_remove() instead of
ida_remove() as we had used ida_simple_get() to allocate the ida.

Signed-off-by: Roger Quadros 
---
 drivers/phy/phy-core.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index c64a2f3..49c4465 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -614,8 +614,9 @@ struct phy *phy_create(struct device *dev, const struct 
phy_ops *ops,
return phy;
 
 put_dev:
-   put_device(&phy->dev);
-   ida_remove(&phy_ida, phy->id);
+   put_device(&phy->dev);  /* calls phy_release() which frees resources */
+   return ERR_PTR(ret);
+
 free_phy:
kfree(phy);
return ERR_PTR(ret);
@@ -799,7 +800,7 @@ static void phy_release(struct device *dev)
 
phy = to_phy(dev);
dev_vdbg(dev, "releasing '%s'\n", dev_name(dev));
-   ida_remove(&phy_ida, phy->id);
+   ida_simple_remove(&phy_ida, phy->id);
kfree(phy);
 }
 
-- 
1.8.3.2

--
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 1/6] ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on

[Roger Quadros]

After clarification from the hardware team it was found that
this 1.8V PHY supply can't be switched OFF when SoC is Active.
It can only be switched off when in PORz (power on reset).

This patch is required for proper functionality of USB, SATA
and PCIe on DRA7-evm.

CC: Rajendra Nayak 
CC: Tero Kristo 
Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/dra7-evm.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4adc280..8308954 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -240,6 +240,7 @@
regulator-name = "ldo3";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-always-on;
regulator-boot-on;
};
 
-- 
1.8.3.2

--
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/6] phy: core: Support regulator supply for PHY power

[Roger Quadros]

Some PHYs can be powered by an external power regulator.
e.g. USB_HS PHY on DRA7 SoC. Make the PHY core support a
power regulator.

Signed-off-by: Roger Quadros 
---
 drivers/phy/phy-core.c  | 32 
 include/linux/phy/phy.h |  2 ++
 2 files changed, 34 insertions(+)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 49c4465..d817107 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static struct class *phy_class;
 static DEFINE_MUTEX(phy_provider_mutex);
@@ -226,6 +227,12 @@ int phy_power_on(struct phy *phy)
if (!phy)
return 0;
 
+   if (phy->pwr) {
+   ret = regulator_enable(phy->pwr);
+   if (ret)
+   return ret;
+   }
+
ret = phy_pm_runtime_get_sync(phy);
if (ret < 0 && ret != -ENOTSUPP)
return ret;
@@ -247,6 +254,8 @@ int phy_power_on(struct phy *phy)
 out:
mutex_unlock(&phy->mutex);
phy_pm_runtime_put_sync(phy);
+   if (phy->pwr)
+   regulator_disable(phy->pwr);
 
return ret;
 }
@@ -272,6 +281,9 @@ int phy_power_off(struct phy *phy)
mutex_unlock(&phy->mutex);
phy_pm_runtime_put(phy);
 
+   if (phy->pwr)
+   regulator_disable(phy->pwr);
+
return 0;
 }
 EXPORT_SYMBOL_GPL(phy_power_off);
@@ -588,6 +600,16 @@ struct phy *phy_create(struct device *dev, const struct 
phy_ops *ops,
goto free_phy;
}
 
+   /* phy-supply */
+   phy->pwr = regulator_get_optional(dev, "phy");
+   if (IS_ERR(phy->pwr)) {
+   if (PTR_ERR(phy->pwr) == -EPROBE_DEFER) {
+   ret = -EPROBE_DEFER;
+   goto free_ida;
+   }
+   phy->pwr = NULL;
+   }
+
device_initialize(&phy->dev);
mutex_init(&phy->mutex);
 
@@ -617,6 +639,9 @@ put_dev:
put_device(&phy->dev);  /* calls phy_release() which frees resources */
return ERR_PTR(ret);
 
+free_ida:
+   ida_simple_remove(&phy_ida, phy->id);
+
 free_phy:
kfree(phy);
return ERR_PTR(ret);
@@ -664,6 +689,10 @@ EXPORT_SYMBOL_GPL(devm_phy_create);
 void phy_destroy(struct phy *phy)
 {
pm_runtime_disable(&phy->dev);
+
+   if (phy->pwr)
+   regulator_put(phy->pwr);
+
device_unregister(&phy->dev);
 }
 EXPORT_SYMBOL_GPL(phy_destroy);
@@ -800,6 +829,9 @@ static void phy_release(struct device *dev)
 
phy = to_phy(dev);
dev_vdbg(dev, "releasing '%s'\n", dev_name(dev));
+   if (phy->pwr)
+   regulator_put(phy->pwr);
+
ida_simple_remove(&phy_ida, phy->id);
kfree(phy);
 }
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 2760744..9a86945 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct phy;
 
@@ -65,6 +66,7 @@ struct phy {
int init_count;
int power_count;
struct phy_attrsattrs;
+   struct regulator*pwr;
 };
 
 /**
-- 
1.8.3.2

--
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 4/6] phy: core: Add phy-supply to DT binding documentation

[Roger Quadros]

phy-supply is a phandle to the regulator that provides power to the
PHY. This regulator is managed during the PHY power on/off sequence
by the phy core driver.

Signed-off-by: Roger Quadros 
---
 Documentation/devicetree/bindings/phy/phy-bindings.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt 
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
index 8ae844f..2aa1840 100644
--- a/Documentation/devicetree/bindings/phy/phy-bindings.txt
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -10,6 +10,10 @@ Required Properties:
provider can use the values in cells to find the appropriate
PHY.
 
+Optional Properties:
+phy-supply:Phandle to a regulator that provides power to the PHY. This
+   regulator will be managed during the PHY power on/off sequence.
+
 For example:
 
 phys: phy {
-- 
1.8.3.2

--
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 0/6] omap: phy: dra7-evm PHY fixes for 3.16

[Roger Quadros]

Hi,

On DRA7-evm, the VDDA_1V8_PHY supply must be always-on for proper functioning
of the PHYs on the SoC.

The 3.3V USB supply (ldousb_reg) can be turned OFF when the High Speed USB PHYs
are not in use. We add regulator support in the PHY framework core to manage
the PHY's regulator during PHY power on/off.

Finally we add the 3.3V regulator information to the USB2 PHYs.

This series should get the USB and SATA working again on 3.16 on DRA7-evm.

cheers,
-roger

---
Roger Quadros (6):
  ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on
  phy: core: Fix error path in phy_create()
  phy: core: Support regulator supply for PHY power
  phy: core: Add phy-supply to DT binding documentation
  phy: omap-usb2: Balance pm_runtime_enable() on probe failure
  ARM: dts: dra7-evm: Add regulator information to USB2 PHYs

 .../devicetree/bindings/phy/phy-bindings.txt   |  4 +++
 arch/arm/boot/dts/dra7-evm.dts |  9 +
 drivers/phy/phy-core.c | 39 --
 drivers/phy/phy-omap-usb2.c|  8 +++--
 include/linux/phy/phy.h|  2 ++
 5 files changed, 57 insertions(+), 5 deletions(-)

-- 
1.8.3.2

--
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] HID: use multi input quirk for 22b9:2968

[Sergei Shtylyov]

Hello.

On 07/02/2014 02:04 PM, Wen-chien Jesse Sung wrote:


This device generates ABS_Z and ABS_RX events instead of ABS_X and
ABS_Y.



Signed-off-by: Wen-chien Jesse Sung 
---
  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 6d00bb9..ef1d567 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -323,6 +323,7 @@

  #define USB_VENDOR_ID_ETURBOTOUCH 0x22b9
  #define USB_DEVICE_ID_ETURBOTOUCH 0x0006
+#define USB_DEVICE_ID_ETOUBOTOUCH_2968 0x2968


   Not ETURBOTOUCH?

WBR, 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] usb: gadget: f_fs: OS descriptors support

[David Laight]

From: Andrzej Pietrasiewicz
> Sent: 02 July 2014 12:20
> To: linux-usb@vger.kernel.org; Michal Nazarewicz; Felipe Balbi; Greg 
> Kroah-Hartman; Marek Szyprowski
> Subject: Re: [PATCH] usb: gadget: f_fs: OS descriptors support
> 
> W dniu 02.07.2014 13:04, Peter Stuge pisze:
> > Andrzej Pietrasiewicz wrote:
> >> +++ b/include/uapi/linux/usb/functionfs.h
> >> @@ -33,6 +32,42 @@ struct usb_endpoint_descriptor_no_audio {
> > ..
> >> +/* MS OS Extended Compatibility Descriptor header */
> >> +struct usb_ext_compat_desc_header {
> >> +  struct  usb_os_desc_header header;
> >> +  __u8bCount;
> >> +  __u8Reserved;
> >> +} __attribute__((packed));
> >> +
> >> +struct usb_ext_compat_desc {
> >> +  __u8bFirstInterfaceNumber;
> >> +  __u8Reserved1;
> >> +  __u8CompatibleID[8];
> >> +  __u8SubCompatibleID[8];
> >> +  __u8Reserved2[6];
> >> +};
> >
> > Shouldn't usb_ext_compat_desc be packed too, like all the others?
> >
> Good catch, thanks!

In this case it is completely pointless - all the fields are byte aligned.

Alternatively it shouldn't be 'packed', and a full audit of the
other structures done to determine which ones can ever be misaligned
and then determine whether that should actually be allowed.

David



--
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/6] phy: core: Support regulator supply for PHY power

[Sergei Shtylyov]

Hello.

On 07/02/2014 04:03 PM, Roger Quadros wrote:


Some PHYs can be powered by an external power regulator.
e.g. USB_HS PHY on DRA7 SoC. Make the PHY core support a
power regulator.



Signed-off-by: Roger Quadros 
---
  drivers/phy/phy-core.c  | 32 
  include/linux/phy/phy.h |  2 ++
  2 files changed, 34 insertions(+)



diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 49c4465..d817107 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c

[...]

@@ -664,6 +689,10 @@ EXPORT_SYMBOL_GPL(devm_phy_create);
  void phy_destroy(struct phy *phy)
  {
pm_runtime_disable(&phy->dev);
+
+   if (phy->pwr)
+   regulator_put(phy->pwr);


   regulator_put() already handles NULL pointer.


+
device_unregister(&phy->dev);
  }
  EXPORT_SYMBOL_GPL(phy_destroy);
@@ -800,6 +829,9 @@ static void phy_release(struct device *dev)

phy = to_phy(dev);
dev_vdbg(dev, "releasing '%s'\n", dev_name(dev));
+   if (phy->pwr)
+   regulator_put(phy->pwr);


   Same comment here.


+
ida_simple_remove(&phy_ida, phy->id);
kfree(phy);
  }


WBR, 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: DMA over USB

[David Laight]

From: Raghavendra
> Thank you for responding Peter,
> > Raghavendra wrote:
> >> I have a query regarding DMA(Direct Memory Access) for the usb devices.
> > USB devices never do DMA.
> >
> >> As far as Linux is concerned, how the DMA action being taking place for
> >> USB devices.
> > It doesn't take place.
> >
> >> As per my understanding, the USB host controller is taking care of
> >> the DMA operations.
> > That's correct. When an URB is submitted by host software the host
> > controller asks the device for data, and when data arrives from the
> > device the host controller writes the data into memory using DMA.
> As I understand, the USB host controllers(on x86) are basically PCI
> devices and PCI devices are capable of bus mastering, thus performing DMA.
> But, if we take the case of a non x86 platform (say ARM), the USB host
> controller may or may not be capable of performing DMA. In that case how
> far the cases are valid if we try to push the data from the USB device
> through DMA
> For example, if we take the case of a simple USB mouse
> driver(usbmouse.c), it uses DMA to obtain the data. What if this driver
> is associated with a host controller which doesnt have the support for
> DMA. What will happen in that scenario?

It is extremely unlikely that a USB host controller will be unable to
do DMA - in the sense that it transfers USB data to/from host memory
buffers.

However the host buffer addresses are not made available to the USB
target hardware - so it can't select which buffer is used.

It is just possible that the memory the host controller uses is resident
on (say) a PCI card. But the normal bandwidth requirements make that
unlikely.
Another exception might be for slow devices (keyboard/mouse) where the
amount of data is very limited - but that won't be a host.

David

Re: [Patch v7 3/3] usb: dwc3: qcom: Add device tree binding

[Arnd Bergmann]

On Wednesday 02 July 2014 11:43:25 Ivan T. Ivanov wrote:
> > > 
> > >
> > >> > +
> > >> > +   ranges;
> > >> > +
> > >> > +   status = "disabled";
> > >> > +
> > >> > +   dwc3@1100 {
> > >> > +   compatible = "snps,dwc3";
> > >>
> > >> This sub-node is just wrong. Why can't you have a single node with '
> > >> "qcom,dwc3", "snps,dwc3" ' for the compatible property? All you are
> > >> adding here is clocks. Does the Synopsys block have no clocks?
> > >>
> > >> I guess this is copied from other broken dwc3 bindings... That doesn't
> > >> mean you have to copy it.
> > >
> > > The dwc3 core does not deal with clocks.  That is why everyone has a 
> > > wrapper.
> > > That, in addition to pm, has to be handled from the wrapper.  That's my 
> > > take
> > > anyway.  I am sure Felipe can speak more to this.
> > 
> > That is a Linux driver issue which is irrelevant to the binding.
> 
> DWC3 IP core from Synopsys is the same across SoC's (OMAP, Exynos..),
> vendors are adding glue IP to provide necessary clocks and voltages. 
> I think that the DT bindings properly reflect this fact.

Not really. The proper way to do this is to have a single node that
lists multiple compatible strings from the most specific (per SoC variant)
to most generic (the underlying IP core) and have all properties in it.

We have seen many cases before where it later turned out that whatever
feature people thought was SoC specific actually was common to all
of them and that we later want to change the code to handle it in a
common way, and to reflect it in the common binding. The clocks that
Rob mentioned are one example of that.

If you have a binding that separates one IP block into two device nodes,
you cannot later adapt the common driver to be more generic and handle
all sorts of SoCs. See the usb-ehci.txt for an example: it started out
really simple but the generic driver has been extended multiple times
to the point where it handles a lot of SoCs by default.

Arnd
--
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_fs: OS descriptors support

[Michal Nazarewicz]

On Wed, Jul 02 2014, Andrzej Pietrasiewicz  wrote:
> Add support for OS descriptors. The new format of descriptors is used,
> because the "flags" field is required for extensions. os_count gives
> the number of OSDesc[] elements.
> The format of descriptors is given in include/uapi/linux/usb/functionfs.h.
>
> For extended properties descriptor the usb_ext_prop_desc structure covers
> only a part of a descriptor, because the wPropertyNameLength is unknown
> up front.
>
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
> Rebased onto Felipe's testing/next with gadget directory cleanup patches
> applied:
>
> http://www.spinics.net/lists/linux-usb/msg109928.html
>
> This is meant for 3.17.
>
> @Michal: I kindly ask for your review. Your comments will be very
> valuable.

For now I've only skimmed over binding code.

>
>  drivers/usb/gadget/function/f_fs.c  | 345 
> +++-
>  drivers/usb/gadget/function/u_fs.h  |   7 +
>  include/uapi/linux/usb/functionfs.h |  87 -
>  3 files changed, 432 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/f_fs.c 
> b/drivers/usb/gadget/function/f_fs.c
> index 88d6fa2..55c0db7 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -34,6 +34,7 @@
>
>  #include "u_fs.h"
>  #include "u_f.h"
> +#include "u_os_desc.h"
>  #include "configfs.h"
>
>  #define FUNCTIONFS_MAGIC 0xa647361 /* Chosen by a honest dice roll ;) */
> @@ -1644,11 +1645,18 @@ enum ffs_entity_type {
>   FFS_DESCRIPTOR, FFS_INTERFACE, FFS_STRING, FFS_ENDPOINT
>  };
>
> +enum ffs_os_desc_type {
> + FFS_OS_DESC, FFS_OS_DESC_EXT_COMPAT, FFS_OS_DESC_EXT_PROP
> +};
> +
>  typedef int (*ffs_entity_callback)(enum ffs_entity_type entity,
>  u8 *valuep,
>  struct usb_descriptor_header *desc,
>  void *priv);
>
> +typedef int (*ffs_os_desc_callback)(enum ffs_os_desc_type entity,
> + u8 *valuep, void *data, void *priv);
> +
>  static int __must_check ffs_do_desc(char *data, unsigned len,
>   ffs_entity_callback entity, void *priv)
>  {
> @@ -1855,11 +1863,190 @@ static int __ffs_data_do_entity(enum ffs_entity_type 
> type,
>   return 0;
>  }
>
> +/*
> + * Process all extended compatibility/extended property descriptors
> + * of a feature descriptor
> + */
> +static int __must_check ffs_do_os_desc(char *data, unsigned len, u8 *valuep,
> +u16 feature_count,
> +ffs_os_desc_callback entity, void *priv,
> +struct usb_os_desc_header *desc)

The name of this function has to be changed.  Perhaps
ffs_do_os_single_desc?  It took me embarrassing amount of time to figure
out that ffs_do_os_descs and ffs_do_os_desc are different functions.

> +{
> + int ret;
> + enum ffs_os_desc_type *type = (enum ffs_os_desc_type *)valuep;

Read the value already:

enum ffs_os_desc_type type = *(enum ffs_os_desc_type *)valuep;

> + const unsigned _len = len;
> +
> + ENTER();
> +
> + /* loop over all ext compat/ext prop descriptors */
> + while (feature_count--) {
> + ret = entity(*type, (u8 *)desc, (void *)data, priv);

You don't have to cast to void *.  It's implicit.

> + if (unlikely(ret < 0)) {
> + pr_debug("bad OS descriptor, type: %d\n", *valuep);
> + return ret;
> + }
> + data += ret;
> + len -= ret;
> + }
> + return _len - len;
> +}
> +
> +/* Process a number of complete Feature Descriptors (Ext Compat or Ext Prop) 
> */
> +static int __must_check ffs_do_os_descs(unsigned count,
> + char *data, unsigned len,
> + ffs_os_desc_callback entity, void *priv)
> +{
> + const unsigned _len = len;
> + unsigned long num = 0;
> +
> + ENTER();
> +
> + for (;;) {
> + int ret;
> + enum ffs_os_desc_type type;
> + u16 feature_count;
> + struct usb_os_desc_header *desc = (void *)data;

if (len < sizeof(*desc))
return -EINVAL;

With the union addition that I've mentioned near the end of the email,
this would also handle checking if bCount/wCount is there.

> +
> + if (num == count)
> + return _len - len;

for (num = 0; num < count; ++num) {
…;
}
return _len - len;

> +
> + /* Record "descriptor" entity */
> + /*
> +  * Process dwLength, bcdVersion, wIndex,
> +  * get b/wCount.
> +  * Move the data pointer to the beginning of
> +  * extended compatibilities proper or
> +  * extended properties proper portions of the
> +  * data
> + 

Re: [PATCH] HID: use multi input quirk for 22b9:2968

[Jesse Sung]

2014-07-02 20:19 GMT+08:00 Sergei Shtylyov :
> Hello.
>
>
> On 07/02/2014 02:04 PM, Wen-chien Jesse Sung wrote:
>
>> This device generates ABS_Z and ABS_RX events instead of ABS_X and
>> ABS_Y.
>
>
>> Signed-off-by: Wen-chien Jesse Sung 
>> ---
>>   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 6d00bb9..ef1d567 100644
>> --- a/drivers/hid/hid-ids.h
>> +++ b/drivers/hid/hid-ids.h
>> @@ -323,6 +323,7 @@
>>
>>   #define USB_VENDOR_ID_ETURBOTOUCH 0x22b9
>>   #define USB_DEVICE_ID_ETURBOTOUCH 0x0006
>> +#define USB_DEVICE_ID_ETOUBOTOUCH_2968 0x2968
>
>
>Not ETURBOTOUCH?

Oops... Let me fix that...

Thanks,
Jesse
--
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/6] ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on

[Nishanth Menon]

On 07/02/2014 07:03 AM, Roger Quadros wrote:
> After clarification from the hardware team it was found that
> this 1.8V PHY supply can't be switched OFF when SoC is Active.
> It can only be switched off when in PORz (power on reset).

I dont think folks know the reasoning why hardware team decided that
the voltage rail cannot be switched off -> I suggest adding the
following information as well.

Since isolation is not present in the design for these PHY IPs to
allow for the PHY rail to be switched off, there is a very high risk
of IP reliability and additional leakage paths which can result in
additional power consumption.

Only scenario where this rail can be switched off is part of Power on
reset sequencing, but it needs to be kept always-on during operation.

> 
> This patch is required for proper functionality of USB, SATA
> and PCIe on DRA7-evm.
> 
> CC: Rajendra Nayak 
> CC: Tero Kristo 
> Signed-off-by: Roger Quadros 
> ---
>  arch/arm/boot/dts/dra7-evm.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
> index 4adc280..8308954 100644
> --- a/arch/arm/boot/dts/dra7-evm.dts
> +++ b/arch/arm/boot/dts/dra7-evm.dts
> @@ -240,6 +240,7 @@
>   regulator-name = "ldo3";
>   regulator-min-microvolt = <180>;
>   regulator-max-microvolt = <180>;
> + regulator-always-on;
>   regulator-boot-on;
>   };
>  
> 


-- 
Regards,
Nishanth Menon
--
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 v2] HID: use multi input quirk for 22b9:2968

[Wen-chien Jesse Sung]

This device generates ABS_Z and ABS_RX events instead of ABS_X and
ABS_Y.

Signed-off-by: Wen-chien Jesse Sung 
---
 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 6d00bb9..e15a90b 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -323,6 +323,7 @@
 
 #define USB_VENDOR_ID_ETURBOTOUCH  0x22b9
 #define USB_DEVICE_ID_ETURBOTOUCH  0x0006
+#define USB_DEVICE_ID_ETURBOTOUCH_2968 0x2968
 
 #define USB_VENDOR_ID_EZKEY0x0518
 #define USB_DEVICE_ID_BTC_8193 0x0002
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 59badc1..e193167 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -49,6 +49,7 @@ static const struct hid_blacklist {
 
{ USB_VENDOR_ID_EMS, USB_DEVICE_ID_EMS_TRIO_LINKER_PLUS_II, 
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_ETURBOTOUCH, USB_DEVICE_ID_ETURBOTOUCH, 
HID_QUIRK_MULTI_INPUT },
+   { USB_VENDOR_ID_ETURBOTOUCH, USB_DEVICE_ID_ETURBOTOUCH_2968, 
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_GREENASIA, USB_DEVICE_ID_GREENASIA_DUAL_USB_JOYPAD, 
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_PANTHERLORD, 
USB_DEVICE_ID_PANTHERLORD_TWIN_USB_JOYSTICK, HID_QUIRK_MULTI_INPUT | 
HID_QUIRK_SKIP_OUTPUT_REPORTS },
{ USB_VENDOR_ID_PLAYDOTCOM, USB_DEVICE_ID_PLAYDOTCOM_EMS_USBII, 
HID_QUIRK_MULTI_INPUT },
-- 
1.9.1

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

Re: [PATCH] usb: gadget: f_fs: OS descriptors support

[Michal Nazarewicz]

On Wed, Jul 02 2014, David Laight  wrote:
> From: Andrzej Pietrasiewicz
>> Sent: 02 July 2014 12:20
>> To: linux-usb@vger.kernel.org; Michal Nazarewicz; Felipe Balbi; Greg 
>> Kroah-Hartman; Marek Szyprowski
>> Subject: Re: [PATCH] usb: gadget: f_fs: OS descriptors support
>> 
>> W dniu 02.07.2014 13:04, Peter Stuge pisze:
>> > Andrzej Pietrasiewicz wrote:
>> >> +++ b/include/uapi/linux/usb/functionfs.h
>> >> @@ -33,6 +32,42 @@ struct usb_endpoint_descriptor_no_audio {
>> > ..
>> >> +/* MS OS Extended Compatibility Descriptor header */
>> >> +struct usb_ext_compat_desc_header {
>> >> + struct  usb_os_desc_header header;
>> >> + __u8bCount;
>> >> + __u8Reserved;
>> >> +} __attribute__((packed));
>> >> +
>> >> +struct usb_ext_compat_desc {
>> >> + __u8bFirstInterfaceNumber;
>> >> + __u8Reserved1;
>> >> + __u8CompatibleID[8];
>> >> + __u8SubCompatibleID[8];
>> >> + __u8Reserved2[6];
>> >> +};
>> >
>> > Shouldn't usb_ext_compat_desc be packed too, like all the others?
>> >
>> Good catch, thanks!
>
> In this case it is completely pointless - all the fields are byte aligned.
>
> Alternatively it shouldn't be 'packed', and a full audit of the
> other structures done to determine which ones can ever be misaligned
> and then determine whether that should actually be allowed.

All of the structures describe a wire protocol, whether we thing the
structure can be allowed or not is inconsequential since that's what is
being used.  All of those structures must be packed.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
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

Chipidea gadget unplug/disconnect event

[Michael Grzeschik]

Hi Peter,

Is it possible to get the chipidea to generate an
event on udc unplugging?

I see the code path in ci_udc_vbus_session of udc.c to
trigger such an event, but unfortunately it
was never possible to run into that code.

The function ci_otg_work in otg.c is prepared to do that
in case the irq got triggered by OTGSC_BSVIS bit change.

This is true for plugging, but never happened to be called on
unplugging. Is there anything missing to get this working? Or is this
completely impossible by the core? I was already fiddling around with
the other irq cases OTGSC_*IE, but never got anything useful.

I am working on the imx25 otg capable SoC.


Regards,
Michael


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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: am335x: linux 3.16-rc3: USB DMA issue

[Yegor Yefremov]

On Tue, Jul 1, 2014 at 5:37 PM, Ezequiel García
 wrote:
> On 1 July 2014 12:07, Yegor Yefremov  wrote:
> [..]
>>
>> What can be done with these error messages:
>>
>> of_get_named_gpiod_flags: can't parse gpios property of node
>> '/ocp/usb@4740/usb-phy@47401300[0]'
>> 47401300.usb-phy supply vcc not found, using dummy regulator
>> musb-hdrc musb-hdrc.0.auto: Failed to request rx1.
>> musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
>> platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral
>> of_get_named_gpiod_flags: can't parse gpios property of node
>> '/ocp/usb@4740/usb-phy@47401b00[0]'
>> 47401b00.usb-phy supply vcc not found, using dummy regulator
>> musb-hdrc musb-hdrc.1.auto: Failed to request rx1.
>> musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517
>> platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral
>> couldn't find an available UDC
>>
>
> The above are typical deferal messages. Have you tried building
> everything as a module or moving the DMA devicetree node so it's
> probed earlier?
>
> But I'm not sure it's related to the problem you are seeing.

Compiling as a module helped. Thanks.

Yegor
--
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: am335x: linux 3.16-rc3: USB DMA issue

[Yegor Yefremov]

On Tue, Jul 1, 2014 at 5:43 PM, Bin Liu  wrote:
> On Tue, Jul 1, 2014 at 10:37 AM, Ezequiel García
>  wrote:
>> On 1 July 2014 12:07, Yegor Yefremov  wrote:
>> [..]
>>>
>>> What can be done with these error messages:
>>>
>>> of_get_named_gpiod_flags: can't parse gpios property of node
>>> '/ocp/usb@4740/usb-phy@47401300[0]'
>>> 47401300.usb-phy supply vcc not found, using dummy regulator
>>> musb-hdrc musb-hdrc.0.auto: Failed to request rx1.
>>> musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
>>> platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral
>>> of_get_named_gpiod_flags: can't parse gpios property of node
>>> '/ocp/usb@4740/usb-phy@47401b00[0]'
>>> 47401b00.usb-phy supply vcc not found, using dummy regulator
>>> musb-hdrc musb-hdrc.1.auto: Failed to request rx1.
>>> musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517
>>> platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral
>>> couldn't find an available UDC
>>>
>>
>> The above are typical deferal messages. Have you tried building
>> everything as a module or moving the DMA devicetree node so it's
>> probed earlier?
>>
>> But I'm not sure it's related to the problem you are seeing.
>
> It might be ZLP related. Daniel's patch "dma: cppi41: handle 0-length
> packets" might solve it.

Have applied the patch, but it didn't help. Compiling the drivers as a
module help for now.

Yegor
--
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_fs: OS descriptors support

[David Laight]

From: Michal Nazarewicz
...
> > Alternatively it shouldn't be 'packed', and a full audit of the
> > other structures done to determine which ones can ever be misaligned
> > and then determine whether that should actually be allowed.
> 
> All of the structures describe a wire protocol, whether we thing the
> structure can be allowed or not is inconsequential since that's what is
> being used.  All of those structures must be packed.

That just isn't true.
Just because a structure maps a protocol packet doesn't mean it has
to be 'packed'.
The TCP stack doesn't mark anything 'packed'.
It relies on the ethernet driver correctly aligning receive messages.

There is a significant cost is accessing a 32bit field from an aligned
offset in a packed structure on every cpu that can't itself perform
misaligned transfers, this is about everything except vax, x86 and
some very recent arm chips (windows was never doing to run on arm
without hardware support for misaligned transfers).

Not the least of the reasons for hardware not supporting misaligned
transfers is the difficulty with faults on writes that cross page
boundaries (or require software TLB lookups).

David

RE: DMA over USB

[Alan Stern]

On Wed, 2 Jul 2014, David Laight wrote:

> From: Raghavendra
> > Thank you for responding Peter,
> > > Raghavendra wrote:
> > >> I have a query regarding DMA(Direct Memory Access) for the usb devices.
> > > USB devices never do DMA.
> > >
> > >> As far as Linux is concerned, how the DMA action being taking place for
> > >> USB devices.
> > > It doesn't take place.
> > >
> > >> As per my understanding, the USB host controller is taking care of
> > >> the DMA operations.
> > > That's correct. When an URB is submitted by host software the host
> > > controller asks the device for data, and when data arrives from the
> > > device the host controller writes the data into memory using DMA.
> > As I understand, the USB host controllers(on x86) are basically PCI
> > devices and PCI devices are capable of bus mastering, thus performing DMA.
> > But, if we take the case of a non x86 platform (say ARM), the USB host
> > controller may or may not be capable of performing DMA.

That's right.

> > In that case how
> > far the cases are valid if we try to push the data from the USB device
> > through DMA
> > For example, if we take the case of a simple USB mouse
> > driver(usbmouse.c), it uses DMA to obtain the data.

DMA gets used if the host controller supports it.

> > What if this driver
> > is associated with a host controller which doesnt have the support for
> > DMA. What will happen in that scenario?

Then DMA isn't used.  PIO gets used instead.

> It is extremely unlikely that a USB host controller will be unable to
> do DMA - in the sense that it transfers USB data to/from host memory
> buffers.

There are plenty of USB host controllers that can't do DMA.  The 
kernel has to take responsibility for transferring data between the 
controller memory and the host memory, using PIO.

> However the host buffer addresses are not made available to the USB
> target hardware - so it can't select which buffer is used.
> 
> It is just possible that the memory the host controller uses is resident
> on (say) a PCI card. But the normal bandwidth requirements make that
> unlikely.

Host controllers always have data buffers.

> Another exception might be for slow devices (keyboard/mouse) where the
> amount of data is very limited - but that won't be a host.

Alan Stern

--
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 0/3] Tegra USB probe order issue fix

[Alan Stern]

On Wed, 2 Jul 2014, Tuomas Tynkkynen wrote:

> Hi all,
> 
> This series fixes a probe order issue with the Tegra EHCI driver.
> Basically, the register area of the 1st USB controller contains some
> registers that are global to all of the controllers, but that are also
> cleared when reset is asserted to the 1st controller. So if (say) the
> 3rd controller would be the first one to finish probing successfully,
> then the reset that happens during the 1st controller's probe would
> result in broken USB. So the before doing anything with the USB HW,
> we should reset the 1st controller once, and then never ever reset
> it again.

This sounds very much like the sort of thing that ought to be described 
in DT.  It is a hardware dependence, and DT exists for the purpose of 
describing the hardware.

Alan Stern

--
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/8] CLK: ti: dra7: Initialize USB_DPLL

[Tero Kristo]

On 03/07/2014 03:09 PM, Roger Quadros wrote:

USB_DPLL must be initialized and locked at boot so that
USB modules can work.

Also program USB_DLL_M2 output to half rate.

CC: Mike Turquette 
CC: Tero Kristo 
Signed-off-by: Roger Quadros 
---
  drivers/clk/ti/clk-7xx.c | 11 +++
  1 file changed, 11 insertions(+)


Hi,

Resurrecting this patch, as it seems the clock-parenting stuff via DT 
hasn't really moved that much forward.


Thus, this patch has been now queued for 3.17, thanks.

-Tero



diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 9977653..f89f3c2 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -18,6 +18,7 @@

  #define DRA7_DPLL_ABE_DEFFREQ 361267200
  #define DRA7_DPLL_GMAC_DEFFREQ10
+#define DRA7_DPLL_USB_DEFFREQ  96000


  static struct ti_dt_clk dra7xx_clks[] = {
@@ -328,5 +329,15 @@ int __init dra7xx_dt_clk_init(void)
if (rc)
pr_err("%s: failed to configure GMAC DPLL!\n", __func__);

+   dpll_ck = clk_get_sys(NULL, "dpll_usb_ck");
+   rc = clk_set_rate(dpll_ck, DRA7_DPLL_USB_DEFFREQ);
+   if (rc)
+   pr_err("%s: failed to configure USB DPLL!\n", __func__);
+
+   dpll_ck = clk_get_sys(NULL, "dpll_usb_m2_ck");
+   rc = clk_set_rate(dpll_ck, DRA7_DPLL_USB_DEFFREQ/2);
+   if (rc)
+   pr_err("%s: failed to set USB_DPLL M2 OUT\n", __func__);
+
return rc;
  }



--
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: remove CONFIG_USB_PERSIST from Documentation

[Alan Stern]

On Wed, 2 Jul 2014, Paul Bolle wrote:

> On Tue, 2014-06-24 at 13:19 -0400, Alan Stern wrote:
> > On Tue, 24 Jun 2014, Paul Bolle wrote:
> > > On Tue, 2014-06-24 at 10:25 -0400, Alan Stern wrote:
> > > > Also, that "Later kernels" thing has already arrived.  I believe it was 
> > > > implemented in 2.6.35.
> > > 
> > > How does the kernel currently call the disconnect method? I can't yet
> > > say for sure, and it seems silly to send a v2 dropping those lines
> > > without actually knowing why they can be dropped.
> > 
> > In drivers/usb/core/driver.c:usb_resume_complete(), which is called 
> > during the final "complete" phase of system suspend, interfaces that 
> > were marked for rebinding (because their drivers didn't have proper PM 
> > support) get rebound.
> > 
> > Is that what you wanted to know?
> 
> I haven't yet discovered what the link is between rebinding and the
> "disconnect" method. I'll have to study that. This is far from urgent,
> so that might take me quite some time.

Rebinding means unbinding followed by binding.  The disconnect method 
gets called during unbinding.  The detailed call chain is:

usb_resume_complete ->
rebind_marked_interfaces -> 
usb_rebind_intf ->
usb_forced_unbind_intf ->
usb_driver_release_interface ->
device_release_driver ->
__device_release_driver ->
usb_unbind_interface ->
disconnect.

Alan Stern

--
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] Documentation: sysfs-bus-usb: update power/persist description

[Alan Stern]

On Wed, 2 Jul 2014, Paul Bolle wrote:

> There's no power/persist file for hubs. And CONFIG_USB_PERSIST was
> removed in v2.6.26. Update the description of power/persist accordingly.
> Also remove the line on its default value. It is not entirely correct, as
> CONFIG_USB_DEFAULT_PERSIST and the USB_QUIRK_RESET flag influence the
> default. It is not needed to understand this file anyhow.
> 
> Signed-off-by: Paul Bolle 
> ---
> v2: incorporate Alan's feedback. The clearest way to do that was to not
> mention the default value at all. Trying to do handle the default
> correctly made the text way too complicated. I hope Alan agrees.
> 
> Perhaps the line on hubs should not be added, as the text now states
> that device directories "can" contain this file.
> 
>  Documentation/ABI/stable/sysfs-bus-usb | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/ABI/stable/sysfs-bus-usb 
> b/Documentation/ABI/stable/sysfs-bus-usb
> index a6b685724740..e2bc700a6f9c 100644
> --- a/Documentation/ABI/stable/sysfs-bus-usb
> +++ b/Documentation/ABI/stable/sysfs-bus-usb
> @@ -3,13 +3,13 @@ Date:   May 2007
>  KernelVersion:   2.6.23
>  Contact: Alan Stern 
>  Description:
> - If CONFIG_USB_PERSIST is set, then each USB device directory
> - will contain a file named power/persist.  The file holds a
> - boolean value (0 or 1) indicating whether or not the
> - "USB-Persist" facility is enabled for the device.  Since the
> - facility is inherently dangerous, it is disabled by default
> - for all devices except hubs.  For more information, see
> - Documentation/usb/persist.txt.
> + USB device directories can contain a file named power/persist.
> + The file holds a boolean value (0 or 1) indicating whether or
> + not the "USB-Persist" facility is enabled for the device.  For
> + hubs this facility is always enabled and their device
> + directories will not contain this file.
> +
> + For more information, see Documentation/usb/persist.txt.
>  
>  What:/sys/bus/usb/devices/.../power/autosuspend
>  Date:March 2007
> 

Acked-by: Alan Stern 

--
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/6] ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on

[Roger Quadros]

On 07/02/2014 04:05 PM, Nishanth Menon wrote:
> On 07/02/2014 07:03 AM, Roger Quadros wrote:
>> After clarification from the hardware team it was found that
>> this 1.8V PHY supply can't be switched OFF when SoC is Active.
>> It can only be switched off when in PORz (power on reset).
> 
> I dont think folks know the reasoning why hardware team decided that
> the voltage rail cannot be switched off -> I suggest adding the
> following information as well.
> 
> Since isolation is not present in the design for these PHY IPs to
> allow for the PHY rail to be switched off, there is a very high risk
> of IP reliability and additional leakage paths which can result in
> additional power consumption.
> 
> Only scenario where this rail can be switched off is part of Power on
> reset sequencing, but it needs to be kept always-on during operation.

This sort of information should be in the TRM instead, but doesn't harm to be 
in the commit message so I'll do that.
Thanks.

cheers,
-roger
> 
>>
>> This patch is required for proper functionality of USB, SATA
>> and PCIe on DRA7-evm.
>>
>> CC: Rajendra Nayak 
>> CC: Tero Kristo 
>> Signed-off-by: Roger Quadros 
>> ---
>>  arch/arm/boot/dts/dra7-evm.dts | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
>> index 4adc280..8308954 100644
>> --- a/arch/arm/boot/dts/dra7-evm.dts
>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>> @@ -240,6 +240,7 @@
>>  regulator-name = "ldo3";
>>  regulator-min-microvolt = <180>;
>>  regulator-max-microvolt = <180>;
>> +regulator-always-on;
>>  regulator-boot-on;
>>  };
>>  
>>
> 
> 

--
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 0/3] Tegra USB probe order issue fix

[Stephen Warren]

On 07/02/2014 08:02 AM, Alan Stern wrote:
> On Wed, 2 Jul 2014, Tuomas Tynkkynen wrote:
> 
>> Hi all,
>>
>> This series fixes a probe order issue with the Tegra EHCI driver.
>> Basically, the register area of the 1st USB controller contains some
>> registers that are global to all of the controllers, but that are also
>> cleared when reset is asserted to the 1st controller. So if (say) the
>> 3rd controller would be the first one to finish probing successfully,
>> then the reset that happens during the 1st controller's probe would
>> result in broken USB. So the before doing anything with the USB HW,
>> we should reset the 1st controller once, and then never ever reset
>> it again.
> 
> This sounds very much like the sort of thing that ought to be described 
> in DT.  It is a hardware dependence, and DT exists for the purpose of 
> describing the hardware.

DT is more about describing the HW, not how SW has to use the HW.
probe() ordering is a SW issue, not a HW description. It's driver
knowledge that the HW resets have to run in a certain order, and if the
driver didn't actually reset the HW ever (but rather, re-programmed all
registers so reset was never needed), then order wouldn't be relevant

DT certainly doesn't have any mechanism for describing probe order or
anything like that, although you can fake it out by adding phandles
between nodes, and having SW wait for the driver for the referenced node
to probe first. That won't work here though, since there's no guarantee
that the USB1 node will actually be enabled (that USB port might not be
hooked up on the board, hence the DT node will be disabled), so we can't
rely on a driver for it ever appearing.
--
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 v7 3/3] usb: dwc3: qcom: Add device tree binding

[Felipe Balbi]

Hi,

On Wed, Jul 02, 2014 at 02:48:17PM +0200, Arnd Bergmann wrote:
> On Wednesday 02 July 2014 11:43:25 Ivan T. Ivanov wrote:
> > > > 
> > > >
> > > >> > +
> > > >> > +   ranges;
> > > >> > +
> > > >> > +   status = "disabled";
> > > >> > +
> > > >> > +   dwc3@1100 {
> > > >> > +   compatible = "snps,dwc3";
> > > >>
> > > >> This sub-node is just wrong. Why can't you have a single node with '
> > > >> "qcom,dwc3", "snps,dwc3" ' for the compatible property? All you are
> > > >> adding here is clocks. Does the Synopsys block have no clocks?
> > > >>
> > > >> I guess this is copied from other broken dwc3 bindings... That doesn't
> > > >> mean you have to copy it.
> > > >
> > > > The dwc3 core does not deal with clocks.  That is why everyone has a 
> > > > wrapper.

everyone has a wrapper for several others reasons. PM from the point of
view of the Synopsys IP is *completely* different from PM from the point
of view the $current_soc. The wrapper helps abstract that. Currently,
there's little PM implemented in the driver, but when we get to
implementing the nice features Synopsys has given us (hibernation, for
instance) it will start to be aparent why the driver was split like
that.

> > > > That, in addition to pm, has to be handled from the wrapper.  That's my 
> > > > take
> > > > anyway.  I am sure Felipe can speak more to this.
> > > 
> > > That is a Linux driver issue which is irrelevant to the binding.
> > 
> > DWC3 IP core from Synopsys is the same across SoC's (OMAP, Exynos..),
> > vendors are adding glue IP to provide necessary clocks and voltages. 
> > I think that the DT bindings properly reflect this fact.
> 
> Not really. The proper way to do this is to have a single node that
> lists multiple compatible strings from the most specific (per SoC variant)
> to most generic (the underlying IP core) and have all properties in it.
> 
> We have seen many cases before where it later turned out that whatever
> feature people thought was SoC specific actually was common to all
> of them and that we later want to change the code to handle it in a
> common way, and to reflect it in the common binding. The clocks that
> Rob mentioned are one example of that.
> 
> If you have a binding that separates one IP block into two device nodes,
> you cannot later adapt the common driver to be more generic and handle
> all sorts of SoCs. See the usb-ehci.txt for an example: it started out
> really simple but the generic driver has been extended multiple times
> to the point where it handles a lot of SoCs by default.

The fact is that you _DO_ have *TWO* IP blocks. The synopsys DWC3 is one
IP and the wrapper is another IP which adapts the synopsys IP to the
SoC's integration context.

From the SoC point of view, the device only needs one (or maybe two)
clocks, an IRQ line, etc... The wrapper then, sometimes, enables that
particular memory region, enables IRQs and generates several other
clocks which are needed for proper operation of the IP.

Having this sort of "bridge" or "glue" driver also helps *HUGELY* in
different PM methodologies different SoCs use. I certainly don't want
any clock API calls in my dwc3 driver when I'm running on top of a PCI
bus on an intel platform. Likewise, I don't want any pci_enable_device()
calls in my dwc3 driver when I'm running on OMAP/Exynos/Qcom/etc.

Now, you guys just decided to give crap to the authors for no aparent
reason. If you really want to describe the HW then every single clock
node and every single voltage rail would have to be described but that
would just create a whole bunch of fixed clocks and fixed regulators
which have no way of being controlled whatsoever and just waste memory
due to several other instances of such drivers being needed.

It's pointless to continue discussing if we should have one clock node
or two clock nodes. If the wrapper doesn't need an interface clock, it
just doesn't need an interface clock and it's not up to us to start
*GUESSING* that it maybe has both clock inputs tied to the same clock
node if that's not what's written in the documentation. Sure, Qcom folks
could ask their HW designers, but what would that give us in practice ?
Nothing, not a single damn benefit.

So can we just move on from this pointless discussion now ?

cheers

-- 
balbi


signature.asc
Description: Digital signature

[PATCH][RFC] USB: zerocopy support for usbfs

[Stefan Klug]

Hi everybody,
in short: The attached patch adds zerocopy support to the usbfs driver.
I tested it on x86 and on a globalscale mirabox ARM board. Until now it 
works

quite nice and I'd love to get some comments and feedback on the patch.

Longer version: The usbfs driver does not support direct data transfers 
from the controller
to user-memory. For several use-cases (in my case USB3 Vision cameras 
pushing up to 360MB/s)
the copy operation from kernel to user-space results in a lot of 
unnecessary CPU overhead
especially on small embedded devices. I measured a decrease in CPU usage 
from 44% to 22% on

a the mirabox.

This patch implements zerocopy beside the existing code paths, so it is 
easy to disable

zerocopy at runtime and to directly compare the CPU usage.
To disable zerocopy just do an
echo 1 > /sys/module/usbcore/parameters/usbfs_disable_zerocopy
and to reenable it
echo 0 > /sys/module/usbcore/parameters/usbfs_disable_zerocopy

On modern desktop systems the change in CPU usage is quite low so this 
mostly affects

smaller embedded devices.

Implementation details:
The patch only touches drivers/usb/core/devio.c.
In procy_do_submiturb(), it is checked if zerocopy is allowed. This is 
currently a rough
check which compares the number of required pages to 
ps->dev->bus->sg_tablesize.

I don't know if there is more to check there.
Then the user memory provided inside the usbdevfs_urb structure is 
pinned to

physical memory using get_user_pages_fast().
All the user pages are added to the scatter-gather list and the logic 
continues as before.
In copy_urb_data_to_user() the pages are marked with 
set_page_dirty_lock() if the transfer

 was a zerocopy one.
In free_async() the pinned pages are released, if the transfer was a 
zerocopy one.


Questions/Notes:
- I'm quite unhappy with the added member async::is_user_mem. Is there a 
better place

  where I could store this information?
- I had a look at some other drivers using the get_user_pages -> 
sg_set_page -> page_cache_release

  technique and didn't see any special code to handle corner cases.
  Are there corner cases? - Like usb controllers not supporting the 
whole memory etc. ?

- In the kernel log I see messages like:
  xhci_hcd :00:14.0: WARN Event TRB for slot 4 ep 8 with no TDs queued?
  after enabling zerocopy. Any idea where this might come from?

This patch should cleanly apply to the current master (3.16-rc2)

Kind regards
Stefan

Signed-off-by: Stefan Klug 
---

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 257876e..c97d1ec 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -4,6 +4,7 @@
  *  devio.c  --  User space communication with USB devices.
  *
  *  Copyright (C) 1999-2000  Thomas Sailer (sai...@ife.ee.ethz.ch)
+ *  Copyright (C) 2014  Stefan Klug (stefan.k...@baslerweb.com)
  *
  *  This program is free software; you can redistribute it and/or 
modify
  *  it under the terms of the GNU General Public License as 
published by

@@ -30,6 +31,7 @@
  *04.01.2000   0.2   Turned into its own filesystem
  *30.09.2005   0.3   Fix user-triggerable oops in async URB delivery
  * (CAN-2005-3055)
+ *07.05.2014   0.4   Added zerocopy support
  */

 /*/
@@ -52,6 +54,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "usb.h"

@@ -94,6 +97,9 @@ struct async {
 u32 secid;
 u8 bulk_addr;
 u8 bulk_status;
+
+//set to 1, if the buffer is pinned user-memory
+u8 is_user_mem;
 };

 static bool usbfs_snoop;
@@ -118,6 +124,12 @@ module_param(usbfs_memory_mb, uint, 0644);
 MODULE_PARM_DESC(usbfs_memory_mb,
 "maximum MB allowed for usbfs buffers (0 = no limit)");

+
+static bool usbfs_disable_zerocopy = false;
+module_param(usbfs_disable_zerocopy, bool, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(usbfs_disable_zerocopy, "true to disable zerocopy and 
fallback to the old implementation");

+
+
 /* Hard limit, necessary to avoid arithmetic overflow */
 #define USBFS_XFER_MAX(UINT_MAX / 2 - 100)

@@ -289,14 +301,23 @@ static struct async *alloc_async(unsigned int 
numisoframes)

 static void free_async(struct async *as)
 {
 int i;
+struct page* p;

 put_pid(as->pid);
 if (as->cred)
 put_cred(as->cred);
+
 for (i = 0; i < as->urb->num_sgs; i++) {
-if (sg_page(&as->urb->sg[i]))
-kfree(sg_virt(&as->urb->sg[i]));
+p = sg_page(&as->urb->sg[i]);
+if (p) {
+if(as->is_user_mem) {
+page_cache_release(p);
+} else {
+kfree(sg_virt(&as->urb->sg[i]));
+}
+}
 }
+
 kfree(as->urb->sg);
 kfree(as->urb->transfer_buffer);
 kfree(as->urb->setup_packet);
@@ -419,9 +440,11 @@ static void snoop_urb_data(struct urb *urb, 
unsigned len)

 }
 }

-static int copy_urb_data_to_user(u8 __user *userbuffer, str

Re: [PATCH 0/3] Tegra USB probe order issue fix

[Alan Stern]

On Wed, 2 Jul 2014, Stephen Warren wrote:

> On 07/02/2014 08:02 AM, Alan Stern wrote:
> > On Wed, 2 Jul 2014, Tuomas Tynkkynen wrote:
> > 
> >> Hi all,
> >>
> >> This series fixes a probe order issue with the Tegra EHCI driver.
> >> Basically, the register area of the 1st USB controller contains some
> >> registers that are global to all of the controllers, but that are also
> >> cleared when reset is asserted to the 1st controller. So if (say) the
> >> 3rd controller would be the first one to finish probing successfully,
> >> then the reset that happens during the 1st controller's probe would
> >> result in broken USB. So the before doing anything with the USB HW,
> >> we should reset the 1st controller once, and then never ever reset
> >> it again.
> > 
> > This sounds very much like the sort of thing that ought to be described 
> > in DT.  It is a hardware dependence, and DT exists for the purpose of 
> > describing the hardware.
> 
> DT is more about describing the HW, not how SW has to use the HW.

Tuomas wrote: "the register area of the 1st USB controller contains
some registers that are global to all of the controllers, but that are
also cleared when reset is asserted to the 1st controller."  That is
very much an attribute of the hardware and so DT should describe it.

> probe() ordering is a SW issue, not a HW description. It's driver
> knowledge that the HW resets have to run in a certain order, and if the
> driver didn't actually reset the HW ever (but rather, re-programmed all
> registers so reset was never needed), then order wouldn't be relevant
> 
> DT certainly doesn't have any mechanism for describing probe order or
> anything like that, although you can fake it out by adding phandles
> between nodes, and having SW wait for the driver for the referenced node
> to probe first. That won't work here though, since there's no guarantee
> that the USB1 node will actually be enabled (that USB port might not be
> hooked up on the board, hence the DT node will be disabled), so we can't
> rely on a driver for it ever appearing.

I wasn't talking about probe order; I was talking about the fact that 
registers pertinent to the later controllers are in the reset domain of 
the first controller.

Alan Stern

--
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 0/3] Tegra USB probe order issue fix

[Stephen Warren]

On 07/02/2014 10:09 AM, Alan Stern wrote:
> On Wed, 2 Jul 2014, Stephen Warren wrote:
> 
>> On 07/02/2014 08:02 AM, Alan Stern wrote:
>>> On Wed, 2 Jul 2014, Tuomas Tynkkynen wrote:
>>>
 Hi all,

 This series fixes a probe order issue with the Tegra EHCI driver.
 Basically, the register area of the 1st USB controller contains some
 registers that are global to all of the controllers, but that are also
 cleared when reset is asserted to the 1st controller. So if (say) the
 3rd controller would be the first one to finish probing successfully,
 then the reset that happens during the 1st controller's probe would
 result in broken USB. So the before doing anything with the USB HW,
 we should reset the 1st controller once, and then never ever reset
 it again.
>>>
>>> This sounds very much like the sort of thing that ought to be described 
>>> in DT.  It is a hardware dependence, and DT exists for the purpose of 
>>> describing the hardware.
>>
>> DT is more about describing the HW, not how SW has to use the HW.
> 
> Tuomas wrote: "the register area of the 1st USB controller contains
> some registers that are global to all of the controllers, but that are
> also cleared when reset is asserted to the 1st controller."  That is
> very much an attribute of the hardware and so DT should describe it.

So you want to add a Boolean DT property to the first USB controller
node indicating that it has the "shared" reset? That would be fine, but
would only replace the content of tegra_find_usb1_node(); much of the
rest of the patch would remain the same.

I guess in this case, it's fine to require DT changes to enable the new
feature of fixing this issue, so long as the code continues to work the
same as it currently does with old DTs. Due to the backwards
compatibility requirement, the patch will end up slightly more complex,
but hopefully not too bad.

>> probe() ordering is a SW issue, not a HW description. It's driver
>> knowledge that the HW resets have to run in a certain order, and if the
>> driver didn't actually reset the HW ever (but rather, re-programmed all
>> registers so reset was never needed), then order wouldn't be relevant
>>
>> DT certainly doesn't have any mechanism for describing probe order or
>> anything like that, although you can fake it out by adding phandles
>> between nodes, and having SW wait for the driver for the referenced node
>> to probe first. That won't work here though, since there's no guarantee
>> that the USB1 node will actually be enabled (that USB port might not be
>> hooked up on the board, hence the DT node will be disabled), so we can't
>> rely on a driver for it ever appearing.
> 
> I wasn't talking about probe order; I was talking about the fact that 
> registers pertinent to the later controllers are in the reset domain of 
> the first controller.
> 
> Alan Stern

--
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 0/5] usb: gadget: cleanup gadget driver .unbind usage at udc driver

[Felipe Balbi]

On Tue, Jul 01, 2014 at 04:50:02AM +, Peter Chen wrote:
>  
> > -Original Message-
> > From: Peter Chen [mailto:peter.c...@freescale.com]
> > Sent: Saturday, June 21, 2014 9:41 PM
> > To: ba...@ti.com
> > Cc: linux-usb@vger.kernel.org
> > Subject: Re: [PATCH 0/5] usb: gadget: cleanup gadget driver .unbind usage
> > at udc driver
> > 
> > On Wed, May 21, 2014 at 09:04:16AM +0800, Peter Chen wrote:
> > > Hi Felipe,
> > >
> > > This patch set cleans up unnecessary .unbind calling at udc driver,
> > > the udc core covers gadget driver's .unbind calling well.
> > >
> > > Peter Chen (5):
> > >   usb: gadget: fsl_udc_core: should not call gadget driver's .unbind
> > >   usb: gadget: fusb300_udc: should not call gadget driver's .unbind
> > >   usb: gadget: m66592-udc: should not call gadget driver's .unbind
> > >   usb: gadget: net2272: do not need to judge gadget driver's .unbind
> > >   usb: gadget: omap_udc: should not call gadget driver's .unbind
> > >
> > >  drivers/usb/gadget/fsl_udc_core.c |1 -
> > >  drivers/usb/gadget/fusb300_udc.c  |2 --
> > >  drivers/usb/gadget/m66592-udc.c   |2 --
> > >  drivers/usb/gadget/net2272.c  |2 +-
> > >  drivers/usb/gadget/omap_udc.c |5 +
> > >  5 files changed, 2 insertions(+), 10 deletions(-)
> > >
> > > --
> > > 1.7.8
> > >
> > 
> > Hi Felipe,
> > 
> > How about this patch set?
> > 
> 
> ping again.

it's in my testing/next branch, you'll receive an automated email once
I'm done with all my build tests.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2][for 3.16 0/3] Gadget directory cleanup

[Felipe Balbi]

On Tue, Jul 01, 2014 at 01:14:28PM +0200, Andrzej Pietrasiewicz wrote:
> W dniu 30.06.2014 20:21, Felipe Balbi pisze:
> >Hi,
> >
> >On Tue, Jun 17, 2014 at 02:19:14PM +0200, Andrzej Pietrasiewicz wrote:
> >>This is a follow-up to this thread:
> >>
> >>http://www.spinics.net/lists/linux-usb/msg107611.html
> 
> 
> 
> >>
> >>Rebased onto Greg's usb-next.
> >
> >please rebase on my testing/next, doesn't apply.
> >
> 
> Done.

alright, it's now in my testing/next branch. You'll receive my automated
email once I'm done.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 2/2] usb: gadget: Add xilinx axi usb2 device support

[Felipe Balbi]

Hi,

On Sun, May 25, 2014 at 11:10:30PM +0530, sundeep subbaraya wrote:
> Hi Felipe,
> 
> Please take a look at below about how this IP works:
> 
> IN:
>   req.buf ---> DMA (transfers from ddr to IP buffer, raise DMA
> done interrupt and set Buffer ready to transfer data to Host)>Host
> PC
>   buffer sent interrupt
> 
> OUT:
>  Host PC--->buffer ready interrupt--->DMA (transfer from IP buffer
> to DDR,DMA done interrupt, set Buffer ready to receive next data from
> Host)-->req.buf
> 
> I written logic to call completion in DMA done handler because it
> works for both IN and OUT eps. But I see significant performance
> degradation (by copying a file to mass storage gadget). DMA can handle
> unaligned address too but it has ep max limit (say 512 for bulk).
> Hence it is SW job to split packets and to drive DMA till req.length
> completes. I feel polling for a while is faster than switching between
> interrupt handler back and forth rapidly. Moreover, DMA may or may not
> be present in IP based on user configuration at design time.
> 
> I fixed all other comments expect this one if you do not agree for
> polling then I may have to create threads and do this stuff. What do
> you suggest?

Can you resend your driver so we can review again everything you have
fixed ? I guess you have no other way... polling it is.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 0/3] usb: common: otg-fsm: add HNP polling support for otg fsm

[Felipe Balbi]

On Mon, May 19, 2014 at 01:55:42PM +0800, Li Jun wrote:
> From: Li Jun 
> 
> Hi Felipe,
> 
> This patchset adds otg HNP polling common part for otg fsm.

awesome :-) How have you tested it ?

> 
> Li Jun (3):
>   usb: common: otg-fsm: start HNP polling timer in host state
>   usb: common: otg-fsm: add HNP polling request sending funciton

please fix this typo s/funciton/function/

-- 
balbi


signature.asc
Description: Digital signature

[PATCH 2/2 v5] HID: leds: move led_mode attribute to led-class devices in MSI GT683R driver

[Janne Kanniainen]

Move led_mode attribute from HID device to led-class devices. This will also 
fix race condition by using attribute-groups.

Signed-off-by: Janne Kanniainen 
---

Changes in v3:
- Style fixes
- Rename sysfs-class-hid-driver-gt683r to sysfs-class-leds-driver-gt683r

Changes in v4:
- Rename sysfs-class-leds-driver-gt683r to sysfs-class-leds-gt683r
- Change "What: " to /sys/class/leds//gt683r/mode
- Change .name from gt683r_led to gt683r

Changes in v5:
- Move mode attribute to gt683r/mode

 .../ABI/testing/sysfs-class-hid-driver-gt683r  | 14 -
 Documentation/ABI/testing/sysfs-class-leds-gt683r  | 16 ++
 drivers/hid/hid-gt683r.c   | 36 ++
 3 files changed, 40 insertions(+), 26 deletions(-)
 delete mode 100644 Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
 create mode 100644 Documentation/ABI/testing/sysfs-class-leds-gt683r

diff --git a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r 
b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
deleted file mode 100644
index 317e9d5..000
--- a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
+++ /dev/null
@@ -1,14 +0,0 @@
-What:  /sys/class/hidraw//device/leds_mode
-Date:  Jun 2014
-KernelVersion: 3.17
-Contact:   Janne Kanniainen 
-Description:
-   Set the mode of LEDs
-
-   0 - normal
-   1 - audio
-   2 - breathing
-
-   Normal: LEDs are fully on when enabled
-   Audio:  LEDs brightness depends on sound level
-   Breathing: LEDs brightness varies at human breathing rate
\ No newline at end of file
diff --git a/Documentation/ABI/testing/sysfs-class-leds-gt683r 
b/Documentation/ABI/testing/sysfs-class-leds-gt683r
new file mode 100644
index 000..e4fae60
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-leds-gt683r
@@ -0,0 +1,16 @@
+What:  /sys/class/leds//gt683r/mode
+Date:  Jun 2014
+KernelVersion: 3.17
+Contact:   Janne Kanniainen 
+Description:
+   Set the mode of LEDs. You should notice that changing the mode
+   of one LED will update the mode of its two sibling devices as
+   well.
+
+   0 - normal
+   1 - audio
+   2 - breathing
+
+   Normal: LEDs are fully on when enabled
+   Audio:  LEDs brightness depends on sound level
+   Breathing: LEDs brightness varies at human breathing rate
\ No newline at end of file
diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
index 073bd80..0d6f135 100644
--- a/drivers/hid/hid-gt683r.c
+++ b/drivers/hid/hid-gt683r.c
@@ -84,12 +84,13 @@ static void gt683r_brightness_set(struct led_classdev 
*led_cdev,
}
 }
 
-static ssize_t leds_mode_show(struct device *dev,
+static ssize_t mode_show(struct device *dev,
struct device_attribute *attr,
char *buf)
 {
u8 sysfs_mode;
-   struct hid_device *hdev = container_of(dev, struct hid_device, dev);
+   struct hid_device *hdev = container_of(dev->parent,
+   struct hid_device, dev);
struct gt683r_led *led = hid_get_drvdata(hdev);
 
if (led->mode == GT683R_LED_NORMAL)
@@ -102,12 +103,13 @@ static ssize_t leds_mode_show(struct device *dev,
return scnprintf(buf, PAGE_SIZE, "%u\n", sysfs_mode);
 }
 
-static ssize_t leds_mode_store(struct device *dev,
+static ssize_t mode_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
 {
u8 sysfs_mode;
-   struct hid_device *hdev = container_of(dev, struct hid_device, dev);
+   struct hid_device *hdev = container_of(dev->parent,
+   struct hid_device, dev);
struct gt683r_led *led = hid_get_drvdata(hdev);
 
 
@@ -212,7 +214,22 @@ fail:
mutex_unlock(&led->lock);
 }
 
-static DEVICE_ATTR_RW(leds_mode);
+static DEVICE_ATTR_RW(mode);
+
+static struct attribute *gt683r_led_attrs[] = {
+   &dev_attr_mode.attr,
+   NULL
+};
+
+static const struct attribute_group gt683r_led_group = {
+   .name = "gt683r",
+   .attrs = gt683r_led_attrs,
+};
+
+static const struct attribute_group *gt683r_led_groups[] = {
+   >683r_led_group,
+   NULL
+};
 
 static int gt683r_led_probe(struct hid_device *hdev,
const struct hid_device_id *id)
@@ -261,6 +278,8 @@ static int gt683r_led_probe(struct hid_device *hdev,
led->led_devs[i].name = name;
led->led_devs[i].max_brightness = 1;
led->led_devs[i].brightness_set = gt683r_brightness_set;
+   led->led_devs[i].groups = gt683r_led_groups;
+
ret = led_classdev_register(&hdev->dev, &led->led_devs[i]);
   

Re: [PATCH 0/3] Tegra USB probe order issue fix

[Alan Stern]

On Wed, 2 Jul 2014, Stephen Warren wrote:

> On 07/02/2014 10:09 AM, Alan Stern wrote:
> > On Wed, 2 Jul 2014, Stephen Warren wrote:
> > 
> >> On 07/02/2014 08:02 AM, Alan Stern wrote:
> >>> On Wed, 2 Jul 2014, Tuomas Tynkkynen wrote:
> >>>
>  Hi all,
> 
>  This series fixes a probe order issue with the Tegra EHCI driver.
>  Basically, the register area of the 1st USB controller contains some
>  registers that are global to all of the controllers, but that are also
>  cleared when reset is asserted to the 1st controller. So if (say) the
>  3rd controller would be the first one to finish probing successfully,
>  then the reset that happens during the 1st controller's probe would
>  result in broken USB. So the before doing anything with the USB HW,
>  we should reset the 1st controller once, and then never ever reset
>  it again.
> >>>
> >>> This sounds very much like the sort of thing that ought to be described 
> >>> in DT.  It is a hardware dependence, and DT exists for the purpose of 
> >>> describing the hardware.
> >>
> >> DT is more about describing the HW, not how SW has to use the HW.
> > 
> > Tuomas wrote: "the register area of the 1st USB controller contains
> > some registers that are global to all of the controllers, but that are
> > also cleared when reset is asserted to the 1st controller."  That is
> > very much an attribute of the hardware and so DT should describe it.
> 
> So you want to add a Boolean DT property to the first USB controller
> node indicating that it has the "shared" reset?

Something like that, yes.

> That would be fine, but
> would only replace the content of tegra_find_usb1_node(); much of the
> rest of the patch would remain the same.

That's okay.  tegra_find_usb1_node() was the most objectionable part of
the patch.

> I guess in this case, it's fine to require DT changes to enable the new
> feature of fixing this issue, so long as the code continues to work the
> same as it currently does with old DTs. Due to the backwards
> compatibility requirement, the patch will end up slightly more complex,
> but hopefully not too bad.

Good.

Alan Stern

--
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_fs: OS descriptors support

[Michal Nazarewicz]

On Wed, Jul 02 2014, David Laight  wrote:
> From: Michal Nazarewicz
> ...
>> > Alternatively it shouldn't be 'packed', and a full audit of the
>> > other structures done to determine which ones can ever be misaligned
>> > and then determine whether that should actually be allowed.
>> 
>> All of the structures describe a wire protocol, whether we thing the
>> structure can be allowed or not is inconsequential since that's what is
>> being used.  All of those structures must be packed.
>
> That just isn't true.
> Just because a structure maps a protocol packet doesn't mean it has
> to be 'packed'.
> The TCP stack doesn't mark anything 'packed'.
> It relies on the ethernet driver correctly aligning receive messages.

Unfortunately in USB even if the message is correctly aligned, the
fields in descriptors do not have to be.  Furthermore, descriptors are
stacked one after another and they rarely are multiply of four (or even
two) bytes.  usb_config_descriptor for example is 9 bytes.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
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][RFC] USB: zerocopy support for usbfs

[Greg KH]

On Wed, Jul 02, 2014 at 05:53:56PM +0200, Stefan Klug wrote:
> Hi everybody,
> in short: The attached patch adds zerocopy support to the usbfs driver.
> I tested it on x86 and on a globalscale mirabox ARM board. Until now it
> works
> quite nice and I'd love to get some comments and feedback on the patch.

Very nice.

Minor non-technical issues here, your patch is corrupted (linewrapped
and tabs converted to spaces) and can't be applied at all.  Can you fix
your email client and try again?  Look at
Documentation/email_clients.txt for hints on how to do this.

> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -4,6 +4,7 @@
>   *  devio.c  --  User space communication with USB devices.
>   *
>   *  Copyright (C) 1999-2000  Thomas Sailer (sai...@ife.ee.ethz.ch)
> + *  Copyright (C) 2014  Stefan Klug (stefan.k...@baslerweb.com)

According to legal advice given to me, this isn't needed / true, so can
you drop it?  Or, if you have different legal advice, might I ask for
what the legal justification is that this needs to be added?

>   *  This program is free software; you can redistribute it and/or
> modify
>   *  it under the terms of the GNU General Public License as published
> by
> @@ -30,6 +31,7 @@
>   *04.01.2000   0.2   Turned into its own filesystem
>   *30.09.2005   0.3   Fix user-triggerable oops in async URB delivery
>   * (CAN-2005-3055)
> + *07.05.2014   0.4   Added zerocopy support

No need to do this, we use git now and that's where the changelog goes.
We should just delete this "fake changelog" entirely from this file.

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][RFC] USB: zerocopy support for usbfs

[Alan Stern]

On Wed, 2 Jul 2014, Stefan Klug wrote:

> Hi everybody,
> in short: The attached patch adds zerocopy support to the usbfs driver.
> I tested it on x86 and on a globalscale mirabox ARM board. Until now it 
> works
> quite nice and I'd love to get some comments and feedback on the patch.
> 
> Longer version: The usbfs driver does not support direct data transfers 
> from the controller
> to user-memory. For several use-cases (in my case USB3 Vision cameras 
> pushing up to 360MB/s)
> the copy operation from kernel to user-space results in a lot of 
> unnecessary CPU overhead
> especially on small embedded devices. I measured a decrease in CPU usage 
> from 44% to 22% on
> a the mirabox.
> 
> This patch implements zerocopy beside the existing code paths, so it is 
> easy to disable
> zerocopy at runtime and to directly compare the CPU usage.
> To disable zerocopy just do an
>  echo 1 > /sys/module/usbcore/parameters/usbfs_disable_zerocopy
> and to reenable it
>  echo 0 > /sys/module/usbcore/parameters/usbfs_disable_zerocopy
> 
> On modern desktop systems the change in CPU usage is quite low so this 
> mostly affects
> smaller embedded devices.
> 
> Implementation details:
> The patch only touches drivers/usb/core/devio.c.
> In procy_do_submiturb(), it is checked if zerocopy is allowed. This is 
> currently a rough
> check which compares the number of required pages to 
> ps->dev->bus->sg_tablesize.
> I don't know if there is more to check there.
> Then the user memory provided inside the usbdevfs_urb structure is 
> pinned to
> physical memory using get_user_pages_fast().
> All the user pages are added to the scatter-gather list and the logic 
> continues as before.
> In copy_urb_data_to_user() the pages are marked with 
> set_page_dirty_lock() if the transfer
>   was a zerocopy one.
> In free_async() the pinned pages are released, if the transfer was a 
> zerocopy one.

Overall this implementation seems quite straightforward.  However, it
appears that your email client has mangled the whitespace in the patch.

The patch contains many style violations; you should run it through
checkpatch.pl.  It also has one or two mistakes, such as the
calculation of u for the amount of memory used.

> Questions/Notes:
> - I'm quite unhappy with the added member async::is_user_mem. Is there a 
> better place
>where I could store this information?

No, async is the right place.  Why are you unhappy about it?

> - I had a look at some other drivers using the get_user_pages -> 
> sg_set_page -> page_cache_release
>technique and didn't see any special code to handle corner cases.
>Are there corner cases? - Like usb controllers not supporting the 
> whole memory etc. ?

Indeed yes.  The page addresses have to be checked against the DMA
mask.  Also, many host controllers cannot handle arbitrary alignment.  
It would be best to require that the buffer start at a page boundary.

> - In the kernel log I see messages like:
>xhci_hcd :00:14.0: WARN Event TRB for slot 4 ep 8 with no TDs queued?
>after enabling zerocopy. Any idea where this might come from?

Not directly related; that's a bug in xhci-hcd.

Using a global module parameter to control the use of zerocopy (for
anything other than debugging or testing) is a bad idea.  If you think
people will have a reason for avoiding zerocopy then you should make it
possible to decide for each URB, by adding a new flag to struct
usbdevfs_urb.

People will want to use zerocopy with isochronous transfers as well as 
bulk.  Implementing that isn't going to be quite so easy; it will be 
necessary for the user to set up a memory mapping.  In fact, once 
that's done the same mechanism could be used for bulk transfers too.

Alan Stern

--
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][RFC] USB: zerocopy support for usbfs

[Peter Stuge]

Thank you very much for working on this, Stefan.

Alan Stern wrote:
> Also, many host controllers cannot handle arbitrary alignment.  
> It would be best to require that the buffer start at a page boundary.

This requires a bit of negotiation with userspace, maybe per-URB but
it seems better to negotiate per-claim or even per-open. What about
large control transfers?


> Using a global module parameter to control the use of zerocopy (for
> anything other than debugging or testing) is a bad idea.

I agree.


> If you think people will have a reason for avoiding zerocopy then
> you should make it possible to decide for each URB, by adding a new
> flag to struct usbdevfs_urb.

People might want to use zerocopy always, but have buffers in
userspace which make that impossible with the given hardware.

It's important that the kernel gives userspace enough information
about the constraints, if userspace wants zerocopy.


> People will want to use zerocopy with isochronous transfers as well as 
> bulk.  Implementing that isn't going to be quite so easy; it will be 
> necessary for the user to set up a memory mapping.  In fact, once 
> that's done the same mechanism could be used for bulk transfers too.

Indeed I think userspace wants to be involved in choosing memory also
with bulk, in order to ensure that zerocopy will always work when
userspace cares about that.

Is it enough to expose the DMA mask of the host controller?


//Peter
--
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][RFC] USB: zerocopy support for usbfs

[Oliver Neukum]

On Wed, 2014-07-02 at 17:53 +0200, Stefan Klug wrote:

> Implementation details:
> The patch only touches drivers/usb/core/devio.c.
> In procy_do_submiturb(), it is checked if zerocopy is allowed. This is 
> currently a rough
> check which compares the number of required pages to 
> ps->dev->bus->sg_tablesize.

It seems to me that the check is per call, so using
multiple calls one could still pin unlimited amounts
of memory.

> I don't know if there is more to check there.
> Then the user memory provided inside the usbdevfs_urb structure is 
> pinned to
> physical memory using get_user_pages_fast().
> All the user pages are added to the scatter-gather list and the logic 
> continues as before.

How do you enforce the cache coherency rules?
Also you don't have a fall back if get_user_pages_fast()
returns less than requested. It seems to me that than you
ought to fall back buffered IO.

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: [PATCH][RFC] USB: zerocopy support for usbfs

[Alan Stern]

On Wed, 2 Jul 2014, Peter Stuge wrote:

> Thank you very much for working on this, Stefan.
> 
> Alan Stern wrote:
> > Also, many host controllers cannot handle arbitrary alignment.  
> > It would be best to require that the buffer start at a page boundary.
> 
> This requires a bit of negotiation with userspace, maybe per-URB but

I don't follow.  What negotiation is needed?  All that needs to happen 
is the user program submits a transfer where the buffer is aligned on a 
page boundary.

> it seems better to negotiate per-claim or even per-open. What about
> large control transfers?

The kernel doesn't support scatter-gather for control transfers, only 
bulk.

> > If you think people will have a reason for avoiding zerocopy then
> > you should make it possible to decide for each URB, by adding a new
> > flag to struct usbdevfs_urb.
> 
> People might want to use zerocopy always, but have buffers in
> userspace which make that impossible with the given hardware.
> 
> It's important that the kernel gives userspace enough information
> about the constraints, if userspace wants zerocopy.

I don't know of any way for the kernel to give userspace any
information about constraints of this sort.  Do you?  For example, the
man page for open(2) says: "The O_DIRECT flag may impose alignment
restrictions on the length and address of user-space buffers and the
file offset of I/Os", but it doesn't say how to find out what those
restrictions are.

> > People will want to use zerocopy with isochronous transfers as well as 
> > bulk.  Implementing that isn't going to be quite so easy; it will be 
> > necessary for the user to set up a memory mapping.  In fact, once 
> > that's done the same mechanism could be used for bulk transfers too.
> 
> Indeed I think userspace wants to be involved in choosing memory also
> with bulk, in order to ensure that zerocopy will always work when
> userspace cares about that.
> 
> Is it enough to expose the DMA mask of the host controller?

It doesn't need to be exposed, since the mmap(2) call would be handled
by the kernel's USB stack (and besides, the user program can't request
that the mapped memory be located in any particular physical address
region).

Furthermore, the DMA mask already is exposed in sysfs.  For example,
the DMA mask for the host controller on bus 2 is given in
/sys/bus/usb/devices/usb2/../dma_mask_bits.

Alan Stern

--
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][RFC] USB: zerocopy support for usbfs

[Alan Stern]

On Wed, 2 Jul 2014, Oliver Neukum wrote:

> On Wed, 2014-07-02 at 17:53 +0200, Stefan Klug wrote:
> 
> > Implementation details:
> > The patch only touches drivers/usb/core/devio.c.
> > In procy_do_submiturb(), it is checked if zerocopy is allowed. This is 
> > currently a rough
> > check which compares the number of required pages to 
> > ps->dev->bus->sg_tablesize.
> 
> It seems to me that the check is per call, so using
> multiple calls one could still pin unlimited amounts
> of memory.

usbfs keeps track of the total amount of pinned memory and enforces an
overall limit.  It will be necessary to add the size of the transfer
buffer to that total.

> > I don't know if there is more to check there.
> > Then the user memory provided inside the usbdevfs_urb structure is 
> > pinned to
> > physical memory using get_user_pages_fast().
> > All the user pages are added to the scatter-gather list and the logic 
> > continues as before.
> 
> How do you enforce the cache coherency rules?

There is no way to do this.  If the user program accesses memory when 
it shouldn't, the transfer might not work right.

> Also you don't have a fall back if get_user_pages_fast()
> returns less than requested. It seems to me that than you
> ought to fall back buffered IO.

Agreed.

Alan Stern

--
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][RFC] USB: zerocopy support for usbfs

[Peter Stuge]

Alan Stern wrote:
> > > Also, many host controllers cannot handle arbitrary alignment.  
> > > It would be best to require that the buffer start at a page boundary.
> > 
> > This requires a bit of negotiation with userspace, maybe per-URB but
> 
> I don't follow.  What negotiation is needed?  All that needs to happen 
> is the user program submits a transfer where the buffer is aligned on a 
> page boundary.

The negotiation needed would be for userspace to learn what alignment
is required, so that it can make sure to provide only such buffers.
But see below on mmap..


> > it seems better to negotiate per-claim or even per-open. What about
> > large control transfers?
> 
> The kernel doesn't support scatter-gather for control transfers, only 
> bulk.

That could possibly change, right, and then it would be nice to have
zerocopy for free there as well?


> > It's important that the kernel gives userspace enough information
> > about the constraints, if userspace wants zerocopy.
> 
> I don't know of any way for the kernel to give userspace any
> information about constraints of this sort.  Do you?

I don't know of any at the moment, no. It might be done through an
ioctl into usbfs, but if sysfs already has all neccessary information
then no ioctl is needed. Anyway...


> > Indeed I think userspace wants to be involved in choosing memory also
> > with bulk, in order to ensure that zerocopy will always work when
> > userspace cares about that.
> > 
> > Is it enough to expose the DMA mask of the host controller?
> 
> It doesn't need to be exposed, since the mmap(2) call would be handled
> by the kernel's USB stack (and besides, the user program can't request
> that the mapped memory be located in any particular physical address
> region).

Since alignment isn't the only issue I don't think there's a way to
avoid it. I was just hoping to be able to avoid allocating zerocopy
buffers with mmap().


> Furthermore, the DMA mask already is exposed in sysfs.
> For example, the DMA mask for the host controller on bus 2 is
> given in /sys/bus/usb/devices/usb2/../dma_mask_bits.

I realize that this doesn't help much, since userspace can't get the
physical address for its virtual addresses anyway.


//Peter
--
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][RFC] USB: zerocopy support for usbfs

[Alan Stern]

On Wed, 2 Jul 2014, Peter Stuge wrote:

> > The kernel doesn't support scatter-gather for control transfers, only 
> > bulk.
> 
> That could possibly change, right, and then it would be nice to have
> zerocopy for free there as well?

No.  ohci-hcd doesn't support control transfers larger than 4 KB
anyway, and ehci-hcd doesn't support control transfers larger than 16 
KB.  This is not likely to change.  Besides, a control transfer can 
never be larger than 64 KB, and throughput isn't an issue for them.

> > > Indeed I think userspace wants to be involved in choosing memory also
> > > with bulk, in order to ensure that zerocopy will always work when
> > > userspace cares about that.
> > > 
> > > Is it enough to expose the DMA mask of the host controller?
> > 
> > It doesn't need to be exposed, since the mmap(2) call would be handled
> > by the kernel's USB stack (and besides, the user program can't request
> > that the mapped memory be located in any particular physical address
> > region).
> 
> Since alignment isn't the only issue I don't think there's a way to
> avoid it. I was just hoping to be able to avoid allocating zerocopy
> buffers with mmap().

How else can you guarantee that a buffer is located in the first 4 GB
of memory?  Even on a 32-bit system (if the computer has more than 4 GB 
of RAM)?

Alan Stern

--
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: Chipidea gadget unplug/disconnect event

[Peter Chen]

 
> 
> Is it possible to get the chipidea to generate an event on udc unplugging?
> 

Yes, it has already implemented at ci_usc_vbus_session.

> I see the code path in ci_udc_vbus_session of udc.c to trigger such an
> event, but unfortunately it was never possible to run into that code.
> 
> The function ci_otg_work in otg.c is prepared to do that in case the irq
> got triggered by OTGSC_BSVIS bit change.
> 
> This is true for plugging, but never happened to be called on unplugging.
> Is there anything missing to get this working? Or is this completely
> impossible by the core? I was already fiddling around with the other irq
> cases OTGSC_*IE, but never got anything useful.

Once the vbus lower than B_SESSION_VALID, it will trigger (set OTGSC_BSVIS too)
BSV interrupt. Check your vbus after unplugging please.

Peter

> 
> I am working on the imx25 otg capable SoC.
> 
> 

--
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 07/12] usb: chipidea: add a generic driver

[punnaiah choudary kalluri]

Since its a generic driver, support for configuring the dma_mask using
dma_coerce_mask_and_coherent would be good.

Regards,
Punnaiah

On Tue, Jun 24, 2014 at 4:05 PM, Antoine Ténart
 wrote:
> Add a generic ChipIdea driver, with optional PHY and clock, to support
> ChipIdea controllers that doesn't need specific functions.
>
> Needed for the Marvell Berlin SoCs SUB controllers.
>
> Signed-off-by: Antoine Ténart 
> ---
>  drivers/usb/chipidea/Makefile  |   1 +
>  drivers/usb/chipidea/ci_hdrc_generic.c | 108 
> +
>  2 files changed, 109 insertions(+)
>  create mode 100644 drivers/usb/chipidea/ci_hdrc_generic.c
>
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index 2f099c7df7b5..c705f0fe7a00 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -20,4 +20,5 @@ endif
>
>  ifneq ($(CONFIG_OF),)
> obj-$(CONFIG_USB_CHIPIDEA)  += usbmisc_imx.o ci_hdrc_imx.o
> +   obj-$(CONFIG_USB_CHIPIDEA)  += ci_hdrc_generic.o
>  endif
> diff --git a/drivers/usb/chipidea/ci_hdrc_generic.c 
> b/drivers/usb/chipidea/ci_hdrc_generic.c
> new file mode 100644
> index ..27520710a1f7
> --- /dev/null
> +++ b/drivers/usb/chipidea/ci_hdrc_generic.c
> @@ -0,0 +1,108 @@
> +/*
> + * Copyright (C) 2014 Marvell Technology Group Ltd.
> + *
> + * Antoine Ténart 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ci.h"
> +
> +struct ci_hdrc_generic_priv {
> +   struct platform_device  *ci_pdev;
> +   struct clk  *clk;
> +};
> +
> +static int ci_hdrc_generic_probe(struct platform_device *pdev)
> +{
> +   struct device *dev = &pdev->dev;
> +   struct ci_hdrc_generic_priv *priv;
> +   struct ci_hdrc_platform_data ci_pdata = {
> +   .name   = "ci_hdrc",
> +   .capoffset  = DEF_CAPOFFSET,
> +   .flags  = CI_HDRC_REQUIRE_TRANSCEIVER |
> + CI_HDRC_DISABLE_STREAMING,
> +   };
> +   int ret;
> +
> +   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> +   if (!priv)
> +   return -ENOMEM;
> +
> +   priv->clk = devm_clk_get(dev, NULL);
> +   if (!IS_ERR(priv->clk)) {
> +   ret = clk_prepare_enable(priv->clk);
> +   if (ret) {
> +   dev_err(dev, "failed to enable the clock: %d\n", ret);
> +   return ret;
> +   }
> +   }
> +
> +   ci_pdata.phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 0);
> +   if (IS_ERR(ci_pdata.phy))
> +   /* PHY is optional */
> +   ci_pdata.phy = NULL;
> +
> +   priv->ci_pdev = ci_hdrc_add_device(dev, pdev->resource,
> +pdev->num_resources, &ci_pdata);
> +   if (IS_ERR(priv->ci_pdev)) {
> +   ret = PTR_ERR(priv->ci_pdev);
> +   if (ret != -EPROBE_DEFER)
> +   dev_err(dev,
> +   "failed to register ci_hdrc platform device: 
> %d\n",
> +   ret);
> +   goto clk_err;
> +   }
> +
> +   platform_set_drvdata(pdev, priv);
> +
> +   pm_runtime_no_callbacks(dev);
> +   pm_runtime_enable(dev);
> +
> +   return 0;
> +
> +clk_err:
> +   clk_disable_unprepare(priv->clk);
> +   return ret;
> +}
> +
> +static int ci_hdrc_generic_remove(struct platform_device *pdev)
> +{
> +   struct ci_hdrc_generic_priv *priv = platform_get_drvdata(pdev);
> +
> +   pm_runtime_disable(&pdev->dev);
> +   ci_hdrc_remove_device(priv->ci_pdev);
> +   clk_disable_unprepare(priv->clk);
> +
> +   return 0;
> +}
> +
> +static const struct of_device_id ci_hdrc_generic_of_match[] = {
> +   { .compatible = "chipidea-usb" },
> +   { }
> +};
> +MODULE_DEVICE_TABLE(of, ci_hdrc_generic_of_match);
> +
> +static struct platform_driver ci_hdrc_generic_driver = {
> +   .probe  = ci_hdrc_generic_probe,
> +   .remove = ci_hdrc_generic_remove,
> +   .driver = {
> +   .name   = "chipidea-usb",
> +   .owner  = THIS_MODULE,
> +   .of_match_table = ci_hdrc_generic_of_match,
> +   },
> +};
> +module_platform_driver(ci_hdrc_generic_driver);
> +
> +MODULE_DESCRIPTION("Generic ChipIdea HDRC USB binding");
> +MODULE_AUTHOR("Antoine Ténart ");
> +MODULE_LICENSE("GPL");
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a mes

[PATCH net-next] r8152: increase the tx timeout

[Hayes Wang]

When the system is too busy to complete the urb, the tx timout function
would be called. This causes the other tx urbs would be killed, too.
Increase the tx timeout to avoid it.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2543196..e9685ce 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -441,7 +441,7 @@ enum rtl_register_content {
 #define BYTE_EN_END_MASK   0xf0
 
 #define RTL8152_RMS(VLAN_ETH_FRAME_LEN + VLAN_HLEN)
-#define RTL8152_TX_TIMEOUT (HZ)
+#define RTL8152_TX_TIMEOUT (5 * HZ)
 
 /* rtl8152 flags */
 enum rtl8152_flags {
-- 
1.9.3

--
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: [PATCHv2 0/6] phy: simplified phy lookup

[Vivek Gautam]

Hi,


On Wed, Jul 2, 2014 at 5:01 PM, Kishon Vijay Abraham I  wrote:
> Hi,
>
> On Thursday 05 June 2014 06:51 PM, Vivek Gautam wrote:
>> Hi Heikki,
>>
>>
>> On Thu, Jun 5, 2014 at 6:22 PM, Heikki Krogerus
>>  wrote:
>>> Hi,
>>>
>>> So the idea with these is that they should help to make it possible to
>>> request phys without caring about how they are mapped to the
>>> consumers, meaning, was is the mapping done in DT, ACPI, etc. Mapping
>>> phys to consumers can be now done with lookups similarly how clocks
>>> can be mapped in clkdev.c.
>>>
>>> Vivek needs to handle the phys of dwc3 also in xhci driver on
>>> Exynos5420 SoC, so I'm resending these now.
>>
>> Thank you so much for your efforts.
>> This will greatly help me in preparing the patches for PHY tuning.
>
> Can I get Tested-by please?

Sure,
I have tested this series with my phy-calibration patches. [1]
The entire lookup method looks fine.

Although i am re-working on my patches, but for this series -

Tested-by: Vivek Gautam 


[1] https://lkml.org/lkml/2014/6/6/202


-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
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 0/3] usb: common: otg-fsm: add HNP polling support for otg fsm

[Li Jun]

On Wed, Jul 02, 2014 at 11:49:07AM -0500, Felipe Balbi wrote:
> On Mon, May 19, 2014 at 01:55:42PM +0800, Li Jun wrote:
> > From: Li Jun 
> > 
> > Hi Felipe,
> > 
> > This patchset adds otg HNP polling common part for otg fsm.
> 
> awesome :-) How have you tested it ?
>

Tested by 2 Freescale i.MX boards and also verified by USB PET test.
I had sent out v2 of this patchset.

> > 
> > Li Jun (3):
> >   usb: common: otg-fsm: start HNP polling timer in host state
> >   usb: common: otg-fsm: add HNP polling request sending funciton
> 
> please fix this typo s/funciton/function/
> 
Thanks, I will fix and resend.

Li Jun
> -- 
> 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 v3] usb: hcd: add generic PHY support

[Vivek Gautam]

Cc: Alan, Mathias Nyman, Julius Werner, Heikki Krogerus

Hi,


On Wed, Jun 25, 2014 at 4:02 PM, Vivek Gautam  wrote:
> Hi Sergei,
>
>
> On Fri, May 30, 2014 at 7:42 PM, Yoshihiro Shimoda
>  wrote:
>> From Sergei Shtylyov 
>>
>> Add the generic PHY support, analogous to the USB PHY support. Intended it 
>> to be
>> used with the PCI EHCI/OHCI drivers and the xHCI platform driver.
>>
>> Signed-off-by: Sergei Shtylyov 
>> Signed-off-by: Yoshihiro Shimoda 
>> ---
>> This patch is against the 'usb-next' branch of Greg KH's 'usb.git' repo.
>> (commit id = 70d2f61fc7559df3d5be32a9d01efdb9ee1b11d8)
>>
>> Changes in version 3:
>>  - rebased the current usb-next.
>>  - I tested this patch on my R-Car H2 USB 3.0 driver (not merged yet)
>>
>>  drivers/usb/core/hcd.c  |   42 --
>>  include/linux/usb/hcd.h |3 ++-
>>  2 files changed, 42 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
>> index bec31e2..2841149 100644
>> --- a/drivers/usb/core/hcd.c
>> +++ b/drivers/usb/core/hcd.c
>> @@ -42,6 +42,7 @@
>>  #include 
>>  #include 
>>
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -2649,6 +2650,29 @@ int usb_add_hcd(struct usb_hcd *hcd,
>> }
>> }
>>
>> +   if (IS_ENABLED(CONFIG_GENERIC_PHY)) {
>> +   struct phy *phy = phy_get(hcd->self.controller, "usb");
>
> The xHCI host controller is going to have two controllers (main and
> shared) USB2 controller and
> USB3 controller. So they will have two different PHYs.
> For example, the DWC3, which has a xHCI controller, has to have 2
> different phys -- usb2-phy and usb3-phy.
>
> So, how the two 'hcd's' will be able to differentiate and get two separate 
> PHYs.
> Unfortunately, the xHCI with DWC3 doesn't have a device node too, so
> it needs to have
> a way out to look up the PHYs (in a way suggested by Heikki :
> usb: dwc3: host: convey the PHYs to xhci
> (https://lkml.org/lkml/2014/6/5/585) and related patch series.
> But this also has an issue, since we need to have two separate
> constant strings to distinguish between the two PHYs,
> while creating the lookup table.
>
> So how do you suggest me to get link the two PHYs in DWC3 with the
> XHCI host controller, the issue which i am
> facing currently while working with the patch:
> usb: host: xhci-plat: Add support to get PHYsand the related patch
> series, since we need to handle PHY from the hcd.

Can someone please clear my doubt here.

This can help me getting a clear picture of how to align with the xhci's request
for PHY to let it handle any sort of phy-calibration, which we are
trying in the patch-series:
[PATCH v1 0/4] Fine tune USB 3.0 PHY on exynos5420
https://lkml.org/lkml/2014/6/6/202

I have also posted my doubts in the thread :
[PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs
https://lkml.org/lkml/2014/6/25/150

[snip]


-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
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