[PATCH usb:usb-next] USB: ezusb: make some vars/funcs static

[Fengguang Wu]

Signed-off-by: Fengguang Wu 
---
 drivers/usb/misc/ezusb.c |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next
head:   70c048a238c780c226eb4b115ebaa908cb3b34ec
commit: 70c048a238c780c226eb4b115ebaa908cb3b34ec [72/73] USB: ezusb: move 
ezusb.c from drivers/usb/serial to drivers/usb/misc

+ drivers/usb/misc/ezusb.c:25:22: sparse: symbol 'ezusb_fx1' was not declared. 
Should it be static?
+ drivers/usb/misc/ezusb.c:30:22: sparse: symbol 'ezusb_fx2' was not declared. 
Should it be static?
+ drivers/usb/misc/ezusb.c:39:5: sparse: symbol 'ezusb_writememory' was not 
declared. Should it be static?
+ drivers/usb/misc/ezusb.c:63:5: sparse: symbol 'ezusb_set_reset' was not 
declared. Should it be static?
+ drivers/usb/misc/ezusb.c:73:5: sparse: symbol 'ezusb_fx1_set_reset' was not 
declared. Should it be static?
+ drivers/usb/misc/ezusb.c:79:5: sparse: symbol 'ezusb_fx2_set_reset' was not 
declared. Should it be static?
+ drivers/usb/misc/ezusb.c:147:5: sparse: symbol 
'ezusb_fx1_ihex_firmware_download' was not declared. Should it be static?
+ drivers/usb/misc/ezusb.c:154:5: sparse: symbol 
'ezusb_fx2_ihex_firmware_download' was not declared. Should it be static?

--- linux-next.orig/drivers/usb/misc/ezusb.c2012-09-27 14:16:27.914648701 
+0800
+++ linux-next/drivers/usb/misc/ezusb.c 2012-09-27 14:16:38.158648945 +0800
@@ -22,12 +22,12 @@ struct ezusb_fx_type {
unsigned short max_internal_adress;
 };
 
-struct ezusb_fx_type ezusb_fx1 = {
+static struct ezusb_fx_type ezusb_fx1 = {
.cpucs_reg = 0x7F92,
.max_internal_adress = 0x1B3F,
 };
 
-struct ezusb_fx_type ezusb_fx2 = {
+static struct ezusb_fx_type ezusb_fx2 = {
.cpucs_reg = 0xE600,
.max_internal_adress = 0x3FFF,
 };
@@ -36,7 +36,7 @@ struct ezusb_fx_type ezusb_fx2 = {
 #define WRITE_INT_RAM 0xA0
 #define WRITE_EXT_RAM 0xA3
 
-int ezusb_writememory(struct usb_device *dev, int address,
+static int ezusb_writememory(struct usb_device *dev, int address,
unsigned char *data, int length, __u8 request)
 {
int result;
@@ -60,7 +60,7 @@ int ezusb_writememory(struct usb_device
 }
 EXPORT_SYMBOL_GPL(ezusb_writememory);
 
-int ezusb_set_reset(struct usb_device *dev, unsigned short cpucs_reg,
+static int ezusb_set_reset(struct usb_device *dev, unsigned short cpucs_reg,
 unsigned char reset_bit)
 {
int response = ezusb_writememory(dev, cpucs_reg, &reset_bit, 1, 
WRITE_INT_RAM);
@@ -70,13 +70,13 @@ int ezusb_set_reset(struct usb_device *d
return response;
 }
 
-int ezusb_fx1_set_reset(struct usb_device *dev, unsigned char reset_bit)
+static int ezusb_fx1_set_reset(struct usb_device *dev, unsigned char reset_bit)
 {
return ezusb_set_reset(dev, ezusb_fx1.cpucs_reg, reset_bit);
 }
 EXPORT_SYMBOL_GPL(ezusb_fx1_set_reset);
 
-int ezusb_fx2_set_reset(struct usb_device *dev, unsigned char reset_bit)
+static int ezusb_fx2_set_reset(struct usb_device *dev, unsigned char reset_bit)
 {
return ezusb_set_reset(dev, ezusb_fx2.cpucs_reg, reset_bit);
 }
@@ -144,14 +144,14 @@ out:
return ret;
 }
 
-int ezusb_fx1_ihex_firmware_download(struct usb_device *dev,
+static int ezusb_fx1_ihex_firmware_download(struct usb_device *dev,
 const char *firmware_path)
 {
return ezusb_ihex_firmware_download(dev, ezusb_fx1, firmware_path);
 }
 EXPORT_SYMBOL_GPL(ezusb_fx1_ihex_firmware_download);
 
-int ezusb_fx2_ihex_firmware_download(struct usb_device *dev,
+static int ezusb_fx2_ihex_firmware_download(struct usb_device *dev,
 const char *firmware_path)
 {
return ezusb_ihex_firmware_download(dev, ezusb_fx2, firmware_path);
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] usb: otg: nop: add dt support

[Afzal Mohammed]

From: "B, Ravi" 

Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.

Signed-off-by: Ravi Babu 
Signed-off-by: Ajay Kumar Gupta 
Signed-off-by: Afzal Mohammed 
---

Hi,

This series is made over over Balbi's usb "master" branch.

It applies cleanly over "musb" branch too.

Regards
Afzal

 Documentation/devicetree/bindings/usb/am33xx-usb.txt |  3 +++
 drivers/usb/otg/nop-usb-xceiv.c  | 10 ++
 2 files changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt 
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ca8fa56..9782585 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,3 +12,6 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
  - power : Should be "250". This signifies the controller can supply upto
500mA when operating in host mode.
+
+NOP USB PHY
+ - compatible : Should be "nop-xceiv-usb"
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index e52e35e..64bfbe4 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -27,6 +27,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -154,12 +155,21 @@ static int __devexit nop_usb_xceiv_remove(struct 
platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id nop_xceiv_id_table[] = {
+   { .compatible = "nop-xceiv-usb" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, nop_xceiv_id_table);
+#endif
+
 static struct platform_driver nop_usb_xceiv_driver = {
.probe  = nop_usb_xceiv_probe,
.remove = __devexit_p(nop_usb_xceiv_remove),
.driver = {
.name   = "nop_usb_xceiv",
.owner  = THIS_MODULE,
+   .of_match_table = of_match_ptr(nop_xceiv_id_table),
},
 };
 
-- 
1.7.12

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

[PATCH 3/3] usb: musb: dsps: document dt bindings properly

[Afzal Mohammed]

DT bindings have '-' (hyphens) instead of '_' (underscore),
update the documentation to reflect it.

Signed-off-by: Afzal Mohammed 
---
 Documentation/devicetree/bindings/usb/am33xx-usb.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt 
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index 9782585..6d5d5f0 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -3,12 +3,12 @@ AM33XX MUSB GLUE
  - ti,hwmods : must be "usb_otg_hs"
  - multipoint : Should be "1" indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
- - num_eps : Specifies the number of endpoints. This is also a
+ - num-eps : Specifies the number of endpoints. This is also a
MUSB configuration-specific setting. Should be set to "16"
- - ram_bits : Specifies the ram address size. Should be set to "12"
- - port0_mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
+ - ram-bits : Specifies the ram address size. Should be set to "12"
+ - port0-mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
represents PERIPHERAL.
- - port1_mode : Should be "1" to represent HOST. "3" signifies OTG and "2"
+ - port1-mode : Should be "1" to represent HOST. "3" signifies OTG and "2"
represents PERIPHERAL.
  - power : Should be "250". This signifies the controller can supply upto
500mA when operating in host mode.
-- 
1.7.12

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

[PATCH 2/3] usb: musb: dsps: remove nop unregister

[Afzal Mohammed]

"usb: musb: dsps: remove explicit NOP device creation"
removed nop register, but not unregistering, remove nop
unregister in error and exit path.

Signed-off-by: Afzal Mohammed 
---
 drivers/usb/musb/musb_dsps.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 444346e..9d7ca4c 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -411,7 +411,6 @@ static int dsps_musb_init(struct musb *musb)
return 0;
 err0:
usb_put_phy(musb->xceiv);
-   usb_nop_xceiv_unregister();
return status;
 }
 
@@ -431,7 +430,6 @@ static int dsps_musb_exit(struct musb *musb)
 
/* NOP driver needs change if supporting dual instance */
usb_put_phy(musb->xceiv);
-   usb_nop_xceiv_unregister();
 
return 0;
 }
-- 
1.7.12

--
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 02/12] usb: chipidea: udc: add pullup fuction, needed by the uvc gadget

[Chen Peter-B29397]

 
> > > hw_write(ci, OP_USBINTR, ~0,
> > >
> USBi_UI|USBi_UEI|USBi_PCI|USBi_URI|USBi_SLI);
> > > -   hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
> > > } else {
> > > -   hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
> > > hw_write(ci, OP_USBINTR, ~0, 0);
> > > }
> >
> > Hi Marc, your above change break the function that load gadget before
> > plug usb cable.
> 
> What do you mean with that? When switching into device role, the
> otg can load every gadget-module without having the hardware pluged-in.
> 

Are you sure? In current chipidea otg design, the gadget will be freed
when device->host, but the gadget will not be re-created when host->device.
So, when the device connects to pc again, there will be an null pointer error.
(I use g_serial.ko)

Peter


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

Re: [PATCH 4/4] usb: phy: omap-usb2: enable 960Mhz clock for omap5

[Felipe Balbi]

On Thu, Sep 27, 2012 at 10:43:06AM +0530, ABRAHAM, KISHON VIJAY wrote:
> Hi,
> 
> On Wed, Sep 26, 2012 at 11:57 PM, Felipe Balbi  wrote:
> > Hi,
> >
> > On Wed, Sep 26, 2012 at 11:10:48AM +0530, ABRAHAM, KISHON VIJAY wrote:
> >> Hi,
> >>
> >> On Wed, Sep 19, 2012 at 5:26 PM, Felipe Balbi  wrote:
> >> > On Wed, Sep 19, 2012 at 05:00:29PM +0530, Kishon Vijay Abraham I wrote:
> >> >> "usb_otg_ss_refclk960m" is needed by usb2 phy present in omap5. For
> >> >> omap4, the clk_get of this clock will fail since it does not have this
> >> >> clock.
> >> >>
> >> >> Signed-off-by: Kishon Vijay Abraham I 
> >> >> ---
> >> >>  Documentation/devicetree/bindings/usb/usb-phy.txt |3 +++
> >> >>  drivers/usb/phy/omap-usb2.c   |   28 
> >> >> -
> >> >>  2 files changed, 30 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
> >> >> b/Documentation/devicetree/bindings/usb/usb-phy.txt
> >> >> index 7c5fd89..d5626de 100644
> >> >> --- a/Documentation/devicetree/bindings/usb/usb-phy.txt
> >> >> +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
> >> >> @@ -24,6 +24,9 @@ Required properties:
> >> >>  add the address of control module phy power register until a driver for
> >> >>  control module is added
> >> >>
> >> >> +Optional properties:
> >> >> + - has960mhzclk: should be added if the phy needs 960mhz clock
> >> >> +
> >> >>  This is usually a subnode of ocp2scp to which it is connected.
> >> >>
> >> >>  usb3phy@4a084400 {
> >> >> diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
> >> >> index d36c282..d6612ba 100644
> >> >> --- a/drivers/usb/phy/omap-usb2.c
> >> >> +++ b/drivers/usb/phy/omap-usb2.c
> >> >> @@ -146,6 +146,7 @@ static int __devinit omap_usb2_probe(struct 
> >> >> platform_device *pdev)
> >> >>   struct omap_usb *phy;
> >> >>   struct usb_otg  *otg;
> >> >>   struct resource *res;
> >> >> + struct device_node  *np = pdev->dev.of_node;
> >> >>
> >> >>   phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
> >> >>   if (!phy) {
> >> >> @@ -190,6 +191,15 @@ static int __devinit omap_usb2_probe(struct 
> >> >> platform_device *pdev)
> >> >>   }
> >> >>   clk_prepare(phy->wkupclk);
> >> >>
> >> >> + if (of_property_read_bool(np, "has960mhzclk")) {
> >> >> + phy->optclk = devm_clk_get(phy->dev, 
> >> >> "usb_otg_ss_refclk960m");
> >> >> + if (IS_ERR(phy->optclk)) {
> >> >> + dev_err(&pdev->dev, "unable to get refclk960m\n");
> >> >> + return PTR_ERR(phy->optclk);
> >> >> + }
> >> >> + clk_prepare(phy->optclk);
> >> >> + }
> >> >
> >> > instead, can't you just always try to get the clock but ignore the error
> >> > if it fails ?
> >>
> >> This clock is needed for usb2 to work in dwc3 (omap5). So we have to
> >> report the error in case we dont get the clock no?
> >
> > sure, but you don't need to bail out. Print a warning message such as:
> >
> > dev_dbg(&pdev->dev, "couldn't get refclk960m, trying without\n");
> 
> but then we'll get this debug message for omap4 which actually doesn't
> need 960m clk.

then make it dev_vdbg(). It's just a debugging message, it's not saying
it will fail, it's just stating that clock isn't present and we're
trying without because it's known that some versions don't need that
clock.

Another way to do it, would be to request or not the extra clock, based
on the Revision Register (if this IP has one).

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 4/4] usb: phy: omap-usb2: enable 960Mhz clock for omap5

[ABRAHAM, KISHON VIJAY]

Hi,

On Wed, Sep 26, 2012 at 11:57 PM, Felipe Balbi  wrote:
> Hi,
>
> On Wed, Sep 26, 2012 at 11:10:48AM +0530, ABRAHAM, KISHON VIJAY wrote:
>> Hi,
>>
>> On Wed, Sep 19, 2012 at 5:26 PM, Felipe Balbi  wrote:
>> > On Wed, Sep 19, 2012 at 05:00:29PM +0530, Kishon Vijay Abraham I wrote:
>> >> "usb_otg_ss_refclk960m" is needed by usb2 phy present in omap5. For
>> >> omap4, the clk_get of this clock will fail since it does not have this
>> >> clock.
>> >>
>> >> Signed-off-by: Kishon Vijay Abraham I 
>> >> ---
>> >>  Documentation/devicetree/bindings/usb/usb-phy.txt |3 +++
>> >>  drivers/usb/phy/omap-usb2.c   |   28 
>> >> -
>> >>  2 files changed, 30 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
>> >> b/Documentation/devicetree/bindings/usb/usb-phy.txt
>> >> index 7c5fd89..d5626de 100644
>> >> --- a/Documentation/devicetree/bindings/usb/usb-phy.txt
>> >> +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
>> >> @@ -24,6 +24,9 @@ Required properties:
>> >>  add the address of control module phy power register until a driver for
>> >>  control module is added
>> >>
>> >> +Optional properties:
>> >> + - has960mhzclk: should be added if the phy needs 960mhz clock
>> >> +
>> >>  This is usually a subnode of ocp2scp to which it is connected.
>> >>
>> >>  usb3phy@4a084400 {
>> >> diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
>> >> index d36c282..d6612ba 100644
>> >> --- a/drivers/usb/phy/omap-usb2.c
>> >> +++ b/drivers/usb/phy/omap-usb2.c
>> >> @@ -146,6 +146,7 @@ static int __devinit omap_usb2_probe(struct 
>> >> platform_device *pdev)
>> >>   struct omap_usb *phy;
>> >>   struct usb_otg  *otg;
>> >>   struct resource *res;
>> >> + struct device_node  *np = pdev->dev.of_node;
>> >>
>> >>   phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
>> >>   if (!phy) {
>> >> @@ -190,6 +191,15 @@ static int __devinit omap_usb2_probe(struct 
>> >> platform_device *pdev)
>> >>   }
>> >>   clk_prepare(phy->wkupclk);
>> >>
>> >> + if (of_property_read_bool(np, "has960mhzclk")) {
>> >> + phy->optclk = devm_clk_get(phy->dev, 
>> >> "usb_otg_ss_refclk960m");
>> >> + if (IS_ERR(phy->optclk)) {
>> >> + dev_err(&pdev->dev, "unable to get refclk960m\n");
>> >> + return PTR_ERR(phy->optclk);
>> >> + }
>> >> + clk_prepare(phy->optclk);
>> >> + }
>> >
>> > instead, can't you just always try to get the clock but ignore the error
>> > if it fails ?
>>
>> This clock is needed for usb2 to work in dwc3 (omap5). So we have to
>> report the error in case we dont get the clock no?
>
> sure, but you don't need to bail out. Print a warning message such as:
>
> dev_dbg(&pdev->dev, "couldn't get refclk960m, trying without\n");

but then we'll get this debug message for omap4 which actually doesn't
need 960m clk.

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

[PATCH v2 2/2] USB: set hub's default autosuspend delay as 0

[Ming Lei]

This patch sets hub device's default autosuspend delay as 0 to
speedup bus suspend, see comments in code for details.

Cc: Alan Stern 
Signed-off-by: Ming Lei 
---
 drivers/usb/core/hub.c |   34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index e67994c..7c2cba9 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1629,6 +1629,40 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
desc = intf->cur_altsetting;
hdev = interface_to_usbdev(intf);
 
+   /*
+* Set default autosuspend delay as 0 to speedup bus suspend,
+* based on the below considerations:
+*
+* - Unlike other drivers, the hub driver does not rely on the
+*   autosuspend delay to provide enough time to handle a wakeup
+*   event, and the submitted status URB is just to check future
+*   change on hub downstream ports, so it is safe to do it.
+*
+* - The patch might cause one or more auto supend/resume for
+*   below very rare devices when they are plugged into hub
+*   first time:
+*
+*  devices having trouble initializing, and disconnect
+*  themselves from the bus and then reconnect a second
+*  or so later
+*
+*  devices just for downloading firmware, and disconnects
+*  themselves after completing it
+*
+*   These quite rare devices still can change the autosuspend
+*   delay of their parent hub in the probe() to one appropriate
+*   value to avoid the subtle problem if someone does care it.
+*
+* - The patch may cause one or more auto suspend/resume on
+*   hub during running 'lsusb', but it is probably too
+*   infrequent to worry about.
+*
+* - Change autosuspend delay of hub can avoid unnecessary auto
+*   suspend timer for hub, also may decrease power consumption
+*   of USB bus.
+*/
+   pm_runtime_set_autosuspend_delay(&hdev->dev, 0);
+
/* Hubs have proper suspend/resume support. */
usb_enable_autosuspend(hdev);
 
-- 
1.7.9.5

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

[PATCH v2 1/2] USB: check port changes before hub runtime suspend for some bug device

[Ming Lei]

From: Ming Lei 

The hub status endpoint has a long 'bInterval', which is 255ms
for FS/LS device and 256ms for HS device according to USB 2.0 spec,
so the device connection change may be reported later more than 255ms
via status pipe.

The connection change in hub may have been happened already on the
downstream ports, but no status URB completes when it is killed
in hub_suspend(auto), so the connection change may be missed by some
buggy hub devices, which won't generate remote wakeup signal after
their remote wakeup is enabled and they are put into suspend state.

The problem can be observed at least on the below Genesys Logic, Inc.
hub devices:

0x05e3,0x0606
0x05e3,0x0608

In theory, there is no way to fix the problem completely, but we
can make it less likely to occur by this patch.

This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND
to check ports' change during hub_suspend(auto) for the buggy
devices. If ports' change is found, terminate the auto suspend and
return to working state.

So for the buggy hubs, if the connection change happend before
the ports' check, it can be handled correctly. If it happens between
the ports' check and enabling remote wakeup/entering suspend, it
will be missed. Considered the interval is quite short, it is very
less likely to happen during the window.

Cc: Alan Stern 
Signed-off-by: Ming Lei 
---
 drivers/usb/core/hub.c |   38 ++
 1 file changed, 38 insertions(+)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 6dc41c6..e67994c 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -39,6 +39,8 @@
 #endif
 #endif
 
+#define HUB_QUIRK_CHECK_PORT_AUTOSUSPEND   0x01
+
 enum port_power_policy {
USB_PORT_POWER_ON = 0,
USB_PORT_POWER_OFF,
@@ -92,6 +94,8 @@ struct usb_hub {
unsignedquiescing:1;
unsigneddisconnected:1;
 
+   unsignedquirk_check_port_auto_suspend:1;
+
unsignedhas_indicators:1;
u8  indicator[USB_MAXCHILDREN];
struct delayed_work leds;
@@ -1683,6 +1687,9 @@ descriptor_error:
if (hdev->speed == USB_SPEED_HIGH)
highspeed_hubs++;
 
+   if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
+   hub->quirk_check_port_auto_suspend = 1;
+
if (hub_configure(hub, endpoint) >= 0)
return 0;
 
@@ -3158,6 +3165,21 @@ int usb_port_resume(struct usb_device *udev, 
pm_message_t msg)
 
 #endif
 
+static int check_ports_changed(struct usb_hub *hub)
+{
+   int port1;
+
+   for (port1 = 1; port1 <= hub->hdev->maxchild; ++port1) {
+   u16 portstatus, portchange;
+   int status;
+
+   status = hub_port_status(hub, port1, &portstatus, &portchange);
+   if (!status && portchange)
+   return 1;
+   }
+   return 0;
+}
+
 static int hub_suspend(struct usb_interface *intf, pm_message_t msg)
 {
struct usb_hub  *hub = usb_get_intfdata (intf);
@@ -3176,6 +3198,17 @@ static int hub_suspend(struct usb_interface *intf, 
pm_message_t msg)
return -EBUSY;
}
}
+
+   if (hdev->do_remote_wakeup && hub->quirk_check_port_auto_suspend) {
+   /* check if there are changes pending on hub ports */
+   if (check_ports_changed(hub)) {
+   if (!PMSG_IS_AUTO(msg) &&
+   device_may_wakeup(&hdev->dev))
+   pm_wakeup_event(&hdev->dev, 2000);
+   return -EBUSY;
+   }
+   }
+
if (hub_is_superspeed(hdev) && hdev->do_remote_wakeup) {
/* Enable hub to send remote wakeup for all ports. */
for (port1 = 1; port1 <= hdev->maxchild; port1++) {
@@ -4766,6 +4799,11 @@ static const struct attribute_group *port_dev_group[] = {
 };
 
 static const struct usb_device_id hub_id_table[] = {
+{ .match_flags = USB_DEVICE_ID_MATCH_VENDOR
+  | USB_DEVICE_ID_MATCH_INT_CLASS,
+  .idVendor = 0x05e3,
+  .bInterfaceClass = USB_CLASS_HUB,
+  .driver_info = HUB_QUIRK_CHECK_PORT_AUTOSUSPEND},
 { .match_flags = USB_DEVICE_ID_MATCH_DEV_CLASS,
   .bDeviceClass = USB_CLASS_HUB},
 { .match_flags = USB_DEVICE_ID_MATCH_INT_CLASS,
-- 
1.7.9.5

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

[PATCH v2 0/2] USB: USB: two changes on hub autosuspend

[Ming Lei]

There are two patches on usb hub autosuspend.

Change log:
V2:
- check on udev->do_remote_wakeup(1/2)
- handle wakeup source for system sleep(1/2)
- remove unnecessary comments(2/2)
- fix comments(2/2)
V1:
- only check ports change on bug devices(1/2)
- add comments on waking up hub by usb space context(2/2)


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 1/2] ARM: Kirkwood: ehci-orion: Add device tree binding

[Olof Johansson]

On Mon, Sep 24, 2012 at 09:13:53AM +0200, Andrew Lunn wrote:
> > > +Required properties:
> > > +- compatible: must be "marvell,orion-ehci"
> > > +- reg: physical base address of the controller and length of memory 
> > > mapped
> > > +  region.
> > > +- interrupts: The EHCI interrupt
> > > +- phy-version: Can be one of:
> > > +  "NA" - Don't touch the phy, something else has already configured it.
> > > +  "orion5x" - PHY setup as specified by the Orion5x Errata
> > > +
> > > +Example:
> > > +
> > > +   ehci@5 {
> > > +   compatible = "marvell,orion-ehci";
> > > +   reg = <0x5 0x1000>;
> > > +   interrupts = <19>;
> > > +   phy-version = "NA";
> > > +   };
> > 
> > This isn't an appropriate binding for phy. I know, it maps straight
> > over from the platform data, but it doesn't focus on what the actual
> > hardware is.
> > 
> > A couple of options. What probably makes most sense depending on how
> > other phy bindings are moving ahead is to add a phy node under the
> > ehci controller for the "orion5x" case, and have an appropriate
> > compatible value there. No node means the same as "NA" in the above
> > binding. Alternatively, have a phy phandle that points to the phy
> > device if it sits on an i2c bus, etc.
> 
> I Olaf
> 
> Could i suggest a third option:
> 
> I just drop USB phy configuration all together.  Only mach-orion5x
> needs this and nobody has shown any interest in moving mach-orion5x to
> DT. So i would just hard code it to "NA".
> 
> If anybody does show interest in DT for orion5x, we can add a phy node
> under ehci as a pure extension which does not affect backward
> compatibility.

Yeah, that works too.


-Olof
--
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 v5] ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc

[Rene Buergel]

> Also, does the code in fact support only FX2, neither older chips nor
> newer FX3?
It also does support the FX(1), but not FX3. At first sight, it looks like FX3 
got another
register interface.


> If FX is also supported then perhaps still rename the option,
> although I think renaming is unrelated to the build problems.
>
> I think it makes sense to call the option after the "highest"
> supported chip.
That's what it is. ;)
I would be happy to re-rename this option to USB_EZUSB somewhere in the future,
but i think it is the best option to stick with this for at least one
major version to avoid build errors.

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

Re: [Patch v5] ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc

[Greg KH]

On Wed, Sep 26, 2012 at 11:27:10PM +0200, Peter Stuge wrote:
> Rene Buergel wrote:
> > - renamed CONFIG_USB_EZUSB to CONFIG_USB_EZUSB_FX2 to avoid build errors
> 
> Is this really the reason for the build error? I doubt it.

It is, try it without it, the Makefiles get confused :(

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: proposal for switching off stuff for external ports

[Sarah Sharp]

On Wed, Sep 26, 2012 at 03:14:59PM -0400, Alan Stern wrote:
> On Wed, 26 Sep 2012, Sarah Sharp wrote:
> > On Wed, Sep 26, 2012 at 05:31:43PM +0200, Oliver Neukum wrote:
> > > And it seems to me that in many cases, namely
> > > EHCI with companion controllers and XHCI controllers that implement
> > > a vendor specific switching option, we could switch the ports so that
> > > a minimum number of controllers is connected to ports that are not 
> > > switched
> > > off.
> > 
> > It would be nice to have only one powered host controller, I agree.  But
> > I'm not sure the idea would actually help systems with the EHCI/xHCI
> > port switching.
> > 
> > We would want to leave any powered port under the xHCI host controller,
> > because we want USB 3.0 devices to connect at SuperSpeed.  If we can't
> > switch over the EHCI ports to xHCI, it's either because there isn't a
> > physical switch, or the OEM is preventing the port switchover because it
> > has some internal USB device that doesn't work well under xHCI.  So
> > we're forced into having two powered host controllers, and there's no
> > other way we can switch ports to help.

> But this is starting to sound a little peculiar.  Intel supports the 
> port-power stuff only on its most recent (i.e., not yet released) 
> systems.  Do these same bleeding-edge systems also include the 
> old-style switch-xHCI-ports-back-to-EHCI mechanism?

The Lynx Point chipset has the EHCI/xHCI port switchover:

1c12443 xhci: Add Lynx Point to list of Intel switchable hosts.

As I said in the commit, Lynx Point has one xHCI host and two EHCI
hosts.  All the ports can be switched over from EHCI to xHCI, unlike
with Panther Point.

> If all the ports are set to xHCI and the EHCI controller doesn't have
> any others then it could be powered off, assuming there's some way to
> do that.

Sure.  It would at least be placed into host suspend at that point.  But
I'm not sure what software could do beyond that.

The funny thing is that the OS can't actually tell if it's switched all
the ports from an EHCI controller.  It only gets a port mask register
with the mask of the ports it's allowed to switch over.  There's no
mapping between those bits and which EHCI host has which port.  If
there's less bits set in the port mask register than there is ports on
the two EHCI hosts, then the OS can't tell which EHCI host still has an
unswitched port.  Therefore the OS doesn't know which EHCI host is safe
to power off, if any.  I think we would have to leave any additional
power savings mechanisms to the BIOS at that point.

> > I think you run into similar issues with EHCI hosts with companion
> > controllers.  You want all the powered ports to be under EHCI by
> > default.  If you have a port under UHCI or OHCI, then it's because you
> > have a connected LS/FS device.  So you're stuck with an two powered host
> > controllers.
> 
> Oliver was pointing out that if none of the attached devices are FS/LS 
> then the companion controller and all its ports could be powered off.  
> The EHCI driver knows when a new FS/LS device gets attached, so it 
> could arrange for the companion controller to power back on at that 
> time.

Yep, that might help on some other system with a port power off
mechanism, but not for Lynx Point.  I'm pretty sure Lynx Point only has
EHCI rate matching hubs, and no companion controllers.

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 v5] ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc

[Peter Stuge]

Rene Buergel wrote:
> - renamed CONFIG_USB_EZUSB to CONFIG_USB_EZUSB_FX2 to avoid build errors

Is this really the reason for the build error? I doubt it.

Also, does the code in fact support only FX2, neither older chips nor
newer FX3?


> diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
> index 1bfcd02..bf7dc43 100644
> --- a/drivers/usb/misc/Kconfig
> +++ b/drivers/usb/misc/Kconfig
> @@ -244,3 +244,8 @@ config USB_YUREX
> To compile this driver as a module, choose M here: the
> module will be called yurex.
>  
> +config USB_EZUSB_FX2
> + tristate "Functions for loading firmware on EZUSB chips"

If only FX2 then I suggest mentioning that also in the immediately
user-visible option description, not only in the help.


> + help
> +   Say Y here if you need EZUSB device support.
> +   (Cypress FX/FX2/FX2LP microcontrollers)

If FX is also supported then perhaps still rename the option,
although I think renaming is unrelated to the build problems.

I think it makes sense to call the option after the "highest"
supported chip.


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

Re: [PATCH 1/2] USB: uas: fix locking

[Greg KH]

On Wed, Sep 26, 2012 at 10:28:58AM +0200, Gerd Hoffmann wrote:
> Forgot to unlock in the uas_eh_task_mgmt error paths.
> 
> Signed-off-by: Gerd Hoffmann 

You forgot to add a "Reported-by:" line for this patch, please be more
careful in the future.

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 v5] ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc

[Greg KH]

On Wed, Sep 26, 2012 at 10:20:19PM +0200, Rene Buergel wrote:
> This patch 
> - moves drivers/usb/serial/ezusb.c to drivers/usb/misc/
> - renamed CONFIG_USB_EZUSB to CONFIG_USB_EZUSB_FX2 to avoid build errors

Ah, does this solve the error I was seeing?  Nice job figuring that one
out.

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 v5] ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc

[Rene Buergel]

This patch 
- moves drivers/usb/serial/ezusb.c to drivers/usb/misc/
- renamed CONFIG_USB_EZUSB to CONFIG_USB_EZUSB_FX2 to avoid build errors
- adapts Makefiles and Kconfigs switching from bool to tristate for 
CONFIG_USB_EZUSB_FX2

Signed-off-by: René Bürgel 
---
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 1bfcd02..bf7dc43 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -244,3 +244,8 @@ config USB_YUREX
  To compile this driver as a module, choose M here: the
  module will be called yurex.
 
+config USB_EZUSB_FX2
+   tristate "Functions for loading firmware on EZUSB chips"
+   help
+ Say Y here if you need EZUSB device support.
+ (Cypress FX/FX2/FX2LP microcontrollers)
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 796ce7e..f1f7815 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_USB_CYPRESS_CY7C63)  += cypress_cy7c63.o
 obj-$(CONFIG_USB_CYTHERM)  += cytherm.o
 obj-$(CONFIG_USB_EMI26)+= emi26.o
 obj-$(CONFIG_USB_EMI62)+= emi62.o
+obj-$(CONFIG_USB_EZUSB_FX2)+= ezusb.o
 obj-$(CONFIG_USB_FTDI_ELAN)+= ftdi-elan.o
 obj-$(CONFIG_USB_IDMOUSE)  += idmouse.o
 obj-$(CONFIG_USB_IOWARRIOR)+= iowarrior.o
diff --git a/drivers/usb/serial/ezusb.c b/drivers/usb/misc/ezusb.c
similarity index 100%
rename from drivers/usb/serial/ezusb.c
rename to drivers/usb/misc/ezusb.c
diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index f604f70..76f4622 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -42,11 +42,6 @@ config USB_SERIAL_CONSOLE
 
  If unsure, say N.
 
-config USB_EZUSB
-   bool "Functions for loading firmware on EZUSB chips"
-   help
-   Say Y here if you need EZUSB device support.
-
 config USB_SERIAL_GENERIC
bool "USB Generic Serial Driver"
help
@@ -94,7 +89,7 @@ config USB_SERIAL_CH341
 
 config USB_SERIAL_WHITEHEAT
tristate "USB ConnectTech WhiteHEAT Serial Driver"
-   select USB_EZUSB
+   select USB_EZUSB_FX2
help
  Say Y here if you want to use a ConnectTech WhiteHEAT 4 port
  USB to serial converter device.
@@ -281,7 +276,7 @@ config USB_SERIAL_IUU
 
 config USB_SERIAL_KEYSPAN_PDA
tristate "USB Keyspan PDA Single Port Serial Driver"
-   select USB_EZUSB
+   select USB_EZUSB_FX2
help
  Say Y here if you want to use a Keyspan PDA single port USB to
  serial converter device.  This driver makes use of firmware
@@ -292,7 +287,7 @@ config USB_SERIAL_KEYSPAN_PDA
 
 config USB_SERIAL_KEYSPAN
tristate "USB Keyspan USA-xxx Serial Driver"
-   select USB_EZUSB
+   select USB_EZUSB_FX2
---help---
  Say Y here if you want to use Keyspan USB to serial converter
  devices.  This driver makes use of Keyspan's official firmware
@@ -596,7 +591,7 @@ config USB_SERIAL_CYBERJACK
 
 config USB_SERIAL_XIRCOM
tristate "USB Xircom / Entregra Single Port Serial Driver"
-   select USB_EZUSB
+   select USB_EZUSB_FX2
help
  Say Y here if you want to use a Xircom or Entregra single port USB to
  serial converter device.  This driver makes use of firmware
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index 45871f9..3b3e730 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_USB_SERIAL)+= usbserial.o
 usbserial-y := usb-serial.o generic.o bus.o
 
 usbserial-$(CONFIG_USB_SERIAL_CONSOLE) += console.o
-usbserial-$(CONFIG_USB_EZUSB)  += ezusb.o
 
 obj-$(CONFIG_USB_SERIAL_AIRCABLE)  += aircable.o
 obj-$(CONFIG_USB_SERIAL_ARK3116)   += ark3116.o
--
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: phy: add generic PHY framework

[Marc Kleine-Budde]

On 09/26/2012 05:01 PM, Kishon Vijay Abraham I wrote:
> The PHY framework provides a set of API's for the PHY drivers to
> create/destroy a PHY and API's for the PHY users to obtain a reference to the
> PHY with or without using phandle. To obtain a reference to the PHY without
> using phandle, the platform specfic intialization code (say from board file)
> should have already called phy_bind with the binding information. The binding
> information consists of phy's device name, phy user device name and an index.
> The index is used when the same phy user binds to mulitple phys.
> 
> PHY drivers should create the PHY by passing phy_descriptor that has
> describes the PHY (label, type etc..) and ops like init, exit, suspend, 
> resume,
> poweron, shutdown.
> 
> Cc: Felipe Balbi 
> Cc: Marc Kleine-Budde 
> Signed-off-by: Kishon Vijay Abraham I 

I suggest to talk to someone who is familiar with the linux-bus
abstraction. Adding devices, drivers, matching them and maintaining
binding information should not be reinvented.

See more comments inline.

> ---
> Did testing (phandle path) to some extent by hacking omap-usb2 to use this
> new framework. (completely modifying omap-usb2 to use this framework will
> take some time mostly because of the OTG stuff). Also perfomed non-dt
> testing by moving to a older kernel. Any kind of testing for this patch is
> welcome :-)
>  MAINTAINERS |7 +
>  drivers/Kconfig |2 +
>  drivers/Makefile|2 +
>  drivers/phy/Kconfig |   13 ++
>  drivers/phy/Makefile|5 +
>  drivers/phy/phy-core.c  |  445 
> +++
>  include/linux/phy/phy.h |  182 +++
>  7 files changed, 656 insertions(+)
>  create mode 100644 drivers/phy/Kconfig
>  create mode 100644 drivers/phy/Makefile
>  create mode 100644 drivers/phy/phy-core.c
>  create mode 100644 include/linux/phy/phy.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea0519a..48f3cfb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3078,6 +3078,13 @@ T: git 
> git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
>  S:   Maintained
>  F:   include/asm-generic
>  
> +GENERIC PHY FRAMEWORK
> +M:   Kishon Vijay Abraham I 
> +L:   linux-ker...@vger.kernel.org
> +S:   Supported
> +F:   drivers/phy/
> +F:   include/linux/phy/
> +
>  GENERIC UIO DRIVER FOR PCI DEVICES
>  M:   "Michael S. Tsirkin" 
>  L:   k...@vger.kernel.org
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index 324e958..d289df5 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -154,4 +154,6 @@ source "drivers/vme/Kconfig"
>  
>  source "drivers/pwm/Kconfig"
>  
> +source "drivers/phy/Kconfig"
> +
>  endmenu
> diff --git a/drivers/Makefile b/drivers/Makefile
> index d64a0f7..e39252d 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -40,6 +40,8 @@ obj-y   += char/
>  # gpu/ comes after char for AGP vs DRM startup
>  obj-y+= gpu/
>  
> +obj-y+= phy/
> +
>  obj-$(CONFIG_CONNECTOR)  += connector/
>  
>  # i810fb and intelfb depend on char/agp/
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> new file mode 100644
> index 000..34f7077
> --- /dev/null
> +++ b/drivers/phy/Kconfig
> @@ -0,0 +1,13 @@
> +#
> +# PHY
> +#
> +
> +menuconfig GENERIC_PHY
> + tristate "Generic PHY Support"
> + help
> +   Generic PHY support.
> +
> +   This framework is designed to provide a generic interface for PHY
> +   devices present in the kernel. This layer will have the generic
> +   API by which phy drivers can create PHY using the phy framework and
> +   phy users can obtain reference to the PHY.
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> new file mode 100644
> index 000..9e9560f
> --- /dev/null
> +++ b/drivers/phy/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the phy drivers.
> +#
> +
> +obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> new file mode 100644
> index 000..bf47a88
> --- /dev/null
> +++ b/drivers/phy/phy-core.c
> @@ -0,0 +1,445 @@
> +/*
> + * phy-core.c  --  Generic Phy framework.
> + *
> + * Copyright (C) 2012 Texas Instruments
> + *
> + * Author: Kishon Vijay Abraham I 
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If no

Re: proposal for switching off stuff for external ports

[Alan Stern]

On Wed, 26 Sep 2012, Sarah Sharp wrote:

> On Wed, Sep 26, 2012 at 05:31:43PM +0200, Oliver Neukum wrote:
> > Hi Sarah,
> > 
> > watching your talk and drinking tea I had an idea.
> > 
> > Switching off ports saves power in itself. It also allows
> > switching off host controllers.
> > The problem with switching off power on external ports is that they
> > don't detect hotplug events anymore.
> > 
> > So is there a way to switch off controllers and leave ports on, saving
> > at least some power?
> 
> That sounds awfully like host/bus suspend. :)  Or if you're talking
> about completely powering off the host, a D3 cold mechanism for the PCI
> host controller.

My thought exactly.

> > And it seems to me that in many cases, namely
> > EHCI with companion controllers and XHCI controllers that implement
> > a vendor specific switching option, we could switch the ports so that
> > a minimum number of controllers is connected to ports that are not switched
> > off.
> 
> It would be nice to have only one powered host controller, I agree.  But
> I'm not sure the idea would actually help systems with the EHCI/xHCI
> port switching.
> 
> We would want to leave any powered port under the xHCI host controller,
> because we want USB 3.0 devices to connect at SuperSpeed.  If we can't
> switch over the EHCI ports to xHCI, it's either because there isn't a
> physical switch, or the OEM is preventing the port switchover because it
> has some internal USB device that doesn't work well under xHCI.  So
> we're forced into having two powered host controllers, and there's no
> other way we can switch ports to help.

If all the ports are set to xHCI and the EHCI controller doesn't have
any others then it could be powered off, assuming there's some way to
do that.

But this is starting to sound a little peculiar.  Intel supports the 
port-power stuff only on its most recent (i.e., not yet released) 
systems.  Do these same bleeding-edge systems also include the 
old-style switch-xHCI-ports-back-to-EHCI mechanism?

> I think you run into similar issues with EHCI hosts with companion
> controllers.  You want all the powered ports to be under EHCI by
> default.  If you have a port under UHCI or OHCI, then it's because you
> have a connected LS/FS device.  So you're stuck with an two powered host
> controllers.

Oliver was pointing out that if none of the attached devices are FS/LS 
then the companion controller and all its ports could be powered off.  
The EHCI driver knows when a new FS/LS device gets attached, so it 
could arrange for the companion controller to power back on at that 
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 2/2] usb: dwc3: workaround: unexpected transtion U3 -> RESUME

[Felipe Balbi]

In DWC3 versions < 2.50a configured without
Hibernation mode enabled, there will be an
extra link status change interrupt if device
detects host-initiated U3 exit.

In that case, core will generate an unnecessary
U3 -> RESUME transition which should be ignored
by the driver.

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

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 6c8e461..2189e3f 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2199,6 +2199,34 @@ static void dwc3_gadget_linksts_change_interrupt(struct 
dwc3 *dwc,
unsigned int evtinfo)
 {
enum dwc3_link_statenext = evtinfo & DWC3_LINK_STATE_MASK;
+   unsigned intpwropt;
+
+   /*
+* WORKAROUND: DWC3 < 2.50a have an issue when configured without
+* Hibernation mode enabled which would show up when device detects
+* host-initiated U3 exit.
+*
+* In that case, device will generate a Link State Change Interrupt
+* from U3 to RESUME which is only necessary if Hibernation is
+* configured in.
+*
+* There are no functional changes due to such spurious event and we
+* just need to ignore it.
+*
+* Refers to:
+*
+* STAR#90005704 RTL: SS Resume event generated in non-Hibernation
+* operational mode
+*/
+   pwropt = DWC3_GHWPARAMS1_EN_PWROPT(dwc->hwparams.hwparams1);
+   if ((dwc->revision <= DWC3_REVISION_240A) &&
+   (pwropt != DWC3_GHWPARAMS1_EN_PWROPT_HIB)) {
+   if ((dwc->link_state == DWC3_LINK_STATE_U3) &&
+   (next == DWC3_LINK_STATE_RESUME)) {
+   dev_vdbg(dwc->dev, "ignoring transition U3 -> 
Resume\n");
+   return;
+   }
+   }
 
/*
 * WORKAROUND: DWC3 Revisions <1.83a have an issue which, depending
-- 
1.7.12

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

[PATCH 1/2] usb: dwc3: core: define more revisions

[Felipe Balbi]

Some new revisions of the DWC3 core have
been released, let's add our defines to help
implementing known erratas.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/core.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 243affc..7c1a533 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -693,6 +693,9 @@ struct dwc3 {
 #define DWC3_REVISION_202A 0x5533202a
 #define DWC3_REVISION_210A 0x5533210a
 #define DWC3_REVISION_220A 0x5533220a
+#define DWC3_REVISION_230A 0x5533230a
+#define DWC3_REVISION_240A 0x5533240a
+#define DWC3_REVISION_250A 0x5533250a
 
unsignedis_selfpowered:1;
unsignedthree_stage_setup:1;
-- 
1.7.12

--
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/10] usb: otg: msm: Convert to clk_prepare/unprepare

[Pankaj Jangra]

On Thu, Sep 27, 2012 at 12:18 AM, Stephen Boyd  wrote:
> On 09/26/12 09:58, Pankaj Jangra wrote:
>> On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd  wrote:
>>> diff --git a/drivers/usb/otg/msm_otg.c b/drivers/usb/otg/msm_otg.c
>>> index 9f5fc90..2ae0639 100644
>>> --- a/drivers/usb/otg/msm_otg.c
>>> +++ b/drivers/usb/otg/msm_otg.c
>>> @@ -514,13 +514,13 @@ static int msm_otg_suspend(struct msm_otg *motg)
>>> motg->pdata->otg_control == OTG_PMIC_CONTROL)
>>> writel(readl(USB_PHY_CTRL) | PHY_RETEN, USB_PHY_CTRL);
>>>
>>> -   clk_disable(motg->pclk);
>>> -   clk_disable(motg->clk);
>>> +   clk_disable_unprepare(motg->pclk);
>>> +   clk_disable_unprepare(motg->clk);
>>> if (motg->core_clk)
>>> -   clk_disable(motg->core_clk);
>>> +   clk_disable_unprepare(motg->core_clk);
>>>
>> I was under assumption that system suspend/resume might be called from
>> the interrupt context. If that is case then its not appropriate to
>> call clk_prepare/unprepare here right? or my understanding is not correct
>
> Well we call disable_irq() at the top of this suspend function so I
> suspect your understanding is incorrect. disable_irq() can call
> schedule(). There are also a bunch of regulator calls in
> msm_hsusb_ldo_set_mode() that this suspend function calls (almost all
> regulator calls grab a mutex).

Ok, might be i am worng because in acpuclock driver of msm on
codeaurora tree, i have seen in commit text saying that it can be
called from suspend/resume in interrupt context .
So i was assuming that. Any way thanks.

--
Pankaj Jangra
--
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/10] usb: otg: msm: Convert to clk_prepare/unprepare

[Stephen Boyd]

On 09/26/12 09:58, Pankaj Jangra wrote:
> On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd  wrote:
>> diff --git a/drivers/usb/otg/msm_otg.c b/drivers/usb/otg/msm_otg.c
>> index 9f5fc90..2ae0639 100644
>> --- a/drivers/usb/otg/msm_otg.c
>> +++ b/drivers/usb/otg/msm_otg.c
>> @@ -514,13 +514,13 @@ static int msm_otg_suspend(struct msm_otg *motg)
>> motg->pdata->otg_control == OTG_PMIC_CONTROL)
>> writel(readl(USB_PHY_CTRL) | PHY_RETEN, USB_PHY_CTRL);
>>
>> -   clk_disable(motg->pclk);
>> -   clk_disable(motg->clk);
>> +   clk_disable_unprepare(motg->pclk);
>> +   clk_disable_unprepare(motg->clk);
>> if (motg->core_clk)
>> -   clk_disable(motg->core_clk);
>> +   clk_disable_unprepare(motg->core_clk);
>>
> I was under assumption that system suspend/resume might be called from
> the interrupt context. If that is case then its not appropriate to
> call clk_prepare/unprepare here right? or my understanding is not correct

Well we call disable_irq() at the top of this suspend function so I
suspect your understanding is incorrect. disable_irq() can call
schedule(). There are also a bunch of regulator calls in
msm_hsusb_ldo_set_mode() that this suspend function calls (almost all
regulator calls grab a mutex).

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
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 4/4] usb: phy: omap-usb2: enable 960Mhz clock for omap5

[Felipe Balbi]

Hi,

On Wed, Sep 26, 2012 at 11:10:48AM +0530, ABRAHAM, KISHON VIJAY wrote:
> Hi,
> 
> On Wed, Sep 19, 2012 at 5:26 PM, Felipe Balbi  wrote:
> > On Wed, Sep 19, 2012 at 05:00:29PM +0530, Kishon Vijay Abraham I wrote:
> >> "usb_otg_ss_refclk960m" is needed by usb2 phy present in omap5. For
> >> omap4, the clk_get of this clock will fail since it does not have this
> >> clock.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I 
> >> ---
> >>  Documentation/devicetree/bindings/usb/usb-phy.txt |3 +++
> >>  drivers/usb/phy/omap-usb2.c   |   28 
> >> -
> >>  2 files changed, 30 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
> >> b/Documentation/devicetree/bindings/usb/usb-phy.txt
> >> index 7c5fd89..d5626de 100644
> >> --- a/Documentation/devicetree/bindings/usb/usb-phy.txt
> >> +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
> >> @@ -24,6 +24,9 @@ Required properties:
> >>  add the address of control module phy power register until a driver for
> >>  control module is added
> >>
> >> +Optional properties:
> >> + - has960mhzclk: should be added if the phy needs 960mhz clock
> >> +
> >>  This is usually a subnode of ocp2scp to which it is connected.
> >>
> >>  usb3phy@4a084400 {
> >> diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
> >> index d36c282..d6612ba 100644
> >> --- a/drivers/usb/phy/omap-usb2.c
> >> +++ b/drivers/usb/phy/omap-usb2.c
> >> @@ -146,6 +146,7 @@ static int __devinit omap_usb2_probe(struct 
> >> platform_device *pdev)
> >>   struct omap_usb *phy;
> >>   struct usb_otg  *otg;
> >>   struct resource *res;
> >> + struct device_node  *np = pdev->dev.of_node;
> >>
> >>   phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
> >>   if (!phy) {
> >> @@ -190,6 +191,15 @@ static int __devinit omap_usb2_probe(struct 
> >> platform_device *pdev)
> >>   }
> >>   clk_prepare(phy->wkupclk);
> >>
> >> + if (of_property_read_bool(np, "has960mhzclk")) {
> >> + phy->optclk = devm_clk_get(phy->dev, 
> >> "usb_otg_ss_refclk960m");
> >> + if (IS_ERR(phy->optclk)) {
> >> + dev_err(&pdev->dev, "unable to get refclk960m\n");
> >> + return PTR_ERR(phy->optclk);
> >> + }
> >> + clk_prepare(phy->optclk);
> >> + }
> >
> > instead, can't you just always try to get the clock but ignore the error
> > if it fails ?
> 
> This clock is needed for usb2 to work in dwc3 (omap5). So we have to
> report the error in case we dont get the clock no?

sure, but you don't need to bail out. Print a warning message such as:

dev_dbg(&pdev->dev, "couldn't get refclk960m, trying without\n");

or something similar. Then you don't need to add this has960mhzclk flag
to dts files.

-- 
balbi


signature.asc
Description: Digital signature

Re: proposal for switching off stuff for external ports

[Sarah Sharp]

On Wed, Sep 26, 2012 at 05:31:43PM +0200, Oliver Neukum wrote:
> Hi Sarah,
> 
> watching your talk and drinking tea I had an idea.
> 
> Switching off ports saves power in itself. It also allows
> switching off host controllers.
> The problem with switching off power on external ports is that they
> don't detect hotplug events anymore.
> 
> So is there a way to switch off controllers and leave ports on, saving
> at least some power?

That sounds awfully like host/bus suspend. :)  Or if you're talking
about completely powering off the host, a D3 cold mechanism for the PCI
host controller.

> And it seems to me that in many cases, namely
> EHCI with companion controllers and XHCI controllers that implement
> a vendor specific switching option, we could switch the ports so that
> a minimum number of controllers is connected to ports that are not switched
> off.

It would be nice to have only one powered host controller, I agree.  But
I'm not sure the idea would actually help systems with the EHCI/xHCI
port switching.

We would want to leave any powered port under the xHCI host controller,
because we want USB 3.0 devices to connect at SuperSpeed.  If we can't
switch over the EHCI ports to xHCI, it's either because there isn't a
physical switch, or the OEM is preventing the port switchover because it
has some internal USB device that doesn't work well under xHCI.  So
we're forced into having two powered host controllers, and there's no
other way we can switch ports to help.

I think you run into similar issues with EHCI hosts with companion
controllers.  You want all the powered ports to be under EHCI by
default.  If you have a port under UHCI or OHCI, then it's because you
have a connected LS/FS device.  So you're stuck with an two powered host
controllers.

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] drivers: phy: add generic PHY framework

[Marc Kleine-Budde]

On 09/26/2012 07:41 PM, Dmitry Torokhov wrote:
> On Wednesday, September 26, 2012 09:57:57 AM Joe Perches wrote:
>> On Wed, 2012-09-26 at 20:31 +0530, Kishon Vijay Abraham I wrote:
>>> The PHY framework provides a set of API's for the PHY drivers to
>>> create/destroy a PHY and API's
>>
>> Just some trivial notes.
>>
>>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>>
>> []
>>
>>> @@ -0,0 +1,445 @@
>>
>> []
>>
>>> +static void devm_phy_release(struct device *dev, void *res)
>>> +{
>>> +   struct phy *phy = *(struct phy **)res;
>>
>> That's a bit twisted isn't it?
>> Perhaps
>>  struct phy *phy = res;
> 
> No, because you really need to dereference ptr, not simply cast.

To avoid this confusion I suggest to create a struct phy_res. For now
its only member will be a pointer to a struct phy.

> 
> ...
> 
>>> +
>>> +   ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
>>
>> Is this the right size?
>>
>> Because ptr is **, perhaps sizeof(struct phy) is clearer.
> 
> But incorrect.

A proper struct will make the code more readable here, too.

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] drivers: phy: add generic PHY framework

[Dmitry Torokhov]

On Wednesday, September 26, 2012 09:57:57 AM Joe Perches wrote:
> On Wed, 2012-09-26 at 20:31 +0530, Kishon Vijay Abraham I wrote:
> > The PHY framework provides a set of API's for the PHY drivers to
> > create/destroy a PHY and API's
> 
> Just some trivial notes.
> 
> > diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> 
> []
> 
> > @@ -0,0 +1,445 @@
> 
> []
> 
> > +static void devm_phy_release(struct device *dev, void *res)
> > +{
> > +   struct phy *phy = *(struct phy **)res;
> 
> That's a bit twisted isn't it?
> Perhaps
>   struct phy *phy = res;

No, because you really need to dereference ptr, not simply cast.

...

> > +
> > +   ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
> 
> Is this the right size?
> 
> Because ptr is **, perhaps sizeof(struct phy) is clearer.

But incorrect.

Thanks.

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

Re: [PATCH 3/3] xhci: Intel Panther Point BEI quirk.

[Sarah Sharp]

On Wed, Sep 26, 2012 at 07:59:24AM +0200, Oliver Neukum wrote:
> On Tuesday 25 September 2012 15:29:29 Sarah Sharp wrote:
> > This patch should be backported to kernels as old as 3.0, that contain
> > the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
> > EHCI/xHCI port switching."
> 
> How do you arrive at that commit? The BIOS may also switch ports.

My logic was that the BEI flag is only used under xHCI, and if you don't
have that commit, you don't get the ports under xHCI with Panther Point.

Hmm, but you're right that the BIOS could leave the ports under xHCI.
However, we didn't start using the BEI flag until commit
ad106f292369d753d5c75751cb9e760726e3cd00 "xHCI 1.0: Block Interrupts for
Isoch transfer", which was also added in 3.0.

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: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

[Adrian Sandu]

2012-09-26T20:13:09.700606+03:00 d3xt3r01 kernel: [ 2466.455403] usb
3-1.1: reset SuperSpeed USB device number 14 using xhci_hcd
2012-09-26T20:13:09.713629+03:00 d3xt3r01 kernel: [ 2466.468373]
xhci_hcd :04:00.0: xHCI xhci_drop_endpoint called with disabled ep
88011aea1300
2012-09-26T20:13:09.713667+03:00 d3xt3r01 kernel: [ 2466.468384]
xhci_hcd :04:00.0: xHCI xhci_drop_endpoint called with disabled ep
88011aea1340
2012-09-26T20:13:44.480669+03:00 d3xt3r01 kernel: [ 2501.235365] hub
3-1:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
2012-09-26T20:13:45.005111+03:00 d3xt3r01 kernel: [ 2501.759279] sd
18:0:0:0: Device offlined - not ready after error recovery
2012-09-26T20:13:45.005118+03:00 d3xt3r01 kernel: [ 2501.759300] sd
18:0:0:0: [sdb] Unhandled error code
2012-09-26T20:13:45.005125+03:00 d3xt3r01 kernel: [ 2501.759305] sd
18:0:0:0: [sdb]  Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
2012-09-26T20:13:45.005133+03:00 d3xt3r01 kernel: [ 2501.759312] sd
18:0:0:0: [sdb] CDB: Read(10): 28 00 00 03 2c 00 00 00 f0 00
2012-09-26T20:13:45.005139+03:00 d3xt3r01 kernel: [ 2501.759328]
end_request: I/O error, dev sdb, sector 207872
2012-09-26T20:13:45.005146+03:00 d3xt3r01 kernel: [ 2501.759334]
quiet_error: 23 callbacks suppressed
2012-09-26T20:13:45.005151+03:00 d3xt3r01 kernel: [ 2501.759339]
Buffer I/O error on device sdb, logical block 25984
2012-09-26T20:13:45.005157+03:00 d3xt3r01 kernel: [ 2501.759351]
Buffer I/O error on device sdb, logical block 25985
2012-09-26T20:13:45.005163+03:00 d3xt3r01 kernel: [ 2501.759357]
Buffer I/O error on device sdb, logical block 25986
2012-09-26T20:13:45.005169+03:00 d3xt3r01 kernel: [ 2501.759363]
Buffer I/O error on device sdb, logical block 25987
The result of a simple d3xt3r01 ~ # hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads:   1494 MB in  2.00 seconds = 747.20 MB/sec
 Timing buffered disk reads: read(2097152) returned 1572864 bytes
BLKFLSBUF failed: No such device

It didn't fail the first time though .. I just executed the same
command twice ..
Assuming that 3u is the good thing to cat ..
http://d3xt3r01.tk/~dexter/usbmon/1348679651_3u ..
( given the output in /sys/kernel/debug/usb/devices )

Hope this helps more to identify the issue ..

2012-09-26T20:13:45.005175+03:00 d3xt3r01 kernel: [ 2501.759369]
Buffer I/O error on device sdb, logical block 25988
2012-09-26T20:13:45.005182+03:00 d3xt3r01 kernel: [ 2501.759375]
Buffer I/O error on device sdb, logical block 25989
2012-09-26T20:13:45.005188+03:00 d3xt3r01 kernel: [ 2501.759382]
Buffer I/O error on device sdb, logical block 25990
2012-09-26T20:13:45.005194+03:00 d3xt3r01 kernel: [ 2501.759393] sd
18:0:0:0: rejecting I/O to offline device
2012-09-26T20:13:45.005200+03:00 d3xt3r01 kernel: [ 2501.759407] sd
18:0:0:0: [sdb] killing request
2012-09-26T20:13:45.005207+03:00 d3xt3r01 kernel: [ 2501.759415]
Buffer I/O error on device sdb, logical block 25991
2012-09-26T20:13:45.005213+03:00 d3xt3r01 kernel: [ 2501.759426]
Buffer I/O error on device sdb, logical block 25992
2012-09-26T20:13:45.005220+03:00 d3xt3r01 kernel: [ 2501.759432]
Buffer I/O error on device sdb, logical block 25993
2012-09-26T20:13:45.005227+03:00 d3xt3r01 kernel: [ 2501.759440] sd
18:0:0:0: rejecting I/O to offline device
2012-09-26T20:13:45.005233+03:00 d3xt3r01 kernel: [ 2501.759494] sd
18:0:0:0: rejecting I/O to offline device
2012-09-26T20:13:45.005240+03:00 d3xt3r01 kernel: [ 2501.759505] sd
18:0:0:0: rejecting I/O to offline device
2012-09-26T20:13:45.005246+03:00 d3xt3r01 kernel: [ 2501.759624] sd
18:0:0:0: [sdb] Unhandled error code
2012-09-26T20:13:45.005252+03:00 d3xt3r01 kernel: [ 2501.759630] sd
18:0:0:0: [sdb]  Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
2012-09-26T20:13:45.005259+03:00 d3xt3r01 kernel: [ 2501.759637] sd
18:0:0:0: [sdb] CDB: Read(10): 28 00 00 03 2c f0 00 00 10 00
2012-09-26T20:13:45.005267+03:00 d3xt3r01 kernel: [ 2501.759654]
end_request: I/O error, dev sdb, sector 208112
2012-09-26T20:13:45.020696+03:00 d3xt3r01 kernel: [ 2501.775198] usb
3-1.1: USB disconnect, device number 14


On Wed, Sep 26, 2012 at 7:59 PM, Adrian Sandu  wrote:
> On Wed, Sep 26, 2012 at 5:50 PM, Alan Stern  wrote:
>> On Tue, 25 Sep 2012, Sarah Sharp wrote:
>>
>>> Alan, I'm wondering if the xHCI ring expansion is causing issues with
>>> USB hard drives under xHCI.  Testing with a Buffalo USB 3.0 hard drive
>>> with an NEC uPD720200 xHCI host, I see that the usb-storage and SCSI
>>> initialization produces I/O errors on random sectors in 3.4.0, 3.4.6,
>>> and 3.5.0.  I can't get those errors to be reproduced in 3.3.1.
>>>
>>> The xHCI ring expansion was added in 3.4, and we changed the xHCI's
>>> sg_tablesize:
>>>
>>> int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
>>> {
>>> ...
>>> /* Accept arbitrarily long scatter-gather lists */
>>> hcd->self.sg_tablesize = ~0;
>>>
>>> The usb-storage driver sets the tablesize thus:
>>>
>>> static unsigned int usb_stor_sg_tables

[PATCH] USB: Fix race condition when removing host controllers

[Alan Stern]

This patch (as1607) fixes a race that can occur if a USB host
controller is removed while a process is reading the
/sys/kernel/debug/usb/devices file.

The usb_device_read() routine uses the bus->root_hub pointer to
determine whether or not the root hub is registered.  The is not a
valid test, because the pointer is set before the root hub gets
registered and remains set even after the root hub is unregistered and
deallocated.  As a result, usb_device_read() or usb_device_dump() can
access freed memory, causing an oops.

The patch changes the test to use the hcd->rh_registered flag, which
does get set and cleared at the appropriate times.  It also makes sure
to hold the usb_bus_list_lock mutex while setting the flag, so that
usb_device_read() will become aware of new root hubs as soon as they
are registered.

Signed-off-by: Alan Stern 
Reported-by: Don Zickus 
CC: 

---

 drivers/usb/core/devices.c |2 +-
 drivers/usb/core/hcd.c |6 ++
 2 files changed, 3 insertions(+), 5 deletions(-)

Index: usb-3.6/drivers/usb/core/devices.c
===
--- usb-3.6.orig/drivers/usb/core/devices.c
+++ usb-3.6/drivers/usb/core/devices.c
@@ -624,7 +624,7 @@ static ssize_t usb_device_read(struct fi
/* print devices for all busses */
list_for_each_entry(bus, &usb_bus_list, bus_list) {
/* recurse through all children of the root hub */
-   if (!bus->root_hub)
+   if (!bus_to_hcd(bus)->rh_registered)
continue;
usb_lock_device(bus->root_hub);
ret = usb_device_dump(&buf, &nbytes, &skip_bytes, ppos,
Index: usb-3.6/drivers/usb/core/hcd.c
===
--- usb-3.6.orig/drivers/usb/core/hcd.c
+++ usb-3.6/drivers/usb/core/hcd.c
@@ -1011,10 +1011,7 @@ static int register_root_hub(struct usb_
if (retval) {
dev_err (parent_dev, "can't register root hub for %s, %d\n",
dev_name(&usb_dev->dev), retval);
-   }
-   mutex_unlock(&usb_bus_list_lock);
-
-   if (retval == 0) {
+   } else {
spin_lock_irq (&hcd_root_hub_lock);
hcd->rh_registered = 1;
spin_unlock_irq (&hcd_root_hub_lock);
@@ -1023,6 +1020,7 @@ static int register_root_hub(struct usb_
if (HCD_DEAD(hcd))
usb_hc_died (hcd);  /* This time clean up */
}
+   mutex_unlock(&usb_bus_list_lock);
 
return retval;
 }

--
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: phy: add generic PHY framework

[David Miller]

All networking patches must be submitted to net...@vger.kernel.org

Thank you.
--
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: phy: add generic PHY framework

[Greg KH]

On Wed, Sep 26, 2012 at 08:31:15PM +0530, Kishon Vijay Abraham I wrote:
> The PHY framework provides a set of API's for the PHY drivers to
> create/destroy a PHY and API's for the PHY users to obtain a reference to the
> PHY with or without using phandle. To obtain a reference to the PHY without
> using phandle, the platform specfic intialization code (say from board file)
> should have already called phy_bind with the binding information. The binding
> information consists of phy's device name, phy user device name and an index.
> The index is used when the same phy user binds to mulitple phys.
> 
> PHY drivers should create the PHY by passing phy_descriptor that has
> describes the PHY (label, type etc..) and ops like init, exit, suspend, 
> resume,
> poweron, shutdown.

Do you have an example driver that uses this new framework?

How does it look in sysfs?  You need to add Documentation/ABI/ entries
for the sysfs files you created as well.

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: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

[Adrian Sandu]

On Wed, Sep 26, 2012 at 5:50 PM, Alan Stern  wrote:
> On Tue, 25 Sep 2012, Sarah Sharp wrote:
>
>> Alan, I'm wondering if the xHCI ring expansion is causing issues with
>> USB hard drives under xHCI.  Testing with a Buffalo USB 3.0 hard drive
>> with an NEC uPD720200 xHCI host, I see that the usb-storage and SCSI
>> initialization produces I/O errors on random sectors in 3.4.0, 3.4.6,
>> and 3.5.0.  I can't get those errors to be reproduced in 3.3.1.
>>
>> The xHCI ring expansion was added in 3.4, and we changed the xHCI's
>> sg_tablesize:
>>
>> int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
>> {
>> ...
>> /* Accept arbitrarily long scatter-gather lists */
>> hcd->self.sg_tablesize = ~0;
>>
>> The usb-storage driver sets the tablesize thus:
>>
>> static unsigned int usb_stor_sg_tablesize(struct usb_interface *intf)
>> {
>> struct usb_device *usb_dev = interface_to_usbdev(intf);
>>
>> if (usb_dev->bus->sg_tablesize) {
>> return usb_dev->bus->sg_tablesize;
>> }
>> return SG_ALL;
>> }
>>
>> I notice that SG_ALL is set to SCSI_MAX_SG_SEGMENTS, which is only 128.
>> Should we be passing an arbitrarily large number to the SCSI core?
>
> Yes, there's no reason not to.  The block layer will make sure that
> each individual request has a sufficiently small number of segments.
>
>> There's some wording in include/scsi/scsi.h about also limiting the
>> number of chained sgs to 2048.  I'm wondering if we're hitting some bugs
>> in the SCSI layer because we're setting the sg_tablesize so high.
>
> I doubt it.  Anyway, this stuff is handled by the block layer now, not
> the SCSI layer.  If you look through drivers/scsi, you'll see that
> SG_ALL is used only in various SCSI interface drivers, not in the core.
>
>> Alternately, we could be hitting bugs in the USB 3.0 firmware when we
>> attempt to issue a read or write that's too big.  The read on Adrian's
>> hard drive failed on a bigger read request (122880 bytes).  It would be
>> interesting to see if it works fine if the xHCI sg_tablesize is limited.
>> I'm going to try that with my own drive on 3.5.4 and see if it helps.
>
> There were examples in the earlier usbmon traces where 122880-byte
> reads succeeded, for whatever that's worth...
>
> I doubt very much that you are anywhere close to hitting that limit.
> If a 120-KB transfer has more than 128 SG segments then on average each
> segment would be under 1024 bytes, a lot smaller than a page, which
> seems unlikely.  I don't think I've ever seen a transfer needing more
> than about 8 segments.
>
> Alan Stern
>
Ok, back to vanilla 3.4.11, disabled CONFIG_USB_XHCI_HCD_DEBUGGING ..

I still see

2012-09-26T19:52:16.661604+03:00 d3xt3r01 kernel: [ 1213.416759] usb
3-2.4: reset SuperSpeed USB device number 11 using xhci_hcd
2012-09-26T19:52:16.674632+03:00 d3xt3r01 kernel: [ 1213.429351]
xhci_hcd :04:00.0: xHCI xhci_drop_endpoint called with disabled ep
88011d3c6980
2012-09-26T19:52:16.674665+03:00 d3xt3r01 kernel: [ 1213.429363]
xhci_hcd :04:00.0: xHCI xhci_drop_endpoint called with disabled ep
88011d3c69c0
T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  8 Spd=5000 MxCh= 4
D:  Ver= 3.00 Cls=09(hub  ) Sub=00 Prot=03 MxPS= 9 #Cfgs=  1
P:  Vendor=2109 ProdID=0810 Rev= 3.74
S:  Manufacturer=VIA Labs, Inc.
S:  Product=4-Port USB 3.0 Hub
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  2mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=13(Int.) MxPS=   2 Ivl=4096ms

T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  4 Spd=480  MxCh= 4
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=2109 ProdID=3431 Rev= 2.74
S:  Product=USB2.0 Hub
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms

T:  Bus=03 Lev=02 Prnt=08 Port=00 Cnt=01 Dev#=  9 Spd=5000 MxCh= 0
D:  Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=1058 ProdID=1140 Rev=10.03
S:  Manufacturer=Western Digital
S:  Product=My Book 1140
S:  SerialNumber=5743415A4144303235323133
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  2mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms

T:  Bus=03 Lev=02 Prnt=08 Port=03 Cnt=04 Dev#= 11 Spd=5000 MxCh= 0
D:  Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=1058 ProdID=1140 Rev=10.03
S:  Manufacturer=Western Digital
S:  Product=My Book 1140
S:  SerialNumber=574D415A4135343330323937
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  2mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms

So I need to cat 3u .. right ? Available at
http://d3xt3r01.tk/~dexter/usbmon/1348678668_3u
After the copy .. I see

2012-09-26T19:52:51.477641+03:00 d3xt3r01 kernel: [ 1248.232213] hub
3

Re: [PATCH 01/10] usb: otg: msm: Convert to clk_prepare/unprepare

[Pankaj Jangra]

Hi..

On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd  wrote:
> Add calls to clk_prepare and unprepare so that MSM can migrate to
> the common clock framework.
>
> Cc: Felipe Balbi 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/otg/msm_otg.c | 38 +++---
>  1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/usb/otg/msm_otg.c b/drivers/usb/otg/msm_otg.c
> index 9f5fc90..2ae0639 100644
> --- a/drivers/usb/otg/msm_otg.c
> +++ b/drivers/usb/otg/msm_otg.c
> @@ -514,13 +514,13 @@ static int msm_otg_suspend(struct msm_otg *motg)
> motg->pdata->otg_control == OTG_PMIC_CONTROL)
> writel(readl(USB_PHY_CTRL) | PHY_RETEN, USB_PHY_CTRL);
>
> -   clk_disable(motg->pclk);
> -   clk_disable(motg->clk);
> +   clk_disable_unprepare(motg->pclk);
> +   clk_disable_unprepare(motg->clk);
> if (motg->core_clk)
> -   clk_disable(motg->core_clk);
> +   clk_disable_unprepare(motg->core_clk);
>
I was under assumption that system suspend/resume might be called from
the interrupt context. If that is case then its not appropriate to
call clk_prepare/unprepare here right? or my understanding is not correct

--
Pankaj Jangra
--
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: phy: add generic PHY framework

[Joe Perches]

On Wed, 2012-09-26 at 20:31 +0530, Kishon Vijay Abraham I wrote:
> The PHY framework provides a set of API's for the PHY drivers to
> create/destroy a PHY and API's 

Just some trivial notes.

> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
[]
> @@ -0,0 +1,445 @@
[]
> +static void devm_phy_release(struct device *dev, void *res)
> +{
> + struct phy *phy = *(struct phy **)res;

That's a bit twisted isn't it?
Perhaps
struct phy *phy = res;

[]

> +static int devm_phy_match(struct device *dev, void *res, void *match_data)
> +{
> + return res == match_data;

static bool devm_phy_match(etc...)

[]

> +struct phy *devm_of_phy_get(struct device *dev, const char *phandle, u8 
> index)
> +{
> + struct phy *phy = NULL, **ptr;
> + struct device_node *node;
> +
> + if (!dev->of_node) {
> + dev_dbg(dev, "device does not have a device node entry\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + node = of_parse_phandle(dev->of_node, phandle, index);
> + if (!node) {
> + dev_dbg(dev, "failed to get %s phandle in %s node\n", phandle,
> + dev->of_node->full_name);
> + return ERR_PTR(-ENODEV);
> + }
> +
> + ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);

Is this the right size?

Because ptr is **, perhaps sizeof(struct phy) is clearer.

> + if (!ptr) {
> + dev_dbg(dev, "failed to allocate memory for devres\n");

alloc failures generally don't need specific OOM messages
as the general alloc OOM dumps stack.

> + return ERR_PTR(-ENOMEM);
> + }
> +
> + mutex_lock(&phy_list_mutex);
> +
> + phy = of_phy_lookup(dev, node);
> + if (IS_ERR(phy) || !phy->dev.class ||
> + !try_module_get(phy->dev.class->owner)) {

I think it's tasteful coding style to align like:

if (IS_ERR(phy) || !phy->dev.class ||
!try_module_get(phy->dev.class->owner)) {
[]

> +struct phy *phy_create(struct device *dev, struct phy_descriptor *desc)
> +{
> + int ret;
> + struct phy *phy;
> + struct phy_bind *phy_bind;
> + const char *devname = NULL;
> +
> + if (!dev || !desc) {
> + dev_err(dev, "no descriptor/device provided for PHY\n");
> + ret = -EINVAL;
> + goto err0;
> + }
> +
> + if (!desc->ops) {
> + dev_err(dev, "no PHY ops provided\n");
> + ret = -EINVAL;
> + goto err0;
> + }
> +
> + phy = kzalloc(sizeof(*phy), GFP_KERNEL);
> + if (!phy) {
> + dev_err(dev, "no memory for PHY\n");

No OOM message required...

[]

> +static int __init phy_core_init(void)
> +{
> + phy_class = class_create(THIS_MODULE, "phy");
> + if (IS_ERR(phy_class)) {
> + pr_err("failed to create phy class --> %ld\n",
> + PTR_ERR(phy_class));

You might add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
before any include so that pr_ are prefixed.

cheers, Joe

--
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: Fix race condition when removing EHCI PCI devices

[Don Zickus]

On Wed, Sep 26, 2012 at 12:55:26PM -0400, Alan Stern wrote:
> On Wed, 26 Sep 2012, Don Zickus wrote:
> 
> > Hi Alan,
> > 
> > This patch seemed to be successful.  I copied and pasted the response from
> > our customer (we backported the patch to RHEL-6/2.6.32):
> 
> ...
> 
> > Is there anything else you need from us or can we move forward with this
> > patch?
> 
> That's good enough; I'll submit it to Greg.

Awesome. Thanks!

Cheers,
Don
--
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: Fix race condition when removing EHCI PCI devices

[Alan Stern]

On Wed, 26 Sep 2012, Don Zickus wrote:

> Hi Alan,
> 
> This patch seemed to be successful.  I copied and pasted the response from
> our customer (we backported the patch to RHEL-6/2.6.32):

...

> Is there anything else you need from us or can we move forward with this
> patch?

That's good enough; I'll submit it to Greg.

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: [BUG] FTDI driver framing error with even parity (cont)

[Andrew]

Uwe Bonnes писал 26.09.2012 15:46:

"Andrew" == Andrew   writes:



Andrew> Looks like it's a time for a break, I've been missing the 
trivia
Andrew> and searching for the bug in the wrong place.  Terribly 
sorry

Andrew> for wasting your time, please close the bug report at
Andrew> https://bugzilla.kernel.org/show_bug.cgi?id=47921

Does it work now for you?


Yes, everything works fine now, thanks a lot for your help, and again 
sorry for

wasting your time.


Why don't you close the bug.


Closed. Didn't see I can (unlike our overcomplicated jira setup at 
work) just close bugs here.



Bye


--
Regards,
Andrew
--
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: Fix race condition when removing EHCI PCI devices

[Don Zickus]

On Mon, Sep 24, 2012 at 12:59:51PM -0400, Alan Stern wrote:
> > If you want to track down what's going wrong, you'll have to add some 
> > debugging code to usb_device_read() and usb_remove_hcd().  By the time 
> > usb_device_dump() starts running, it's already too late.
> 
> After thinking about this some more, I realized that my patch still 
> leaves a race -- although the oops would occur in a different place 
> (where usb_device_read checks bus->root_hub->devnum).
> 
> Here's a different patch which should work better.  It relies on the
> rh_registered flag in the usb_hcd structure, which persists as long as
> the usb_bus structure does, rather than on anything stored in the
> root-hub device structure.

Hi Alan,

This patch seemed to be successful.  I copied and pasted the response from
our customer (we backported the patch to RHEL-6/2.6.32):

"
This new patch testing went very well.  In previous tests, the kernel paniced
during the first or second surprise removal of the ehci_hcd PCI device on an
idle system.  I ran an entire night of surprise and polite device removals with
no kernel panic or Oops.  slub_debug=FZPU was used to poison deallocated
storage blocks and check for use after free.  No BUGs were logged by the
allocator.

Numerous messages like the following were seen at the console, indicating that
the stimulus leading to the panic should be occurring:
 cat: /proc/bus/usb/001/006: No such device

Surprise removals occur when the device is electrically disconnected from the
PCI bus while in use.  During a following clean-up operation, the driver's
remove function called.

Polite removals occur when the driver's remove function is called while the
device is in use.  After return from the driver, the device is electrically
disconnected from the PCI bus.

I ran 5 hours of surprise and polite removals on the same idle system that was
used for the previous tests, about 60 trials of each type of removal.  Then a
workload was started to cause mid-level CPU, Memory and Disk stress; the test
continued to run for 8.5 hours more executing about 38 more trials of each type
of PCI removal.
"

Is there anything else you need from us or can we move forward with this
patch?

Thanks again!

Cheers,
Don

> 
> 
> 
> Index: usb-3.6/drivers/usb/core/devices.c
> ===
> --- usb-3.6.orig/drivers/usb/core/devices.c
> +++ usb-3.6/drivers/usb/core/devices.c
> @@ -624,7 +624,7 @@ static ssize_t usb_device_read(struct fi
>   /* print devices for all busses */
>   list_for_each_entry(bus, &usb_bus_list, bus_list) {
>   /* recurse through all children of the root hub */
> - if (!bus->root_hub)
> + if (!bus_to_hcd(bus)->rh_registered)
>   continue;
>   usb_lock_device(bus->root_hub);
>   ret = usb_device_dump(&buf, &nbytes, &skip_bytes, ppos,
> Index: usb-3.6/drivers/usb/core/hcd.c
> ===
> --- usb-3.6.orig/drivers/usb/core/hcd.c
> +++ usb-3.6/drivers/usb/core/hcd.c
> @@ -1011,10 +1011,7 @@ static int register_root_hub(struct usb_
>   if (retval) {
>   dev_err (parent_dev, "can't register root hub for %s, %d\n",
>   dev_name(&usb_dev->dev), retval);
> - }
> - mutex_unlock(&usb_bus_list_lock);
> -
> - if (retval == 0) {
> + } else {
>   spin_lock_irq (&hcd_root_hub_lock);
>   hcd->rh_registered = 1;
>   spin_unlock_irq (&hcd_root_hub_lock);
> @@ -1023,6 +1020,7 @@ static int register_root_hub(struct usb_
>   if (HCD_DEAD(hcd))
>   usb_hc_died (hcd);  /* This time clean up */
>   }
> + mutex_unlock(&usb_bus_list_lock);
>  
>   return retval;
>  }
> 
--
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: proposal for switching off stuff for external ports

[Oliver Neukum]

On Wednesday 26 September 2012 18:38:38 Felipe Balbi wrote:
> Hi,
> 
> On Wed, Sep 26, 2012 at 05:31:43PM +0200, Oliver Neukum wrote:
> > Hi Sarah,
> > 
> > watching your talk and drinking tea I had an idea.
> > 
> > Switching off ports saves power in itself. It also allows
> > switching off host controllers.
> > The problem with switching off power on external ports is that they
> > don't detect hotplug events anymore.
> 
> could we expose that choice to userland, maybe ? Desktop environment

We certainly can. I was looking for a way to keep the cake and eat
at least a part of it. Orthogonal questions really.

> could implement different policies and one of them could to just turn
> them off and require user action to power them on when we connect
> something and another policy could be "poll" for devices. Meaning that
> we power port off for 1 second, then power up and check if there is a
> device connected, then power it off for another second and so on.

This would quite likely require more power than leaving them on.
And of course, it can be done fully in user space.

Regards
Oliver

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

Re: proposal for switching off stuff for external ports

[Felipe Balbi]

Hi,

On Wed, Sep 26, 2012 at 05:31:43PM +0200, Oliver Neukum wrote:
> Hi Sarah,
> 
> watching your talk and drinking tea I had an idea.
> 
> Switching off ports saves power in itself. It also allows
> switching off host controllers.
> The problem with switching off power on external ports is that they
> don't detect hotplug events anymore.

could we expose that choice to userland, maybe ? Desktop environment
could implement different policies and one of them could to just turn
them off and require user action to power them on when we connect
something and another policy could be "poll" for devices. Meaning that
we power port off for 1 second, then power up and check if there is a
device connected, then power it off for another second and so on.

-- 
balbi


signature.asc
Description: Digital signature

proposal for switching off stuff for external ports

[Oliver Neukum]

Hi Sarah,

watching your talk and drinking tea I had an idea.

Switching off ports saves power in itself. It also allows
switching off host controllers.
The problem with switching off power on external ports is that they
don't detect hotplug events anymore.

So is there a way to switch off controllers and leave ports on, saving
at least some power?  And it seems to me that in many cases, namely
EHCI with companion controllers and XHCI controllers that implement
a vendor specific switching option, we could switch the ports so that
a minimum number of controllers is connected to ports that are not switched
off.

What do you think?

Regards
Oliver

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

Re: [PATCH 02/12] usb: chipidea: udc: add pullup fuction, needed by the uvc gadget

[Michael Grzeschik]

Hi,

On Thu, Sep 20, 2012 at 03:08:15PM +0800, Peter Chen wrote:
> On Wed, Sep 12, 2012 at 7:58 PM, Alexander Shishkin
>  wrote:
> > From: Michael Grzeschik 
> >
> > Add function to physicaly enable or disable of pullup connection on the 
> > USB-D+
> > line. The uvc gaget will fail, if this function is not implemented.
> >
> > Cc: 
> > Signed-off-by: Michael Grzeschik 
> > Acked-by: Felipe Balbi 
> > Signed-off-by: Marc Kleine-Budde 
> > Signed-off-by: Alexander Shishkin 
> > ---
> >  drivers/usb/chipidea/udc.c |   21 +
> >  1 file changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > index 7801a3f..32ee870 100644
> > --- a/drivers/usb/chipidea/udc.c
> > +++ b/drivers/usb/chipidea/udc.c
> > @@ -78,8 +78,7 @@ static inline int ep_to_bit(struct ci13xxx *ci, int n)
> >  }
> >
> >  /**
> > - * hw_device_state: enables/disables interrupts & starts/stops device 
> > (execute
> > - *  without interruption)
> > + * hw_device_state: enables/disables interrupts (execute without 
> > interruption)
> >   * @dma: 0 => disable, !0 => enable and set dma engine
> >   *
> >   * This function returns an error code
> > @@ -91,9 +90,7 @@ static int hw_device_state(struct ci13xxx *ci, u32 dma)
> > /* interrupt, error, port change, reset, sleep/suspend */
> > hw_write(ci, OP_USBINTR, ~0,
> >  USBi_UI|USBi_UEI|USBi_PCI|USBi_URI|USBi_SLI);
> > -   hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
> > } else {
> > -   hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
> > hw_write(ci, OP_USBINTR, ~0, 0);
> > }
> 
> Hi Marc, your above change break the function that load gadget before
> plug usb cable.

What do you mean with that? When switching into device role, the
otg can load every gadget-module without having the hardware pluged-in.

> Does your change is because the set/clear usbcmd.rs twice at
> usb_gadget_probe_driver
> /usb_gadget_remove_driver? If it is, do you mind I submit  a patch to re-add 
> it?

If really needed, i suggest to use the api calls instead: 
usb_gadget_{probe,remove}_driver

> 
> > return 0;
> > @@ -1420,6 +1417,21 @@ static int ci13xxx_vbus_draw(struct usb_gadget 
> > *_gadget, unsigned mA)
> > return -ENOTSUPP;
> >  }
> >
> > +/* Change Data+ pullup status
> > + * this func is used by usb_gadget_connect/disconnet
> > + */
> > +static int ci13xxx_pullup(struct usb_gadget *_gadget, int is_on)
> > +{
> > +   struct ci13xxx *ci = container_of(_gadget, struct ci13xxx, gadget);
> > +
> > +   if (is_on)
> > +   hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
> > +   else
> > +   hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
> > +
> > +   return 0;
> > +}
> > +
> >  static int ci13xxx_start(struct usb_gadget *gadget,
> >  struct usb_gadget_driver *driver);
> >  static int ci13xxx_stop(struct usb_gadget *gadget,
> > @@ -1432,6 +1444,7 @@ static int ci13xxx_stop(struct usb_gadget *gadget,
> >  static const struct usb_gadget_ops usb_gadget_ops = {
> > .vbus_session   = ci13xxx_vbus_session,
> > .wakeup = ci13xxx_wakeup,
> > +   .pullup = ci13xxx_pullup,
> > .vbus_draw  = ci13xxx_vbus_draw,
> > .udc_start  = ci13xxx_start,
> > .udc_stop   = ci13xxx_stop,
> > --
> > 1.7.10.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
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 152d:0539 JMicron Technology USB -> eSata and sata port multiplier

[Alan Stern]

On Tue, 25 Sep 2012, Harry McGregor wrote:

> Hi,
> 
> I have been trying for some time to get a JMicron USB/eSata adapter to 
> work properly with a 4 drive Silicon Image based port multiplier 
> enclosure without success.  The port multiplier and drives work cleanly 
> off a PCI Silicon Image eSata card using Debian Wheezy.

> Any suggestions, patches, etc are welcome, this system is a home system, 
> and can be easily rebooted to try any fixes suggested.

Try attaching the JMicron unit (along with the enclosure and drives) to
a machine running Windows.  If it still doesn't work, return or
exchange it.

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: Remote wakeup vs. hub suspend

[Alan Stern]

On Wed, 26 Sep 2012, Peter Chen wrote:

> >> Currently, both ehci_hub_control and ehci_bus_suspend will go bus suspend
> >> routine when CONFIG_USB_SUSPEND is defined, and I am not sure if
> >> PSE and ASE is cleared before we let bus go to suspend (at 
> >> ehci_hub_control).
> >
> > Where does ehci_hub_control put the bus into suspend?  It suspends only
> > individual ports, not the whole bus.
> >
> > If if there's only one port, suspending that port does not suspend the
> > whole bus.  The frame counter continues to update and the root hub will
> > continue to respond to URBs.
> >
> 
> From the code, the URB for roothub just read/write register portsc, it has not
> traffic on usb bus.
> 
> Take my controller as an example, it is chipidea (Synopsis now) single
> port controller,
> this single port is just controller.
> 
> Set portsc.suspendM will stop the SOF, but frame counter will not stop
> until phy clock is
> disabled.

Are you asking whether ASE and PSE are cleared when ehci_hub_control()
puts the only port into suspend mode?  They may or may not be clear.

But if they aren't, the watchdog timer makes sure that they will be
cleared no more than about 15 ms later (in the 3.6 kernel; earlier
kernels can take up to 50 ms).

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] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

The PHY framework provides a set of API's for the PHY drivers to
create/destroy a PHY and API's for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
should have already called phy_bind with the binding information. The binding
information consists of phy's device name, phy user device name and an index.
The index is used when the same phy user binds to mulitple phys.

PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
poweron, shutdown.

Cc: Felipe Balbi 
Cc: Marc Kleine-Budde 
Signed-off-by: Kishon Vijay Abraham I 
---
Did testing (phandle path) to some extent by hacking omap-usb2 to use this
new framework. (completely modifying omap-usb2 to use this framework will
take some time mostly because of the OTG stuff). Also perfomed non-dt
testing by moving to a older kernel. Any kind of testing for this patch is
welcome :-)
 MAINTAINERS |7 +
 drivers/Kconfig |2 +
 drivers/Makefile|2 +
 drivers/phy/Kconfig |   13 ++
 drivers/phy/Makefile|5 +
 drivers/phy/phy-core.c  |  445 +++
 include/linux/phy/phy.h |  182 +++
 7 files changed, 656 insertions(+)
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

diff --git a/MAINTAINERS b/MAINTAINERS
index ea0519a..48f3cfb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3078,6 +3078,13 @@ T:   git 
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
 S: Maintained
 F: include/asm-generic
 
+GENERIC PHY FRAMEWORK
+M: Kishon Vijay Abraham I 
+L: linux-ker...@vger.kernel.org
+S: Supported
+F: drivers/phy/
+F: include/linux/phy/
+
 GENERIC UIO DRIVER FOR PCI DEVICES
 M: "Michael S. Tsirkin" 
 L: k...@vger.kernel.org
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 324e958..d289df5 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -154,4 +154,6 @@ source "drivers/vme/Kconfig"
 
 source "drivers/pwm/Kconfig"
 
+source "drivers/phy/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index d64a0f7..e39252d 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -40,6 +40,8 @@ obj-y += char/
 # gpu/ comes after char for AGP vs DRM startup
 obj-y  += gpu/
 
+obj-y  += phy/
+
 obj-$(CONFIG_CONNECTOR)+= connector/
 
 # i810fb and intelfb depend on char/agp/
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
new file mode 100644
index 000..34f7077
--- /dev/null
+++ b/drivers/phy/Kconfig
@@ -0,0 +1,13 @@
+#
+# PHY
+#
+
+menuconfig GENERIC_PHY
+   tristate "Generic PHY Support"
+   help
+ Generic PHY support.
+
+ This framework is designed to provide a generic interface for PHY
+ devices present in the kernel. This layer will have the generic
+ API by which phy drivers can create PHY using the phy framework and
+ phy users can obtain reference to the PHY.
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
new file mode 100644
index 000..9e9560f
--- /dev/null
+++ b/drivers/phy/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_GENERIC_PHY)  += phy-core.o
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 000..bf47a88
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,445 @@
+/*
+ * phy-core.c  --  Generic Phy framework.
+ *
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+   struct phy *phy = *(struct phy **)res;
+
+   phy_put(phy);
+}
+
+static int devm_phy_match(struct device *dev, void *res, void *match_data)
+{
+   return res =

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

[Alan Stern]

On Tue, 25 Sep 2012, Sarah Sharp wrote:

> Alan, I'm wondering if the xHCI ring expansion is causing issues with
> USB hard drives under xHCI.  Testing with a Buffalo USB 3.0 hard drive
> with an NEC uPD720200 xHCI host, I see that the usb-storage and SCSI
> initialization produces I/O errors on random sectors in 3.4.0, 3.4.6,
> and 3.5.0.  I can't get those errors to be reproduced in 3.3.1.
> 
> The xHCI ring expansion was added in 3.4, and we changed the xHCI's
> sg_tablesize:
> 
> int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
> {
> ...
> /* Accept arbitrarily long scatter-gather lists */
> hcd->self.sg_tablesize = ~0;
> 
> The usb-storage driver sets the tablesize thus:
> 
> static unsigned int usb_stor_sg_tablesize(struct usb_interface *intf)
> {
> struct usb_device *usb_dev = interface_to_usbdev(intf);
> 
> if (usb_dev->bus->sg_tablesize) {
> return usb_dev->bus->sg_tablesize;
> }
> return SG_ALL;
> }
> 
> I notice that SG_ALL is set to SCSI_MAX_SG_SEGMENTS, which is only 128.
> Should we be passing an arbitrarily large number to the SCSI core?

Yes, there's no reason not to.  The block layer will make sure that
each individual request has a sufficiently small number of segments.

> There's some wording in include/scsi/scsi.h about also limiting the
> number of chained sgs to 2048.  I'm wondering if we're hitting some bugs
> in the SCSI layer because we're setting the sg_tablesize so high.

I doubt it.  Anyway, this stuff is handled by the block layer now, not
the SCSI layer.  If you look through drivers/scsi, you'll see that 
SG_ALL is used only in various SCSI interface drivers, not in the core.

> Alternately, we could be hitting bugs in the USB 3.0 firmware when we
> attempt to issue a read or write that's too big.  The read on Adrian's
> hard drive failed on a bigger read request (122880 bytes).  It would be
> interesting to see if it works fine if the xHCI sg_tablesize is limited.
> I'm going to try that with my own drive on 3.5.4 and see if it helps.

There were examples in the earlier usbmon traces where 122880-byte 
reads succeeded, for whatever that's worth...

I doubt very much that you are anywhere close to hitting that limit.  
If a 120-KB transfer has more than 128 SG segments then on average each
segment would be under 1024 bytes, a lot smaller than a page, which
seems unlikely.  I don't think I've ever seen a transfer needing more
than about 8 segments.

Alan Stern

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

RE: [PATCH 1/1] usb: Include generic_interrupt for OMAP2_PLUS

[Philippe De Swert]

Hi,

>On Tue, Sep 25, 2012 at 2:39 PM, Philippe De Swert
>>> Then maybe it's best to just remove the ifdefs and always provide
>>> generic_interrupt() ?
>>>
>>> Anyone against it ?
>
>Providing generic_interrupt seems fine.
>
>> Well it seems there are only two drivers that use it omap2430 and
>> ux500. Maybe we somehow link it to the drivers that need it? (I might
>> have missed other drivers but it looks like it is just those two)
>
>One way I see is that omap2430 and ux500 implement the isr handler
>in platform glue driver and then call the musb_interrupt() as done in
>daxxx, amxxx, ti8xxx platforms. Then generic_interrupt can be removed.

So something along those lines? (If this is the right way I will resend as a 
real patch)

>From deae78e1084749f340ae8b8aaeca51818d5bfc55 Mon Sep 17 00:00:00 2001
From: Philippe De Swert 
Date: Wed, 26 Sep 2012 17:00:46 +0300
Subject: [PATCH 1/1] musb: Move generic_interrupt out of the way

Have all musb drivers define their own isr.

Signed-off-by: Philippe De Swert 
---
 drivers/usb/musb/musb_core.c |   33 ++---
 drivers/usb/musb/omap2430.c  |   22 ++
 drivers/usb/musb/ux500.c |   21 +
 3 files changed, 45 insertions(+), 31 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 26f1bef..1d5ee34 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1496,35 +1496,6 @@ static int __devinit musb_core_init(u16 musb_type, 
struct musb *musb)
return 0;
 }
 
-/*-*/
-
-#if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430) || \
-   defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500)
-
-static irqreturn_t generic_interrupt(int irq, void *__hci)
-{
-   unsigned long   flags;
-   irqreturn_t retval = IRQ_NONE;
-   struct musb *musb = __hci;
-
-   spin_lock_irqsave(&musb->lock, flags);
-
-   musb->int_usb = musb_readb(musb->mregs, MUSB_INTRUSB);
-   musb->int_tx = musb_readw(musb->mregs, MUSB_INTRTX);
-   musb->int_rx = musb_readw(musb->mregs, MUSB_INTRRX);
-
-   if (musb->int_usb || musb->int_tx || musb->int_rx)
-   retval = musb_interrupt(musb);
-
-   spin_unlock_irqrestore(&musb->lock, flags);
-
-   return retval;
-}
-
-#else
-#define generic_interrupt  NULL
-#endif
-
 /*
  * handle all the irqs defined by the HDRC core. for now we expect:  other
  * irq sources (phy, dma, etc) will be handled first, musb->int_* values
@@ -1907,7 +1878,8 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
musb->ops = plat->platform_ops;
 
/* The musb_platform_init() call:
-*   - adjusts musb->mregs and musb->isr if needed,
+*   - adjusts musb->mregs if needed 
+*   - sets the musb->isr 
 *   - may initialize an integrated tranceiver
 *   - initializes musb->xceiv, usually by otg_get_phy()
 *   - stops powering VBUS
@@ -1917,7 +1889,6 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
 * external/discrete ones in various flavors (twl4030 family,
 * isp1504, non-OTG, etc) mostly hooking up through ULPI.
 */
-   musb->isr = generic_interrupt;
status = musb_platform_init(musb);
if (status < 0)
goto fail1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5fdb9da..5461619d 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -306,6 +306,26 @@ static void omap_musb_mailbox_work(struct work_struct 
*mailbox_work)
omap_musb_set_mailbox(glue);
 }
 
+static irqreturn_t omap2430_musb_interrupt(int irq, void *__hci)
+{
+unsigned long   flags;
+irqreturn_t retval = IRQ_NONE;
+struct musb *musb = __hci;
+
+spin_lock_irqsave(&musb->lock, flags);
+
+musb->int_usb = musb_readb(musb->mregs, MUSB_INTRUSB);
+musb->int_tx = musb_readw(musb->mregs, MUSB_INTRTX);
+musb->int_rx = musb_readw(musb->mregs, MUSB_INTRRX);
+
+if (musb->int_usb || musb->int_tx || musb->int_rx)
+retval = musb_interrupt(musb);
+
+spin_unlock_irqrestore(&musb->lock, flags);
+
+return retval;
+}
+
 static int omap2430_musb_init(struct musb *musb)
 {
u32 l;
@@ -325,6 +345,8 @@ static int omap2430_musb_init(struct musb *musb)
return -ENODEV;
}
 
+   musb->isr = omap2430_musb_interrupt;
+
status = pm_runtime_get_sync(dev);
if (status < 0) {
dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c
index a8c0fad..ec9aaec 100644
--- a/drivers/usb/musb/ux500.c
+++ b/drivers/usb/musb/ux500.c
@@ -36,6 +36,26 @@ struct ux500_glue {
 };
 #define glue_to_musb(g) 

Re: The USB is not working with SM502 Graphics, but working with Intel Pc graphics

[Greg KH]

On Wed, Sep 26, 2012 at 03:09:03PM +0530, Thirumalesha N wrote:
> Dear Sir/Madam,
>  
>               I'm testing PMC type SM502 based Graphics card which has usb,
> audio and display interfaces. 
> 
>              I'm using kernel version linux-2.6.21 with redhat enterprise 5.5
> OS.

As you are testing RHEL, please work with Red Hat for this issue, they
are the only ones tha tcan support it, we can't.  Especially as you are
paying for that support, you might as well use it :)

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

Re: Query: usbtest: Test 13: Endpoint Halt Test: At Super Speed does not work

[Pratyush Anand]

On 9/25/2012 9:29 PM, Sarah Sharp wrote:

  Can Pratyush
recompile his Linux host side kernel with CONFIG_USB_DEBUG and
CONFIG_USB_XHCI_HCD_DEBUGGING and send me the dmesg?


Ok, I ll do that.


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

Re: [BUG] FTDI driver framing error with even parity (cont)

[Andrew]

Uwe Bonnes писал 26.09.2012 15:31:

Hello,

on another run now even without inter-character spaces, the analyzer 
sees

the right thing.

Bye


Looks like it's a time for a break, I've been missing the trivia and 
searching for

the bug in the wrong place.
Terribly sorry for wasting your time, please close the bug report at
https://bugzilla.kernel.org/show_bug.cgi?id=47921

--
Regards,
Andrew

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

Re: [BUG] FTDI driver framing error with even parity (cont)

[Uwe Bonnes]

> "Andrew" == Andrew   writes:


Andrew> Looks like it's a time for a break, I've been missing the trivia
Andrew> and searching for the bug in the wrong place.  Terribly sorry
Andrew> for wasting your time, please close the bug report at
Andrew> https://bugzilla.kernel.org/show_bug.cgi?id=47921

Does it work now for you?

Why don't you close the bug.

Bye

-- 
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
- Tel. 06151 162516  Fax. 06151 164321 --
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] FTDI driver framing error with even parity (cont)

[Uwe Bonnes]

Hello,

on another run now even without inter-character spaces, the analyzer sees
the right thing.

Bye

-- 
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
- Tel. 06151 162516  Fax. 06151 164321 --
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] FTDI driver framing error with even parity

[Uwe Bonnes]

Hello Andrew,

I can not see such an error with a FT232R!

Your diagram is propably done by the Saleae Logic Logic analyzer. The
analyzer missanalyses the the trace. If you space the character like with
the patch below and if you don't overwrite the CFLAG setting PARENB with the
call to cfmakeraw(&newtio) , like with the patch below, the trace is decoded
right.

Bye

-- 
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
- Tel. 06151 162516  Fax. 06151 164321 --
diff --git a/main.c b/main.c
index 112689d..6d900a6 100644
--- a/main.c
+++ b/main.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "uart.h"
 
 
@@ -19,6 +20,11 @@ int main(int argc, char* argv[]) {
}

char *hello = "Hello, world\n";
-   write(us->fd, hello, strlen(hello));
+char *p;
+for (p = hello; *p; p++)
+{
+write(us->fd, p, 1);
+usleep(1000);
+}
 }
 
diff --git a/uart.c b/uart.c
index 4a5c7ca..c2fbfa4 100644
--- a/uart.c
+++ b/uart.c
@@ -70,6 +70,7 @@ int uart_init(struct uart_settings_t* us)
}
tcgetattr(fd,&oldtio); /* save current port settings */
bzero(&newtio, sizeof(newtio));
+   cfmakeraw(&newtio);
newtio.c_cflag =  us->cfl | CLOCAL | CREAD;
newtio.c_iflag = us->ifl;
newtio.c_oflag = us->ofl;
@@ -77,7 +78,6 @@ int uart_init(struct uart_settings_t* us)
newtio.c_lflag = 0;
newtio.c_cc[VTIME]= 0;   /* inter-character timer unused */
newtio.c_cc[VMIN] = 1;   /* We're non-blocking */
-   cfmakeraw(&newtio);
tcflush(fd, TCIFLUSH);
tcsetattr(fd,TCSANOW,&newtio);
us->fd=fd;
--
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: removing the timer from cdc-ncm

[Alexey ORISHKO]

> -Original Message-
> From: Oliver Neukum [mailto:oneu...@suse.de]
 
> Thank you. Worse than I hoped, but not unexpected. I'll stare at the
> code a bit.

Just a small clarification: on Ellisys trace I see only
ConnectionSpeedChange and NetworkConnection (Connected). No data was
sent on the bulk pipe before it crashed.

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

Re: [RFC PATCH] drivers: phy: add generic PHY framework

[Marc Kleine-Budde]

On 09/26/2012 11:20 AM, ABRAHAM, KISHON VIJAY wrote:
> Hi,
> 
> On Mon, Sep 17, 2012 at 3:03 PM, Marc Kleine-Budde  
> wrote:
>> On 09/14/2012 03:06 PM, ABRAHAM, KISHON VIJAY wrote:
>>
>> [...]
>>
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> new file mode 100644
> index 000..c55446a
> --- /dev/null
> +++ b/drivers/phy/phy-core.c
> @@ -0,0 +1,437 @@
> +/*
> + * phy-core.c  --  Generic Phy framework.
> + *
> + * Copyright (C) 2012 Texas Instruments
> + *
> + * Author: Kishon Vijay Abraham I 
> + *
> + * This program is free software; you can redistribute  it and/or modify 
> it
> + * under  the terms of  the GNU General  Public License as published by 
> the
> + * Free Software Foundation;  either version 2 of the  License, or (at 
> your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static struct class *phy_class;
> +static LIST_HEAD(phy_list);
> +static DEFINE_MUTEX(phy_list_mutex);
> +static LIST_HEAD(phy_bind_list);
> +
> +static void devm_phy_release(struct device *dev, void *res)
> +{
> + struct phy *phy = *(struct phy **)res;

 What about adding a struct phy_res, doing so,m you don't need these
 casts, and it's easier to add more pointers if needed.
>>>
>>> Wont we still need to do the cast since you get only a void pointer.
>>> Maybe I'm not getting you.
>>
>> As "res" is a void pointer, no need to hast to to a "struct phy_res"
>> pointer, if you think that's unclean code, you can still cast it. But
>> IMHO the code is far more readable.
>>
> +
> + phy_put(phy);
> +}
> +
> +static int devm_phy_match(struct device *dev, void *res, void 
> *match_data)
> +{
> + return res == match_data;
> +}
> +
> +static struct phy *phy_lookup(struct device *dev, u8 index)
> +{
> + struct phy_bind *phy_bind = NULL;
> +
> + list_for_each_entry(phy_bind, &phy_bind_list, list) {
> + if (!(strcmp(phy_bind->dev_name, dev_name(dev))) &&
> + phy_bind->index == index)
> + return phy_bind->phy;
> + }
> +
> + return ERR_PTR(-ENODEV);
> +}
> +
> +static struct phy *of_phy_lookup(struct device *dev, struct device_node 
> *node)
> +{
> + int index = 0;
> + struct phy  *phy;
   ^^

 Please remove that stray space.
>>>
>>> Sure.

> + struct phy_bind *phy_map = NULL;
> +
> + list_for_each_entry(phy_map, &phy_bind_list, list)
> + if (!(strcmp(phy_map->dev_name, dev_name(dev
> + index++;
> +
> + list_for_each_entry(phy, &phy_list, head) {
> + if (node != phy->desc->of_node)
> + continue;
> +
> + phy_map = phy_bind(dev_name(dev), index, 
> dev_name(&phy->dev));
> + if (!IS_ERR(phy_map)) {
> + phy_map->phy = phy;
> + phy_map->auto_bind = true;
> + }
> +
> + return phy;
> + }
> +
> + return ERR_PTR(-ENODEV);
> +}
> +
> +/**
> + * devm_phy_get - lookup and obtain a reference to a phy.
> + * @dev: device that requests this phy
> + * @index: the index of the phy
> + *
> + * Gets the phy using phy_get(), and associates a device with it using
> + * devres. On driver detach, release function is invoked on the devres 
> data,
> + * then, devres data is freed.
> + */
> +struct phy *devm_phy_get(struct device *dev, u8 index)
> +{
> + struct phy **ptr, *phy;
> +
> + ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr)
> + return NULL;
> +
> + phy = phy_get(dev, index);
> + if (!IS_ERR(phy)) {
> + *ptr = phy;
> + devres_add(dev, ptr);
> + } else
> + devres_free(ptr);

 nitpick: when when if has { }, else should have, too.
>>>
>>> Sure.

> +
> + return phy;
> +}
> +EXPORT_SYMBOL_GPL(devm_phy_get);
> +
> +/**
> + * devm_phy_put - release the PHY
> + * @dev: device that wants to re

Re: [RFC PATCH] drivers: phy: add generic PHY framework

[ABRAHAM, KISHON VIJAY]

Hi,

On Mon, Sep 17, 2012 at 3:03 PM, Marc Kleine-Budde  wrote:
> On 09/14/2012 03:06 PM, ABRAHAM, KISHON VIJAY wrote:
>
> [...]
>
 diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
 new file mode 100644
 index 000..c55446a
 --- /dev/null
 +++ b/drivers/phy/phy-core.c
 @@ -0,0 +1,437 @@
 +/*
 + * phy-core.c  --  Generic Phy framework.
 + *
 + * Copyright (C) 2012 Texas Instruments
 + *
 + * Author: Kishon Vijay Abraham I 
 + *
 + * This program is free software; you can redistribute  it and/or modify 
 it
 + * under  the terms of  the GNU General  Public License as published by 
 the
 + * Free Software Foundation;  either version 2 of the  License, or (at 
 your
 + * option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program.  If not, see .
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +static struct class *phy_class;
 +static LIST_HEAD(phy_list);
 +static DEFINE_MUTEX(phy_list_mutex);
 +static LIST_HEAD(phy_bind_list);
 +
 +static void devm_phy_release(struct device *dev, void *res)
 +{
 + struct phy *phy = *(struct phy **)res;
>>>
>>> What about adding a struct phy_res, doing so,m you don't need these
>>> casts, and it's easier to add more pointers if needed.
>>
>> Wont we still need to do the cast since you get only a void pointer.
>> Maybe I'm not getting you.
>
> As "res" is a void pointer, no need to hast to to a "struct phy_res"
> pointer, if you think that's unclean code, you can still cast it. But
> IMHO the code is far more readable.
>
 +
 + phy_put(phy);
 +}
 +
 +static int devm_phy_match(struct device *dev, void *res, void *match_data)
 +{
 + return res == match_data;
 +}
 +
 +static struct phy *phy_lookup(struct device *dev, u8 index)
 +{
 + struct phy_bind *phy_bind = NULL;
 +
 + list_for_each_entry(phy_bind, &phy_bind_list, list) {
 + if (!(strcmp(phy_bind->dev_name, dev_name(dev))) &&
 + phy_bind->index == index)
 + return phy_bind->phy;
 + }
 +
 + return ERR_PTR(-ENODEV);
 +}
 +
 +static struct phy *of_phy_lookup(struct device *dev, struct device_node 
 *node)
 +{
 + int index = 0;
 + struct phy  *phy;
>>>   ^^
>>>
>>> Please remove that stray space.
>>
>> Sure.
>>>
 + struct phy_bind *phy_map = NULL;
 +
 + list_for_each_entry(phy_map, &phy_bind_list, list)
 + if (!(strcmp(phy_map->dev_name, dev_name(dev
 + index++;
 +
 + list_for_each_entry(phy, &phy_list, head) {
 + if (node != phy->desc->of_node)
 + continue;
 +
 + phy_map = phy_bind(dev_name(dev), index, 
 dev_name(&phy->dev));
 + if (!IS_ERR(phy_map)) {
 + phy_map->phy = phy;
 + phy_map->auto_bind = true;
 + }
 +
 + return phy;
 + }
 +
 + return ERR_PTR(-ENODEV);
 +}
 +
 +/**
 + * devm_phy_get - lookup and obtain a reference to a phy.
 + * @dev: device that requests this phy
 + * @index: the index of the phy
 + *
 + * Gets the phy using phy_get(), and associates a device with it using
 + * devres. On driver detach, release function is invoked on the devres 
 data,
 + * then, devres data is freed.
 + */
 +struct phy *devm_phy_get(struct device *dev, u8 index)
 +{
 + struct phy **ptr, *phy;
 +
 + ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
 + if (!ptr)
 + return NULL;
 +
 + phy = phy_get(dev, index);
 + if (!IS_ERR(phy)) {
 + *ptr = phy;
 + devres_add(dev, ptr);
 + } else
 + devres_free(ptr);
>>>
>>> nitpick: when when if has { }, else should have, too.
>>
>> Sure.
>>>
 +
 + return phy;
 +}
 +EXPORT_SYMBOL_GPL(devm_phy_get);
 +
 +/**
 + * devm_phy_put - release the PHY
 + * @dev: device that wants to release this phy
 + * @phy: the phy returned by devm_phy_get()
 + *
 + * destroys the devres associated with this phy and invokes phy_put
 + * to release the phy.
 + */
 +void devm_phy_put(struct device

Re: removing the timer from cdc-ncm

[Oliver Neukum]

On Tuesday 25 September 2012 13:18:10 Alexey ORISHKO wrote:
> > -Original Message-
> > From: Oliver Neukum [mailto:oneu...@suse.de]
> > 
> > here is the patch that does everything I consider theoretically
> > necessary to have bundling of frames in usbnet and adapting cdc-ncm to
> > it.
> > 
> > I'd appreciate any review in case I am doing something stupid.
> > 
> 
> I had a brief look at cdc_ncm and a few corrections needed:
> - remove the following:
> #include 
> ...
> /* Restart the timer, if amount of datagrams is less than given value */
> #define   CDC_NCM_RESTART_TIMER_DATAGRAM_CNT  3
> #define   CDC_NCM_TIMER_PENDING_CNT   2
> #define CDC_NCM_TIMER_INTERVAL(400UL * NSEC_PER_USEC)
> ...
> In struct cdc_ncm_ctx {
> ...
>   struct hrtimer tx_timer;
>   struct tasklet_struct bh;
> ...
> 
> In cdc_ncm_unbind():
>   if (hrtimer_active(&ctx->tx_timer))
>   hrtimer_cancel(&ctx->tx_timer);
> 
>   tasklet_kill(&ctx->bh);

Roger

> I didn't have time to check the new logic for data path, but I've
> tried to run it on Ubuntu 12.04.
> Linux host got panic right after data path has been established
> (i.e. connected to mobile network). 

Thank you. Worse than I hoped, but not unexpected. I'll stare at the
code a bit.

Regards
Oliver

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

Re: Remote wakeup vs. hub suspend

[Peter Chen]

>> > For us to do this would be a little difficult.  System suspend is easy
>> > enough to handle because we don't actually need to put any external
>> > ports into suspend; the entire bus will go into global suspend when the
>> > root hub is suspended.  In fact, this is what we should be doing now
>> > (but we aren't).
>> >
>> Do you think is it OK to set ehci->no_selective_suspend = 1 for single
>> port controller?
>
> In general you should avoid setting that flag if possible.  Setting it
> would prevent the attached device from being runtime suspended.  But if
> that device is a hub, it wouldn't prevent the hub's children from being
> runtime suspended.
>
> The issue described in this email thread affects only external hubs,
> not root hubs.  It's perfectly okay to suspend an EHCI root hub while
> the ports are suspended -- in fact, the EHCI spec requires this.
>
>> Currently, both ehci_hub_control and ehci_bus_suspend will go bus suspend
>> routine when CONFIG_USB_SUSPEND is defined, and I am not sure if
>> PSE and ASE is cleared before we let bus go to suspend (at ehci_hub_control).
>
> Where does ehci_hub_control put the bus into suspend?  It suspends only
> individual ports, not the whole bus.
>
> If if there's only one port, suspending that port does not suspend the
> whole bus.  The frame counter continues to update and the root hub will
> continue to respond to URBs.
>

>From the code, the URB for roothub just read/write register portsc, it has not
traffic on usb bus.

Take my controller as an example, it is chipidea (Synopsis now) single
port controller,
this single port is just controller.

Set portsc.suspendM will stop the SOF, but frame counter will not stop
until phy clock is
disabled.

> 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 2/2] uas: fix gcc warning

[Gerd Hoffmann]

Streamline control flow so it is easier for gcc to follow which paths
can be taken and which can't.

Fixes "warning: 'cmdinfo' may be used uninitialized in this function"

Signed-off-by: Gerd Hoffmann 
---
 drivers/usb/storage/uas.c |   18 --
 1 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 4218701..98b98ee 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -249,16 +249,18 @@ static void uas_stat_cmplt(struct urb *urb)
cmnd = devinfo->cmnd;
else
cmnd = scsi_host_find_tag(shost, tag - 1);
+
if (!cmnd) {
-   if (iu->iu_id != IU_ID_RESPONSE) {
-   usb_free_urb(urb);
-   spin_unlock_irqrestore(&devinfo->lock, flags);
-   return;
+   if (iu->iu_id == IU_ID_RESPONSE) {
+   /* store results for uas_eh_task_mgmt() */
+   memcpy(&devinfo->response, iu, 
sizeof(devinfo->response));
}
-   } else {
-   cmdinfo = (void *)&cmnd->SCp;
+   usb_free_urb(urb);
+   spin_unlock_irqrestore(&devinfo->lock, flags);
+   return;
}
 
+   cmdinfo = (void *)&cmnd->SCp;
switch (iu->iu_id) {
case IU_ID_STATUS:
if (devinfo->cmnd == cmnd)
@@ -292,10 +294,6 @@ static void uas_stat_cmplt(struct urb *urb)
case IU_ID_WRITE_READY:
uas_xfer_data(urb, cmnd, SUBMIT_DATA_OUT_URB);
break;
-   case IU_ID_RESPONSE:
-   /* store results for uas_eh_task_mgmt() */
-   memcpy(&devinfo->response, iu, sizeof(devinfo->response));
-   break;
default:
scmd_printk(KERN_ERR, cmnd,
"Bogus IU (%d) received on status pipe\n", iu->iu_id);
-- 
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

[PATCH 1/2] uas: fix locking

[Gerd Hoffmann]

Forgot to unlock in the uas_eh_task_mgmt error paths.

Signed-off-by: Gerd Hoffmann 
---
 drivers/usb/storage/uas.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 1578909..4218701 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -649,12 +649,14 @@ static int uas_eh_task_mgmt(struct scsi_cmnd *cmnd,
shost_printk(KERN_INFO, shost,
 "%s: %s: submit sense urb failed\n",
 __func__, fname);
+   spin_unlock_irqrestore(&devinfo->lock, flags);
return FAILED;
}
if (uas_submit_task_urb(cmnd, GFP_ATOMIC, function, tag)) {
shost_printk(KERN_INFO, shost,
 "%s: %s: submit task mgmt urb failed\n",
 __func__, fname);
+   spin_unlock_irqrestore(&devinfo->lock, flags);
return FAILED;
}
spin_unlock_irqrestore(&devinfo->lock, flags);
-- 
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

Re: [PATCH v6 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg

[Praveen Paneri]

On Tue, Sep 25, 2012 at 4:59 PM, Marc Kleine-Budde  wrote:
> On 09/24/2012 11:38 AM, Praveen Paneri wrote:
>> Hi Kishon, Felipe,
>>
>> Any further comments on these patches? Can they be merged now?
>
> One nitpick inline.
>
> Marc
>>
>> Thanks,
>> Praveen
>>
>> On Mon, Sep 17, 2012 at 6:24 PM, Praveen Paneri  wrote:
>>> This driver uses usb_phy interface to interact with s3c-hsotg. Supports
>>> phy_init and phy_shutdown functions to enable/disable phy. Tested with
>>> smdk6410 and smdkv310. More SoCs can be brought under later.
>>>
>>> Signed-off-by: Praveen Paneri 
>>> Acked-by: Heiko Stuebner 
>>> ---
>>>  .../devicetree/bindings/usb/samsung-usbphy.txt |9 +
>>>  drivers/usb/phy/Kconfig|8 +
>>>  drivers/usb/phy/Makefile   |1 +
>>>  drivers/usb/phy/samsung-usbphy.c   |  360 
>>> 
>>>  include/linux/platform_data/samsung-usbphy.h   |   27 ++
>>>  5 files changed, 405 insertions(+), 0 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>>>  create mode 100644 drivers/usb/phy/samsung-usbphy.c
>>>  create mode 100644 include/linux/platform_data/samsung-usbphy.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt 
>>> b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>>> new file mode 100644
>>> index 000..fefd9c8
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>>> @@ -0,0 +1,9 @@
>>> +* Samsung's usb phy transceiver
>>> +
>>> +The Samsung's phy transceiver is used for controlling usb otg phy for
>>> +s3c-hsotg usb device controller.
>>> +
>>> +Required properties:
>>> +- compatible : should be "samsung,exynos4210-usbphy"
>>> +- reg : base physical address of the phy registers and length of memory 
>>> mapped
>>> +   region.
>>> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
>>> index 63c339b..313685f 100644
>>> --- a/drivers/usb/phy/Kconfig
>>> +++ b/drivers/usb/phy/Kconfig
>>> @@ -32,3 +32,11 @@ config MV_U3D_PHY
>>> help
>>>   Enable this to support Marvell USB 3.0 phy controller for Marvell
>>>   SoC.
>>> +
>>> +config SAMSUNG_USBPHY
>>> +   bool "Samsung USB PHY controller Driver"
>>> +   depends on USB_S3C_HSOTG
>>> +   select USB_OTG_UTILS
>>> +   help
>>> + Enable this to support Samsung USB phy controller for samsung
>>> + SoCs.
>>> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
>>> index b069f29..55dcfc1 100644
>>> --- a/drivers/usb/phy/Makefile
>>> +++ b/drivers/usb/phy/Makefile
>>> @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o
>>>  obj-$(CONFIG_USB_ISP1301)  += isp1301.o
>>>  obj-$(CONFIG_MV_U3D_PHY)   += mv_u3d_phy.o
>>>  obj-$(CONFIG_USB_EHCI_TEGRA)   += tegra_usb_phy.o
>>> +obj-$(CONFIG_SAMSUNG_USBPHY)   += samsung-usbphy.o
>>> diff --git a/drivers/usb/phy/samsung-usbphy.c 
>>> b/drivers/usb/phy/samsung-usbphy.c
>>> new file mode 100644
>>> index 000..95ec4d0
>>> --- /dev/null
>>> +++ b/drivers/usb/phy/samsung-usbphy.c
>>> @@ -0,0 +1,360 @@
>>> +/* linux/drivers/usb/phy/samsung-usbphy.c
>>> + *
>>> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
>>> + *  http://www.samsung.com
>>> + *
>>> + * Author: Praveen Paneri 
>>> + *
>>> + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG 
>>> controller
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +/* Register definitions */
>>> +
>>> +#define S3C_PHYPWR (0x00)
>>> +
>>> +#define S3C_PHYPWR_NORMAL_MASK (0x19 << 0)
>>> +#define S3C_PHYPWR_OTG_DISABLE (1 << 4)
>>> +#define S3C_PHYPWR_ANALOG_POWERDOWN(1 << 3)
>>> +#define S3C_PHYPWR_FORCE_SUSPEND   (1 << 1)
>>> +/* For Exynos4 */
>>> +#define EXYNOS4_PHYPWR_NORMAL_MASK (0x39 << 0)
>>> +#define EXYNOS4_PHYPWR_SLEEP   (1 << 5)
>>> +
>>> +#define S3C_PHYCLK (0x04)
>>> +
>>> +#define S3C_PHYCLK_MODE_SERIAL (1 << 6)
>>> +#define S3C_PHYCLK_EXT_OSC (1 << 5)
>>> +#define S3C_PHYCLK_COMMON_ON_N (1 << 4)
>>> +#define S3C_PHYCLK_ID_PULL (1 << 2)
>>> +#define S3C_PHYCLK_CLKSEL_MASK (0x3 << 0)
>>> +#defi

Loading CDC composite device ACM and MassStorage: g_acm_ms failed

[i...@bastian-ruppert.de]

Hello,

i have a problem with the composite gadget g_acm_ms (serial and mass
storage).
The kernel is pretty up to date : Linux 3.6.0-rc7.
The architecture is arm davinci omap-l138 on a custom board.

Using the g_mass_storage driver with:
modprobe g_mass_storage file=/mnt/userdata/gadgetfile removable=1
stall=0 ro=0
is working as expected.

Also the g_serial gadget is working.

Trying to use the g_acm_ms gadget failed:

modprobe g_acm_ms file=/mnt/userdata/gadgetfile removable=1 stall=0
ro=0

-bash-3.2# [ 1633.383021]  gadget: common->fsg is NULL in fsg_setup at
534
[ 1633.388716] [ cut here ]
[ 1633.393455] WARNING: at drivers/usb/gadget/f_mass_storage.c:380
fsg_setup+0x6c/0x164 [g_acm_ms]()
[..]

looking in the source code in drivers/usb/gadget/f_mass_storage.c

if (!fsg_is_set(fsg->common))
return -EOPNOTSUPP;

fsg->common seems not to be set up properly.

What is the way to bring up the g_acm_ms gadget, am i missing some
parameters?
Is anybody using successful this gadget, or facing the same problems?

Thank you,

Bastian Ruppert.


P.S. see the full output:

-bash-3.2# [ 1633.383021]  gadget: common->fsg is NULL in fsg_setup at
534
[ 1633.388716] [ cut here ]
[ 1633.393455] WARNING: at drivers/usb/gadget/f_mass_storage.c:380
fsg_setup+0x6c/0x164 [g_acm_ms]()
[ 1633.402312] Modules linked in: g_acm_ms dsplinkk(O) [last unloaded:
g_serial]
[ 1633.409622] [] (unwind_backtrace+0x0/0xf0) from
[] (warn_slowpath_common+0x4c/0x64)
[ 1633.419065] [] (warn_slowpath_common+0x4c/0x64) from
[] (warn_slowpath_null+0x1c/0x24)
[ 1633.428814] [] (warn_slowpath_null+0x1c/0x24) from
[] (fsg_setup+0x6c/0x164 [g_acm_ms])
[ 1633.438689] [] (fsg_setup+0x6c/0x164 [g_acm_ms]) from
[] (composite_setup+0xa70/0xbc4 [g_acm_ms])
[ 1633.449378] [] (composite_setup+0xa70/0xbc4 [g_acm_ms])
from [] (musb_g_ep0_irq+0x87c/0x94c)
[ 1633.459573] [] (musb_g_ep0_irq+0x87c/0x94c) from
[] (musb_interrupt+0x768/0x87c)
[ 1633.468734] [] (musb_interrupt+0x768/0x87c) from
[] (da8xx_musb_interrupt+0x160/0x218)
[ 1633.478412] [] (da8xx_musb_interrupt+0x160/0x218) from
[] (handle_irq_event_percpu+0x34/0x1a8)
[ 1633.488777] [] (handle_irq_event_percpu+0x34/0x1a8) from
[] (handle_irq_event+0x54/0x78)
[ 1633.498623] [] (handle_irq_event+0x54/0x78) from
[] (handle_edge_irq+0x114/0x154)
[ 1633.507861] [] (handle_edge_irq+0x114/0x154) from
[] (generic_handle_irq+0x28/0x30)
[ 1633.517272] [] (generic_handle_irq+0x28/0x30) from
[] (handle_IRQ+0x64/0x8c)
[ 1633.526074] [] (handle_IRQ+0x64/0x8c) from []
(__irq_svc+0x38/0x84)
[ 1633.534123] [] (__irq_svc+0x38/0x84) from []
(cpuidle_wrap_enter+0x54/0xac)
[ 1633.542856] [] (cpuidle_wrap_enter+0x54/0xac) from
[] (cpuidle_enter_state+0x18/0x70)
[ 1633.552448] [] (cpuidle_enter_state+0x18/0x70) from
[] (cpuidle_idle_call+0x94/0xdc)
[ 1633.561949] [] (cpuidle_idle_call+0x94/0xdc) from
[] (cpu_idle+0x78/0xe8)
[ 1633.570503] [] (cpu_idle+0x78/0xe8) from []
(start_kernel+0x2c8/0x330)
[ 1633.578758] ---[ end trace cd3ef2a2e2e7426f ]---
[ 1633.583830]  gadget: common->fsg is NULL in fsg_setup at 534
[ 1633.589513] [ cut here ]
[ 1633.594243] WARNING: at drivers/usb/gadget/f_mass_storage.c:380
fsg_setup+0x6c/0x164 [g_acm_ms]()
[ 1633.603100] Modules linked in: g_acm_ms dsplinkk(O) [last unloaded:
g_serial]
[ 1633.610399] [] (unwind_backtrace+0x0/0xf0) from
[] (warn_slowpath_common+0x4c/0x64)
[ 1633.619838] [] (warn_slowpath_common+0x4c/0x64) from
[] (warn_slowpath_null+0x1c/0x24)
[ 1633.629591] [] (warn_slowpath_null+0x1c/0x24) from
[] (fsg_setup+0x6c/0x164 [g_acm_ms])
[ 1633.639463] [] (fsg_setup+0x6c/0x164 [g_acm_ms]) from
[] (composite_setup+0xa70/0xbc4 [g_acm_ms])
[ 1633.650152] [] (composite_setup+0xa70/0xbc4 [g_acm_ms])
from [] (musb_g_ep0_irq+0x87c/0x94c)
[ 1633.660351] [] (musb_g_ep0_irq+0x87c/0x94c) from
[] (musb_interrupt+0x768/0x87c)
[ 1633.669508] [] (musb_interrupt+0x768/0x87c) from
[] (da8xx_musb_interrupt+0x160/0x218)
[ 1633.679187] [] (da8xx_musb_interrupt+0x160/0x218) from
[] (handle_irq_event_percpu+0x34/0x1a8)
[ 1633.689545] [] (handle_irq_event_percpu+0x34/0x1a8) from
[] (handle_irq_event+0x54/0x78)
[ 1633.699385] [] (handle_irq_event+0x54/0x78) from
[] (handle_edge_irq+0x114/0x154)
[ 1633.708621] [] (handle_edge_irq+0x114/0x154) from
[] (generic_handle_irq+0x28/0x30)
[ 1633.718029] [] (generic_handle_irq+0x28/0x30) from
[] (handle_IRQ+0x64/0x8c)
[ 1633.726829] [] (handle_IRQ+0x64/0x8c) from []
(__irq_svc+0x38/0x84)
[ 1633.734874] [] (__irq_svc+0x38/0x84) from []
(__slab_free+0x8/0x2c8)
[ 1633.742997] [] (__slab_free+0x8/0x2c8) from []
(0xc05d7d7c)
[ 1633.750301] ---[ end trace cd3ef2a2e2e74270 ]---
[ 1633.755481]  gadget: common->fsg is NULL in fsg_setup at 534
[ 1633.761166] [ cut here ]
[ 1633.765897] WARNING: at drivers/usb/gadget/f_mass_storage.c:380
fsg_setup+0x6c/0x164 [g_acm_ms]()
[ 1633.774754] Modules linked in: g_acm_ms dsplinkk(O) [last unloaded:
g_serial]
[ 1633.782060] []

Re: [PATCH v6 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg

[Praveen Paneri]

Hi,

On Tue, Sep 25, 2012 at 6:47 PM, ABRAHAM, KISHON VIJAY  wrote:
> Hi,
>
> On Tue, Sep 25, 2012 at 5:48 PM, Rob Herring  wrote:
>> On 09/25/2012 06:23 AM, Praveen Paneri wrote:
>>> Hi Rob,
>>>
>>> On Mon, Sep 24, 2012 at 6:34 PM, Rob Herring  wrote:
 On 09/17/2012 07:54 AM, Praveen Paneri wrote:
> This driver uses usb_phy interface to interact with s3c-hsotg. Supports
> phy_init and phy_shutdown functions to enable/disable phy. Tested with
> smdk6410 and smdkv310. More SoCs can be brought under later.
>
> Signed-off-by: Praveen Paneri 
> Acked-by: Heiko Stuebner 
> ---
>  .../devicetree/bindings/usb/samsung-usbphy.txt |9 +
>  drivers/usb/phy/Kconfig|8 +
>  drivers/usb/phy/Makefile   |1 +
>  drivers/usb/phy/samsung-usbphy.c   |  360 
> 
>  include/linux/platform_data/samsung-usbphy.h   |   27 ++
>  5 files changed, 405 insertions(+), 0 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>  create mode 100644 drivers/usb/phy/samsung-usbphy.c
>  create mode 100644 include/linux/platform_data/samsung-usbphy.h
>
> diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt 
> b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> new file mode 100644
> index 000..fefd9c8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> @@ -0,0 +1,9 @@
> +* Samsung's usb phy transceiver
> +
> +The Samsung's phy transceiver is used for controlling usb otg phy for
> +s3c-hsotg usb device controller.
> +
> +Required properties:
> +- compatible : should be "samsung,exynos4210-usbphy"
> +- reg : base physical address of the phy registers and length of memory 
> mapped
> + region.

 What's missing here is describing the connection of phys to host
 controllers. We've got several people adding usb phy bindings and need
 to define them in a common way.
>>> yes! it just covers the generic binding. I will update it accordingly
>>> as the generic phy framework takes its final shape.
>>
>> That sounds like the wrong way to define a binding... Figuring out how
>> to describe the h/w should not be dependent on changes in the kernel.
>> Bindings are an ABI and should not be evolving.
But since Kishon is getting the generic bindings ready, I can use them
when those are ready. So do we need to hold the merge of this patch
until then?

Thanks,
Praveen
>
> There can be multiple ways to define the binding. For e.g. We
> discussed few ways of binding the phys to the controller
>
> controller {
>   phy0 = <&phandle1_name>;
>   phy1 = <&phandle2_name>;
> }
>
> phy0 and phy1 are any name given to obtain a reference to the phy and
> the controller should send the phandle name like
> get_phy_by_phandle("phy0");. Then we thought of standardizing that
> name.
>
> and then finally we settled on something like this
> controller {
>   phy = <&phandle0_name>, <&phandle1_name>;
> }
> so that controller can obtain a reference to the PHY using
> *of_phy_get(struct device *dev, const char *phandle, u8 index)*
>
> Thanks
> Kishon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> 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