Re: [PATCH] usb: phy: rename all phy drivers to phy-$name.c

[Felipe Balbi]

Hi,

On Fri, Mar 08, 2013 at 11:33:48AM -0700, Stephen Warren wrote:
> On 03/08/2013 12:08 AM, Felipe Balbi wrote:
> > On Thu, Mar 07, 2013 at 01:37:17PM -0700, Stephen Warren wrote:
> >> On 03/07/2013 08:45 AM, Felipe Balbi wrote:
> >>> this will make sure that we have sensible names for all phy
> >>> drivers. Current situation was already quite bad with too
> >>> generic names being used.
> >> 
> >> Is phy-$name specific enough? There are other types of PHY such
> >> as Ethernet, etc. What about phy-usb-$name?
> > 
> > we will be creating a generic (kernel-wide) phy layer, so I guess
> > that matters very little. Specially since we don't want to be
> > differentiating PHYs by their subsystem and rather by the IP name
> > (which means phy-tegra, phy-samsung, phy-omap, are all 'wrong', but
> > there were no better names).
> 
> On other thought here: The Tegra PHY in question here very
> specifically is a USB PHY. There's no way it could be used as e.g. a
> SATA PHY, either as a HW block or given the driver code that program
> is. Is sharing a PHY IP block or driver ever possible for any HW?

yes it is possible, and OMAP5 shares the same IP for USB3 and SATA. PHYs
don't know about USB, SATA, Ethernet and whatnot. PHYs know solely about
the physical layer. Their work is just to generate the proper electrical
signals.

> Hence, I don't think removing "USB" from the filename makes sense, nor
> even moving it into a generic PHY directory.

fair enough, I have now renamed tegra to phy-tegra-usb.c

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 3/3] usb: phy: isp1301: implement PHY API

[Felipe Balbi]

On Fri, Mar 08, 2013 at 11:53:21PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 08-03-2013 15:30, Felipe Balbi wrote:
> 
> >this patch implements ->init() and ->set_vbus()
> >methods for isp1301 transceiver driver.
> 
> >Later patches can now come in order to remove
> >the hackery from ohci-nxp and lpc32xx udc drivers.
> 
> >Signed-off-by: Felipe Balbi 
> >---
> >  drivers/usb/phy/phy-isp1301.c | 59 
> > +++
> >  1 file changed, 59 insertions(+)
> 
> >diff --git a/drivers/usb/phy/phy-isp1301.c b/drivers/usb/phy/phy-isp1301.c
> >index 36c4d98..af8f9da 100644
> >--- a/drivers/usb/phy/phy-isp1301.c
> >+++ b/drivers/usb/phy/phy-isp1301.c
> [...]
> >@@ -31,6 +34,60 @@ static const struct i2c_device_id isp1301_id[] = {
> [...]
> >+static int isp1301_phy_init(struct usb_phy *phy)
> >+{
> >+struct isp1301 *isp = phy_to_isp(phy);
> >+
> >+/* Disable transparent UART mode first */
> >+isp1301_clear(isp,ISP1301_I2C_MODE_CONTROL_1, MC1_UART_EN);
> 
>You misssed space after comma here.

fixed, thanks.

> >+isp1301_clear(isp, ISP1301_I2C_MODE_CONTROL_1, ~MC1_SPEED_REG);
> >+isp1301_write(isp, ISP1301_I2C_MODE_CONTROL_1, MC1_SPEED_REG);
> >+isp1301_clear(isp, ISP1301_I2C_MODE_CONTROL_2, ~0);
> >+isp1301_write(isp, ISP1301_I2C_MODE_CONTROL_2, (MC2_BI_DI | MC2_PSW_EN
> >+| MC2_SPD_SUSP_CTRL));
> >+
> >+isp1301_clear(isp, ISP1301_I2C_OTG_CONTROL_1, ~0);
> >+isp1301_write(isp, ISP1301_I2C_MODE_CONTROL_1, MC1_DAT_SE0);
> >+isp1301_write(isp, ISP1301_I2C_OTG_CONTROL_1, (OTG1_DM_PULLDOWN
> >+| OTG1_DP_PULLDOWN));
> >+isp1301_clear(isp, ISP1301_I2C_OTG_CONTROL_1, (OTG1_DM_PULLUP
> >+| OTG1_DP_PULLUP));
> 
>() around | not necessary.

this one I'll keep as it aids readability.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/3] usb: phy: isp1301: give it a context structure

[Felipe Balbi]

On Fri, Mar 08, 2013 at 11:47:13PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 08-03-2013 15:30, Felipe Balbi wrote:
> 
> >this patch is a small preparation to fix
> >isp1301 driver so that other platforms can
> >use it.
> 
> >We're defining our private data structure
> >to represent this device and adding the
> >PHY to the PHY list.
> 
> >Later patches will come implementing proper
> >PHY API and removing bogus code from ohci_nxp
> >and lpc32xx_udc drivers.
> 
> >Signed-off-by: Felipe Balbi 
> >---
> >  drivers/usb/phy/phy-isp1301.c | 34 +-
> >  1 file changed, 33 insertions(+), 1 deletion(-)
> 
> >diff --git a/drivers/usb/phy/phy-isp1301.c b/drivers/usb/phy/phy-isp1301.c
> >index 18dbf7e..36c4d98 100644
> >--- a/drivers/usb/phy/phy-isp1301.c
> >+++ b/drivers/usb/phy/phy-isp1301.c
> [...]
> >@@ -23,14 +32,37 @@ static const struct i2c_device_id isp1301_id[] = {
> >  static struct i2c_client *isp1301_i2c_client;
> >
> >  static int isp1301_probe(struct i2c_client *client,
> >- const struct i2c_device_id *i2c_id)
> >+const struct i2c_device_id *i2c_id)
> 
>Is this change necessary?

yes.

hehe, seriously now. I'll revert it.

-- 
balbi


signature.asc
Description: Digital signature

RE: [PATCH 00/12] UVC gadget patches for v3.10

[Bhupesh SHARMA]

Hi Laurent,

> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Saturday, March 02, 2013 1:16 AM
> To: linux-usb@vger.kernel.org
> Cc: Bhupesh SHARMA; Cyril Roelandt; Chen Gang; Felipe Balbi
> Subject: [PATCH 00/12] UVC gadget patches for v3.10
> 
> Hello,
> 
> Here are the miscellaneous fixes and enhacements for the UVC gadget driver
> that I would like to push for v3.10.
> 
> All the patches have already been sent to the list, some of them in an older
> form. I've done my best to consolidate everything and take all comments
> into account. The USB 2.0 enumeration issue should be fixed.
> 
> Bhupesh, would you be able to test the set (without any additional patch) ? I
> will then send a pull request with your Tested-by lines. I will then wait for 
> the
> V4 of your "UVC webcam gadget related changes" patch set, rebased on top
> of this.
> 
> You can get all the patches from
> 
>   git://linuxtv.org/pinchartl/uvcvideo.git uvc-gadget

I tested the enumeration and basic class specific USB request transfer with 
this patchset both for:

- Super-Speed case: Using a PCIe(Gen2)-based-USB3 card from TI connected on a 
Fedora 17 Linux PC.
- High-Speed case: Using standard EHCI based card on a Fedora 17 Linux PC.

You can add my tested-by to the patchset for basic enumeration and 
class-specific request handling.
Note that the detailed data path checking will be possible after I add V4 of my 
UVC webcam gadget related changes.

Tested-by: Bhupesh Sharma 

I will send the V4 shortly.

Regards,
Bhupesh

> Bhupesh Sharma (4):
>   usb: gadget/uvc: Add fix for UVC compliance test suite assertion
> 6.3.90 failure
>   usb: gadget/uvc: Add fix for UVC compliance test suite's assertion
> 6.1.25 failure
>   usb: gadget/uvc: Delay the status stage when setting alternate
> setting 1
>   usb: gadget/uvc: Make video streaming buffer size comply with USB3.0
> SS
> 
> Chen Gang (1):
>   usb: gadget/uvc: Use strlcpy instead of strncpy
> 
> Cyril Roelandt (1):
>   usb: gadget/uvc: Use GFP_ATOMIC under spin lock
> 
> Laurent Pinchart (6):
>   usb: gadget/uvc: Clarify comment about string descriptors
>   usb: gadget/uvc: Rename STATUS_BYTECOUNT to
> UVC_STATUS_MAX_PACKET_SIZE
>   usb: gadget/uvc: Fix coding style issues introduced by SS support
>   usb: gadget/uvc: Merge the SS/HS/FS control endpoint descriptors
>   usb: gadget/uvc: Merge the streaming maxpacket and mult parameters
>   usb: gadget/uvc: Configure the streaming endpoint based on the speed
> 
>  drivers/usb/gadget/f_uvc.c | 262 --
> ---
>  drivers/usb/gadget/f_uvc.h |  12 +-
>  drivers/usb/gadget/uvc.h   |   1 +
>  drivers/usb/gadget/uvc_v4l2.c  |  20 +++-  drivers/usb/gadget/uvc_video.c |
> 13 +-
>  5 files changed, 162 insertions(+), 146 deletions(-)
> 
> --
> Regards,
> 
> Laurent Pinchart

--
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: PROBLEM: since linux kernel 3.8 Apple Cinema Display's usb hub spits errors randomly at boot.

[Jenya Y]

In 03/09/2013 06:10 AM, Jenya Y wrote:

On 03/09/2013 06:06 AM, Jenya Y wrote:
Thank you, I'll try setting them all to 'y' but right now they are 
all set as modules 'm'.

Lets see, I'll try it right away.


Sorry Alan, I tried it - no luck. The errors are still shining 
bravely at system start...



#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_XHCI_HCD is not set
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=y
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_EHCI_HCD_PLATFORM is not set
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_MUSB_HDRC is not set
# CONFIG_USB_CHIPIDEA is not set
# CONFIG_USB_RENESAS_USBHS is not set


I should've mentioned that the number of errors at last restart 
diminished considerably, but maybe it is just accidental. I noticed 
similar things on 3.8 too. Sometimes it's 4, sometimes it's 40.


 Here is the current dmesg from 3.9 gir master with the suggested 
changes.

Sorry used the wrong file, now it's the right one.

// Update
Alan, I'm happy to say that the errors disappeared. I recompiled the 
latest master from torvalds with USB_CONFIG=Y instead of 'm' and the 
errors are gone. I'm not sure it was this particular config flag + the 
settings you suggested earlier or simply the changes that were 
incorporated into the latest master but everything is working perfectly now.


Thank you very very much for you patience with me and I'll be glad to 
assist if you need any help figuring out what went right :)


Jenya
--
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 01/13] usb: phy: nop: Add device tree support and binding information

[Roger Quadros]

On 03/08/2013 05:45 PM, Marc Kleine-Budde wrote:
> On 03/08/2013 11:46 AM, Marc Kleine-Budde wrote:
>> On 02/04/2013 04:58 PM, Roger Quadros wrote:
>>> The PHY clock, clock rate, VCC regulator and RESET regulator
>>> can now be provided via device tree.
>>>
>>> Signed-off-by: Roger Quadros 
>>> ---
>>>  .../devicetree/bindings/usb/usb-nop-xceiv.txt  |   34 
>>> 
>>>  drivers/usb/otg/nop-usb-xceiv.c|   31 
>>> ++
>>>  2 files changed, 65 insertions(+), 0 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt 
>>> b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>>> new file mode 100644
>>> index 000..d7e2726
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>>> @@ -0,0 +1,34 @@
>>> +USB NOP PHY
>>> +
>>> +Required properties:
>>> +- compatible: should be usb-nop-xceiv
>>> +
>>> +Optional properties:
>>> +- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
>>> +  /bindings/clock/clock-bindings.txt
>>> +  This property is required if clock-frequency is specified.
>>> +
>>> +- clock-names: Should be "main_clk"
>>> +
>>> +- clock-frequency: the clock frequency (in Hz) that the PHY clock must
>>> +  be configured to.
>>> +
>>> +- vcc-supply: phandle to the regulator that provides RESET to the PHY.
>>> +
>>> +- reset-supply: phandle to the regulator that provides power to the PHY.
>>> +
>>> +Example:
>>> +
>>> +   hsusb1_phy {
>>> +   compatible = "usb-nop-xceiv";
>>> +   clock-frequency = <1920>;
>>
>> Why do you hardcode the clock frequency here? You should use
>> clk_get_rate() to get the frequency from the clock tree.
> 
> What about declaring a "fixed-clock" node in the device tree? Then it
> should be possible to keep the driver free of any omap specific code.
> 

The current implementation is not OMAP specific and is not limited to a
fixed frequency clock. The PHY driver is using standard clock APIs to set
the clock rate 'only' if the 'clock-frequency' property is present in the
device tree node.

What is the benefit of declaring it as a "fixed-clock"?
FYI. The clock may not necessarily be a fixed frequency clock and someone
needs to program the rate.

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

[PATCH] vers/usb/gadget: beautify code, delete useless comments

[Chen Gang]

  since parameter driver has been deleted, also need delete relative comments.
relative commit number is d93e2600d80fc41ccf339b4a2843a3007d479907

Signed-off-by: Chen Gang 
---
 drivers/usb/gadget/s3c-hsudc.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c
index 458965a..7da26cf 100644
--- a/drivers/usb/gadget/s3c-hsudc.c
+++ b/drivers/usb/gadget/s3c-hsudc.c
@@ -283,7 +283,6 @@ static void s3c_hsudc_nuke_ep(struct s3c_hsudc_ep *hsep, 
int status)
 /**
  * s3c_hsudc_stop_activity - Stop activity on all endpoints.
  * @hsudc: Device controller for which EP activity is to be stopped.
- * @driver: Reference to the gadget driver which is currently active.
  *
  * All the endpoints are stopped and any pending transfer requests if any on
  * the endpoint are terminated.
-- 
1.7.7.6
--
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] drivers/usb/gadget: beautify code, delete unused code

[Chen Gang]

于 2013年03月04日 22:35, Felipe Balbi 写道:
> since stop_activity() also gets called from RESET interrupt, and in that
> case we need to call driver->disconnect(). Can you make a simple test
> that would take current code and issue a device reset to see if that
> would break, then apply my suggestion above and run the same test again?

  after reference the commit: d93e2600d80fc41ccf339b4a2843a3007d479907
  it seems udc_start and udc_stop will have effect,
  so not need call driver->disconnect()

  is it correct ?

  thanks.

-- 
Chen Gang

Asianux Corporation
--
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] drivers/usb/gadget: beautify code, delete unused code

[Felipe Balbi]

On Mon, Mar 11, 2013 at 06:17:10PM +0800, Chen Gang wrote:
> 于 2013年03月04日 22:35, Felipe Balbi 写道:
> > since stop_activity() also gets called from RESET interrupt, and in that
> > case we need to call driver->disconnect(). Can you make a simple test
> > that would take current code and issue a device reset to see if that
> > would break, then apply my suggestion above and run the same test again?
> 
>   after reference the commit: d93e2600d80fc41ccf339b4a2843a3007d479907
>   it seems udc_start and udc_stop will have effect,
>   so not need call driver->disconnect()
> 
>   is it correct ?

in case of net2272.c and net2280.c, they call stop_activity() also from
disconnect and reset interrupt handlers, in that case the gadget driver
needs to know about the disconnect.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] drivers/usb/gadget: beautify code, delete unused code

[Chen Gang]

于 2013年03月11日 18:17, Chen Gang 写道:
> 于 2013年03月04日 22:35, Felipe Balbi 写道:
>> since stop_activity() also gets called from RESET interrupt, and in that
>> case we need to call driver->disconnect(). Can you make a simple test
>> that would take current code and issue a device reset to see if that
>> would break, then apply my suggestion above and run the same test again?
> 
>   after reference the commit: d93e2600d80fc41ccf339b4a2843a3007d479907
>   it seems udc_start and udc_stop will have effect,
>   so not need call driver->disconnect()
> 
>   is it correct ?
> 
>   thanks.
> 

  another reference commit: 6166c24669678662547bb4e5dbd6a810268b8b7b
  also seems udc_start and udc_stop will have effect.


-- 
Chen Gang

Asianux Corporation
--
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] vers/usb/gadget: beautify code, delete useless comments

[Felipe Balbi]

On Mon, Mar 11, 2013 at 06:14:19PM +0800, Chen Gang wrote:
> 
>   since parameter driver has been deleted, also need delete relative comments.
> relative commit number is d93e2600d80fc41ccf339b4a2843a3007d479907
> 
> Signed-off-by: Chen Gang 

please come up with a better Subject and commit log. Something along the
lines of:

usb: gadget: s3c-hsudc: delete outdated comment

since commit d93e260 (usb: gadget: s3c-hsudc: use udc_start and udc_stop
functions) the 'driver' parameter has been deleted from
s3c_hsudc_stop_activity() but its documentation was left outdated. This
patch deletes the comment since it makes no sense anymore.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] usb: gadget: s3c-hsudc: delete outdated comment

[Chen Gang]

since commit d93e260 (usb: gadget: s3c-hsudc: use udc_start and udc_stop
functions) the 'driver' parameter has been deleted from
s3c_hsudc_stop_activity() but its documentation was left outdated. This
patch deletes the comment since it makes no sense anymore.


Signed-off-by: Chen Gang 
---
 drivers/usb/gadget/s3c-hsudc.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c
index 458965a..7da26cf 100644
--- a/drivers/usb/gadget/s3c-hsudc.c
+++ b/drivers/usb/gadget/s3c-hsudc.c
@@ -283,7 +283,6 @@ static void s3c_hsudc_nuke_ep(struct s3c_hsudc_ep *hsep, 
int status)
 /**
  * s3c_hsudc_stop_activity - Stop activity on all endpoints.
  * @hsudc: Device controller for which EP activity is to be stopped.
- * @driver: Reference to the gadget driver which is currently active.
  *
  * All the endpoints are stopped and any pending transfer requests if any on
  * the endpoint are terminated.
-- 
1.7.7.6
--
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: pxa25x: fix disconnect reporting

[Felipe Balbi]

when commit 6166c24 (usb: gadget: pxa25x_udc:
convert to udc_start/udc_stop) converted
this driver to udc_start/udc_stop, it failed
to consider the fact that stop_activity()
is called from disconnect interrupt.

Fix the problem so that gadget drivers know
about proper disconnect sequences.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/gadget/pxa25x_udc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/gadget/pxa25x_udc.c b/drivers/usb/gadget/pxa25x_udc.c
index 9aa9dd5..d0f3748 100644
--- a/drivers/usb/gadget/pxa25x_udc.c
+++ b/drivers/usb/gadget/pxa25x_udc.c
@@ -1303,6 +1303,10 @@ stop_activity(struct pxa25x_udc *dev, struct 
usb_gadget_driver *driver)
}
del_timer_sync(&dev->timer);
 
+   /* report disconnect; the driver is already quiesced */
+   if (driver)
+   driver->disconnect(&dev->gadget);
+
/* re-init driver-visible data structures */
udc_reinit(dev);
 }
-- 
1.8.1.rc1.5.g7e0651a

--
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] drivers/usb/gadget: beautify code, delete unused code

[Chen Gang]

于 2013年03月11日 18:21, Felipe Balbi 写道:
> in case of net2272.c and net2280.c, they call stop_activity() also from
> disconnect and reset interrupt handlers, in that case the gadget driver
> needs to know about the disconnect.

  I guess your meaning is:
for net2272.c and net2280.c, we still need driver->disconnect. although for 
others do not need.

  if it is correct:
I will try to find another members which have relative HW to help us to 
test it.
  e.g. communicate with the relative company to help test their own product.
  e.g. find another relative members with net22??.c which have HW and can 
help us.

if I can not find other members to help us, I will try to find another ways.
  if so, maybe I need more time to do it.
  if so, I am sorry to have to delay the time point (2013-3-15)
and I guess the new time point is within a month (before 2013-4-15)

  all together: I beleive "ways is always more than issues".


BTW:
  I also add comments for your test program, please check whether it is ok, 
thanks.

--

/**
 * device-reset.c - Reset a USB device multiple times
 *
 * Copyright (C) 2013 Felipe Balbi 
 *
 * This file is part of the USB Verification Tools Project
 *
 * USB Tools is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public Liicense as published by
 * the Free Software Foundation, either version 3 of the license, or
 * (at your option) any later version.
 *
 * USB Tools is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with USB Tools. If not, see .
 *
 *
 * compiling:
 *   $(CROSS_COMPILE)gcc -Wall -O2 -g -lusb-1.0 -o device-reset device-reset.c
 * this file name is device-reset.c
 * it needs libusb.h (for fedora, package name is libusb1-devel)
 *
 * usage:
 *   [root@gchenlinux tmp]# ./device-reset -h
 *   ./device-reset -D VID:PID
 *   [root@gchenlinux tmp]# lsusb
 *   ...
 *   Bus 002 Device 003: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter
 *   ...
 *   [root@gchenlinux tmp]# ./device-reset -D 05e3:0718
 *
 * result:
 *   it will run 1 times.
 *   all printing lines should content PASSED, and should not content FAILED.
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 

#include 

#define OPTION(n, h, v) \
{   \
.name   = #n,   \
.has_arg= h,\
.val= v,\
}

static struct option device_reset_opts[] = {
OPTION("help",  0, 'h'),
OPTION("device",1, 'D'),
{  }/* Terminating entry */
};

static void usage(char *cmd)
{
fprintf(stdout, "%s -D VID:PID\n", cmd);
}

int main(int argc, char *argv[])
{
libusb_context  *context;
libusb_device_handle*udevh;

unsignedvid = 0;
unsignedpid = 0;

int ret = 0;
int i;

while (1) {
int optidx;
int opt;

char*token;

opt = getopt_long(argc, argv, "D:h", device_reset_opts, 
&optidx);
if (opt == -1)
break;

switch (opt) {
case 'D':
token = strtok(optarg, ":");
vid = strtoul(token, NULL, 16);
token = strtok(NULL, ":");
pid = strtoul(token, NULL, 16);
break;
case 'h': /* FALLTHROUGH */
default:
usage(argv[0]);
exit(-1);
}
}

libusb_init(&context);

udevh = libusb_open_device_with_vid_pid(context, vid, pid);
if (!udevh) {
perror("open");
ret = -ENODEV;
goto out0;
}

for (i = 0; i < 1; i++) {
ret = libusb_reset_device(udevh);
printf("Reset #%d: ", i + 1);

if (ret < 0) {
printf("FAILED\n");
break;
} else {
printf("PASSED\n");
}
}

libusb_close(udevh);

out0:
libusb_exit(context);

return ret;
}

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

Re: [PATCH] drivers/usb/gadget: beautify code, delete unused code

[Felipe Balbi]

On Mon, Mar 11, 2013 at 06:42:25PM +0800, Chen Gang wrote:
> if I can not find other members to help us, I will try to find another 
> ways.

code inspection works most of the time.

>   all together: I beleive "ways is always more than issues".
> 
> 
> BTW:
>   I also add comments for your test program, please check whether it
>   is ok, thanks.

sure, it's alright.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] drivers/usb/gadget: beautify code, delete unused code

[Chen Gang]

于 2013年03月11日 18:50, Felipe Balbi 写道:
> On Mon, Mar 11, 2013 at 06:42:25PM +0800, Chen Gang wrote:
>> > if I can not find other members to help us, I will try to find another 
>> > ways.
> code inspection works most of the time.
> 

  excuse me, my English is not quite well, could you describe it with more 
details ?

  thanks.


-- 
Chen Gang

Asianux Corporation
--
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] drivers/usb/gadget: beautify code, delete unused code

[Felipe Balbi]

On Mon, Mar 11, 2013 at 07:03:02PM +0800, Chen Gang wrote:
> 于 2013年03月11日 18:50, Felipe Balbi 写道:
> > On Mon, Mar 11, 2013 at 06:42:25PM +0800, Chen Gang wrote:
> >> > if I can not find other members to help us, I will try to
> >> > find another ways.
> > code inspection works most of the time.
> > 
>   excuse me, my English is not quite well, could you describe it with
>   more details ?

I mean just reading the code and understanding what it does. When you
don't have HW to test, it's the only way to patch the driver.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] drivers/usb/gadget: beautify code, delete unused code

[Chen Gang F T]

于 2013年03月11日 19:07, Felipe Balbi 写道:
> I mean just reading the code and understanding what it does. When you
> don't have HW to test, it's the only way to patch the driver.

  ok, thanks.

  and I still try to find another ways, at least within this week (before 
2013-03-15).

  thanks again.

-- 
Chen Gang

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

[GIT PULL] USB patches

[Felipe Balbi]

Hi Greg,

Here's my second set of fixes for this -rc cycle. Since my previous pull
request didn't reach v3.9-rc2, this one is based out of the previous.

Surprised to see that git gracefully found a common commit by just running:

$ git request-pull greg/usb-linus usb fixes-for-v3.9-rc3

(usb is my remote to kernel.org)

Anyway, let me know if you have any issues. I have merged this tag on top of
your greg/usb-linus branch just to make sure there'd be no conflicts and it
merges just fine.

cheers

The following changes since commit 29240e2392786c39007df2f4162f3dc4680f3dec:

  usb: gadget: u_uac1: NULL dereference on error path (2013-03-04 13:16:45 
+0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
tags/fixes-for-v3.9-rc3

for you to fetch changes up to 66e4afc77f76653460d7eb31ec793506ada1ad33:

  usb: gadget: pxa25x: fix disconnect reporting (2013-03-11 12:40:31 +0200)


usb: fixes for v3.9-rc3

Most fixes are on 'musb' driver. There's a sparse warning
fix which marks omap2430_glue as static, a build warning
fix which was found with randconfig, a fix for omap_musb_mailbox
check and removal of 'select' from musb's Kconfig to prevent
Kconfig warnings.

Other than that, pxa25x got a fix which was introduced by the
latest conversion to udc_start/udc_stop patchset, kernel-doc
warnings for composite layer  and dwc3 got a build fix on
sparc64.


Aaro Koskinen (2):
  usb: musb: omap2430: fix omap_musb_mailbox glue check again
  usb: musb: omap2430: fix sparse warning

Andrew Morton (1):
  usb: dwc3: ep0: fix sparc64 build

Felipe Balbi (3):
  usb: musb: remove all 'select' from Kconfig
  usb: musb: fix compile warning
  usb: gadget: pxa25x: fix disconnect reporting

Nishanth Menon (1):
  usb: gadget: composite: fix kernel-doc warnings

 drivers/usb/dwc3/ep0.c  |  7 ---
 drivers/usb/gadget/composite.c  |  5 +
 drivers/usb/gadget/pxa25x_udc.c |  4 
 drivers/usb/musb/Kconfig|  5 -
 drivers/usb/musb/musb_core.c|  2 --
 drivers/usb/musb/omap2430.c | 12 
 include/linux/usb/composite.h   |  3 ++-
 7 files changed, 19 insertions(+), 19 deletions(-)
--
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] vers/usb/gadget: beautify code, delete useless comments

[Sergei Shtylyov]

Hello.

On 11-03-2013 14:14, Chen Gang wrote:

>since parameter driver has been deleted, also need delete relative 
> comments.
>  relative

   You probably meant "related" in both cases?

> commit number is d93e2600d80fc41ccf339b4a2843a3007d479907

   Please also specify that commit's summary line in parens (or however you 
like).

> Signed-off-by: Chen Gang 

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: About USBADRA bit at DEVICEADDR for chipidea driver

[Alexander Shishkin]

Peter Chen  writes:

> On Fri, Mar 08, 2013 at 04:06:30PM +0200, Alexander Shishkin wrote:
>> Peter Chen  writes:
>> 
>> > On Fri, Mar 08, 2013 at 12:39:04PM +0200, Alexander Shishkin wrote:
>> >> Peter Chen  writes:
>> >> 
>> >> > Hi David
>> >> 
>> >> Hi,
>> >> 
>> >> > I notice at your code for hw_usb_set_address, there is a comment for it
>> >> > /**
>> >> >  * This function explicitly sets the address, without the "USBADRA" 
>> >> > (advance)
>> >> >  * feature, which is not supported by older versions of the controller.
>> >> >  */
>> >> 
>> >> That's mine. David's original driver did use USBADRA. I removed it
>> >> because it's not supported by some versions of chipidea, for example the
>> >> one that Marvell integrated in their kirkwood SoCs.
>> >> 
>> >> > If we use USB3.0 host for CV test, we must use this bit, or the host
>> >> > may send GET_DESCRIPTOR before the controller set address.
>> >> 
>> >> That's because we don't have the state machine for ep0 currently,
>> >> USBADRA has nothing to do with it.
>> >
>> > Can you explain more? As far as I know, it is the completion of set_address
>> > cost too much time that the host sends next command before device
>> > sets address.
>> 
>> USBADRA doesn't magically speed up anything. It's a convenience thing
>> that lets you set the controller's address register value straight away
>> instead of deferring it till after status phase of
>> SET_ADDRESS. The status phase won't happen any sooner than normally.
>> 
>
> Correct, but the problem is after the status phase finished, when 
> the software can set address without using USBADRA? Assuming the busy system,
> the interrupt latecy, etc?
>
> For USB 3.0 host CV test, the host sends GET_DESCRIPTOR very quick (<500us)
> once it accept the status of SET_ADDRESS

The USB 2.0 spec says the recovery period after the status phase of
SetAddress is 2ms. That should be enough to process the transfer
completion interrupt, shouldn't it?
Why is USB 3 CV violating this and why should we care? I guess, if we
really want to, we can make USBADRA usage conditional, BUT something
tells me that there will be more arbitrary timing expectations then that
we won't necessarily be able to meet.

Regards,
--
Alex
--
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: About USBADRA bit at DEVICEADDR for chipidea driver

[Chen Peter-B29397]

 
> >
> > For USB 3.0 host CV test, the host sends GET_DESCRIPTOR very quick
> (<500us)
> > once it accept the status of SET_ADDRESS
> 
> The USB 2.0 spec says the recovery period after the status phase of
> SetAddress is 2ms. That should be enough to process the transfer
> completion interrupt, shouldn't it?
> Why is USB 3 CV violating this and why should we care? I guess, if we
> really want to, we can make USBADRA usage conditional, BUT something
> tells me that there will be more arbitrary timing expectations then that
> we won't necessarily be able to meet.
> 

I will investigate it more after finishing several chipidea related patches.

> Regards,
> --
> Alex


--
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/core/devio.c: Don't use GFP_KERNEL while we cannot reset a storage device

[Ming Lei]

On Sat, Mar 9, 2013 at 12:50 AM, Alexey Khoroshilov
 wrote:
> As it was described by Oliver Neukum in commit acbe2fe
> "USB: Don't use GFP_KERNEL while we cannot reset a storage device":
>
>   Memory allocations with GFP_KERNEL can cause IO to a storage device
>   which can fail resulting in a need to reset the device. Therefore
>   GFP_KERNEL cannot be safely used between usb_lock_device()
>   and usb_unlock_device(). Replace by GFP_NOIO.
>
> The patch fixes the same issue in usb/core/devio.c.
> All the allocations fixed are under usb_lock_device() from usbdev_do_ioctl().

I am wondering why the device lock is needed for usbdev_do_ioctl()? Looks
device lock isn't required for USB transfer of kernel driver.


Thanks,
-- 
Ming Lei
--
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: fsl_udc_core: set address request aren't handled like expected. usb30cv test suite fails.

[Peter Bestler]

On Fri, Mar 08, 2013 at 11:54:41AM +0200, Felipe Balbi wrote:
> On Fri, Mar 08, 2013 at 05:38:53PM +0800, Peter Chen wrote:
> > On Thu, Mar 07, 2013 at 09:58:52AM +0100, Peter Bestler wrote:
> > > Hi,
> > > 
> > > We try to get our device (based on p2020rdb) usb 2.0 compliant. We ran 
> > > the usb30cv test suite (version 1.0.1.2, chapter 9 tests for usb 2.0 
> > > devices) on win7 with g_zero and g_serial. We access the device via an 
> > > usb 3.0 hcd from intel. Our device runs the 3.2.35-rt52 kernel. I spotted 
> > > the following problem with ch9setaddress in fsl_udc_core.c.
> > > 
> > > All tests passed on single execution. At running it in batch mode the 
> > > first test after switching from default to adressed state failed. The 
> > > subsequent tests passed. It doesn't depend on the selected tests, only on 
> > > the switch over from default to adressed. It fails with our custom 
> > > gadgetfs driver too. Another device with Intel PXA25x and the same setup 
> > > passes all tests.
> > > 
> > > With the total phase usbsniffer i spotted the following behavior:
> > > The test issues a setAddress and receives an ACK, 125 us afterwards the 
> > > host issues a getDescriptor (setuptx) request, which fails at setuptx. 
> > > The USB sniffer reports invalid PID sequence.
> > > 
> > > For debugging purpose I delayed the dma_map_single in ep0_prime_status  
> > > (which does the ACK, right?) by 2 milliseconds. And all tests are passing 
> > > in batch mode. It's quite the same sequence on the bus, but between 
> > > setAdress and its ACK is a delay of 3 ms.
> > > 
> > > I think delaying the ACK in set request isn't the way to go. I think we 
> > > set the address too early; we have to wait until the status phase of the 
> > > set address has finished. My understanding is that the device has to 
> > > respond to address 0 until the complete status phase of setAddress is 
> > > passed (is this correct).
> > > 
> > > Has anybody ran the usb30cv on fsl_udc recently? 
> > > 
> > > After applying the patch f79a60b8785 none of the tests run anymore. Did I 
> > > miss anything here?  How can we fix this issue?
> > > 
> > > Best regards 
> > > 
> > > Peter
> > > 
> > > --- Patch for debugging ---
> > > diff --git a/drivers/usb/gadget/fsl_udc_core.c 
> > > b/drivers/usb/gadget/fsl_udc_core.c
> > > index 55abfb6..fdbfd25 100644
> > > --- a/drivers/usb/gadget/fsl_udc_core.c
> > > +++ b/drivers/usb/gadget/fsl_udc_core.c
> > > @@ -1285,6 +1285,7 @@ static int ep0_prime_status(struct fsl_udc *udc, 
> > > int direction)
> > > req->req.complete = NULL;
> > > req->dtd_count = 0;
> > >  
> > > +   udelay(2000);
> > > req->req.dma = dma_map_single(ep->udc->gadget.dev.parent,
> > > req->req.buf, req->req.length,
> > > ep_is_in(ep) ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
> > > 
> > > 
> > > 
> > > 
> > 
> > Please check your datasheet if your controller has USBADRA bit
> > at DEVICEADDR, if it exists, it means your controller supports
> > advance store device address function. Please have a try for 
> > below change, if it fixes your problem, please give a tested-by,
> > then, I can make change for chipidea and fsl-core driver.
> > 
> > diff --git a/drivers/usb/gadget/fsl_udc_core.c 
> > b/drivers/usb/gadget/fsl_udc_core.c
> > index 04d5fef..a75c884 100644
> > --- a/drivers/usb/gadget/fsl_udc_core.c
> > +++ b/drivers/usb/gadget/fsl_udc_core.c
> > @@ -1335,10 +1335,14 @@ static void udc_reset_ep_queue(struct fsl_udc *udc, 
> > u8 pipe)
> >   */
> >  static void ch9setaddress(struct fsl_udc *udc, u16 value, u16 index, u16 
> > length)
> >  {
> > -   /* Save the new address to device struct */
> > udc->device_address = (u8) value;
> > +   /* Set the new address */
> > +   fsl_writel(((u32)value << USB_DEVICE_ADDRESS_BIT_POS)| 
> > +   (1 << USB_DEVICE_ADDRESS_BIT_POS),
> 
> do you mean:
> 
> (u32) ((value << USB_DEVICE_ADDRESS_BIT_POS) |
>   (1 << USB_DEVICE_ADDRESS_BIT_POS))
> 
> ??
> 
> Also, why do you need the extra (1 << USB_DEVICE_ADDRESS_BIT_POS) ?
> 
> You'd be making all addresses odd, no ?

Sorry, my wrong, should be below:

diff --git a/drivers/usb/gadget/fsl_udc_core.c 
b/drivers/usb/gadget/fsl_udc_core.c
index 04d5fef..b0e78e6 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -1335,10 +1335,14 @@ static void udc_reset_ep_queue(struct fsl_udc *udc, u8 
pipe)
  */
 static void ch9setaddress(struct fsl_udc *udc, u16 value, u16 index, u16 
length)
 {
-   /* Save the new address to device struct */
udc->device_address = (u8) value;
+   /* Set the new address */
+   fsl_writel(((u32)value << USB_DEVICE_ADDRESS_BIT_POS)| 
+   (1 << USB_DEVICE_ADDRESS_ADV_BIT_POS),
+   &dr_regs->deviceaddr);
/* Update usb state */
udc->usb_state = USB_STATE_ADDRESS;
+
/* Status phase */
if (ep0_prime_status(udc, EP_DI

Re: [PATCH 00/12] UVC gadget patches for v3.10

[Laurent Pinchart]

Hi Bhupesh,

On Monday 11 March 2013 15:07:05 Bhupesh SHARMA wrote:
> On Saturday, March 02, 2013 1:16 AM Laurent Pinchart wrote:
> > 
> > Hello,
> > 
> > Here are the miscellaneous fixes and enhacements for the UVC gadget driver
> > that I would like to push for v3.10.
> > 
> > All the patches have already been sent to the list, some of them in an
> > older form. I've done my best to consolidate everything and take all
> > comments into account. The USB 2.0 enumeration issue should be fixed.
> > 
> > Bhupesh, would you be able to test the set (without any additional patch)
> > ? I will then send a pull request with your Tested-by lines. I will then
> > wait for the V4 of your "UVC webcam gadget related changes" patch set,
> > rebased on top of this.
> > 
> > You can get all the patches from
> > 
> > git://linuxtv.org/pinchartl/uvcvideo.git uvc-gadget
> 
> I tested the enumeration and basic class specific USB request transfer with
> this patchset both for:
> 
> - Super-Speed case: Using a PCIe(Gen2)-based-USB3 card from TI connected on
> a Fedora 17 Linux PC. - High-Speed case: Using standard EHCI based card on
> a Fedora 17 Linux PC.
> 
> You can add my tested-by to the patchset for basic enumeration and
> class-specific request handling. Note that the detailed data path checking
> will be possible after I add V4 of my UVC webcam gadget related changes.
> 
> Tested-by: Bhupesh Sharma 

Thanks a lot.

Felipe, I've added the Tested-by line to the patches and pushed the result to

git://linuxtv.org/pinchartl/uvcvideo.git uvc-gadget

You can also pick the patches from the list if that's easier for you.

-- 
Regards,

Laurent Pinchart

--
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: About USBADRA bit at DEVICEADDR for chipidea driver

[Alan Stern]

On Mon, 11 Mar 2013, Alexander Shishkin wrote:

> > For USB 3.0 host CV test, the host sends GET_DESCRIPTOR very quick (<500us)
> > once it accept the status of SET_ADDRESS
> 
> The USB 2.0 spec says the recovery period after the status phase of
> SetAddress is 2ms. That should be enough to process the transfer
> completion interrupt, shouldn't it?
> Why is USB 3 CV violating this and why should we care? I guess, if we

Probably because the recovery period, being in the USB 2.0 spec,
applies to USB-2 devices -- whereas the USB-3 CV tries to test USB-3
devices.  Do they have the same recovery period?

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: Use resource_size function

[Alan Stern]

On Sun, 10 Mar 2013, Paul Vlase wrote:

> Signed-off-by: Paul Vlase 
> ---
>  drivers/usb/host/ehci-mv.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
> index 3065809..5cd9f96 100644
> --- a/drivers/usb/host/ehci-mv.c
> +++ b/drivers/usb/host/ehci-mv.c
> @@ -225,7 +225,7 @@ static int mv_ehci_probe(struct platform_device *pdev)
>   (void __iomem *) ((unsigned long) ehci_mv->cap_regs + offset);
>  
>   hcd->rsrc_start = r->start;
> - hcd->rsrc_len = r->end - r->start + 1;
> + hcd->rsrc_len = resource_size(r);
>   hcd->regs = ehci_mv->op_regs;
>  
>   hcd->irq = platform_get_irq(pdev, 0);

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: PROBLEM: since linux kernel 3.8 Apple Cinema Display's usb hub spits errors randomly at boot.

[Alan Stern]

On Mon, 11 Mar 2013, Jenya Y wrote:

> // Update
> Alan, I'm happy to say that the errors disappeared. I recompiled the 
> latest master from torvalds with USB_CONFIG=Y instead of 'm' and the 
> errors are gone. I'm not sure it was this particular config flag + the 
> settings you suggested earlier or simply the changes that were 
> incorporated into the latest master but everything is working perfectly now.
> 
> Thank you very very much for you patience with me and I'll be glad to 
> assist if you need any help figuring out what went right :)

Well, I'd like to take the credit for this but I don't really deserve 
it.  :-)

The problem you had is a valid one and it deserves to be fixed.  
People should not have to select particular combinations of config 
options in order to avoid a ton of error messages.

I'll try to work out a patch in the next few days.  Can you recreate
the arrangement where all the errors occurred, in order to test the
patch when it is ready?

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

[PATCH -next] USB: misc: usb3503: use module_i2c_driver to simplify the code

[Wei Yongjun]

From: Wei Yongjun 

Use the module_i2c_driver() macro to make the code smaller
and a bit simpler.

Signed-off-by: Wei Yongjun 
---
 drivers/usb/misc/usb3503.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index f713f6a..d3a1cce 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -307,18 +307,7 @@ static struct i2c_driver usb3503_driver = {
.id_table   = usb3503_id,
 };
 
-static int __init usb3503_init(void)
-{
-   return i2c_add_driver(&usb3503_driver);
-}
-
-static void __exit usb3503_exit(void)
-{
-   i2c_del_driver(&usb3503_driver);
-}
-
-module_init(usb3503_init);
-module_exit(usb3503_exit);
+module_i2c_driver(usb3503_driver);
 
 MODULE_AUTHOR("Dongjin Kim ");
 MODULE_DESCRIPTION("USB3503 USB HUB driver");

--
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: REQUEST : Some help to write a new driver for LEAP motion device

[Greg KH]

On Sun, Mar 10, 2013 at 07:52:55PM +0100, LECOQ Vincent wrote:
> Hello Dears,
> 
> I have near me 2 piece of the Leap Motion device released as
> developpers release kits. (http://www.leapmotion.com/)
> The constructor give me only drivers for Microsoft ans Apple
> environements, and of course closed source.
> I ve have install a virtualbox with an windows environement and
> initialize the device, play some minute with.
> 
> During this time I ve record the usbmon output that You can found
> here : http://oktail.org/download/dump_usb
> 
> 
> Somebody can help me to understand this trace and start the linux driver ?

Why not try asking the company if they will provide the specs for how to
talk to the device, so that we can make a USB driver for Linux in a much
easier manner?

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: [GIT PULL] USB patches

[Greg KH]

On Mon, Mar 11, 2013 at 01:14:36PM +0200, Felipe Balbi wrote:
> Hi Greg,
> 
> Here's my second set of fixes for this -rc cycle. Since my previous pull
> request didn't reach v3.9-rc2, this one is based out of the previous.

That is fine, due to my travels last week, I didn't get a chance to get
stuff to Linus.  I should catch up this week.

> Surprised to see that git gracefully found a common commit by just running:
> 
>   $ git request-pull greg/usb-linus usb fixes-for-v3.9-rc3
> 
> (usb is my remote to kernel.org)
> 
> Anyway, let me know if you have any issues. I have merged this tag on top of
> your greg/usb-linus branch just to make sure there'd be no conflicts and it
> merges just fine.
> 
> cheers
> 
> The following changes since commit 29240e2392786c39007df2f4162f3dc4680f3dec:
> 
>   usb: gadget: u_uac1: NULL dereference on error path (2013-03-04 13:16:45 
> +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/fixes-for-v3.9-rc3

Pulled and pushed out, 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

[PATCH] usb/gadget: FunctionFS: Fix enable multiple instances

[Andrzej Pietrasiewicz]

This patch fixes an "off-by-one" bug found in
581791f5c7a480b2cc3431af9a6e799ffd51eb5e.
During gfs_bind/gfs_unbind the functionfs_bind/functionfs_unbind should be
called for every functionfs instance. With the "i" pre-decremented they
were not called for the zeroth instance.

Signed-off-by: Andrzej Pietrasiewicz 
Signed-off-by: Kyungmin Park 
Cc: 

---
 drivers/usb/gadget/g_ffs.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/g_ffs.c b/drivers/usb/gadget/g_ffs.c
index d3ace90..919177b 100644
--- a/drivers/usb/gadget/g_ffs.c
+++ b/drivers/usb/gadget/g_ffs.c
@@ -358,7 +358,7 @@ static int gfs_bind(struct usb_composite_dev *cdev)
if (unlikely(ret < 0))
goto error;
 
-   for (i = func_num; --i; ) {
+   for (i = func_num; i--; ) {
ret = functionfs_bind(ffs_tab[i].ffs_data, cdev);
if (unlikely(ret < 0)) {
while (++i < func_num)
@@ -413,7 +413,7 @@ static int gfs_unbind(struct usb_composite_dev *cdev)
gether_cleanup();
gfs_ether_setup = false;
 
-   for (i = func_num; --i; )
+   for (i = func_num; i--; )
if (ffs_tab[i].ffs_data)
functionfs_unbind(ffs_tab[i].ffs_data);
 
-- 
1.7.0.4

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

Re: [PATCH] usb/core/devio.c: Don't use GFP_KERNEL while we cannot reset a storage device

[Alan Stern]

On Mon, 11 Mar 2013, Ming Lei wrote:

> On Sat, Mar 9, 2013 at 12:50 AM, Alexey Khoroshilov
>  wrote:
> > As it was described by Oliver Neukum in commit acbe2fe
> > "USB: Don't use GFP_KERNEL while we cannot reset a storage device":
> >
> >   Memory allocations with GFP_KERNEL can cause IO to a storage device
> >   which can fail resulting in a need to reset the device. Therefore
> >   GFP_KERNEL cannot be safely used between usb_lock_device()
> >   and usb_unlock_device(). Replace by GFP_NOIO.
> >
> > The patch fixes the same issue in usb/core/devio.c.
> > All the allocations fixed are under usb_lock_device() from 
> > usbdev_do_ioctl().
> 
> I am wondering why the device lock is needed for usbdev_do_ioctl()? Looks
> device lock isn't required for USB transfer of kernel driver.

Of course you have to lock the device before changing its driver.  What 
would happen if two different threads tried to change a device's driver 
at the same time?

usbdev_do_ioctl() needs to acquire the device lock in order to prevent 
races with driver_disconnect() and usbdev_remove().

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/core/devio.c: Don't use GFP_KERNEL while we cannot reset a storage device

[Ming Lei]

On Mon, Mar 11, 2013 at 11:32 PM, Alan Stern  wrote:
>
> Of course you have to lock the device before changing its driver.  What
> would happen if two different threads tried to change a device's driver
> at the same time?

Yes, claim/release interface need device lock, but the patch doesn't
touch claim/release command handling.

>
> usbdev_do_ioctl() needs to acquire the device lock in order to prevent
> races with driver_disconnect() and usbdev_remove().

Looks the patch basically converts the allocation inside URB submit path,
and actually I mean why we need to hold device lock in submitting
URB path?  Device lock isn't required before submitting URBs
in kernel driver.


Thanks,
-- 
Ming Lei
--
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 01/13] usb: phy: nop: Add device tree support and binding information

[Marc Kleine-Budde]

On 02/05/2013 08:26 AM, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Feb 04, 2013 at 05:58:48PM +0200, Roger Quadros wrote:
>> The PHY clock, clock rate, VCC regulator and RESET regulator
>> can now be provided via device tree.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  .../devicetree/bindings/usb/usb-nop-xceiv.txt  |   34 
>> 
>>  drivers/usb/otg/nop-usb-xceiv.c|   31 ++
>>  2 files changed, 65 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt 
>> b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> new file mode 100644
>> index 000..d7e2726
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> @@ -0,0 +1,34 @@
>> +USB NOP PHY
>> +
>> +Required properties:
>> +- compatible: should be usb-nop-xceiv
>> +
>> +Optional properties:
>> +- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
>> +  /bindings/clock/clock-bindings.txt
>> +  This property is required if clock-frequency is specified.
>> +
>> +- clock-names: Should be "main_clk"
>> +
>> +- clock-frequency: the clock frequency (in Hz) that the PHY clock must
>> +  be configured to.
>> +
>> +- vcc-supply: phandle to the regulator that provides RESET to the PHY.
>> +
>> +- reset-supply: phandle to the regulator that provides power to the PHY.
>> +
>> +Example:
>> +
>> +hsusb1_phy {
>> +compatible = "usb-nop-xceiv";
>> +clock-frequency = <1920>;
>> +clocks = <&osc 0>;
>> +clock-names = "main_clk";
>> +vcc-supply = <&hsusb1_vcc_regulator>;
>> +reset-supply = <&hsusb1_reset_regulator>;
>> +};
>> +
>> +hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
>> +and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
>> +hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
>> +controls RESET.
>> diff --git a/drivers/usb/otg/nop-usb-xceiv.c 
>> b/drivers/usb/otg/nop-usb-xceiv.c
>> index ac027a1..adbb7ab 100644
>> --- a/drivers/usb/otg/nop-usb-xceiv.c
>> +++ b/drivers/usb/otg/nop-usb-xceiv.c
>> @@ -34,6 +34,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  struct nop_usb_xceiv {
>>  struct usb_phy  phy;
>> @@ -138,8 +139,19 @@ static int nop_set_host(struct usb_otg *otg, struct 
>> usb_bus *host)
>>  return 0;
>>  }
>>  
>> +static void nop_xeiv_get_dt_pdata(struct device *dev,
> 
> asking to remove, but xeiv != xceiv :-)
> 
>> +struct nop_usb_xceiv_platform_data *pdata)
>> +{
>> +struct device_node *node = dev->of_node;
>> +u32 clk_rate;
>> +
>> +if (!of_property_read_u32(node, "clock-frequency", &clk_rate))
>> +pdata->clk_rate = clk_rate;
>> +}
>> +
>>  static int nop_usb_xceiv_probe(struct platform_device *pdev)
>>  {
>> +struct device *dev = &pdev->dev;
>>  struct nop_usb_xceiv_platform_data *pdata = pdev->dev.platform_data;
>>  struct nop_usb_xceiv*nop;
>>  enum usb_phy_type   type = USB_PHY_TYPE_USB2;
>> @@ -153,6 +165,17 @@ static int nop_usb_xceiv_probe(struct platform_device 
>> *pdev)
>>  if (!nop->phy.otg)
>>  return -ENOMEM;
>>  
>> +if (dev->of_node) {
>> +pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> +if (!pdata) {
>> +dev_err(dev, "Memory allocation failure\n");
>> +return -ENOMEM;
>> +}
>> +nop_xeiv_get_dt_pdata(dev, pdata);
> 
> actually, I would prefer to not create pdata at all. I mean, ideally
> pdata would be used to initialize fields in your own structure, so first
> move clk_rate to your own private structure, copy pdata's clk_rate value
> to that, then you don't need this hackery when using DT.

As far as I can see, clk_rate is never used, but in the probe function.
Why should it be saved into the private data structure at all?

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 01/13] usb: phy: nop: Add device tree support and binding information

[Marc Kleine-Budde]

On 03/11/2013 09:40 AM, Roger Quadros wrote:
> On 03/08/2013 05:45 PM, Marc Kleine-Budde wrote:
>> On 03/08/2013 11:46 AM, Marc Kleine-Budde wrote:
>>> On 02/04/2013 04:58 PM, Roger Quadros wrote:
 The PHY clock, clock rate, VCC regulator and RESET regulator
 can now be provided via device tree.

 Signed-off-by: Roger Quadros 
 ---
  .../devicetree/bindings/usb/usb-nop-xceiv.txt  |   34 
 
  drivers/usb/otg/nop-usb-xceiv.c|   31 
 ++
  2 files changed, 65 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt

 diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt 
 b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
 new file mode 100644
 index 000..d7e2726
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
 @@ -0,0 +1,34 @@
 +USB NOP PHY
 +
 +Required properties:
 +- compatible: should be usb-nop-xceiv
 +
 +Optional properties:
 +- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
 +  /bindings/clock/clock-bindings.txt
 +  This property is required if clock-frequency is specified.
 +
 +- clock-names: Should be "main_clk"
 +
 +- clock-frequency: the clock frequency (in Hz) that the PHY clock must
 +  be configured to.
 +
 +- vcc-supply: phandle to the regulator that provides RESET to the PHY.
 +
 +- reset-supply: phandle to the regulator that provides power to the PHY.
 +
 +Example:
 +
 +  hsusb1_phy {
 +  compatible = "usb-nop-xceiv";
 +  clock-frequency = <1920>;
>>>
>>> Why do you hardcode the clock frequency here? You should use
>>> clk_get_rate() to get the frequency from the clock tree.
>>
>> What about declaring a "fixed-clock" node in the device tree? Then it
>> should be possible to keep the driver free of any omap specific code.
>>
> 
> The current implementation is not OMAP specific and is not limited to a
> fixed frequency clock. The PHY driver is using standard clock APIs to set
> the clock rate 'only' if the 'clock-frequency' property is present in the
> device tree node.
> 
> What is the benefit of declaring it as a "fixed-clock"?
> FYI. The clock may not necessarily be a fixed frequency clock and someone
> needs to program the rate.

Okay, now I got it.

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 02/13] USB: phy: nop: Defer probe if device needs VCC/RESET

[Marc Kleine-Budde]

On 02/05/2013 10:43 AM, Roger Quadros wrote:
> On 02/05/2013 11:09 AM, Felipe Balbi wrote:
>> On Tue, Feb 05, 2013 at 10:44:05AM +0200, Roger Quadros wrote:
> diff --git a/include/linux/usb/nop-usb-xceiv.h 
> b/include/linux/usb/nop-usb-xceiv.h
> index 3265b61..148d351 100644
> --- a/include/linux/usb/nop-usb-xceiv.h
> +++ b/include/linux/usb/nop-usb-xceiv.h
> @@ -6,6 +6,10 @@
>   struct nop_usb_xceiv_platform_data {
>   enum usb_phy_type type;
>   unsigned long clk_rate;
> +
> +/* if set fails with -EPROBE_DEFER if can't get regulator */
> +unsigned int needs_vcc:1;
> +unsigned int needs_reset:1;

 how about u8 here?
>>>
>>> Not sure. Bitfields are usually defined as unsigned int.
>>
>> IIRC the benefit is that compiler can try to optimize those flags. I
>> mean, if you have 32 1-bit flags, compiler will combine those in a
>> single u32. Someone correct me if I'm wrong.
>>
> 
> Yes you are right. Kishon was asking me to use u8 instead of unsigned int, 
> which
> I don't think is necessary. AFAIK, it is a norm to use unsigned int when 
> defining
> a bitfield. Compilers are known to behave funny with bitfields. I don't mind
> using bool for each.

In the current version (rogerq/v3.8-usbhost17-dt) of this patch you've
put both needs_* into the private data struct and the pdata, but it's
only used inside the probe function.

regards,
Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] usb/core/devio.c: Don't use GFP_KERNEL while we cannot reset a storage device

[Alan Stern]

On Mon, 11 Mar 2013, Ming Lei wrote:

> On Mon, Mar 11, 2013 at 11:32 PM, Alan Stern  
> wrote:
> >
> > Of course you have to lock the device before changing its driver.  What
> > would happen if two different threads tried to change a device's driver
> > at the same time?
> 
> Yes, claim/release interface need device lock, but the patch doesn't
> touch claim/release command handling.

Then why did you ask?  You wrote: "Looks device lock isn't required for
USB transfer of kernel driver."


> > usbdev_do_ioctl() needs to acquire the device lock in order to prevent
> > races with driver_disconnect() and usbdev_remove().
> 
> Looks the patch basically converts the allocation inside URB submit path,
> and actually I mean why we need to hold device lock in submitting
> URB path?  Device lock isn't required before submitting URBs
> in kernel driver.

In general it isn't, no.  But usbfs uses the lock to prevent races with 
driver_disconnect() -- it is invalid to submit URBs after the 
disconnect routine has returned.

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: FunctionFS: Fix enable multiple instances

[Michal Nazarewicz]

On Mon, Mar 11 2013, Andrzej Pietrasiewicz wrote:
> This patch fixes an "off-by-one" bug found in
> 581791f5c7a480b2cc3431af9a6e799ffd51eb5e.
> During gfs_bind/gfs_unbind the functionfs_bind/functionfs_unbind should be
> called for every functionfs instance. With the "i" pre-decremented they
> were not called for the zeroth instance.
>
> Signed-off-by: Andrzej Pietrasiewicz 
> Signed-off-by: Kyungmin Park 
> Cc: 

Acked-by: Michal Nazarewicz 

> ---
>  drivers/usb/gadget/g_ffs.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/g_ffs.c b/drivers/usb/gadget/g_ffs.c
> index d3ace90..919177b 100644
> --- a/drivers/usb/gadget/g_ffs.c
> +++ b/drivers/usb/gadget/g_ffs.c
> @@ -358,7 +358,7 @@ static int gfs_bind(struct usb_composite_dev *cdev)
>   if (unlikely(ret < 0))
>   goto error;
>  
> - for (i = func_num; --i; ) {
> + for (i = func_num; i--; ) {
>   ret = functionfs_bind(ffs_tab[i].ffs_data, cdev);
>   if (unlikely(ret < 0)) {
>   while (++i < func_num)
> @@ -413,7 +413,7 @@ static int gfs_unbind(struct usb_composite_dev *cdev)
>   gether_cleanup();
>   gfs_ether_setup = false;
>  
> - for (i = func_num; --i; )
> + for (i = func_num; i--; )
>   if (ffs_tab[i].ffs_data)
>   functionfs_unbind(ffs_tab[i].ffs_data);
>  
> -- 
> 1.7.0.4
>

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

pgpIczGey7PeN.pgp
Description: PGP signature

Re: [PATCH] usb: musb: log VBUS error

[Tony Lindgren]

* Grazvydas Ignotas  [130309 16:53]:
> VBUS_ERROR is a serious error that the driver often doesn't recover from
> in my tests, so we should at least inform the user about it.

Patch makes sens to me, just a related question..

Do you get this when trying to enable the host mode, right? Or have you seen
this in other situations too?

If the error happens when enabling the host mode, my experience is that
the VBUS_ERROR is caused by the musb trying to be too smart and doing the
timeouts automatically. If the VBUS on the hardware does not raise fast
enough to the right range for whatever reason, musb can produce this
error.

Regards,

Tony
 
> Signed-off-by: Grazvydas Ignotas 
> ---
>  drivers/usb/musb/musb_core.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index f95404e..df6a54e 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -602,7 +602,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8 
> int_usb,
>   break;
>   }
>  
> - dev_dbg(musb->controller, "VBUS_ERROR in %s (%02x, %s), retry 
> #%d, port1 %08x\n",
> + dev_printk(ignore ? KERN_DEBUG : KERN_ERR, musb->controller,
> +"VBUS_ERROR in %s (%02x, %s), retry #%d, port1 
> %08x\n",
>   otg_state_string(musb->xceiv->state),
>   devctl,
>   ({ char *s;
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Problem with linux-3.7.7 (Stern - d01875f11f05f76fc471cec94d701201c1b34389)

[Alan Stern]

On Mon, 11 Mar 2013, Adrian Bassett wrote:

> > You know, the 6e0c3339a6 commit consists of two hunks, and they are
> > pretty much independent of one another.  You could try reverting each
> > of the hunks separately to narrow things down.  Maybe only one of them
> > is responsible for your problem.
> 
> Have now been able to do this.
> 
> Using a vanilla 3.8.2 as base but with the following commit reverted
> as it's scheduled for removal in 3.8.3 anyway:
> 
> 55bcdce8a8228223ec4d17d8ded8134ed265d2c5 - 'USB: EHCI: remove ASS/PSS polling 
> timeout'
> 
> Then 6e0c3339a6f19d748f16091d0a05adeb1e1f822b - 'USB: EHCI: unlink
> one async QH at a time' - was also reverted and two kernels were
> built.  The first, 'A', incorporated the first part of 6e0c3339
> (changes to drivers/usb/host/ehci-q.c starting at line 1197) while
> the second, 'B', had that code reverted in favour of the remainder of
> the original composite patch.
> 
> What I found was that 'A' was entirely un-problematic in that I could
> not trigger the problem behaviour at all. On the other hand, 'B'
> could be made to trigger at first suspend/resume attempt.  Moreover,
> whilst previously the system with the composite patch in would always
> return after a few minutes, with 'B' I eventually gave up waiting and
> forced a re-boot.  Perhaps the first half of the original patch in
> some way mitigates the effects of the second.

Ah, that explains a lot.  Indeed, there does appear to be a bug.

I haven't tried out this patch myself, but I think it will fix your
problem.  It is based on 3.8 and should apply to 3.8.2.  Let me know
what happens.

Alan Stern



Index: 3.8/drivers/usb/host/ehci-hcd.c
===
--- 3.8.orig/drivers/usb/host/ehci-hcd.c
+++ 3.8/drivers/usb/host/ehci-hcd.c
@@ -302,6 +302,7 @@ static void ehci_quiesce (struct ehci_hc
 
 static void end_unlink_async(struct ehci_hcd *ehci);
 static void unlink_empty_async(struct ehci_hcd *ehci);
+static void unlink_empty_async_suspended(struct ehci_hcd *ehci);
 static void ehci_work(struct ehci_hcd *ehci);
 static void start_unlink_intr(struct ehci_hcd *ehci, struct ehci_qh *qh);
 static void end_unlink_intr(struct ehci_hcd *ehci, struct ehci_qh *qh);
Index: 3.8/drivers/usb/host/ehci-hub.c
===
--- 3.8.orig/drivers/usb/host/ehci-hub.c
+++ 3.8/drivers/usb/host/ehci-hub.c
@@ -328,7 +328,7 @@ static int ehci_bus_suspend (struct usb_
ehci->rh_state = EHCI_RH_SUSPENDED;
 
end_unlink_async(ehci);
-   unlink_empty_async(ehci);
+   unlink_empty_async_suspended(ehci);
ehci_handle_intr_unlinks(ehci);
end_free_itds(ehci);
 
Index: 3.8/drivers/usb/host/ehci-q.c
===
--- 3.8.orig/drivers/usb/host/ehci-q.c
+++ 3.8/drivers/usb/host/ehci-q.c
@@ -1316,6 +1316,20 @@ static void unlink_empty_async(struct eh
}
 }
 
+/* The root hub is suspended; unlink all the async QHs */
+static void unlink_empty_async_suspended(struct ehci_hcd *ehci)
+{
+   struct ehci_qh  *qh, *qh_to_unlink;
+
+   qh = ehci->async->qh_next.qh;
+   while (qh) {
+   qh_to_unlink = qh;
+   qh = qh->qh_next.qh;
+   WARN_ON(!list_empty(&qh_to_unlink->qtd_list));
+   start_unlink_async(ehci, qh_to_unlink);
+   }
+}
+
 /* makes sure the async qh will become idle */
 /* caller must own ehci->lock */
 

--
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/core/devio.c: Don't use GFP_KERNEL while we cannot reset a storage device

[Ming Lei]

On Tue, Mar 12, 2013 at 12:08 AM, Alan Stern  wrote:
> On Mon, 11 Mar 2013, Ming Lei wrote:
>
>> On Mon, Mar 11, 2013 at 11:32 PM, Alan Stern  
>> wrote:
>> >
>> > Of course you have to lock the device before changing its driver.  What
>> > would happen if two different threads tried to change a device's driver
>> > at the same time?
>>
>> Yes, claim/release interface need device lock, but the patch doesn't
>> touch claim/release command handling.
>
> Then why did you ask?  You wrote: "Looks device lock isn't required for
> USB transfer of kernel driver."

Maybe I didn't expressed clearly, sorry. Here the USB transfer means
URBs submitting.

>
>
>> > usbdev_do_ioctl() needs to acquire the device lock in order to prevent
>> > races with driver_disconnect() and usbdev_remove().
>>
>> Looks the patch basically converts the allocation inside URB submit path,
>> and actually I mean why we need to hold device lock in submitting
>> URB path?  Device lock isn't required before submitting URBs
>> in kernel driver.
>
> In general it isn't, no.  But usbfs uses the lock to prevent races with
> driver_disconnect() -- it is invalid to submit URBs after the
> disconnect routine has returned.

If so, we may introduce another lock to avoid the race.

So I think we may figure out to decrease the device lock
scope in devio.c, and most of ioctl commands might not require it
at all, then the problem addressed by the patch can be fixed too.


Thanks,
-- 
Ming Lei
--
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: phy: rename all phy drivers to phy-$name.c

[Stephen Warren]

On 03/11/2013 12:59 AM, Felipe Balbi wrote:
> Hi,
> 
> On Fri, Mar 08, 2013 at 10:26:45AM -0700, Stephen Warren wrote:
>> On 03/08/2013 12:08 AM, Felipe Balbi wrote:
>>> On Thu, Mar 07, 2013 at 01:37:17PM -0700, Stephen Warren
>>> wrote:
 On 03/07/2013 08:45 AM, Felipe Balbi wrote:
> this will make sure that we have sensible names for all
> phy drivers. Current situation was already quite bad with
> too generic names being used.
 
 Is phy-$name specific enough? There are other types of PHY
 such as Ethernet, etc. What about phy-usb-$name?
>>> 
>>> we will be creating a generic (kernel-wide) phy layer, so I
>>> guess that matters very little. Specially since we don't want
>>> to be differentiating PHYs by their subsystem and rather by the
>>> IP name (which means phy-tegra, phy-samsung, phy-omap, are all
>>> 'wrong', but there were no better names).
>>> 
 Venu, please comment on what conflicts, if any, this will
 cause with the patches you'll be sending to clean up the
 Tegra USB/PHY drivers. Thanks.
>>> 
>>> BTW, let's stop with the whole dependency between PHY driver 
>>> cleanup and arch/arm/mach-tegra/, too many patches have gone 
>>> upstream bypassing my tree. What we should be doing is figuring
>>> out how to remove arch/ dependencies so that patches can go
>>> upstream and not cause conflicts.
>> 
>> Unfortunately, there's no way to actually avoid the dependencies 
>> themselves. The DT bindings and EHCI/PHY controller split are
>> wrong, and need work on both the DT and drivers to fix.
> 
> but those changes don't need to come together, right ? I mean, for
> the DT part you could add the bindings to driver A without removing
> from driver B and span the changes accross 2 merge windows.

There is only a single driver. It's being reworked to support the new
binding.

>> I guess I could apply all the initial DT changes to a topic
>> branch in the Tegra tree (item 1 below), and have you merge that
>> branch into yours, and then you could take all the USB-related
>> patches (item 2 below) through your tree. Would that work
>> better?
> 
> I'm not merging, taking everything as patches, sorry.

In that case, the Tegra USB driver changes have to go through the
Tegra tree this kernel cycle. The only way to avoid this, as you said
above, would be to break the patches into n kernel cycles, which will
introduce another 2-3 months delay, and I really don't see any point
at all in doing that just to avoid a git pull, or taking the patches
through the Tegra tree.
--
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: phy: rename all phy drivers to phy-$name.c

[Stephen Warren]

On 03/11/2013 01:01 AM, Felipe Balbi wrote:
> Hi,
> 
> On Fri, Mar 08, 2013 at 11:33:48AM -0700, Stephen Warren wrote:
>> On 03/08/2013 12:08 AM, Felipe Balbi wrote:
>>> On Thu, Mar 07, 2013 at 01:37:17PM -0700, Stephen Warren
>>> wrote:
 On 03/07/2013 08:45 AM, Felipe Balbi wrote:
> this will make sure that we have sensible names for all
> phy drivers. Current situation was already quite bad with
> too generic names being used.
 
 Is phy-$name specific enough? There are other types of PHY
 such as Ethernet, etc. What about phy-usb-$name?
>>> 
>>> we will be creating a generic (kernel-wide) phy layer, so I
>>> guess that matters very little. Specially since we don't want
>>> to be differentiating PHYs by their subsystem and rather by the
>>> IP name (which means phy-tegra, phy-samsung, phy-omap, are all
>>> 'wrong', but there were no better names).
>> 
>> On other thought here: The Tegra PHY in question here very 
>> specifically is a USB PHY. There's no way it could be used as
>> e.g. a SATA PHY, either as a HW block or given the driver code
>> that program is. Is sharing a PHY IP block or driver ever
>> possible for any HW?
> 
> yes it is possible, and OMAP5 shares the same IP for USB3 and SATA.
> PHYs don't know about USB, SATA, Ethernet and whatnot. PHYs know
> solely about the physical layer. Their work is just to generate the
> proper electrical signals.

Hmm. Is the current code in drivers/usb/phy/tegra_usb_phy.c not really
a PHY driver, then? Tegra's USB PHY HW module definitely does know
that it's specifically a USB PHY. It has direct knowledge of
UTMI/ULPI/... Instead, should the code be part of the EHCI driver,
since the concept of a PHY known to drivers/usb/phy doesn't seem
related to what the Tegra PHY HW actually is?
--
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: musb: log VBUS error

[Grazvydas Ignotas]

On Mon, Mar 11, 2013 at 6:24 PM, Tony Lindgren  wrote:
> * Grazvydas Ignotas  [130309 16:53]:
>> VBUS_ERROR is a serious error that the driver often doesn't recover from
>> in my tests, so we should at least inform the user about it.
>
> Patch makes sens to me, just a related question..
>
> Do you get this when trying to enable the host mode, right? Or have you seen
> this in other situations too?

I sometimes see it when booting with cable connected to PC or
connecting cable to PC after using a host adapter. In those cases OTG
port dies completely until a powercycle :(

> If the error happens when enabling the host mode, my experience is that
> the VBUS_ERROR is caused by the musb trying to be too smart and doing the
> timeouts automatically. If the VBUS on the hardware does not raise fast
> enough to the right range for whatever reason, musb can produce this
> error.

Yeah the driver seems to expect that and has a "ignore" variable, I
use KERN_DEBUG level in case it's set.

>
> Regards,
>
> Tony
>

-- 
Gražvydas
--
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: musb: log VBUS error

[Tony Lindgren]

* Grazvydas Ignotas  [130311 10:12]:
> On Mon, Mar 11, 2013 at 6:24 PM, Tony Lindgren  wrote:
> > * Grazvydas Ignotas  [130309 16:53]:
> >> VBUS_ERROR is a serious error that the driver often doesn't recover from
> >> in my tests, so we should at least inform the user about it.
> >
> > Patch makes sens to me, just a related question..
> >
> > Do you get this when trying to enable the host mode, right? Or have you seen
> > this in other situations too?
> 
> I sometimes see it when booting with cable connected to PC or
> connecting cable to PC after using a host adapter. In those cases OTG
> port dies completely until a powercycle :(

Hmm OK. I suspect there's some kernel bug currently with the OTG id pin
detection where it's initial state during the boot is ignored. But replugging
the cable should fix that, and in your case it sounds like that's not
the case.
 
> > If the error happens when enabling the host mode, my experience is that
> > the VBUS_ERROR is caused by the musb trying to be too smart and doing the
> > timeouts automatically. If the VBUS on the hardware does not raise fast
> > enough to the right range for whatever reason, musb can produce this
> > error.
> 
> Yeah the driver seems to expect that and has a "ignore" variable, I
> use KERN_DEBUG level in case it's set.

Yes in the host case I think we then just retry enabling the session bit
and don't have anything in place to check that the VBUS regulator is ready
or not. Have not looked at that code for a while though.

Regards,

Tony
--
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 v4] xhci - correct comp_mode_recovery_timer on return from hibernate

[Cortes, Alexis]

Hi Sarah,

Sorry for my delayed response, I was investigating this. By 'Inactive' state 
you mean the Compliance mode? since SS.Inactive and Compliance are not the same.

When in D3hot or D3cold, the host must be able to transmit a PME whenever a 
device is plugged into the DS port.  If a SS device is plugged into DS port and 
fails to make it to U0, the Port will land in Compliance or SS.Disabled.  If 
Compliance, then there will be no PME notification.  If it lands in 
SS.Disabled, the USB2 will be enabled and then a PME notification will be sent 
for USB2 connection. I just realized this.

Hope this helps.

Best Regards,
Alexis Cortes.

-Original Message-
From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com] 
Sent: Wednesday, March 06, 2013 3:32 PM
To: Alan Stern; Cortes, Alexis
Cc: Tony Camuso; linux-usb@vger.kernel.org; r...@sisk.pl; dzic...@redhat.com
Subject: Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return from 
hibernate

On Wed, Mar 06, 2013 at 10:12:14AM -0500, Alan Stern wrote:
> On Tue, 5 Mar 2013, Sarah Sharp wrote:
> 
> > static void compliance_mode_recovery(unsigned long arg) { ...
> > for (i = 0; i < xhci->num_usb3_ports; i++) {
> > temp = xhci_readl(xhci, xhci->usb3_ports[i]);
> > if ((temp & PORT_PLS_MASK) == USB_SS_PORT_LS_COMP_MOD) {
> > /*
> >  * Compliance Mode Detected. Letting USB Core
> >  * handle the Warm Reset
> >  */
> > 
> > What happens when the xHCI host controller goes into D3cold due to 
> > runtime PM?  The port status registers will read as all f's, so we 
> > will miss any transitions to the compliance mode that happened 
> > before or during the transition to D3cold.
> > 
> > This code probably needs to wake up the host controller and keep it 
> > from suspending until all the ports can be read.
> > 
> > Alan, would the right way to do that be a get/put call into the 
> > runtime PM core?
> 
> If xhci_suspend deletes the Compliance Mode Recovery timer then the 
> timer will never fire while the controller is in D3cold.  The problem 
> won't arise.

Alex,

Can the USB 3.0 port go into the Inactive sate while the host is in D3hot or 
D3cold?  If so, will we see a PME that will cause the USB core resume the host? 
 I'm concerned that if we don't get a port status change event when the port 
goes into the Inactive state, then we won't get an interrupt if the port 
transitions to the Inactive state while the host is in D3.

If the ports can't go into the Inactive state while the host is in D3, then I 
agree with Alan that it's fine to delete the timer in xhci_suspend.

However, if the ports can to into the Inactive state and we won't get a PME, 
then we have to keep the timer running while the xHCI host is runtime suspended.

Sarah Sharp
--
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] USB: cdc-wdm: fix read buffer overflow

[Greg Kroah-Hartman]

On Fri, Feb 15, 2013 at 12:30:11PM +0100, Bjørn Mork wrote:
> Oliver Neukum  writes:
> > On Friday 15 February 2013 08:53:28 Bjørn Mork wrote:
> >> Oliver Neukum  writes:
> >
> >> > We have to let user space recover. To do so we need to indicate when
> >> > exactly we dropped data.
> >> 
> >> The problem with that is that this is likely to happen when a client
> >> just doesn't care. It will just continue happily ignoring the read data,
> >> writing new commands or whatever.  Then  the *next* client opening the
> >> file for reading will see this error.
> >
> > Well, this may be a separate bug. Should the buffer be cleared when
> > we run out of openers?
> 
> No. A valid use case, currently working just fine, is using e.g. shell
> commands to sequentially write and read, closing the file inbetween.  I
> don't see any reason to suddenly break that.  It is a userspace visible
> ABI.



What ever was decided here?  Can someone please send me the patch that
you two agreed would solve this problem?

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: [GIT PULL] USB patches

[Felipe Balbi]

Hi,

On Mon, Mar 11, 2013 at 08:29:00AM -0700, Greg KH wrote:
> On Mon, Mar 11, 2013 at 01:14:36PM +0200, Felipe Balbi wrote:
> > Hi Greg,
> > 
> > Here's my second set of fixes for this -rc cycle. Since my previous pull
> > request didn't reach v3.9-rc2, this one is based out of the previous.
> 
> That is fine, due to my travels last week, I didn't get a chance to get
> stuff to Linus.  I should catch up this week.
> 
> > Surprised to see that git gracefully found a common commit by just running:
> > 
> > $ git request-pull greg/usb-linus usb fixes-for-v3.9-rc3
> > 
> > (usb is my remote to kernel.org)
> > 
> > Anyway, let me know if you have any issues. I have merged this tag on top of
> > your greg/usb-linus branch just to make sure there'd be no conflicts and it
> > merges just fine.
> > 
> > cheers
> > 
> > The following changes since commit 29240e2392786c39007df2f4162f3dc4680f3dec:
> > 
> >   usb: gadget: u_uac1: NULL dereference on error path (2013-03-04 13:16:45 
> > +0200)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> > tags/fixes-for-v3.9-rc3
> 
> Pulled and pushed out, thanks.

hmm... and of course I made a mistake. Forgot to git add one hunk of one
patch, can you take it in patch form ? It's below, but I'll send as a
proper patch as a reply to this mail as well.

8< - cut here --

From 1e7bd9f5130d33a9bd6c005138030ac9ce8bbe7c Mon Sep 17 00:00:00 2001
From: Felipe Balbi 
Date: Mon, 11 Mar 2013 19:58:06 +0200
Subject: [PATCH] usb: musb: core: fix possible build error with randconfig

when making commit e574d57 (usb: musb: fix
compile warning) I forgot to git add this
part of the patch which ended up introducing
a possible build error.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/musb/musb_core.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 13382e0..daec6e0 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1624,8 +1624,6 @@ EXPORT_SYMBOL_GPL(musb_dma_completion);
 
 /*-*/
 
-#ifdef CONFIG_SYSFS
-
 static ssize_t
 musb_mode_show(struct device *dev, struct device_attribute *attr, char *buf)
 {
@@ -1742,8 +1740,6 @@ static const struct attribute_group musb_attr_group = {
.attrs = musb_attributes,
 };
 
-#endif /* sysfs */
-
 /* Only used to provide driver mode change events */
 static void musb_irq_work(struct work_struct *data)
 {
-- 
1.8.1.rc1.5.g7e0651a

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] usb: musb: core: fix possible build error with randconfig

[Felipe Balbi]

when making commit e574d57 (usb: musb: fix
compile warning) I forgot to git add this
part of the patch which ended up introducing
a possible build error.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/musb/musb_core.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 13382e0..daec6e0 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1624,8 +1624,6 @@ EXPORT_SYMBOL_GPL(musb_dma_completion);
 
 /*-*/
 
-#ifdef CONFIG_SYSFS
-
 static ssize_t
 musb_mode_show(struct device *dev, struct device_attribute *attr, char *buf)
 {
@@ -1742,8 +1740,6 @@ static const struct attribute_group musb_attr_group = {
.attrs = musb_attributes,
 };
 
-#endif /* sysfs */
-
 /* Only used to provide driver mode change events */
 static void musb_irq_work(struct work_struct *data)
 {
-- 
1.8.1.rc1.5.g7e0651a

--
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: phy: rename all phy drivers to phy-$name.c

[Felipe Balbi]

Hi,

On Mon, Mar 11, 2013 at 11:05:15AM -0600, Stephen Warren wrote:
> >> On 03/08/2013 12:08 AM, Felipe Balbi wrote:
> >>> On Thu, Mar 07, 2013 at 01:37:17PM -0700, Stephen Warren
> >>> wrote:
>  On 03/07/2013 08:45 AM, Felipe Balbi wrote:
> > this will make sure that we have sensible names for all
> > phy drivers. Current situation was already quite bad with
> > too generic names being used.
>  
>  Is phy-$name specific enough? There are other types of PHY
>  such as Ethernet, etc. What about phy-usb-$name?
> >>> 
> >>> we will be creating a generic (kernel-wide) phy layer, so I
> >>> guess that matters very little. Specially since we don't want
> >>> to be differentiating PHYs by their subsystem and rather by the
> >>> IP name (which means phy-tegra, phy-samsung, phy-omap, are all
> >>> 'wrong', but there were no better names).
> >> 
> >> On other thought here: The Tegra PHY in question here very 
> >> specifically is a USB PHY. There's no way it could be used as
> >> e.g. a SATA PHY, either as a HW block or given the driver code
> >> that program is. Is sharing a PHY IP block or driver ever
> >> possible for any HW?
> > 
> > yes it is possible, and OMAP5 shares the same IP for USB3 and SATA.
> > PHYs don't know about USB, SATA, Ethernet and whatnot. PHYs know
> > solely about the physical layer. Their work is just to generate the
> > proper electrical signals.
> 
> Hmm. Is the current code in drivers/usb/phy/tegra_usb_phy.c not really
> a PHY driver, then? Tegra's USB PHY HW module definitely does know
> that it's specifically a USB PHY. It has direct knowledge of

knowledge of UTMI/ULPI doesn't mean it knows it's a USB PHY. SATA and
USB3 use the PIPE3 interface, which was designed, originally, for PCIe.

It's just that UTMI/ULPI only got used in USB scenario.

> UTMI/ULPI/... Instead, should the code be part of the EHCI driver,

no way, no. EHCI-core should be taught about PHYs instead.

> since the concept of a PHY known to drivers/usb/phy doesn't seem
> related to what the Tegra PHY HW actually is?

I disagree a PHY is a PHY, no matter if it's attached to a Host IP,
Device IP or DRD IP.

-- 
balbi


signature.asc
Description: Digital signature

Re: [GIT PULL] USB patches

[Greg KH]

On Mon, Mar 11, 2013 at 08:00:29PM +0200, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Mar 11, 2013 at 08:29:00AM -0700, Greg KH wrote:
> > On Mon, Mar 11, 2013 at 01:14:36PM +0200, Felipe Balbi wrote:
> > > Hi Greg,
> > > 
> > > Here's my second set of fixes for this -rc cycle. Since my previous pull
> > > request didn't reach v3.9-rc2, this one is based out of the previous.
> > 
> > That is fine, due to my travels last week, I didn't get a chance to get
> > stuff to Linus.  I should catch up this week.
> > 
> > > Surprised to see that git gracefully found a common commit by just 
> > > running:
> > > 
> > >   $ git request-pull greg/usb-linus usb fixes-for-v3.9-rc3
> > > 
> > > (usb is my remote to kernel.org)
> > > 
> > > Anyway, let me know if you have any issues. I have merged this tag on top 
> > > of
> > > your greg/usb-linus branch just to make sure there'd be no conflicts and 
> > > it
> > > merges just fine.
> > > 
> > > cheers
> > > 
> > > The following changes since commit 
> > > 29240e2392786c39007df2f4162f3dc4680f3dec:
> > > 
> > >   usb: gadget: u_uac1: NULL dereference on error path (2013-03-04 
> > > 13:16:45 +0200)
> > > 
> > > are available in the git repository at:
> > > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> > > tags/fixes-for-v3.9-rc3
> > 
> > Pulled and pushed out, thanks.
> 
> hmm... and of course I made a mistake. Forgot to git add one hunk of one
> patch, can you take it in patch form ? It's below, but I'll send as a
> proper patch as a reply to this mail as well.

Applied, 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: PROBLEM: USB device registered on OHCI instead of EHCI at boot

[Bruce Guenter]

On Fri, Mar 08, 2013 at 09:35:50PM -0500, Alan Stern wrote:
> The dmesg log shows the card reader attached to the EHCI controller at
> timestamp 2.569228 (which should be the boot-time detection) -- not to
> the OHCI controller.  And it doesn't show any devices on bus 5.  Why
> not?

I have no idea. I'm sure there was a slow down on this boot (I posted
right after unplugging the reader and plugging it back in) and the lsusb
contents were accurate. However, I can no longer reproduce it with
either this 3.8.2 kernel or 3.7.10, so I don't know.  Maybe there is
something after boot that is messing things up.

Sorry for the noise.

-- 
Bruce Guenter http://untroubled.org/


signature.asc
Description: Digital signature

Re: PROBLEM: USB device registered on OHCI instead of EHCI at boot

[Alan Stern]

On Mon, 11 Mar 2013, Bruce Guenter wrote:

> On Fri, Mar 08, 2013 at 09:35:50PM -0500, Alan Stern wrote:
> > The dmesg log shows the card reader attached to the EHCI controller at
> > timestamp 2.569228 (which should be the boot-time detection) -- not to
> > the OHCI controller.  And it doesn't show any devices on bus 5.  Why
> > not?
> 
> I have no idea. I'm sure there was a slow down on this boot (I posted
> right after unplugging the reader and plugging it back in) and the lsusb
> contents were accurate. However, I can no longer reproduce it with
> either this 3.8.2 kernel or 3.7.10, so I don't know.  Maybe there is
> something after boot that is messing things up.

Okay; if it happens again, collect the information and we'll go on from 
there.

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: phy: rename all phy drivers to phy-$name.c

[Felipe Balbi]

Hi,

On Mon, Mar 11, 2013 at 11:02:43AM -0600, Stephen Warren wrote:
> >> On 03/08/2013 12:08 AM, Felipe Balbi wrote:
> >>> On Thu, Mar 07, 2013 at 01:37:17PM -0700, Stephen Warren
> >>> wrote:
>  On 03/07/2013 08:45 AM, Felipe Balbi wrote:
> > this will make sure that we have sensible names for all
> > phy drivers. Current situation was already quite bad with
> > too generic names being used.
>  
>  Is phy-$name specific enough? There are other types of PHY
>  such as Ethernet, etc. What about phy-usb-$name?
> >>> 
> >>> we will be creating a generic (kernel-wide) phy layer, so I
> >>> guess that matters very little. Specially since we don't want
> >>> to be differentiating PHYs by their subsystem and rather by the
> >>> IP name (which means phy-tegra, phy-samsung, phy-omap, are all
> >>> 'wrong', but there were no better names).
> >>> 
>  Venu, please comment on what conflicts, if any, this will
>  cause with the patches you'll be sending to clean up the
>  Tegra USB/PHY drivers. Thanks.
> >>> 
> >>> BTW, let's stop with the whole dependency between PHY driver 
> >>> cleanup and arch/arm/mach-tegra/, too many patches have gone 
> >>> upstream bypassing my tree. What we should be doing is figuring
> >>> out how to remove arch/ dependencies so that patches can go
> >>> upstream and not cause conflicts.
> >> 
> >> Unfortunately, there's no way to actually avoid the dependencies 
> >> themselves. The DT bindings and EHCI/PHY controller split are
> >> wrong, and need work on both the DT and drivers to fix.
> > 
> > but those changes don't need to come together, right ? I mean, for
> > the DT part you could add the bindings to driver A without removing
> > from driver B and span the changes accross 2 merge windows.
> 
> There is only a single driver. It's being reworked to support the new
> binding.

alright, so what's the problem of adding new binding without removing
old one for v3.10 and remove old on v3.11 ? It gives a 3 month grace
period for all boards to be converted, at least.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb/core/devio.c: Don't use GFP_KERNEL while we cannot reset a storage device

[Alan Stern]

On Tue, 12 Mar 2013, Ming Lei wrote:

> > In general it isn't, no.  But usbfs uses the lock to prevent races with
> > driver_disconnect() -- it is invalid to submit URBs after the
> > disconnect routine has returned.
> 
> If so, we may introduce another lock to avoid the race.
> 
> So I think we may figure out to decrease the device lock
> scope in devio.c, and most of ioctl commands might not require it
> at all, then the problem addressed by the patch can be fixed too.

That might work.  A mutex could be added to the dev_state structure.  
The mutex would be locked whenever an URB was being submitted and
during driver_disconnect, and perhaps a few other places too, but not
when memory was being allocated.  The device itself would remain 
unlocked most of the time.

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

[PATCH] usb: chipidea: core: switch over to devm_ioremap_resource

[Felipe Balbi]

switch over to the newly added devm_ioremap_resource
which provides more consistent error messages.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/chipidea/core.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 57cae1f..7f3a9e1 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -410,11 +410,9 @@ static int ci_hdrc_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   base = devm_request_and_ioremap(dev, res);
-   if (!base) {
-   dev_err(dev, "can't request and ioremap resource\n");
-   return -ENOMEM;
-   }
+   base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
 
ci = devm_kzalloc(dev, sizeof(*ci), GFP_KERNEL);
if (!ci) {
-- 
1.8.1.rc1.5.g7e0651a

--
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: phy: rename all phy drivers to phy-$name.c

[Stephen Warren]

On 03/11/2013 12:49 PM, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Mar 11, 2013 at 11:02:43AM -0600, Stephen Warren wrote:
 On 03/08/2013 12:08 AM, Felipe Balbi wrote:
> On Thu, Mar 07, 2013 at 01:37:17PM -0700, Stephen Warren 
> wrote:
>> On 03/07/2013 08:45 AM, Felipe Balbi wrote:
>>> this will make sure that we have sensible names for
>>> all phy drivers. Current situation was already quite
>>> bad with too generic names being used.
>> 
>> Is phy-$name specific enough? There are other types of
>> PHY such as Ethernet, etc. What about phy-usb-$name?
> 
> we will be creating a generic (kernel-wide) phy layer, so
> I guess that matters very little. Specially since we don't
> want to be differentiating PHYs by their subsystem and
> rather by the IP name (which means phy-tegra, phy-samsung,
> phy-omap, are all 'wrong', but there were no better
> names).
> 
>> Venu, please comment on what conflicts, if any, this
>> will cause with the patches you'll be sending to clean up
>> the Tegra USB/PHY drivers. Thanks.
> 
> BTW, let's stop with the whole dependency between PHY
> driver cleanup and arch/arm/mach-tegra/, too many patches
> have gone upstream bypassing my tree. What we should be
> doing is figuring out how to remove arch/ dependencies so
> that patches can go upstream and not cause conflicts.
 
 Unfortunately, there's no way to actually avoid the
 dependencies themselves. The DT bindings and EHCI/PHY
 controller split are wrong, and need work on both the DT and
 drivers to fix.
>>> 
>>> but those changes don't need to come together, right ? I mean,
>>> for the DT part you could add the bindings to driver A without
>>> removing from driver B and span the changes accross 2 merge
>>> windows.
>> 
>> There is only a single driver. It's being reworked to support the
>> new binding.
> 
> alright, so what's the problem of adding new binding without
> removing old one for v3.10 and remove old on v3.11 ? It gives a 3
> month grace period for all boards to be converted, at least.

By binding, I assume you mean the driver code that implements the
binding, so you want the driver to support both the old and new
bindings at once? I don't think that's practical in this case.

Currently the EHCI driver parses a single EHCI DT node, and passes
some information down to the PHY driver. The PHY driver is in fact
just a set of functions and not actually any kind of driver.

The patches will split the single EHCI DT node into a separate EHCI
and PHY DT nodes, convert the PHY driver to an actual (platform)
driver, move the parsing of the PHY DT node into the new PHY DT
driver, and remove the parsing of the PHY-related properties from the
EHCI driver. Supporting both sets of DT content across that transition
would be rather difficult I think.

The patches will convert all in-tree boards, and I'm pretty confident
that there aren't actually any out-of-tree boards for Tegra (that use
a mainline kernel; there are plenty that don't use DT and are based on
much older kernels). Hence, I don't see any need for a grace period
here. Even if there are out-of-tree boards, the conversion of the DT
content would take about 30 seconds. I'll volunteer to even do it
(without testing!) for any out-of-tree boards if there are any.

One reason that I really care about moving this forward quickly, is
that you had indicated the driver cleanup was a pre-requisite to
continuing to extend the code. Right now, the Tegra USB drivers only
support Tegra20. We'd really like to get Tegra30 and now Tegra114 USB
support into mainline ASAP.
--
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: remove MACH_OMAP_H4_OTG

[Paul Bolle]

The Kconfig option MACH_OMAP_H4_OTG was already considered dead as of
v2.6.36, as can be seen in commit
267ecec95f7d215d2da38252640b06198515acc3 ("Removing dead
MACH_OMAP_H4_OTG"). Remove its last trace now.

Signed-off-by: Paul Bolle 
---
0) Tested with "make ARCH=arm menuconfig" (specifically whether setting
either MACH_OMAP_H2 or MACH_OMAP_H3 still selected ISP1301_OMAP).

1) By the way "if ARCH_OMAP" on the next line seems superfluous, as
ARCH_OMAP1 already selects ARCH_OMAP. Minor nit, actually.

 drivers/usb/gadget/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 5a0c541..c65b5e2 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -194,7 +194,7 @@ config USB_FUSB300
 config USB_OMAP
tristate "OMAP USB Device Controller"
depends on ARCH_OMAP1
-   select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_H4_OTG
+   select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3
select USB_OTG_UTILS if ARCH_OMAP
help
   Many Texas Instruments OMAP processors have flexible full
-- 
1.7.11.7

--
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: phy: rename all phy drivers to phy-$name.c

[Felipe Balbi]

Hi,

On Mon, Mar 11, 2013 at 01:54:54PM -0600, Stephen Warren wrote:
> > On Mon, Mar 11, 2013 at 11:02:43AM -0600, Stephen Warren wrote:
>  On 03/08/2013 12:08 AM, Felipe Balbi wrote:
> > On Thu, Mar 07, 2013 at 01:37:17PM -0700, Stephen Warren 
> > wrote:
> >> On 03/07/2013 08:45 AM, Felipe Balbi wrote:
> >>> this will make sure that we have sensible names for
> >>> all phy drivers. Current situation was already quite
> >>> bad with too generic names being used.
> >> 
> >> Is phy-$name specific enough? There are other types of
> >> PHY such as Ethernet, etc. What about phy-usb-$name?
> > 
> > we will be creating a generic (kernel-wide) phy layer, so
> > I guess that matters very little. Specially since we don't
> > want to be differentiating PHYs by their subsystem and
> > rather by the IP name (which means phy-tegra, phy-samsung,
> > phy-omap, are all 'wrong', but there were no better
> > names).
> > 
> >> Venu, please comment on what conflicts, if any, this
> >> will cause with the patches you'll be sending to clean up
> >> the Tegra USB/PHY drivers. Thanks.
> > 
> > BTW, let's stop with the whole dependency between PHY
> > driver cleanup and arch/arm/mach-tegra/, too many patches
> > have gone upstream bypassing my tree. What we should be
> > doing is figuring out how to remove arch/ dependencies so
> > that patches can go upstream and not cause conflicts.
>  
>  Unfortunately, there's no way to actually avoid the
>  dependencies themselves. The DT bindings and EHCI/PHY
>  controller split are wrong, and need work on both the DT and
>  drivers to fix.
> >>> 
> >>> but those changes don't need to come together, right ? I mean,
> >>> for the DT part you could add the bindings to driver A without
> >>> removing from driver B and span the changes accross 2 merge
> >>> windows.
> >> 
> >> There is only a single driver. It's being reworked to support the
> >> new binding.
> > 
> > alright, so what's the problem of adding new binding without
> > removing old one for v3.10 and remove old on v3.11 ? It gives a 3
> > month grace period for all boards to be converted, at least.
> 
> By binding, I assume you mean the driver code that implements the
> binding, so you want the driver to support both the old and new
> bindings at once? I don't think that's practical in this case.
> 
> Currently the EHCI driver parses a single EHCI DT node, and passes
> some information down to the PHY driver. The PHY driver is in fact
> just a set of functions and not actually any kind of driver.

that's quite wrong :-)

> The patches will split the single EHCI DT node into a separate EHCI
> and PHY DT nodes, convert the PHY driver to an actual (platform)
> driver, move the parsing of the PHY DT node into the new PHY DT
> driver, and remove the parsing of the PHY-related properties from the
> EHCI driver. Supporting both sets of DT content across that transition
> would be rather difficult I think.

ok, now I get the full picture.

> The patches will convert all in-tree boards, and I'm pretty confident
> that there aren't actually any out-of-tree boards for Tegra (that use
> a mainline kernel; there are plenty that don't use DT and are based on
> much older kernels). Hence, I don't see any need for a grace period
> here. Even if there are out-of-tree boards, the conversion of the DT
> content would take about 30 seconds. I'll volunteer to even do it
> (without testing!) for any out-of-tree boards if there are any.

I guess we can't delete this from archives anymore :-p

> One reason that I really care about moving this forward quickly, is
> that you had indicated the driver cleanup was a pre-requisite to
> continuing to extend the code. Right now, the Tegra USB drivers only
> support Tegra20. We'd really like to get Tegra30 and now Tegra114 USB
> support into mainline ASAP.

Alright, now that I have the full picture it makes it a lot easier to
ack patches, thanks. Sorry for somewhat wasting time, please carry on.

-- 
balbi


signature.asc
Description: Digital signature

Re: RFC: [PATCH 1/3] usb: cdc_ncm: patch for VMware

[Ben Hutchings]

On Sun, 2013-03-10 at 22:12 +0100, Loic Domaigne wrote:
> On Fri, Mar 08, 2013 at 04:28:59PM -0600, Dan Williams wrote:
> > On Fri, 2013-03-08 at 22:03 +0100, Loic Domaigne wrote:
> > >  
> > > +/* maximum Rx URB size */
> > > +/*
> > > + * in the original Linux driver, the rx urb size can be up to
> > > + * CDC_NCM_NTB_MAX_SIZE_RX.
> > > + *
> > > + * Under VMware (as of wks9), URB size greater than 16kB is a problem,
> > > + * so simply adjust this define when the driver is compiled for a VMware
> > > + * environment.
> > > + *
> > > + */
> > > +#ifdef VMWARE_BUG
> > > +#warning "Compiling for VMware"
> > > +#define CDC_NCM_MAX_RX_URB_SIZE 16384
> > > +#else
> > > +#define CDC_NCM_MAX_RX_URB_SIZE CDC_NCM_NTB_MAX_SIZE_RX
> > > +#endif
> > 
> > I can't see how that is going to get past any sort of review.  Either
> > there's some other way of detecting that the CPU is the VMWare emulated
> > one or you're stuck with the bug until VMWare fixes it.
> 
> Yeah, I know.
> 
> The kludge consists to (re)compile the kernel module on the VMWare guest with
> the VMWARE_BUG compiler flag set. 
> 
> We have a helper script for that task, but it's distros specific. We can 
> detect automatically a VMWare emulated CPU in some cases, but not always.
> As a result, we end up sometimes asking the user.
> 
> I am aware that it's not suitable as a generic solution. But waiting a fix
> from VMWare might not be practical for you either.
> 
> Any better ideas?

Example from drivers/misc/vmw_balloon.c:

#include 
...
/*
 * Check if we are running on VMware's hypervisor and bail out
 * if we are not.
 */
if (x86_hyper != &x86_hyper_vmware)
return -ENODEV;

Obviously for a non-x86-specific driver this needs to be conditional on
#ifdef CONFIG_X86.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
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: REQUEST : Some help to write a new driver for LEAP motion device

[LECOQ Vincent]

On 03/11/2013 04:24 PM, Greg KH wrote:

On Sun, Mar 10, 2013 at 07:52:55PM +0100, LECOQ Vincent wrote:

Hello Dears,

I have near me 2 piece of the Leap Motion device released as
developpers release kits. (http://www.leapmotion.com/)
The constructor give me only drivers for Microsoft ans Apple
environements, and of course closed source.
I ve have install a virtualbox with an windows environement and
initialize the device, play some minute with.

During this time I ve record the usbmon output that You can found
here : http://oktail.org/download/dump_usb


Somebody can help me to understand this trace and start the linux driver ?

Why not try asking the company if they will provide the specs for how to
talk to the device, so that we can make a USB driver for Linux in a much
easier manner?

thanks,

greg k-h
The manufacturer have planed to release a linux drivers too in some 
week, but surely in closed source only.

I preffer to have an open source.
I have already manage this kind of technology for human detections 
before, i just need to understand the initialization of the device to do 
the nexts steps (driver, userland library and API).


Thanks

Vincent.
--
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: REQUEST : Some help to write a new driver for LEAP motion device

[Greg KH]

On Mon, Mar 11, 2013 at 09:41:47PM +0100, LECOQ Vincent wrote:
> On 03/11/2013 04:24 PM, Greg KH wrote:
> >On Sun, Mar 10, 2013 at 07:52:55PM +0100, LECOQ Vincent wrote:
> >>Hello Dears,
> >>
> >>I have near me 2 piece of the Leap Motion device released as
> >>developpers release kits. (http://www.leapmotion.com/)
> >>The constructor give me only drivers for Microsoft ans Apple
> >>environements, and of course closed source.
> >>I ve have install a virtualbox with an windows environement and
> >>initialize the device, play some minute with.
> >>
> >>During this time I ve record the usbmon output that You can found
> >>here : http://oktail.org/download/dump_usb
> >>
> >>
> >>Somebody can help me to understand this trace and start the linux driver ?
> >Why not try asking the company if they will provide the specs for how to
> >talk to the device, so that we can make a USB driver for Linux in a much
> >easier manner?
> >
> >thanks,
> >
> >greg k-h
> The manufacturer have planed to release a linux drivers too in some
> week, but surely in closed source only.

Why do you think this?  USB Linux drivers can not be closed source.  If
they are planning on releasing Linux drivers, great, all should be fine.

> I preffer to have an open source.
> I have already manage this kind of technology for human detections
> before, i just need to understand the initialization of the device
> to do the nexts steps (driver, userland library and API).

"just" can be an understatement :)

Good luck,

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

[RFC] USB: cdc-wdm: implement IOCTL_WDM_MAX_COMMAND

[Bjørn Mork]

Userspace applications need to know the maximum supported message
size.

Using a character device as interface to USB control messages hides
the fact that these messages have a strict size limit.  The userspace
application must in most cases still be aware of this limit. It must
allocate sufficiently large read buffers, and it must prevent the
driver from splitting messages if the protocol requires more
advanced fragmentation like e.g. CDC MBIM does.

The limit could be read from CDC functional descriptors for CDC WDM
and CDC MBIM devices, duplicating the parsing already done by the
driver probe.  For other devices, where the limit is based on a
hardcoded default, the application will need hardcode this default
as well. Such hidden and implicit kernel dependencies are bad and
makes it impossible to ever change the defaults.

All this is unnecessarily complex and likely to make drivers and
applications end up using different limits, causing errors which
are hard to debug and replicate.

Exporting the maximum message size from the driver simplifies
the task for the userspace application, and creates a unified
information source independent of device and function class.

Signed-off-by: Bjørn Mork 
---

Oliver Neukum  writes:
> On Saturday 09 February 2013 20:16:20 Bjørn Mork wrote:
>> Oliver Neukum  writes:
>> > On Saturday 09 February 2013 18:41:52 Bjørn Mork wrote:
>
>> Well, OK..., "generic" then.  In the sense that the attribute stays the
>> same regardless of whether the value is hardcoded in the driver (QMI),
>> or parsed from wMaxCommand (CDC WDM) or wMaxControlMessage (CDC MBIM)
>> 
>> Not sure I understand what you want here...  I am trying to avoid having
>> three different attributes for the three drivers currently needing this
>> number.
>
> I would say that the most generic solution would be an ioctl()

I am not exactly sure how to do this, but does this look like something
that could be submitted?

The issue just came up again, after I tried to get a user with an
Ericsson H5521gw modem to run mbimcli.  It failed because the hard coded
message size is too big. We need a simple way for userspace applications
to check the message size.


Bjørn

 Documentation/ioctl/ioctl-number.txt |1 +
 drivers/usb/class/cdc-wdm.c  |   19 +++
 include/linux/usb/cdc-wdm.h  |2 ++
 include/uapi/linux/usb/cdc-wdm.h |   21 +
 4 files changed, 43 insertions(+)
 create mode 100644 include/uapi/linux/usb/cdc-wdm.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index 3210540..237acab 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -131,6 +131,7 @@ Code  Seq#(hex) Include FileComments
 'H'40-4F   sound/hdspm.h   conflict!
 'H'40-4F   sound/hdsp.hconflict!
 'H'90  sound/usb/usx2y/usb_stream.h
+'H'A0  uapi/linux/usb/cdc-wdm.h
 'H'C0-F0   net/bluetooth/hci.h conflict!
 'H'C0-DF   net/bluetooth/hidp/hidp.h   conflict!
 'H'C0-DF   net/bluetooth/cmtp/cmtp.h   conflict!
diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index 5f0cb41..6463d8c 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -13,6 +13,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -628,6 +629,22 @@ static int wdm_release(struct inode *inode, struct file 
*file)
return 0;
 }
 
+static long wdm_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+   struct wdm_device *desc = file->private_data;
+   int rv = 0;
+
+   switch (cmd) {
+   case IOCTL_WDM_MAX_COMMAND:
+   if (copy_to_user((void __user *)arg, &desc->wMaxCommand, 
sizeof(desc->wMaxCommand)))
+   rv = -EFAULT;
+   break;
+   default:
+   rv = -ENOTTY;
+   }
+   return rv;
+}
+
 static const struct file_operations wdm_fops = {
.owner =THIS_MODULE,
.read = wdm_read,
@@ -636,6 +653,8 @@ static const struct file_operations wdm_fops = {
.flush =wdm_flush,
.release =  wdm_release,
.poll = wdm_poll,
+   .unlocked_ioctl = wdm_ioctl,
+   .compat_ioctl = wdm_ioctl,
.llseek =   noop_llseek,
 };
 
diff --git a/include/linux/usb/cdc-wdm.h b/include/linux/usb/cdc-wdm.h
index 719c332..0b3f429 100644
--- a/include/linux/usb/cdc-wdm.h
+++ b/include/linux/usb/cdc-wdm.h
@@ -11,6 +11,8 @@
 #ifndef __LINUX_USB_CDC_WDM_H
 #define __LINUX_USB_CDC_WDM_H
 
+#include 
+
 extern struct usb_driver *usb_cdc_wdm_register(struct usb_interface *intf,
struct usb_endpoint_descriptor *ep,
int bufsize,
diff --git a/include/uapi/linux/usb/cdc-wdm.h b/include/uapi/linux/usb/cdc-wdm.h
new file mode 100644
index 000..f03134f
--- /dev/null
+++ b/include/u

Re: [RFC] USB: cdc-wdm: implement IOCTL_WDM_MAX_COMMAND

[Greg KH]

On Mon, Mar 11, 2013 at 10:00:21PM +0100, Bjørn Mork wrote:
> Userspace applications need to know the maximum supported message
> size.

Can't they get that from sysfs from the USB field that defines this?

Adding a new ioctl is usually not a good idea, who is going to change
the userspace tools to properly call this ioctl?

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 v2] USB: cdc-wdm: fix read buffer overflow

[Bjørn Mork]

Greg Kroah-Hartman  writes:
> On Fri, Feb 15, 2013 at 12:30:11PM +0100, Bjørn Mork wrote:
>> Oliver Neukum  writes:
>> > On Friday 15 February 2013 08:53:28 Bjørn Mork wrote:
>> >> Oliver Neukum  writes:
>> >
>> >> > We have to let user space recover. To do so we need to indicate when
>> >> > exactly we dropped data.
>> >> 
>> >> The problem with that is that this is likely to happen when a client
>> >> just doesn't care. It will just continue happily ignoring the read data,
>> >> writing new commands or whatever.  Then  the *next* client opening the
>> >> file for reading will see this error.
>> >
>> > Well, this may be a separate bug. Should the buffer be cleared when
>> > we run out of openers?
>> 
>> No. A valid use case, currently working just fine, is using e.g. shell
>> commands to sequentially write and read, closing the file inbetween.  I
>> don't see any reason to suddenly break that.  It is a userspace visible
>> ABI.
>
> 
>
> What ever was decided here?  Can someone please send me the patch that
> you two agreed would solve this problem?

I believe Oliver's patch titled "cdc-wdm: fix buffer overflow" dated
Wed, 27 Feb 2013 10:29:02 +0100 was the conclusion to all this.  I'll
leave it to Oliver to resend it if this is correct.


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: [RFC] USB: cdc-wdm: implement IOCTL_WDM_MAX_COMMAND

[Bjørn Mork]

Greg KH  writes:

> On Mon, Mar 11, 2013 at 10:00:21PM +0100, Bjørn Mork wrote:
>> Userspace applications need to know the maximum supported message
>> size.
>
> Can't they get that from sysfs from the USB field that defines this?

Not at the moment since we don't export it.  But that is of course easy
to fix.

This was how I started.  The next problem was that this "message size"
property is common to all drivers using the cdc-wdm code (cdc-wdm,
cdc_mbim and qmi_wwan), and they all have different USB descriptors
defining it.  So you would have 3 different fields (if you decided to add
a pseudo field for qmi_wwan, which hard codes a sane value) for the same
property.

This made me create the first patch, which added a common sysfs propery
to the cdc-wdm device instead.  The response to that was 
"I would say that the most generic solution would be an ioctl()"


> Adding a new ioctl is usually not a good idea, who is going to change
> the userspace tools to properly call this ioctl?

That will be Aleksander's job :)

No, being serious I do realize the problem and I don't know if it is
such a good idea either.  But I do know that we need some way for the
driver to let userspace know this value without having to guess too
much.

Currently, when a userspace application sees a /dev/cdc-wdmX device, it
will have to 
- check which USB interface it belongs to,
- parse the DMM descriptor if it is CDC WDM,
- parse the MBIM descriptor if it is CDC MBIM
- check if the driver is qmi_wwan if none of the above
- know which value qmi_wwan has hard coded

No application does this.


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: [RFC] USB: cdc-wdm: implement IOCTL_WDM_MAX_COMMAND

[Greg KH]

On Mon, Mar 11, 2013 at 10:28:21PM +0100, Bjørn Mork wrote:
> Greg KH  writes:
> 
> > On Mon, Mar 11, 2013 at 10:00:21PM +0100, Bjørn Mork wrote:
> >> Userspace applications need to know the maximum supported message
> >> size.
> >
> > Can't they get that from sysfs from the USB field that defines this?
> 
> Not at the moment since we don't export it.  But that is of course easy
> to fix.
> 
> This was how I started.  The next problem was that this "message size"
> property is common to all drivers using the cdc-wdm code (cdc-wdm,
> cdc_mbim and qmi_wwan), and they all have different USB descriptors
> defining it.  So you would have 3 different fields (if you decided to add
> a pseudo field for qmi_wwan, which hard codes a sane value) for the same
> property.
> 
> This made me create the first patch, which added a common sysfs propery
> to the cdc-wdm device instead.  The response to that was 
> "I would say that the most generic solution would be an ioctl()"
> 
> 
> > Adding a new ioctl is usually not a good idea, who is going to change
> > the userspace tools to properly call this ioctl?
> 
> That will be Aleksander's job :)
> 
> No, being serious I do realize the problem and I don't know if it is
> such a good idea either.  But I do know that we need some way for the
> driver to let userspace know this value without having to guess too
> much.
> 
> Currently, when a userspace application sees a /dev/cdc-wdmX device, it
> will have to 
> - check which USB interface it belongs to,
> - parse the DMM descriptor if it is CDC WDM,
> - parse the MBIM descriptor if it is CDC MBIM
> - check if the driver is qmi_wwan if none of the above
> - know which value qmi_wwan has hard coded
> 
> No application does this.

Hm, I hate to ask, but what does other OSes do (OS-X, Windows, etc.)
about this?

And what happens today that causes us to need this size?  How have we
lived so long without it?

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: Flood of xhci warnings with 3.9.0-rc1

[Sarah Sharp]

On Sun, Mar 10, 2013 at 12:04:40PM -0700, Stephen Hemminger wrote:
> My test kernel is screaming with xHCI messages into kernel log.
> [   76.117016] xhci_hcd :00:14.0: WARN Event TRB for slot 1 ep 0 with no 
> TDs queued?
> 
> 
> This is using kernel based on net-next which is based on 3.9.0-rc1.

Please send `sudo lspci -vvv -n` output as well.

Do you have any USB devices that have auto-suspend turned on?  I'm aware
that the message above gets printed when a device auto-suspends, and it
really shouldn't in that case.

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

Re: [RFC] USB: cdc-wdm: implement IOCTL_WDM_MAX_COMMAND

[Bjørn Mork]

Greg KH  writes:
>
>> Currently, when a userspace application sees a /dev/cdc-wdmX device, it
>> will have to 
>> - check which USB interface it belongs to,
>> - parse the DMM descriptor if it is CDC WDM,
>> - parse the MBIM descriptor if it is CDC MBIM
>> - check if the driver is qmi_wwan if none of the above
>> - know which value qmi_wwan has hard coded
>> 
>> No application does this.
>
> Hm, I hate to ask, but what does other OSes do (OS-X, Windows, etc.)
> about this?

I don't know, but I do believe they implement more (most?) of the
management protocols in their drivers, making this particular issue a
non-problem.  The driver will take care of message formatting,
fragmentation etc.  Instead they will of course have hundreds of other
kernel<->userspace API issues...

I believe that our current approach, giving userspace full access to the
management channel using a character device, result in the simplest
possible userspace API.  But the message size is an implicit part of
this API whether we want it or not.  Explictly exporting it will make
this clearer and reduce the possibility of errors.

I have no strong feelings on how it should be exported, and I do
appreciate the need to discuss all options before choosing a method.  I
know we cannot change this later, so we do want it to be perfect from
the beginning.

> And what happens today that causes us to need this size?  How have we
> lived so long without it?

That's simple. We've only just started using the /dev/cdc-wdmX devices.

The underlying problem has always been there.  The cdc-wdm driver
translates between a character device stream and a message based
protocol.  The application using the character device will need to know
the maximum message size to prevent the driver from splitting messages.

The maximum message size *is* already part of the API and always has
been.

But until we got libqmi and qmi support in oFono a few months ago, there
wasn't a single userspace application opening these character devices.
And even after that, it was still pretty simple: There is no way for a
QMI device to tell the host what size to use, so the qmi_wwan driver has
a hard coded value.  Which makes it reasonable for the applications to
hard code the same value.

The real trouble started with cdc_mbim in v3.8.  MBIM devices use wildly
different maximum message sizes, and will fail if the userspace
application doesn't get it right.  I revisited this issue now because a
user had such a problem. A *real* end user with a *real* problem :)  We
can of course claim that this is a bug in libmbim (certainly is), but it
is a fact that the bug is there because we haven't made it clear that
the message size is part of the API.  And it doesn't help that the
application will have to reimplement a lot of lsusb just to get this
value, which the driver already has parsed.

Yes, we can solve that by putting the MBIM functional descriptor in
sysfs, leaving QMI as it is and ignore WDM.  Maybe that is best?  I just
thought that I could make this a generic export on behalf of any driver
using cdc-wdm, independent of actual descriptors.  And by that also
making it clearer that this single value is important to userspace.

I'll take the full blame for introducing this problem.  Writing the
above I realized that everything was fine until I started messing with
it :)



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: Isochronous transfer error on USB3

[Sarah Sharp]

On Mon, Mar 11, 2013 at 01:21:48PM +0100, jean-philippe francois wrote:
> Hi,
> 
> The company I work for is doing USB cameras, for which I wrote the
> drivers (out of tree).

Kernel driver or userspace driver?

> Raw camera data are transferred using isochronous transfer, which work
> fine when used on USB2 EHCI.
> 
> However when plugging the camera on an USB3 port, xhci spits the
> following messages on URB submission :
> 
> [ 1704.989785] xhci_hcd :01:00.0: ERROR Transfer event TRB DMA ptr
> not part of current TD

Does the device work properly, despite the error messages?  I see that
there are transfer errors in the log file, along with those messages.
Are those expected?

> USB3 host  is an asmedia ASM1042.

Do you know if this is a 1.0 xHCI host?  E.g. when you enable
CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING, do you see lines
like this during driver initialization:

CAPLENGTH AND HCIVERSION 0x180:

If you see that line start with 0x100, it's a 1.0 xHCI host.  If starts
with 0x096, it's a 0.96 host; 0x095 would be a 0.95 host.

I ask because I have a todo list entry to fix short packet handling on
xHCI 1.0 hosts:

"On Intel Lynx Point xHCI, when you plug in a HS USB webcam, the log
will fill with the error message:

ERROR Transfer event TRB DMA ptr not part of current TD

However, the video looks fine, and there is no impact on the driver
behavior.

This is caused by a change between the xHCI 0.96 and the xHCI 1.0 spec.
The change describes in section 4.10.1.1 how the xHCI host controller
should handle short transfers that happen on a TD comprised of more than
one TRB chained together. The 0.96 spec says that the host will only
send one event with a short completion code for the TD. The 1.0 spec
says if the short packet happened on a TRB that wasn't the last TRB in
the TD, then we will get two events with short completions (one for the
short TRB and one for the last TRB with the IOC flag set). The 1.0 spec
says that the xHCI driver shall not consider the TD to be done until the
second event is received.

The current xHCI driver behavior finishes the TD when it receives the
first short event. Then when it receives the second event, it prints the
warning message.

This also appeared under the xHCI 1.0 host in Intel Panther Point xHCI,
but it was mistaken for a known hardware bug, the spurious successful
event bug. The work-around that was put into the driver masks this xHCI
driver bug.

Impact on the driver is minimal for this bug.

The easy fix is just to change the XHCI_SPURIOUS_SUCCESS quirk to be
applied for all 1.0 xHCI hosts. However, that doesn't solve the race
condition that exists when the endpoint is stopped before the second
event TRB is received.

The harder fix is to either add an event data TRB after the chained TD
(and stop using ISP and IOC flags), or make the xHCI ring handling code
wait for the second event completion for xHCI 1.0 hosts."

Sarah Sharp
--
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 v4] xhci - correct comp_mode_recovery_timer on return from hibernate

[Sarah Sharp]

On Mon, Mar 11, 2013 at 05:33:26PM +, Cortes, Alexis wrote:
> Hi Sarah,
> 
> Sorry for my delayed response, I was investigating this. By 'Inactive' state 
> you mean the Compliance mode? since SS.Inactive and Compliance are not the 
> same.

Yes, I mean Compliance mode.

> When in D3hot or D3cold, the host must be able to transmit a PME whenever a 
> device is plugged into the DS port.  If a SS device is plugged into DS port 
> and fails to make it to U0, the Port will land in Compliance or SS.Disabled.  
> If Compliance, then there will be no PME notification.  If it lands in 
> SS.Disabled, the USB2 will be enabled and then a PME notification will be 
> sent for USB2 connection. I just realized this.

Then we definitely need to poll during runtime suspend, or disable
runtime PM for the PCI device all together.

Does this mean wake from S3 (system suspend) on device connect will be
broken as well, if the port fails to make it to U0 and goes into
Compliance mode?

Sarah Sharp

> -Original Message-
> From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com] 
> Sent: Wednesday, March 06, 2013 3:32 PM
> To: Alan Stern; Cortes, Alexis
> Cc: Tony Camuso; linux-usb@vger.kernel.org; r...@sisk.pl; dzic...@redhat.com
> Subject: Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return 
> from hibernate
> 
> On Wed, Mar 06, 2013 at 10:12:14AM -0500, Alan Stern wrote:
> > On Tue, 5 Mar 2013, Sarah Sharp wrote:
> > 
> > > static void compliance_mode_recovery(unsigned long arg) { ...
> > > for (i = 0; i < xhci->num_usb3_ports; i++) {
> > > temp = xhci_readl(xhci, xhci->usb3_ports[i]);
> > > if ((temp & PORT_PLS_MASK) == USB_SS_PORT_LS_COMP_MOD) {
> > > /*
> > >  * Compliance Mode Detected. Letting USB Core
> > >  * handle the Warm Reset
> > >  */
> > > 
> > > What happens when the xHCI host controller goes into D3cold due to 
> > > runtime PM?  The port status registers will read as all f's, so we 
> > > will miss any transitions to the compliance mode that happened 
> > > before or during the transition to D3cold.
> > > 
> > > This code probably needs to wake up the host controller and keep it 
> > > from suspending until all the ports can be read.
> > > 
> > > Alan, would the right way to do that be a get/put call into the 
> > > runtime PM core?
> > 
> > If xhci_suspend deletes the Compliance Mode Recovery timer then the 
> > timer will never fire while the controller is in D3cold.  The problem 
> > won't arise.
> 
> Alex,
> 
> Can the USB 3.0 port go into the Inactive sate while the host is in D3hot or 
> D3cold?  If so, will we see a PME that will cause the USB core resume the 
> host?  I'm concerned that if we don't get a port status change event when the 
> port goes into the Inactive state, then we won't get an interrupt if the port 
> transitions to the Inactive state while the host is in D3.
> 
> If the ports can't go into the Inactive state while the host is in D3, then I 
> agree with Alan that it's fine to delete the timer in xhci_suspend.
> 
> However, if the ports can to into the Inactive state and we won't get a PME, 
> then we have to keep the timer running while the xHCI host is runtime 
> suspended.
> 
> Sarah Sharp
--
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: Flood of xhci warnings with 3.9.0-rc1

[Stephen Hemminger]

On Mon, 11 Mar 2013 14:48:01 -0700
Sarah Sharp  wrote:

> On Sun, Mar 10, 2013 at 12:04:40PM -0700, Stephen Hemminger wrote:
> > My test kernel is screaming with xHCI messages into kernel log.
> > [   76.117016] xhci_hcd :00:14.0: WARN Event TRB for slot 1 ep 0 with 
> > no TDs queued?
> > 
> > 
> > This is using kernel based on net-next which is based on 3.9.0-rc1.
> 
> Please send `sudo lspci -vvv -n` output as well.
> 
> Do you have any USB devices that have auto-suspend turned on?  I'm aware
> that the message above gets printed when a device auto-suspends, and it
> really shouldn't in that case.
> 
> Sarah Sharp

I don't explicitly turn on auto-suspend, but maybe some sysctl is doing it 
(powertop?).

00:00.0 0600: 8086:0150 (rev 09)
Subsystem: 1043:84ca
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 0604: 8086:0151 (rev 09) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [88] Subsystem: 1043:84ca
Capabilities: [80] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee00298  Data: 
Capabilities: [a0] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, 
L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 256 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
TransPend-
LnkCap: Port #2, Speed 8GT/s, Width x16, ASPM L0s L1, Latency 
L0 <256ns, L1 <8us
ClockPM- Surprise- LLActRep- BwNot+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- 
BWMgmt+ ABWMgmt+
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- 
Surprise-
Slot #1, PowerLimit 75.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- 
LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- 
Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ 
Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- 
CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID , PMEStatus- PMEPending-
DevCap2: Completion Timeout: Not Supported, TimeoutDis- ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-, 
Selectable De-emphasis: -3.5dB
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, 
EqualizationComplete-, EqualizationPhase1-
 EqualizationPhase2-, EqualizationPhase3-, 
LinkEqualizationRequest-
Capabilities: [100 v1] Virtual Channel
Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
Arb:Fixed- WRR32- WRR64- WRR128-
Ctrl:   ArbSelect=Fixed
Status: InProgress-
VC0:Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb:Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [140 v1] Root Complex Link
Desc:   PortNumber=02 ComponentID=01 EltType=Config
Link0:  Desc:   TargetPort=00 TargetComponent=01 AssocRCRB- 
LinkType=MemMapped LinkValid+
Addr:   fed19000
Capabilities: [d94 v1] #19
Kernel driver in use: pcieport

00:02.0 0300: 8086:0162 (rev 09) (prog-if 00 [VGA controller])
Subsystem: 1043:84ca
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- Fas

Re: [PATCH] vers/usb/gadget: beautify code, delete useless comments

[Chen Gang]

  Felipe Balbi also pointed my subject and comments issue.
  and I have sent the related new patch for it.
  the new patch subject is "[PATCH] usb: gadget: s3c-hsudc: delete outdated 
comment"

  please help checking the new patch, thanks.

  :-)


于 2013年03月11日 19:28, Sergei Shtylyov 写道:
> Hello.
> 
> On 11-03-2013 14:14, Chen Gang wrote:
> 
>>since parameter driver has been deleted, also need delete relative 
>> comments.
>>  relative
> 
>You probably meant "related" in both cases?

  ok, thanks, I need notice, next time.


> 
>> commit number is d93e2600d80fc41ccf339b4a2843a3007d479907
> 
>Please also specify that commit's summary line in parens (or however you 
> like).

  ok, thanks. I need notice, next time.

> 
>> Signed-off-by: Chen Gang 
> 
> WBR, Sergei
> 
> 
> 


-- 
Chen Gang

Asianux Corporation
--
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 v7 0/6] staging: DWC2 DesignWare USB HS OTG driver

[Paul Zimmerman]

Hi Greg,

Here is the latest version of the DWC2 patch set. This version includes
changes suggested by Felipe in his review of the HCD code. Only patch #2
has had any substantial changes since last time.

I have also moved the driver to the staging tree, since it doesn't look
like it's ready for mainline yet.

-- 
Paul


This is a host-mode driver for the Synopsys DesignWare HS OTG controller. 
This is the same controller whose peripheral mode is implemented by the
existing s3c-hsotg driver. This controller is also used in host mode in the
Raspberry Pi via a very ugly out-of-tree driver, so merging this would be a
step toward bringing USB support for that platform into mainline.

The idea is to add a dwc2/ directory alongside the existing dwc3/ directory,
initially to contain just this host-mode driver. Once that has been accepted
we would then like to move the s3c-hsotg driver into this directory and
integrate it to make a dual-role driver. Finally we will implement support
for the OTG features of the controller.

This driver is still a work in progress, to wit:

- Only a PCI bus interface has been implemented so far. However the core
  code and the PCI bus glue code are contained in separate modules, so it
  will be easy to add platform driver interfaces in the future. I have
  already done that with a platform driver for the Raspberry Pi, but it
  is not included here since USB support for that platform is out of tree.

- There is no power-management support yet.

- There is quite a bit of debug code included. We would like to keep that
  until the integration with s3c-hsotg is complete, then most of it can be
  stripped out.

Changes since v6 - Made a fix to the dwc2_hcd_endpoint_disable() function
to close a race that Felipe spotted. Refactored some of the HCD code per
Felipe's suggestions. Moved driver to the staging tree.

Changes since v5 - Made a few minor tweaks in response to Felipe's last
review. Also, use usb_calc_bus_time() in place of a private version,
and implement the .clear_tt_buffer_complete callback, both at the
suggestion of Alan Stern. Fixed a couple of driver crashes that were
exposed by those changes.

Changes since v4 - Changes in response to Felipe's third review. Also
removed the module parameters. Plus made a few more cleanups and
simplifications.

Changes since v3 - Numerous changes in response to Felipe's second review.

Changes since v2 - Fixed a problem with periodic transfers, so hubs, mice
and keyboards work reliably now. Fixed a spurious channel halted interrupt
by disabling the interrupt if the channel is idle.

Changes since v1 - Numerous changes in response to Felipe's review.

Paul Zimmerman (6):
  Core files for the DWC2 driver
  HCD files for the DWC2 driver
  HCD descriptor DMA support for the DWC2 driver
  PCI bus interface for the DWC2 driver
  Hook the DWC2 driver into the build system
  Add a MAINTAINERS entry for the DWC2 driver

 MAINTAINERS  |6 +
 drivers/staging/Kconfig  |2 +
 drivers/staging/Makefile |1 +
 drivers/staging/dwc2/Kconfig |   41 +
 drivers/staging/dwc2/Makefile|   23 +
 drivers/staging/dwc2/core.c  | 2678 ++
 drivers/staging/dwc2/core.h  |  658 +
 drivers/staging/dwc2/core_intr.c |  505 +++
 drivers/staging/dwc2/hcd.c   | 2951 ++
 drivers/staging/dwc2/hcd.h   |  737 ++
 drivers/staging/dwc2/hcd_ddma.c  | 1196 +++
 drivers/staging/dwc2/hcd_intr.c  | 2079 +++
 drivers/staging/dwc2/hcd_queue.c |  675 +
 drivers/staging/dwc2/hw.h|  811 +++
 drivers/staging/dwc2/pci.c   |  198 +++
 15 files changed, 12561 insertions(+)
 create mode 100644 drivers/staging/dwc2/Kconfig
 create mode 100644 drivers/staging/dwc2/Makefile
 create mode 100644 drivers/staging/dwc2/core.c
 create mode 100644 drivers/staging/dwc2/core.h
 create mode 100644 drivers/staging/dwc2/core_intr.c
 create mode 100644 drivers/staging/dwc2/hcd.c
 create mode 100644 drivers/staging/dwc2/hcd.h
 create mode 100644 drivers/staging/dwc2/hcd_ddma.c
 create mode 100644 drivers/staging/dwc2/hcd_intr.c
 create mode 100644 drivers/staging/dwc2/hcd_queue.c
 create mode 100644 drivers/staging/dwc2/hw.h
 create mode 100644 drivers/staging/dwc2/pci.c

-- 
1.8.2.rc0.16.g20a599e

--
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 v7 3/6] staging: HCD descriptor DMA support for the DWC2 driver

[Paul Zimmerman]

This file contains code to support the HCD descriptor DMA mode of
the controller

Signed-off-by: Paul Zimmerman 
Reviewed-by: Felipe Balbi 
---
 drivers/staging/dwc2/hcd_ddma.c | 1196 +++
 1 file changed, 1196 insertions(+)
 create mode 100644 drivers/staging/dwc2/hcd_ddma.c

diff --git a/drivers/staging/dwc2/hcd_ddma.c b/drivers/staging/dwc2/hcd_ddma.c
new file mode 100644
index 000..ab88f50
--- /dev/null
+++ b/drivers/staging/dwc2/hcd_ddma.c
@@ -0,0 +1,1196 @@
+/*
+ * hcd_ddma.c - DesignWare HS OTG Controller descriptor DMA routines
+ *
+ * Copyright (C) 2004-2013 Synopsys, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The names of the above-listed copyright holders may not be used
+ *to endorse or promote products derived from this software without
+ *specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation; either version 2 of the License, or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
+ * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
+ * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*
+ * This file contains the Descriptor DMA implementation for Host mode
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "core.h"
+#include "hcd.h"
+
+static u16 dwc2_frame_list_idx(u16 frame)
+{
+   return frame & (FRLISTEN_64_SIZE - 1);
+}
+
+static u16 dwc2_desclist_idx_inc(u16 idx, u16 inc, u8 speed)
+{
+   return (idx + inc) &
+   ((speed == USB_SPEED_HIGH ? MAX_DMA_DESC_NUM_HS_ISOC :
+ MAX_DMA_DESC_NUM_GENERIC) - 1);
+}
+
+static u16 dwc2_desclist_idx_dec(u16 idx, u16 inc, u8 speed)
+{
+   return (idx - inc) &
+   ((speed == USB_SPEED_HIGH ? MAX_DMA_DESC_NUM_HS_ISOC :
+ MAX_DMA_DESC_NUM_GENERIC) - 1);
+}
+
+static u16 dwc2_max_desc_num(struct dwc2_qh *qh)
+{
+   return (qh->ep_type == USB_ENDPOINT_XFER_ISOC &&
+   qh->dev_speed == USB_SPEED_HIGH) ?
+   MAX_DMA_DESC_NUM_HS_ISOC : MAX_DMA_DESC_NUM_GENERIC;
+}
+
+static u16 dwc2_frame_incr_val(struct dwc2_qh *qh)
+{
+   return qh->dev_speed == USB_SPEED_HIGH ?
+  (qh->interval + 8 - 1) / 8 : qh->interval;
+}
+
+static int dwc2_desc_list_alloc(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh,
+   gfp_t flags)
+{
+   qh->desc_list = dma_alloc_coherent(hsotg->dev,
+   sizeof(struct dwc2_hcd_dma_desc) *
+   dwc2_max_desc_num(qh), &qh->desc_list_dma,
+   flags);
+
+   if (!qh->desc_list)
+   return -ENOMEM;
+
+   memset(qh->desc_list, 0,
+  sizeof(struct dwc2_hcd_dma_desc) * dwc2_max_desc_num(qh));
+
+   qh->n_bytes = kzalloc(sizeof(u32) * dwc2_max_desc_num(qh), flags);
+   if (!qh->n_bytes) {
+   dma_free_coherent(hsotg->dev, sizeof(struct dwc2_hcd_dma_desc)
+ * dwc2_max_desc_num(qh), qh->desc_list,
+ qh->desc_list_dma);
+   qh->desc_list = NULL;
+   return -ENOMEM;
+   }
+
+   return 0;
+}
+
+static void dwc2_desc_list_free(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh)
+{
+   if (qh->desc_list) {
+   dma_free_coherent(hsotg->dev, sizeof(struct dwc2_hcd_dma_desc)
+ * dwc2_max_desc_num(qh), qh->desc_list,
+ qh->desc_list_dma);
+   qh->desc_list = NULL;
+   }
+
+   kfree(qh->n_bytes);
+   qh->n_bytes = NULL;
+}
+
+static int dwc2_frame_li

[PATCH v7 4/6] staging: PCI bus interface for the DWC2 driver

[Paul Zimmerman]

This file contains the PCI bus interface "glue" for the DWC2 driver

Signed-off-by: Paul Zimmerman 
Reviewed-by: Felipe Balbi 
---
 drivers/staging/dwc2/pci.c | 198 +
 1 file changed, 198 insertions(+)
 create mode 100644 drivers/staging/dwc2/pci.c

diff --git a/drivers/staging/dwc2/pci.c b/drivers/staging/dwc2/pci.c
new file mode 100644
index 000..117d3ce
--- /dev/null
+++ b/drivers/staging/dwc2/pci.c
@@ -0,0 +1,198 @@
+/*
+ * pci.c - DesignWare HS OTG Controller PCI driver
+ *
+ * Copyright (C) 2004-2013 Synopsys, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The names of the above-listed copyright holders may not be used
+ *to endorse or promote products derived from this software without
+ *specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation; either version 2 of the License, or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
+ * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
+ * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*
+ * Provides the initialization and cleanup entry points for the DWC_otg PCI
+ * driver
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "core.h"
+#include "hcd.h"
+
+#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
+#define PCI_PRODUCT_ID_HAPS_HSOTG  0xabc0
+
+static const char dwc2_driver_name[] = "dwc_otg";
+
+static struct dwc2_core_params dwc2_module_params = {
+   .otg_cap= -1,
+   .otg_ver= -1,
+   .dma_enable = -1,
+   .dma_desc_enable= 0,
+   .speed  = -1,
+   .enable_dynamic_fifo= -1,
+   .en_multiple_tx_fifo= -1,
+   .host_rx_fifo_size  = 1024,
+   .host_nperio_tx_fifo_size   = 256,
+   .host_perio_tx_fifo_size= 1024,
+   .max_transfer_size  = 65535,
+   .max_packet_count   = 511,
+   .host_channels  = -1,
+   .phy_type   = -1,
+   .phy_utmi_width = 16,   /* 16 bits - NOT DETECTABLE */
+   .phy_ulpi_ddr   = -1,
+   .phy_ulpi_ext_vbus  = -1,
+   .i2c_enable = -1,
+   .ulpi_fs_ls = -1,
+   .host_support_fs_ls_low_power   = -1,
+   .host_ls_low_power_phy_clk  = -1,
+   .ts_dline   = -1,
+   .reload_ctl = -1,
+   .ahb_single = -1,
+};
+
+/**
+ * dwc2_driver_remove() - Called when the DWC_otg core is unregistered with the
+ * DWC_otg driver
+ *
+ * @dev: Bus device
+ *
+ * This routine is called, for example, when the rmmod command is executed. The
+ * device may or may not be electrically present. If it is present, the driver
+ * stops device processing. Any resources used on behalf of this device are
+ * freed.
+ */
+static void dwc2_driver_remove(struct pci_dev *dev)
+{
+   struct dwc2_hsotg *hsotg = pci_get_drvdata(dev);
+
+   dev_dbg(&dev->dev, "%s(%p)\n", __func__, dev);
+
+   dwc2_hcd_remove(&dev->dev, hsotg);
+   pci_disable_device(dev);
+}
+
+/**
+ * dwc2_driver_probe() - Called when the DWC_otg core is bound to the DWC_otg
+ * driver
+ *
+ * @dev: Bus device
+ *
+ * This routine creates the driver components required to control the device
+ * (core, HCD, and PCD) and initializes the device. The driver components are
+ * stored in a dwc2_hsotg structure. A reference to the dwc2_hsotg is saved
+ * in the device

[PATCH v7 5/6] staging: Hook the DWC2 driver into the build system

[Paul Zimmerman]

Add the DWC2 Kconfig and Makefile, and modify the USB Kconfig and
Makefile to include them

Signed-off-by: Paul Zimmerman 
---
 drivers/staging/Kconfig   |  2 ++
 drivers/staging/Makefile  |  1 +
 drivers/staging/dwc2/Kconfig  | 41 +
 drivers/staging/dwc2/Makefile | 23 +++
 4 files changed, 67 insertions(+)
 create mode 100644 drivers/staging/dwc2/Kconfig
 create mode 100644 drivers/staging/dwc2/Makefile

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 093f10c..1df401a 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -140,4 +140,6 @@ source "drivers/staging/zcache/Kconfig"
 
 source "drivers/staging/goldfish/Kconfig"
 
+source "drivers/staging/dwc2/Kconfig"
+
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index fa41b04..2a6a607 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -62,3 +62,4 @@ obj-$(CONFIG_SB105X)  += sb105x/
 obj-$(CONFIG_FIREWIRE_SERIAL)  += fwserial/
 obj-$(CONFIG_ZCACHE)   += zcache/
 obj-$(CONFIG_GOLDFISH) += goldfish/
+obj-$(CONFIG_USB_DWC2) += dwc2/
diff --git a/drivers/staging/dwc2/Kconfig b/drivers/staging/dwc2/Kconfig
new file mode 100644
index 000..610418a
--- /dev/null
+++ b/drivers/staging/dwc2/Kconfig
@@ -0,0 +1,41 @@
+config USB_DWC2
+   tristate "DesignWare USB2 DRD Core Support"
+   depends on USB
+   select USB_OTG_UTILS
+   help
+ Say Y or M here if your system has a Dual Role HighSpeed
+ USB controller based on the DesignWare HSOTG IP Core.
+
+ If you choose to build this driver as dynamically linked
+ modules, the core module will be called dwc2.ko, and the
+ PCI bus interface module (if you have a PCI bus system)
+ will be called dwc2_pci.ko.
+
+ NOTE: This driver at present only implements the Host mode
+ of the controller. The existing s3c-hsotg driver supports
+ Peripheral mode, but only for the Samsung S3C platforms.
+ There are plans to merge the s3c-hsotg driver with this
+ driver in the near future to create a dual-role driver.
+
+if USB_DWC2
+
+config USB_DWC2_DEBUG
+   bool "Enable Debugging Messages"
+   help
+ Say Y here to enable debugging messages in the DWC2 Driver.
+
+config USB_DWC2_VERBOSE
+   bool "Enable Verbose Debugging Messages"
+   depends on USB_DWC2_DEBUG
+   help
+ Say Y here to enable verbose debugging messages in the DWC2 Driver.
+ WARNING: Enabling this will quickly fill your message log.
+ If in doubt, say N.
+
+config USB_DWC2_TRACK_MISSED_SOFS
+   bool "Enable Missed SOF Tracking"
+   help
+ Say Y here to enable logging of missed SOF events to the dmesg log.
+ If in doubt, say N.
+
+endif
diff --git a/drivers/staging/dwc2/Makefile b/drivers/staging/dwc2/Makefile
new file mode 100644
index 000..6dccf46
--- /dev/null
+++ b/drivers/staging/dwc2/Makefile
@@ -0,0 +1,23 @@
+ccflags-$(CONFIG_USB_DWC2_DEBUG)   += -DDEBUG
+ccflags-$(CONFIG_USB_DWC2_VERBOSE) += -DVERBOSE_DEBUG
+
+obj-$(CONFIG_USB_DWC2) += dwc2.o
+
+dwc2-y += core.o core_intr.o
+
+# NOTE: This driver at present only implements the Host mode
+# of the controller. The existing s3c-hsotg driver supports
+# Peripheral mode, but only for the Samsung S3C platforms.
+# There are plans to merge the s3c-hsotg driver with this
+# driver in the near future to create a dual-role driver. Once
+# that is done, Host mode will become an optional feature that
+# is selected with a config option.
+
+dwc2-y += hcd.o hcd_intr.o
+dwc2-y += hcd_queue.o hcd_ddma.o
+
+ifneq ($(CONFIG_PCI),)
+   obj-$(CONFIG_USB_DWC2)  += dwc2_pci.o
+endif
+
+dwc2_pci-y += pci.o
-- 
1.8.2.rc0.16.g20a599e

--
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 v7 6/6] staging: Add a MAINTAINERS entry for the DWC2 driver

[Paul Zimmerman]

Add myself as maintainer of the DWC2 driver

Signed-off-by: Paul Zimmerman 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e95b1e9..6672165 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2470,6 +2470,12 @@ M:   Matthew Garrett 
 S: Maintained
 F: drivers/platform/x86/dell-wmi.c
 
+DESIGNWARE USB2 DRD IP DRIVER
+M: Paul Zimmerman 
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/staging/dwc2/
+
 DESIGNWARE USB3 DRD IP DRIVER
 M: Felipe Balbi 
 L: linux-usb@vger.kernel.org
-- 
1.8.2.rc0.16.g20a599e

--
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: Flood of xhci warnings with 3.9.0-rc1

[Sarah Sharp]

On Mon, Mar 11, 2013 at 05:04:05PM -0700, Stephen Hemminger wrote:
> On Mon, 11 Mar 2013 14:48:01 -0700
> Sarah Sharp  wrote:
> 
> > On Sun, Mar 10, 2013 at 12:04:40PM -0700, Stephen Hemminger wrote:
> > > My test kernel is screaming with xHCI messages into kernel log.
> > > [   76.117016] xhci_hcd :00:14.0: WARN Event TRB for slot 1 ep 0 with 
> > > no TDs queued?
> > > 
> > > 
> > > This is using kernel based on net-next which is based on 3.9.0-rc1.
> > 
> > Please send `sudo lspci -vvv -n` output as well.
> > 
> > Do you have any USB devices that have auto-suspend turned on?  I'm aware
> > that the message above gets printed when a device auto-suspends, and it
> > really shouldn't in that case.
> > 
> > Sarah Sharp
> 
> I don't explicitly turn on auto-suspend, but maybe some sysctl is doing it 
> (powertop?).

Well, let's find out.  Can you please run the following command as root?

for f in /sys/bus/usb/devices/*; do if [ -e $f/power/control ]; then echo 
"Filename: $f"; cat "$f/power/control"; fi done

> 00:14.0 0c03: 8086:1e31 (rev 04) (prog-if 30 [XHCI])
>   Subsystem: 1043:84ca
>   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
>   Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> SERR-Latency: 0
>   Interrupt: pin A routed to IRQ 44
>   Region 0: Memory at f7d0 (64-bit, non-prefetchable) [size=64K]
>   Capabilities: [70] Power Management version 2
>   Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA 
> PME(D0-,D1-,D2-,D3hot+,D3cold+)
>   Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>   Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
>   Address: fee002f8  Data: 
>   Kernel driver in use: xhci_hcd

All right.  You've got a Intel Panther Point xHCI host then.

Did you notice these messages on older kernels, or just with the 3.9-rc1
kernel?

Sarah Sharp
--
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 0/6] staging: DWC2 DesignWare USB HS OTG driver

[Greg KH]

On Mon, Mar 11, 2013 at 05:47:57PM -0700, Paul Zimmerman wrote:
> Hi Greg,
> 
> Here is the latest version of the DWC2 patch set. This version includes
> changes suggested by Felipe in his review of the HCD code. Only patch #2
> has had any substantial changes since last time.
> 
> I have also moved the driver to the staging tree, since it doesn't look
> like it's ready for mainline yet.

All applied now, 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: fsl_udc_core: set address request aren't handled like expected. usb30cv test suite fails.

[Peter Chen]

> 
> Hi,
> 
> I tested your patch, Peter and it works fine. All tests of the usbcv30 
> are passing with my setup. Thank you so far.
> 
> So you get a tested-by: peter.best...@omicron.at
> 
> In my opinion we do it in the wrong order; we set the address before the 
> status stage
> completes. But isn't the setAddress request specified that we should
> set it after the status stage completes, like it was before 
> (http://www.beyondlogic.org/usbnutshell/usb6.shtml)

We set address at the ep0_req_complete, it is called after the status stage
is completed.

-- 

Best Regards,
Peter Chen

--
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: PROBLEM: since linux kernel 3.8 Apple Cinema Display's usb hub spits errors randomly at boot.

[Jenya Y]

On 03/11/2013 04:06 PM, Alan Stern wrote:

On Mon, 11 Mar 2013, Jenya Y wrote:


// Update
Alan, I'm happy to say that the errors disappeared. I recompiled the
latest master from torvalds with USB_CONFIG=Y instead of 'm' and the
errors are gone. I'm not sure it was this particular config flag + the
settings you suggested earlier or simply the changes that were
incorporated into the latest master but everything is working perfectly now.

Thank you very very much for you patience with me and I'll be glad to
assist if you need any help figuring out what went right :)

Well, I'd like to take the credit for this but I don't really deserve
it.  :-)

The problem you had is a valid one and it deserves to be fixed.
People should not have to select particular combinations of config
options in order to avoid a ton of error messages.

I'll try to work out a patch in the next few days.  Can you recreate
the arrangement where all the errors occurred, in order to test the
patch when it is ready?

Alan Stern


Absolutely, I'd be glad to help.

Just tell me what kernel should I use to apply your patch and I'll 
prepare the env to test it.

--
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: Flood of xhci warnings with 3.9.0-rc1

[Stephen Hemminger]

On Mon, 11 Mar 2013 17:55:42 -0700
Sarah Sharp  wrote:

> Well, let's find out.  Can you please run the following command as root?
> 
> for f in /sys/bus/usb/devices/*; do if [ -e $f/power/control ]; then echo 
> "Filename: $f"; cat "$f/power/control"; fi done

All are marked auto
Filename: /sys/bus/usb/devices/1-1
auto
Filename: /sys/bus/usb/devices/2-1
auto
Filename: /sys/bus/usb/devices/2-1.5
auto
Filename: /sys/bus/usb/devices/2-1.5.1
on
Filename: /sys/bus/usb/devices/2-1.5.3
on
Filename: /sys/bus/usb/devices/2-1.5.4
on
Filename: /sys/bus/usb/devices/2-1.6
auto
Filename: /sys/bus/usb/devices/3-4
auto
Filename: /sys/bus/usb/devices/usb1
auto
Filename: /sys/bus/usb/devices/usb2
auto
Filename: /sys/bus/usb/devices/usb3
auto
Filename: /sys/bus/usb/devices/usb4
auto
--
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: Flood of xhci warnings with 3.9.0-rc1

[Stephen Hemminger]

On Mon, 11 Mar 2013 17:55:42 -0700
Sarah Sharp  wrote:

> All right.  You've got a Intel Panther Point xHCI host then.
> 
> Did you notice these messages on older kernels, or just with the 3.9-rc1
> kernel?

It seems to be new in 3.9, haven't bisected it down.
--
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: Fwd: a usb regression in kernel 2.6.37 and upper

[Alan Stern]

On Mon, 11 Mar 2013, Sarah Sharp wrote:

> On Mon, Mar 11, 2013 at 02:50:57PM +0800, Joshua wrote:

...

> > Recently, I read the EHCI 1.1 addendum specification. I noticed there
> > are some implementations in kernel for that spec by intel engineers,
> > but i didn't find the "Hardware Prefetching" support . Did the kernel
> > support that feature?
> > I doubt there have such a EHCI that supports the EHCI 1.1.
> 
> What would an EHCI addendum have to do with your particular bug?  Or is
> this a different question?
> 
> Alan Stern would probably be the best person to ask this question, since
> he's the EHCI maintainer.

ehci-hcd does not support Hardware Prefetching.

Since Intel played a big role in designing the EHCI 1.1 addendum, it 
seems likely that they made some EHCI controllers supporting those 
extensions.  But I don't know the details, and I don't know if the 
controllers in the current chipsets support EHCI-1.1.

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: About USBADRA bit at DEVICEADDR for chipidea driver

[Peter Chen]

On Mon, Mar 11, 2013 at 10:58:05AM -0400, Alan Stern wrote:
> On Mon, 11 Mar 2013, Alexander Shishkin wrote:
> 
> > > For USB 3.0 host CV test, the host sends GET_DESCRIPTOR very quick 
> > > (<500us)
> > > once it accept the status of SET_ADDRESS
> > 
> > The USB 2.0 spec says the recovery period after the status phase of
> > SetAddress is 2ms. That should be enough to process the transfer
> > completion interrupt, shouldn't it?
> > Why is USB 3 CV violating this and why should we care? I guess, if we
> 
> Probably because the recovery period, being in the USB 2.0 spec,
> applies to USB-2 devices -- whereas the USB-3 CV tries to test USB-3
> devices.  Do they have the same recovery period?
> 

Alex & Alan, I checked the USB 3.0 spec, there is no requirement
for recovery time. So, for this problem, it is USB3 CV suite's problem,
When it detects 2.0 device, it should follow 2.0 recovery time.

-- 

Best Regards,
Peter Chen

--
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 15/18] driver: usb: storage: remove cast for kmalloc return value

[Zhang Yanfei]

remove cast for kmalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Matthew Dharm 
Cc: Greg Kroah-Hartman 
Cc: Andrew Morton 
Cc: linux-usb@vger.kernel.org
Cc: usb-stor...@lists.one-eyed-alien.net
---
 drivers/usb/storage/isd200.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/storage/isd200.c b/drivers/usb/storage/isd200.c
index ecea478..06a3d22 100644
--- a/drivers/usb/storage/isd200.c
+++ b/drivers/usb/storage/isd200.c
@@ -1457,8 +1457,7 @@ static int isd200_init_info(struct us_data *us)
retStatus = ISD200_ERROR;
else {
info->id = kzalloc(ATA_ID_WORDS * 2, GFP_KERNEL);
-   info->RegsBuf = (unsigned char *)
-   kmalloc(sizeof(info->ATARegs), GFP_KERNEL);
+   info->RegsBuf = kmalloc(sizeof(info->ATARegs), GFP_KERNEL);
info->srb.sense_buffer =
kmalloc(SCSI_SENSE_BUFFERSIZE, GFP_KERNEL);
if (!info->id || !info->RegsBuf || !info->srb.sense_buffer) {
-- 
1.7.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