Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

>> > That's right.  Interrupts can occur at almost any time (on
>> > multiprocessor systems they can occur even when interrupts are disabled
>> > on some of the CPUs).
>>
>> I am confused. I add the spinlock functions to kagen2_ep_queue function.
>>
>>   spin_lock_irqsave(&dev->lock, flags);
>>   ..
>>   spin_unlock_irqrestore(&dev->lock, flags);
>>
>> When kagen2_ep_queue function is called, the error "BUG: scheduling
>> while atomic: swapper/0/0x0002" occurs. I test the same spinlock
>> functions in other device module. It is ok in other device module.
>
> While the function holds a spinlock, it is not allowed to sleep.
>
> The BUG occurs because kagen2_ep_queue must call some function that can
> sleep.  But since you did not provide the rest of the BUG message
> (including the stack trace), I can't tell what function it calls.

The "BUG: scheduling while atomic" is solved. Need to add extra
spinlock functions for req->complete() as below:
spin_unlock(&dev->lock);
req->complete(ep, req);
spin_lock(&dev->lock);

Now, the SCSI_WRITE_10 command is received but the data is not
received. There is disconnect or port reset after SCSI_WRITE_10
command. Please see below:

[start_transfer] 613e2d71 61757463
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 f6 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 01 00 00 01 00 00 00 00 80 b7 21
EP1 OUT IRQ 0x28
g_file_storage gadget: disconnect or port reset
g_file_storage gadget: SCSI command: WRITE(10);  Dc=10, Do=512;  Hc=10, Ho=512
[start_transfer] 43425355 f6
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: do_scsi_command
unlink (ep1) pio
kagen2_set_halt 1 0
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete --> 0, 0/512
g_file_storage gadget: reset config
g_file_storage gadget: reset interface
g_file_storage gadget: handle_exception


"g_file_storage gadget: do_scsi_command" is from extra DBG statement
that i added in file_storage.c.

if (do_scsi_command(fsg) || finish_reply(fsg))
{
DBG(fsg, "do_scsi_command\n");
continue;
}

thanks,
victor
--
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 RESEND 4/4] usb: tilegx: fix memleak when create hcd fail

[Libo Chen]

When usb_create_hcd fail, we should call gxio_usb_host_destroy

Signed-off-by: Libo Chen 
---
 drivers/usb/host/ohci-tilegx.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ohci-tilegx.c b/drivers/usb/host/ohci-tilegx.c
index 1ae7b28..5888fc4 100644
--- a/drivers/usb/host/ohci-tilegx.c
+++ b/drivers/usb/host/ohci-tilegx.c
@@ -112,8 +112,10 @@ static int ohci_hcd_tilegx_drv_probe(struct 
platform_device *pdev)
 
hcd = usb_create_hcd(&ohci_tilegx_hc_driver, &pdev->dev,
 dev_name(&pdev->dev));
-   if (!hcd)
-   return -ENOMEM;
+   if (!hcd){
+   ret = -ENOMEM;
+   goto err_hcd;
+   }
 
/*
 * We don't use rsrc_start to map in our registers, but seems like
@@ -165,6 +167,7 @@ err_have_irq:
 err_no_irq:
tilegx_stop_ohc();
usb_put_hcd(hcd);
+err_hcd:
gxio_usb_host_destroy(&pdata->usb_ctx);
return ret;
 }
-- 
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 RESEND 0/4] usb: fix four memleak

[Libo Chen]

change address from "Libo Chen "  to "Libo Chen 
"

fix four goto wrong tag, avoid memleak 

Libo Chen (4):
  usb: ehci-s5p: fix memleak when devm_usb_get_phy fail
  usb: isp1760-if: fix memleak when platform_get_resource fail
  usb: ohci: fix goto wrong tag in err case
  usb: tilegx: fix memleak when create hcd fail

 drivers/usb/host/ehci-s5p.c|1 +
 drivers/usb/host/isp1760-if.c  |4 +++-
 drivers/usb/host/ohci-nxp.c|   12 ++--
 drivers/usb/host/ohci-tilegx.c |7 +--
 4 files changed, 15 insertions(+), 9 deletions(-)


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

[PATCH RESEND 2/4] usb: isp1760-if: fix memleak when platform_get_resource fail

[Libo Chen]

When platform_get_resource fail, we should release_mem_region

Signed-off-by: Libo Chen 
---
 drivers/usb/host/isp1760-if.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/host/isp1760-if.c b/drivers/usb/host/isp1760-if.c
index bbb791b..a13709e 100644
--- a/drivers/usb/host/isp1760-if.c
+++ b/drivers/usb/host/isp1760-if.c
@@ -373,8 +373,10 @@ static int isp1760_plat_probe(struct platform_device *pdev)
irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!irq_res) {
pr_warning("isp1760: IRQ resource not available\n");
-   return -ENODEV;
+   ret = -ENODEV;
+   goto cleanup;
}
+
irqflags |= irq_res->flags & IRQF_TRIGGER_MASK;
 
if (priv) {
-- 
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 RESEND 1/4] usb: ehci-s5p: fix memleak when devm_usb_get_phy fail

[Libo Chen]

When devm_usb_get_phy fail, we should free hcd

Signed-off-by: Libo Chen 
---
 drivers/usb/host/ehci-s5p.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 6357752..3fbab58 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -107,6 +107,7 @@ static int s5p_ehci_probe(struct platform_device *pdev)
if (IS_ERR(phy)) {
/* Fallback to pdata */
if (!pdata) {
+   usb_put_hcd(hcd);
dev_warn(&pdev->dev, "no platform data or transceiver 
defined\n");
return -EPROBE_DEFER;
} else {
-- 
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 RESEND 3/4] usb: ohci: fix goto wrong tag in err case

[Libo Chen]

fix goto wrong tag in usb_hcd_nxp_probe

Signed-off-by: Libo Chen 
---
 drivers/usb/host/ohci-nxp.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/ohci-nxp.c b/drivers/usb/host/ohci-nxp.c
index f4988fb..eb294a9 100644
--- a/drivers/usb/host/ohci-nxp.c
+++ b/drivers/usb/host/ohci-nxp.c
@@ -234,7 +234,7 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
if (usb_disabled()) {
dev_err(&pdev->dev, "USB is disabled\n");
ret = -ENODEV;
-   goto out;
+   goto out1;
}
 
/* Enable AHB slave USB clock, needed for further USB clock control */
@@ -265,13 +265,13 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
if (IS_ERR(usb_dev_clk)) {
dev_err(&pdev->dev, "failed to acquire USB DEV Clock\n");
ret = PTR_ERR(usb_dev_clk);
-   goto out4;
+   goto out3;
}
 
ret = clk_enable(usb_dev_clk);
if (ret < 0) {
dev_err(&pdev->dev, "failed to start USB DEV Clock\n");
-   goto out5;
+   goto out4;
}
 
/* Enable USB otg clocks */
@@ -279,7 +279,7 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
if (IS_ERR(usb_otg_clk)) {
dev_err(&pdev->dev, "failed to acquire USB DEV Clock\n");
ret = PTR_ERR(usb_otg_clk);
-   goto out6;
+   goto out5;
}
 
__raw_writel(__raw_readl(USB_CTRL) | USB_HOST_NEED_CLK_EN, USB_CTRL);
@@ -287,7 +287,7 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
ret = clk_enable(usb_otg_clk);
if (ret < 0) {
dev_err(&pdev->dev, "failed to start USB DEV Clock\n");
-   goto out7;
+   goto out6;
}
 
isp1301_configure();
@@ -296,7 +296,7 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
if (!hcd) {
dev_err(&pdev->dev, "Failed to allocate HC buffer\n");
ret = -ENOMEM;
-   goto out8;
+   goto out7;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-- 
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 3/4] usb: ohci: fix goto wrong tag in err case

[Libo Chen]

From: Libo Chen 

fix goto wrong tag in usb_hcd_nxp_probe

Signed-off-by: Libo Chen 
---
 drivers/usb/host/ohci-nxp.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/ohci-nxp.c b/drivers/usb/host/ohci-nxp.c
index f4988fb..eb294a9 100644
--- a/drivers/usb/host/ohci-nxp.c
+++ b/drivers/usb/host/ohci-nxp.c
@@ -234,7 +234,7 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
if (usb_disabled()) {
dev_err(&pdev->dev, "USB is disabled\n");
ret = -ENODEV;
-   goto out;
+   goto out1;
}
 
/* Enable AHB slave USB clock, needed for further USB clock control */
@@ -265,13 +265,13 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
if (IS_ERR(usb_dev_clk)) {
dev_err(&pdev->dev, "failed to acquire USB DEV Clock\n");
ret = PTR_ERR(usb_dev_clk);
-   goto out4;
+   goto out3;
}
 
ret = clk_enable(usb_dev_clk);
if (ret < 0) {
dev_err(&pdev->dev, "failed to start USB DEV Clock\n");
-   goto out5;
+   goto out4;
}
 
/* Enable USB otg clocks */
@@ -279,7 +279,7 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
if (IS_ERR(usb_otg_clk)) {
dev_err(&pdev->dev, "failed to acquire USB DEV Clock\n");
ret = PTR_ERR(usb_otg_clk);
-   goto out6;
+   goto out5;
}
 
__raw_writel(__raw_readl(USB_CTRL) | USB_HOST_NEED_CLK_EN, USB_CTRL);
@@ -287,7 +287,7 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
ret = clk_enable(usb_otg_clk);
if (ret < 0) {
dev_err(&pdev->dev, "failed to start USB DEV Clock\n");
-   goto out7;
+   goto out6;
}
 
isp1301_configure();
@@ -296,7 +296,7 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
if (!hcd) {
dev_err(&pdev->dev, "Failed to allocate HC buffer\n");
ret = -ENOMEM;
-   goto out8;
+   goto out7;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-- 
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/4] usb: ehci-s5p: fix memleak when fallback to pdata

[Libo Chen]

From: Libo Chen 

When devm_usb_get_phy fail, we should free hcd

Signed-off-by: Libo Chen 
---
 drivers/usb/host/ehci-s5p.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 6357752..3fbab58 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -107,6 +107,7 @@ static int s5p_ehci_probe(struct platform_device *pdev)
if (IS_ERR(phy)) {
/* Fallback to pdata */
if (!pdata) {
+   usb_put_hcd(hcd);
dev_warn(&pdev->dev, "no platform data or transceiver 
defined\n");
return -EPROBE_DEFER;
} else {
-- 
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 4/4] usb: tilegx: fix memleak when create hcd fail

[Libo Chen]

From: Libo Chen 

When usb_create_hcd fail, we should call gxio_usb_host_destroy

Signed-off-by: Libo Chen 
---
 drivers/usb/host/ohci-tilegx.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ohci-tilegx.c b/drivers/usb/host/ohci-tilegx.c
index 1ae7b28..5888fc4 100644
--- a/drivers/usb/host/ohci-tilegx.c
+++ b/drivers/usb/host/ohci-tilegx.c
@@ -112,8 +112,10 @@ static int ohci_hcd_tilegx_drv_probe(struct 
platform_device *pdev)
 
hcd = usb_create_hcd(&ohci_tilegx_hc_driver, &pdev->dev,
 dev_name(&pdev->dev));
-   if (!hcd)
-   return -ENOMEM;
+   if (!hcd){
+   ret = -ENOMEM;
+   goto err_hcd;
+   }
 
/*
 * We don't use rsrc_start to map in our registers, but seems like
@@ -165,6 +167,7 @@ err_have_irq:
 err_no_irq:
tilegx_stop_ohc();
usb_put_hcd(hcd);
+err_hcd:
gxio_usb_host_destroy(&pdata->usb_ctx);
return ret;
 }
-- 
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 2/4] usb: isp1760-if: fix memleak when platform_get_resource fail

[Libo Chen]

From: Libo Chen 

When platform_get_resource fail, we should release_mem_region

Signed-off-by: Libo Chen 
---
 drivers/usb/host/isp1760-if.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/host/isp1760-if.c b/drivers/usb/host/isp1760-if.c
index bbb791b..a13709e 100644
--- a/drivers/usb/host/isp1760-if.c
+++ b/drivers/usb/host/isp1760-if.c
@@ -373,8 +373,10 @@ static int isp1760_plat_probe(struct platform_device *pdev)
irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!irq_res) {
pr_warning("isp1760: IRQ resource not available\n");
-   return -ENODEV;
+   ret = -ENODEV;
+   goto cleanup;
}
+
irqflags |= irq_res->flags & IRQF_TRIGGER_MASK;
 
if (priv) {
-- 
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 0/4] usb: fix four memleak

[Libo Chen]

fix four goto wrong tag, avoid memleak 

Libo Chen (4):
  usb: ehci-s5p: fix memleak when fallback to pdata
  usb: isp1760-if: fix memleak when platform_get_resource fail
  usb: ohci: fix goto wrong tag in err case
  usb: tilegx: fix memleak when create hcd fail

 drivers/usb/host/ehci-s5p.c|1 +
 drivers/usb/host/isp1760-if.c  |4 +++-
 drivers/usb/host/ohci-nxp.c|   12 ++--
 drivers/usb/host/ohci-tilegx.c |7 +--
 4 files changed, 15 insertions(+), 9 deletions(-)


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

Re: undefined reference to `usb_gadget_unmap_request' regression

[Peter Chen]

We met similar problem at chipidea. I give a patch, but maybe there
can be improved.

http://marc.info/?l=linux-usb&m=136804273919518&w=2

On Thu, May 9, 2013 at 12:34 AM, Vivek Gautam  wrote:
> Hi Felipe,
>
> Commit 388e5c51135f817f01177c42261f1116a6d7f2ad usb: dwc3: remove dwc3
> dependency on host AND gadget
> by me breaks compilation when USB_DWC3=y, USB=y but USB_GADGET=m,
> additionally when either of USB_DWC3_GADGET=y or USB_DWC3_DUAL_ROLE=y   :-(
>
> I had some confusion with this actually.
>
> We started with making USB_DWC3 independent of USB and USB_GADGET.
> Thereby added some helping configs USB_DWC3_HOST, USB_DWC3_GADGET and
> USB_DWC3_DUAL_ROLE.
> Now when USB_GADGET=m and USB=y; USB_DWC3=y
> Now, USB_DWC3_DUAL_ROLE=y or USB_DWC3_GADGET=y will make things worse, since
> it will compile
> dwc3/gadget.c and dwc3/ep0.c
> This lets the compilation to break since usb/gadget/** is still compiling as
> module.
> But the errors it throws for functions are already exported with
> EXPORT_SYMBOL_GPL(), then why these errors then.
>
> A possible flaw with this could be that "USB_DWC3_HOST, USB_DWC3_GADGET and
> USB_DWC3_DUAL_ROLE"
> are still 'bool' type configs. But making this as 'tristate' too doesn't
> makes our life easier.
> Ideally dwc3/gadget.c and dwc3/ep0.c should be compiling as modules when
> USB_GADGET=m.
> But then we have functions like dwc3_host_init() and dwc3_gadget_init() and
> other similar functions in dwc3/core.c which give
> compilation break.
>
> Help please  :-)
>
>
> Thanks
> Vivek
> --
> 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



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

Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'

[Joe Rayhawk]

On Tue, Apr 23, 2013 at 05:09:35PM +0200, Clemens Ladisch wrote:
> Alan Stern wrote:
> > On Tue, 23 Apr 2013, Clemens Ladisch wrote:
> >> Why is having a queue of two URB with one packet each suddenly not
> >> allowed?
> >
> > It _is_ allowed when URB_ISO_ASAP is clear.  I have never fully
> > understood why the audio driver sets that flag.  By setting it, you are
> > telling the host controller driver that you are willing to give up
> > reduced latency in order to avoid underruns.
> 
> This flag was needed to avoid having to set urb->start_frame.
> 
> With the changed queueing API, the audio driver needs to change too.
> I'll look into this ...

For what it's worth, the following -stable patch

"ALSA: USB: adjust for changed 3.8 USB API"
c75c5ab575af7db707689cdbb5a5c458e9a034bb

fixes the discontinuous playback on period sizes between 139 and 192,
but the discontinuous playback on period sizes between 48 and 138 has
been replaced by rather worse kernel blocking and kernel errors:

jrayhawk@richardiv:~$ sudo tail -F -n 0 /var/log/kern.log &
[1] 4490
jrayhawk@richardiv:~$ time perl -e 'print pack "H*", "00FF" x 2048' | aplay 
--period-size=192 -r 48000 -f S16_LE -c2 -D hw:0,0
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

real0m0.053s
user0m0.008s
sys 0m0.000s
jrayhawk@richardiv:~$ time perl -e 'print pack "H*", "00FF" x 2048' | aplay 
--period-size=48 -r 48000 -f S16_LE -c2 -D hw:0,0
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
May  8 17:01:56 richardiv kernel: [ 1680.923474] cannot submit urb (err = -18)
May  8 17:01:56 richardiv kernel: [ 1680.924472] cannot submit urb (err = -18)

real0m10.023s
user0m0.008s
sys 0m0.004s


signature.asc
Description: Digital signature

[PATCH v7 3/3] ARM: shmobile: BOCK-W: add USB support

[Sergei Shtylyov]

Register the USB PHY device from bockw_init(), passing the platform  data to it.
Set machine's init_late() method to r8a7778_init_late() in order for [EO]HCI to
get registered too...

Don't forget to add USB PENC0/1 pins to bockw_pinctrl_map[].

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov 

---
Changes since version 6:
- added USB PENC0/1 pins to bockw_pinctrl_map[].

Changes since version 4:
- annotated 'usb_phy_platform_data' as '__initdata' since it's kmemdup()'ed
  while registering the platform device anyway;
- refreshed the patch.

Changes since version 3:
- removed initializer for 'usb_phy_platform_data' letting it be set to all 0s;
- refreshed the patch.

Changes since version 2:
- refreshed the patch.

Changes since the original posting:
- removed initializer for no longer existing field in 'usb_phy_platform_data',
  modified the comment to the 'ferrite_bead' field initializer.

 arch/arm/mach-shmobile/board-bockw.c |8 
 1 file changed, 8 insertions(+)

Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -63,6 +63,8 @@ static struct sh_mobile_sdhi_info sdhi0_
.tmio_flags = TMIO_MMC_HAS_IDLE_WAIT,
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data __initdata;
+
 static const struct pinctrl_map bockw_pinctrl_map[] = {
/* SCIF0 */
PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a7778",
@@ -78,6 +80,10 @@ static const struct pinctrl_map bockw_pi
  "sdhi0_data4", "sdhi0"),
PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7778",
  "sdhi0_wp", "sdhi0"),
+   PIN_MAP_MUX_GROUP_DEFAULT("ehci-platform", "pfc-r8a7778",
+ "usb0", "usb0"),
+   PIN_MAP_MUX_GROUP_DEFAULT("ehci-platform", "pfc-r8a7778",
+ "usb1", "usb1"),
 };
 
 #define FPGA   0x1820
@@ -91,6 +97,7 @@ static void __init bockw_init(void)
r8a7778_clock_init();
r8a7778_init_irq_extpin(1);
r8a7778_add_standard_devices();
+   r8a7778_add_usb_phy_device(&usb_phy_platform_data);
 
pinctrl_register_mappings(bockw_pinctrl_map,
  ARRAY_SIZE(bockw_pinctrl_map));
@@ -146,4 +153,5 @@ DT_MACHINE_START(BOCKW_DT, "bockw")
.init_machine   = bockw_init,
.init_time  = shmobile_timer_init,
.dt_compat  = bockw_boards_compat_dt,
+   .init_late  = r8a7778_init_late,
 MACHINE_END
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 2/3] ARM: shmobile: r8a7778: add USB support

[Sergei Shtylyov]

Add USB clock and EHCI, OHCI, and USB PHY platform devices for R8A7778 SoC;  add
a function to register PHY device with board-specific platform data and register
EHCI and OHCI platfrom devices from the init_late() board method.

Also,  don't forget to enable CONFIG_ARCH_HAS_[EO]HCI options for R8A7778 SoC in
Kconfig...

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov 

---
Changes since version 5:
- renamed the R-Car PHY driver header file in #include.

Changes since version 4:
- annotated USB resources and '[eo]hci_info' as '__initdata' since they're
  kmemdup()'ed while registering the platform devices anyway;
- refreshed the patch.

Changes since version 3:
- resolved reject in the 'clock-r8a7778.c' file, refreshed the patch.

Changes since version 2:
- refreshed the patch.

Changes since the original posting:
- resolved rejects in the 'clock-r8a7778.c' file;
- lowercased the SoC name in the subject.

 arch/arm/mach-shmobile/Kconfig|2 
 arch/arm/mach-shmobile/clock-r8a7778.c|4 
 arch/arm/mach-shmobile/include/mach/r8a7778.h |3 
 arch/arm/mach-shmobile/setup-r8a7778.c|  108 ++
 4 files changed, 117 insertions(+)

Index: renesas/arch/arm/mach-shmobile/Kconfig
===
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -41,6 +41,8 @@ config ARCH_R8A7778
select CPU_V7
select SH_CLK_CPG
select ARM_GIC
+   select USB_ARCH_HAS_EHCI
+   select USB_ARCH_HAS_OHCI
 
 config ARCH_R8A7779
bool "R-Car H1 (R8A77790)"
Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -105,6 +105,7 @@ static struct clk *main_clks[] = {
 enum {
MSTP323, MSTP322, MSTP321,
MSTP114,
+   MSTP100,
MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
MSTP016, MSTP015,
MSTP_NR };
@@ -114,6 +115,7 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP322] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 22, 0), /* SDHI1 */
[MSTP321] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 21, 0), /* SDHI2 */
[MSTP114] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 14, 0), /* Ether */
+   [MSTP100] = SH_CLK_MSTP32(&p_clk, MSTPCR1,  0, 0), /* USB0/1 */
[MSTP026] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 26, 0), /* SCIF0 */
[MSTP025] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 25, 0), /* SCIF1 */
[MSTP024] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 24, 0), /* SCIF2 */
@@ -130,6 +132,8 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP322]), /* SDHI1 */
CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP321]), /* SDHI2 */
CLKDEV_DEV_ID("sh-eth", &mstp_clks[MSTP114]), /* Ether */
+   CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI 
port0/1 */
+   CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI 
port0/1 */
CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -20,10 +20,13 @@
 
 #include 
 #include 
+#include 
 
 extern void r8a7778_add_standard_devices(void);
 extern void r8a7778_add_standard_devices_dt(void);
 extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_init_late(void);
 extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
 extern void r8a7778_init_irq_dt(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -30,6 +30,12 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -89,6 +95,99 @@ static struct sh_timer_config sh_tmu1_pl
&sh_tmu##idx##_platform_data,   \
sizeof(sh_tmu##idx##_platform_data))
 
+/* USB PHY */
+static struct resource usb_phy_resources[] __initdata = {
+   DEFINE_RES_MEM(0xffe70800, 0x100),
+   DEFINE_RES_MEM(0xffe76000, 0x100),
+};
+
+void __init r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+   platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+ usb_phy_resources,
+

[PATCH v7 1/3] rcar-phy: add R8A7778 support

[Sergei Shtylyov]

The driver currently only supports R8A7779 SoC. Compared to it, R8A7778 USB-PHY
has extra register range containing two high-speed signal quality characteristic
control registers which should be set up  during USB-PHY  startup depending on
whether a ferrite bead is in use or not.  So, we now handle an optional second
memory range in the driver's probe method, add the 'ferrite_bead' field to the
driver's platform data, and add an extra (optional) step to the USB-PHY startup
routine which sets up the extended registers.

Also mark in the driver's Kconfig section  that R8A7778 is  now supported and
generally clarify that section, uppercasing the word "phy", while at it... 

The patch has been tested on the Marzen and BOCK-W boards.

Signed-off-by: Sergei Shtylyov 
Acked-by: Felipe Balbi 

---
Changes since version 5:
- renamed the header file into .

Changes since version 3:
- removed stray debugging printk() call.

Changes since version 2:
- moved 'ferrite_bead' bitfield to the start of 'struct rcar_phy_platform_data'
  which allowed to cut the size of the structure from 8 bytes back to 4;
- added a comment about only 2 USB ports on R8A7778'
- added an ACK from Felipe Balbi.

Changes since the original posting:
- made the necessary changes atop of the R8A7779/Marzen pathset version 4.

 drivers/usb/phy/Kconfig|8 +++---
 drivers/usb/phy/rcar-phy.c |   37 -
 include/linux/platform_data/usb-rcar-phy.h |4 ++-
 3 files changed, 38 insertions(+), 11 deletions(-)

Index: renesas/drivers/usb/phy/Kconfig
===
--- renesas.orig/drivers/usb/phy/Kconfig
+++ renesas/drivers/usb/phy/Kconfig
@@ -55,13 +55,13 @@ config MV_U3D_PHY
  SoC.
 
 config USB_RCAR_PHY
-   tristate "Renesas R-Car USB phy support"
+   tristate "Renesas R-Car USB PHY support"
depends on USB || USB_GADGET
select USB_OTG_UTILS
help
- Say Y here to add support for the Renesas R-Car USB phy driver.
- This chip is typically used as USB phy for USB host, gadget.
- This driver supports: R8A7779
+ Say Y here to add support for the Renesas R-Car USB common PHY driver.
+ This device is typically used as USB PHY for USB host, gadget.
+ This driver supports R8A7778 and R8A7779.
 
  To compile this driver as a module, choose M here: the
  module will be called rcar-phy.
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -26,15 +26,21 @@
 #define USBOH0 0x1C
 #define USBCTL00x58
 
+/* High-speed signal quality characteristic control registers (R8A7778 only) */
+#define HSQCTL10x24
+#define HSQCTL20x28
+
 /* USBPCTRL0 */
-#define OVC2   (1 << 10) /* Switches the OVC input pin for port 2: */
+#define OVC2   (1 << 10) /* (R8A7779 only) */
+   /* Switches the OVC input pin for port 2: */
/* 1: USB_OVC2, 0: OVC2 */
 #define OVC1_VBUS1 (1 << 9) /* Switches the OVC input pin for port 1: */
/* 1: USB_OVC1, 0: OVC1/VBUS1   */
/* Function mode: set to 0  */
 #define OVC0   (1 << 8) /* Switches the OVC input pin for port 0: */
/* 1: USB_OVC0 pin, 0: OVC0 */
-#define OVC2_ACT   (1 << 6) /* Host mode: OVC2 polarity:   */
+#define OVC2_ACT   (1 << 6) /* (R8A7779 only)  */
+   /* Host mode: OVC2 polarity:*/
/* 1: active-high, 0: active-low*/
 #define PENC   (1 << 4) /* Function mode: output level of PENC1 pin: */
/* 1: high, 0: low  */
@@ -59,6 +65,7 @@ struct rcar_usb_phy_priv {
spinlock_t lock;
 
void __iomem *reg0;
+   void __iomem *reg1;
int counter;
 };
 
@@ -78,6 +85,7 @@ static int rcar_usb_phy_init(struct usb_
struct device *dev = phy->dev;
struct rcar_phy_platform_data *pdata = dev->platform_data;
void __iomem *reg0 = priv->reg0;
+   void __iomem *reg1 = priv->reg1;
const u8 ovcn_act[] = { OVC0_ACT, OVC1_ACT, OVC2_ACT };
int i;
u32 val;
@@ -96,7 +104,16 @@ static int rcar_usb_phy_init(struct usb_
/* (2) start USB-PHY internal PLL */
iowrite32(PHY_ENB | PLL_ENB, (reg0 + USBPCTRL1));
 
-   /* (3) USB module status check */
+   /* (3) set USB-PHY in accord with the conditions of usage */
+   if (reg1) {
+   u32 hsqctl1 = pdata->ferrite_bead ? 0x41 : 0;
+  

[PATCH v7 0/3] Add USB support to R8A7778/BOCK-W

[Sergei Shtylyov]

Hello.

   Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130426' tag, the R8A7779/Marzen and sh-pfc patchset I've posted.
It was created to add support of R8A7778/BOCK-W USB to the platform code and
the USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and
drivers/usb/phy/ subtrees.

[1/3] rcar-phy: add R8A7778 support
[2/3] ARM: shmobile: r8a7778: add USB support
[3/3] ARM: shmobile: BOCK-W: add USB support

The patch #4 (ARM: shmobile: BOCK-W: enable USB in defconfig) that has been
already merged, is not reposted.

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

Re: Phy and gpio_vbus breakage in 3.9

[Robert Jarzmik]

Robert Jarzmik  writes:

> Hi guys,

I almost forgot.
This simple patch fixes the issue, but I haven't thought it through if it is the
proper fix :

diff --git a/drivers/usb/otg/gpio_vbus.c b/drivers/usb/otg/gpio_vbus.c
index a7d4ac5..f65615c 100644
--- a/drivers/usb/otg/gpio_vbus.c
+++ b/drivers/usb/otg/gpio_vbus.c
@@ -264,6 +264,7 @@ static int __init gpio_vbus_probe(struct platform_device 
*pdev)
gpio_vbus->phy.set_power = gpio_vbus_set_power;
gpio_vbus->phy.set_suspend = gpio_vbus_set_suspend;
gpio_vbus->phy.state = OTG_STATE_UNDEFINED;
+   gpio_vbus->phy.dev = &pdev->dev;
 
gpio_vbus->phy.otg->phy = &gpio_vbus->phy;
gpio_vbus->phy.otg->set_peripheral = gpio_vbus_set_peripheral;


-- 
Robert
--
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: set device dma_mask without reference to global data

[Stephen Warren]

On 05/07/2013 08:54 PM, Peter Chen wrote:
>>
>> This probably could be initialized from some DT property. However,
>> there's no such property defined right now, and considering that DT is
>> supposed to be an ABI, we'd always need the code in this patch as a
>> fallback for DTs that were created before any such property was defined.
>>
>> Equally, since the data is SoC-specific rather than board-specific, and
>> is even fairly unlikely to vary between SoC versions since these values
>> are all 0x anyway, I don't really see much point in putting it
>> into DT, rather than just putting the static data into the driver.
> 
> I mean there is already dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> at function of_platform_device_create, why can't add
> dev->dev.dma_mask = &dev->dev.coherent_dma_mask after that?
> 
> If DT core can do above things, can we delete dma_mask assignment
> at every driver?

Perhaps. However, such a change has a much larger potential for regressions.

I would suggest going with the current patch for 3.10 and any later
backports in order to reduce risk. We can revisit better cleanup for
later kernels.
--
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 2 dev in usb 3 port "unable to enumerate USB device on port"

[Greg KH]

On Wed, May 08, 2013 at 02:14:35PM -0700, curtis.wy...@gdc4s.com wrote:
> I have a USB 2.0 device (wifi card) that is not detected when I plug it
> into a 3.0 port.  It does not show up in /dev/bus/usb.  This is an FC16
> kernel(linux-3.3), and we have tested that it works in FC18 (linux-3.5)
> just fine. I cannot at this point switch out the whole kernel.  I was
> hoping that you could help me narrow down some specific patches that I
> could back port to fix this.

I'd just recommend using FC18, especially as FC16 is obsolete and
end-of-life :)

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

usb 2 dev in usb 3 port "unable to enumerate USB device on port"

[Curtis.Wyatt]

I have a USB 2.0 device (wifi card) that is not detected when I plug it
into a 3.0 port.  It does not show up in /dev/bus/usb.  This is an FC16
kernel(linux-3.3), and we have tested that it works in FC18 (linux-3.5)
just fine. I cannot at this point switch out the whole kernel.  I was
hoping that you could help me narrow down some specific patches that I
could back port to fix this.

Here is the output:
xhci_hcd :00:14.0: Port Status Change Event for port 1
xhci_hcd :00:14.0: resume root hub
usb usb9: usb wakeup-resume
usb usb9: usb auto-resume
hub 9-0:1.0: hub_resume
xhci_hcd :00:14.0: get port status, actual port 0 status  = 0x206e1
xhci_hcd :00:14.0: Get port status returned 0x10101
hub 9-0:1.0: port 1: status 0101 change 0001
xhci_hcd :00:14.0: clear port connect change, actual port 0 status
= 0x6e1
xhci_hcd :00:14.0: get port status, actual port 1 status  = 0x202a0
xhci_hcd :00:14.0: Get port status returned 0x10100
xhci_hcd :00:14.0: clear port connect change, actual port 1 status
= 0x2a0
xhci_hcd :00:14.0: get port status, actual port 2 status  = 0x2a0
xhci_hcd :00:14.0: Get port status returned 0x100
xhci_hcd :00:14.0: get port status, actual port 3 status  = 0x2a0
xhci_hcd :00:14.0: Get port status returned 0x100
hub 9-0:1.0: state 7 ports 4 chg 0002 evt 
xhci_hcd :00:14.0: get port status, actual port 0 status  = 0x6e1
xhci_hcd :00:14.0: Get port status returned 0x101
hub 9-0:1.0: port 1, status 0101, change , 12 Mb/s
xhci_hcd :00:14.0: // Ding dong!
xhci_hcd :00:14.0: Adding 1 ep ctx, 1 now active.
xhci_hcd :00:14.0: Slot 2 output ctx = 0xfffea000 (dma)
xhci_hcd :00:14.0: Slot 2 input ctx = 0xfffeb000 (dma)
xhci_hcd :00:14.0: Set slot id 2 dcbaa entry 88020e48a010 to
0xfffea000
xhci_hcd :00:14.0: set port reset, actual port 0 status  = 0x791
xhci_hcd :00:14.0: get port status, actual port 0 status  = 0xf91
xhci_hcd :00:14.0: Get port status returned 0x511
hub 9-0:1.0: port 1 not reset yet, waiting 50ms
xhci_hcd :00:14.0: Port Status Change Event for port 1
xhci_hcd :00:14.0: get port status, actual port 0 status  = 0x2206e1
xhci_hcd :00:14.0: Get port status returned 0x110101
xhci_hcd :00:14.0: clear port reset change, actual port 0 status  =
0x206e1
xhci_hcd :00:14.0: disable port, actual port 0 status  = 0x206e1
xhci_hcd :00:14.0: // Ding dong!
xhci_hcd :00:14.0: Dropped 1 ep ctxs, flags = 0x1, 0 now active.
xhci_hcd :00:14.0: Bad real port.
hub 9-0:1.0: unable to enumerate USB device on port 1
xhci_hcd :00:14.0: disable port, actual port 0 status  = 0x206e1
hub 9-0:1.0: hub_suspend
usb usb9: bus auto-suspend, wakeup 1

Curtis Wyatt

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

dwc2: Transaction errors with device connected at boot

[Matthijs Kooijman]

Hi Paul,

I'm running into an issue with the dwc2 driver. When I power on my board
with an usb device (mass storage in this case) connected, the hardware
is returning transaction errors (e.g., triggering channel halted +
xacterr interrupts) for every transfer scheduled, starting with the
first ones.

This condition stays even through a reboot, though a power cycle cures
the condition (provided I remove the USB device for the boot). If I
insert the USB device after the board has booted and the driver has
loaded, everything works as expected, also after a reboot (with the
device still plugged in).

This leads me to suspect there is some issue when the time between the
first hardware initialization and the first host channel start is too
small or something like that? Any ideas?

Also, is there any fixed list of what could cause a transaction error,
or is this just a catchall meaning "Something went wrong"?

Thanks,

Matthijs
--
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/4] staging: dwc2: Set a default dma_mask for platform devices

[Matthijs Kooijman]

Hi Paul,

> > +   /*
> > +* Use reasonable defaults so platforms don't have to provide these.
> > +*/
> > +   if (!dev->dev.dma_mask)
> > +   dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
> > +   if (!dev->dev.coherent_dma_mask)
> > +   dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> 
> Hmm. Is it kosher to override these in a driver and force DMA to be
> enabled?

Apparently, since a lot of drivers do it like this. This particular code
was taken from the ehci-platform driver. See also:

http://thread.gmane.org/gmane.linux.usb.general/86066

The discussion in that thread suggests that even though this is not
quite the optimal way to do this, it is the accepted way for now and
changing it needs a bit more complicated changes and more discussion,
apparently.

> What if it has been disabled earlier on purpose, say because the
> platform does not have DMA support? You say "This still allows any
> platform code to set any more specific mask if needed", but how would
> that be done exactly?
Platform code could go over the list of platform devices and (based on the
device-tree compatible value, for example) change the mask of a device.
Admittedly, this could set a more specific mask, but not exactly disable
dma entirely. I guess this is not a usecase for the other drivers?

For the dwc2 driver, I guess the dwc2 hardware would not have dma
enabled if the system does not support it anyway?

Note that this code only runs for platform devices, so not for pci
devices, which can disable dma by not setting a dma_mask when combined
with the next patch.

Gr.

Matthijs
--
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/4] staging: dwc2: Set a default dma_mask for platform devices

[Paul Zimmerman]

> From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> Sent: Wednesday, May 08, 2013 12:45 PM
> 
> Platform devices added through OF usually do not have any dma_mask
> pointer set.  In this case, point it at the coherent_dma_mask and set
> their value to a 32 bit mask. This still allows any platform code to set
> any more specific mask if needed, but makes the driver work for most
> dma-enabled hardware.
> 
> Signed-off-by: Matthijs Kooijman 
> ---
>  drivers/staging/dwc2/platform.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/staging/dwc2/platform.c b/drivers/staging/dwc2/platform.c
> index 74f1b7d..fdf81c2 100644
> --- a/drivers/staging/dwc2/platform.c
> +++ b/drivers/staging/dwc2/platform.c
> @@ -187,6 +187,14 @@ static int dwc2_driver_probe(struct platform_device *dev)
> 
>   hsotg->dev = &dev->dev;
> 
> + /*
> +  * Use reasonable defaults so platforms don't have to provide these.
> +  */
> + if (!dev->dev.dma_mask)
> + dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
> + if (!dev->dev.coherent_dma_mask)
> + dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);

Hmm. Is it kosher to override these in a driver and force DMA to be
enabled? What if it has been disabled earlier on purpose, say because
the platform does not have DMA support? You say "This still allows any
platform code to set any more specific mask if needed", but how would
that be done exactly?

-- 
Paul

--
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 v6 RESEND] usbnet: allow status interrupt URB to always be active

[David Miller]

From: Dan Williams 
Date: Mon, 06 May 2013 16:29:23 -0500

> Some drivers (sierra_net) need the status interrupt URB
> active even when the device is closed, because they receive
> custom indications from firmware.  Add functions to refcount
> the status interrupt URB submit/kill operation so that
> sub-drivers and the generic driver don't fight over whether
> the status interrupt URB is active or not.
> 
> A sub-driver can call usbnet_status_start() at any time, but
> the URB is only submitted the first time the function is
> called.  Likewise, when the sub-driver is done with the URB,
> it calls usbnet_status_stop() but the URB is only killed when
> all users have stopped it.  The URB is still killed and
> re-submitted for suspend/resume, as before, with the same
> refcount it had at suspend.
> 
> Signed-off-by: Dan Williams 

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

Re: [PATCH 2/2 v6 RESEND] sierra_net: keep status interrupt URB active

[David Miller]

From: Dan Williams 
Date: Mon, 06 May 2013 16:34:56 -0500

> The driver and firmware sync up through SYNC messages, and the
> firmware's affirmative reply to these SYNC messages appears to be the
> "Reset" indication received via the status interrupt endpoint.  Thus the
> driver needs the status interrupt endpoint always active so that the
> Reset indication can be received even if the netdev is closed, which is
> the case right after device insertion.
> 
> If the Reset indication is not received by the driver, it continues
> sending SYNC messages to the firmware, which crashes about 10 seconds
> later and the device stops responding.
> 
> Signed-off-by: Dan Williams 

Applied.
--
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/4] staging: dwc2: disable dma when no dma_mask was setup

[Matthijs Kooijman]

If the platform driver failed to setup a dma_mask, but the hardware
advertises support for DMA, before DMA would be enabled in dwc2, but
disabled in the usb core, making all connectivity break.

With this commit, the dwc2 driver will emit a warning and fall back to
slave mode in this case.

Signed-off-by: Matthijs Kooijman 
---
 drivers/staging/dwc2/hcd.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/staging/dwc2/hcd.c b/drivers/staging/dwc2/hcd.c
index eff8e59..d9a2055 100644
--- a/drivers/staging/dwc2/hcd.c
+++ b/drivers/staging/dwc2/hcd.c
@@ -2740,6 +2740,15 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
/* Validate parameter values */
dwc2_set_parameters(hsotg, params);
 
+   /* Check if the bus driver or platform code has setup a dma_mask */
+   if (hsotg->core_params->dma_enable > 0 &&
+   hsotg->dev->dma_mask == NULL) {
+   dev_warn(hsotg->dev,
+"dma_mask not set, disabling DMA\n");
+   hsotg->core_params->dma_enable = 0;
+   hsotg->core_params->dma_desc_enable = 0;
+   }
+
/* Set device flags indicating whether the HCD supports DMA */
if (hsotg->core_params->dma_enable > 0) {
if (dma_set_mask(hsotg->dev, DMA_BIT_MASK(31)) < 0)
-- 
1.8.0

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

[PATCH 0/4] staging: dwc2: DMA improvements

[Matthijs Kooijman]

Hi folks,

here's some more dma fixes for the dwc2 driver. The second patch of this
series is the same as in my previous series, the others are new.

> staging: dwc2: Set a default dma_mask for platform devices

It would be great if at least this first patch in this series could be
included in 3.10, since it is needed to make the dwc2 driver work on the
ralink rt3052 target.
Before, the plan was to set up the dma mask in MIPS platform code, but
because of a similar change in ehci and the uglyness of the code for
that, the plan for that infrastructure was dropped. This patch makes the
setting of the dma_mask happen in the same way as the patch Stephen
Warren (set device dma_mask without reference to global data), so
perhaps it can be pushed to 3.10 together with that one?

> staging: dwc2: disable dma when no dma_mask was setup
This patch might not be strictly required if the previous one is
accepted, but it seems reasonable to just check this to be on the safe
side (in case a bus driver messes up, for example).

> staging: dwc2: when dma is disabled, clear hcd->self.uses_dma
This is a different approach to another patch in my previous series.

> staging: dwc2: Don't touch the dma_mask when dma is disabled
This removes some messing with the dma_mask that I think is unneeded,
but it's not very important in any way.

Thanks,

Matthijs

 drivers/staging/dwc2/hcd.c  | 15 ---
 drivers/staging/dwc2/platform.c |  8 
 2 files changed, 20 insertions(+), 3 deletions(-)

-- 
1.8.0

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

[PATCH 3/4] staging: dwc2: when dma is disabled, clear hcd->self.uses_dma

[Matthijs Kooijman]

When dma is disabled inside dwc2 (because the hardware does not support
it, or the code was changed to disable it for testing), let the usb core
know about this by clearing hcd->self.uses_dma.

By default, the usb core assumes that dma is used when a dma_mask is
set, but this might not always match the dma_enable value in dwc2. To
prevent problems resulting from a mismatch, better to explicitely
disable dma in this case (though everything seemed to work with the
wrong value of uses_dma as well, probably only resulted in some unneeded
work).

Signed-off-by: Matthijs Kooijman 
---
 drivers/staging/dwc2/hcd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/staging/dwc2/hcd.c b/drivers/staging/dwc2/hcd.c
index d9a2055..18a91de 100644
--- a/drivers/staging/dwc2/hcd.c
+++ b/drivers/staging/dwc2/hcd.c
@@ -2766,6 +2766,9 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
if (!hcd)
goto error1;
 
+   if (hsotg->core_params->dma_enable <= 0)
+   hcd->self.uses_dma = 0;
+
hcd->has_tt = 1;
 
spin_lock_init(&hsotg->lock);
-- 
1.8.0

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

[PATCH 1/4] staging: dwc2: Set a default dma_mask for platform devices

[Matthijs Kooijman]

Platform devices added through OF usually do not have any dma_mask
pointer set.  In this case, point it at the coherent_dma_mask and set
their value to a 32 bit mask. This still allows any platform code to set
any more specific mask if needed, but makes the driver work for most
dma-enabled hardware.

Signed-off-by: Matthijs Kooijman 
---
 drivers/staging/dwc2/platform.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/staging/dwc2/platform.c b/drivers/staging/dwc2/platform.c
index 74f1b7d..fdf81c2 100644
--- a/drivers/staging/dwc2/platform.c
+++ b/drivers/staging/dwc2/platform.c
@@ -187,6 +187,14 @@ static int dwc2_driver_probe(struct platform_device *dev)
 
hsotg->dev = &dev->dev;
 
+   /*
+* Use reasonable defaults so platforms don't have to provide these.
+*/
+   if (!dev->dev.dma_mask)
+   dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
+   if (!dev->dev.coherent_dma_mask)
+   dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+
irq = platform_get_irq(dev, 0);
if (irq < 0) {
dev_err(&dev->dev, "missing IRQ resource\n");
-- 
1.8.0

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

[PATCH 4/4] staging: dwc2: Don't touch the dma_mask when dma is disabled

[Matthijs Kooijman]

There was some code that cleared the dma_mask when dma was disabled in
the driver. Given that clearing the mask doesn't actually tell the usb
core we're not using dma, and a previous commit explicitely sets the
hcd->self.uses_dma value, it seems these values are unneeded and can
only potentially cause problems (when reloading a module, for example).

Signed-off-by: Matthijs Kooijman 
---
 drivers/staging/dwc2/hcd.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/dwc2/hcd.c b/drivers/staging/dwc2/hcd.c
index 18a91de..57c6ee7 100644
--- a/drivers/staging/dwc2/hcd.c
+++ b/drivers/staging/dwc2/hcd.c
@@ -2757,9 +2757,6 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
if (dma_set_coherent_mask(hsotg->dev, DMA_BIT_MASK(31)) < 0)
dev_warn(hsotg->dev,
 "can't enable workaround for >2GB RAM\n");
-   } else {
-   dma_set_mask(hsotg->dev, 0);
-   dma_set_coherent_mask(hsotg->dev, 0);
}
 
hcd = usb_create_hcd(&dwc2_hc_driver, hsotg->dev, dev_name(hsotg->dev));
-- 
1.8.0

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

Re: [PATCH 1/1] usb: chipidea: Improve kconfig

[Randy Dunlap]

On 05/08/13 03:02, Peter Chen wrote:
> Randy Dunlap  reported below problem
> at i386:
>> drivers/built-in.o: In function `ci_hdrc_host_init':
>> (.text+0x2ce75c): undefined reference to `ehci_init_driver'
> 
>> When USB_EHCI_HCD=m and USB_CHIPIDEA=y.
> 
> In fact, this problem is existed at all platforms which are using
> chipidea driver. The root cause of this problem is the chipidea host
> uses symbol exported from ehci-hcd, but chipidea core
> does not depends on USB_EHCI_HCD. So, chipidea driver
> will not be compiled as module if USB_EHCI_HCD=m.
> 
> It is very hard to give a perfect solution since chipidea core
> depends on USB || USB_GADGET, and chipdiea host depends on
> both USB_EHCI_HCD and USB_CHIPIDEA, the same problem exists for
> gadget.
> 
> To fix this problem, we had to have below assumptions:
> 
> - If USB_EHCI_HCD=y && USB_GADGET=y, USB_CHIPIDEA can be 'y'.
> 
> - If USB_EHCI_HCD=m && USB_GADGET=y, USB_CHIPIDEA=m
> or USB_CHIPIDEA_HOST can't be seen if USB_CHIPIDEA=y.
> It will cause compile error as no glue layer for ehci.
>> error: #error "missing bus glue for ehci-hcd"
> So, we had to compile USB_CHIPIDEA=m if USB_EHCI_HCD=m,
> current ehci hcd core guarantee it.
> 
> - If USB_EHCI_HCD=y && USB_GADGET=m, USB_CHIPIDEA=m
> or USB_CHIPIDEA_UDC can't be seen if USB_CHIPIDEA=y.
> Of cos, the gadget will out of working at this situation,
> so the user had to compile USB_CHIPIDEA=m.
> 
> - USB_EHCI_HCD=m && USB_GADGET=m, we can't see
> USB_CHIPIDEA_HOST and USB_CHIPIDEA_UDC unless
> USB_CHIPIDEA=m.
> 
> The reason why it has abvoe assumptions:
> - If both ehci core and gadget core build as module,
> the chipidea has to build as module.
> - If one of ehci core or gadget core is built in, another
> is built as module, we can only enable the function which
> is built in, or enable both roles as modules (USB_CHIPIDEA=m),
> since chipidea driver is unify core driver, the host or udc
> is not a individual driver.
> 
> Signed-off-by: Peter Chen 

Acked-by: Randy Dunlap 

Thanks.


> ---
>  drivers/usb/chipidea/Kconfig |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
> index 608a2ae..eb2aa2e 100644
> --- a/drivers/usb/chipidea/Kconfig
> +++ b/drivers/usb/chipidea/Kconfig
> @@ -12,15 +12,15 @@ if USB_CHIPIDEA
>  
>  config USB_CHIPIDEA_UDC
>   bool "ChipIdea device controller"
> - depends on USB_GADGET=y || USB_GADGET=USB_CHIPIDEA
> + depends on USB_GADGET=y || USB_CHIPIDEA=m
>   help
> Say Y here to enable device controller functionality of the
> ChipIdea driver.
>  
>  config USB_CHIPIDEA_HOST
>   bool "ChipIdea host controller"
> - depends on USB=y || USB=USB_CHIPIDEA
> - depends on USB_EHCI_HCD
> + depends on USB=y
> + depends on USB_EHCI_HCD=y || USB_CHIPIDEA=m
>   select USB_EHCI_ROOT_HUB_TT
>   help
> Say Y here to enable host controller functionality of the
> 


-- 
~Randy
--
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] xhci: Compute last_ctx from complete set of endpoints.

[Reilly Grant]

The context entries field of the slot context must be set to one more
than the highest endpoint index currently active. The previous logic
only included the set of endpoints currently being added, meaning that
if an endpoint where dropped then the field would be reset to 1,
deactivating all configured endpoints.

The xHCI spec is decidedly unclear on whether this field includes all
configured endpoints or only those being modified by a configure
endpoint command. My interpretation is the former and is the behavior
observed in the Apple's xHCI driver.
---
 drivers/usb/host/xhci.c | 52 +
 1 file changed, 18 insertions(+), 34 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 53b8f89..5c40d3e 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1557,12 +1557,10 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct 
usb_device *udev,
struct xhci_hcd *xhci;
struct xhci_container_ctx *in_ctx, *out_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
-   struct xhci_slot_ctx *slot_ctx;
-   unsigned int last_ctx;
unsigned int ep_index;
struct xhci_ep_ctx *ep_ctx;
u32 drop_flag;
-   u32 new_add_flags, new_drop_flags, new_slot_info;
+   u32 new_add_flags, new_drop_flags;
int ret;
 
ret = xhci_check_args(hcd, udev, ep, 1, true, __func__);
@@ -1603,24 +1601,13 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct 
usb_device *udev,
ctrl_ctx->add_flags &= cpu_to_le32(~drop_flag);
new_add_flags = le32_to_cpu(ctrl_ctx->add_flags);
 
-   last_ctx = xhci_last_valid_endpoint(le32_to_cpu(ctrl_ctx->add_flags));
-   slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
-   /* Update the last valid endpoint context, if we deleted the last one */
-   if ((le32_to_cpu(slot_ctx->dev_info) & LAST_CTX_MASK) >
-   LAST_CTX(last_ctx)) {
-   slot_ctx->dev_info &= cpu_to_le32(~LAST_CTX_MASK);
-   slot_ctx->dev_info |= cpu_to_le32(LAST_CTX(last_ctx));
-   }
-   new_slot_info = le32_to_cpu(slot_ctx->dev_info);
-
xhci_endpoint_zero(xhci, xhci->devs[udev->slot_id], ep);
 
-   xhci_dbg(xhci, "drop ep 0x%x, slot id %d, new drop flags = %#x, new add 
flags = %#x, new slot info = %#x\n",
+   xhci_dbg(xhci, "drop ep 0x%x, slot id %d, new drop flags = %#x, new add 
flags = %#x\n",
(unsigned int) ep->desc.bEndpointAddress,
udev->slot_id,
(unsigned int) new_drop_flags,
-   (unsigned int) new_add_flags,
-   (unsigned int) new_slot_info);
+   (unsigned int) new_add_flags);
return 0;
 }
 
@@ -1643,11 +1630,9 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct 
usb_device *udev,
struct xhci_hcd *xhci;
struct xhci_container_ctx *in_ctx, *out_ctx;
unsigned int ep_index;
-   struct xhci_slot_ctx *slot_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
u32 added_ctxs;
-   unsigned int last_ctx;
-   u32 new_add_flags, new_drop_flags, new_slot_info;
+   u32 new_add_flags, new_drop_flags;
struct xhci_virt_device *virt_dev;
int ret = 0;
 
@@ -1662,7 +1647,6 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct 
usb_device *udev,
return -ENODEV;
 
added_ctxs = xhci_get_endpoint_flag(&ep->desc);
-   last_ctx = xhci_last_valid_endpoint(added_ctxs);
if (added_ctxs == SLOT_FLAG || added_ctxs == EP0_FLAG) {
/* FIXME when we have to issue an evaluate endpoint command to
 * deal with ep0 max packet size changing once we get the
@@ -1723,24 +1707,14 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct 
usb_device *udev,
 */
new_drop_flags = le32_to_cpu(ctrl_ctx->drop_flags);
 
-   slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
-   /* Update the last valid endpoint context, if we just added one past */
-   if ((le32_to_cpu(slot_ctx->dev_info) & LAST_CTX_MASK) <
-   LAST_CTX(last_ctx)) {
-   slot_ctx->dev_info &= cpu_to_le32(~LAST_CTX_MASK);
-   slot_ctx->dev_info |= cpu_to_le32(LAST_CTX(last_ctx));
-   }
-   new_slot_info = le32_to_cpu(slot_ctx->dev_info);
-
/* Store the usb_device pointer for later use */
ep->hcpriv = udev;
 
-   xhci_dbg(xhci, "add ep 0x%x, slot id %d, new drop flags = %#x, new add 
flags = %#x, new slot info = %#x\n",
+   xhci_dbg(xhci, "add ep 0x%x, slot id %d, new drop flags = %#x, new add 
flags = %#x\n",
(unsigned int) ep->desc.bEndpointAddress,
udev->slot_id,
(unsigned int) new_drop_flags,
-   (unsigned int) new_add_flags,
-   (unsigned int) new_slot_info);
+   (unsigned int) new_add_flags);
return 0;
 }
 

undefined reference to `usb_gadget_unmap_request' regression

[Vivek Gautam]

Hi Felipe,

Commit 388e5c51135f817f01177c42261f1116a6d7f2ad usb: dwc3: remove dwc3 
dependency on host AND gadget
by me breaks compilation when USB_DWC3=y, USB=y but USB_GADGET=m, 
additionally when either of USB_DWC3_GADGET=y or USB_DWC3_DUAL_ROLE=y   :-(


I had some confusion with this actually.

We started with making USB_DWC3 independent of USB and USB_GADGET.
Thereby added some helping configs USB_DWC3_HOST, USB_DWC3_GADGET and 
USB_DWC3_DUAL_ROLE.

Now when USB_GADGET=m and USB=y; USB_DWC3=y
Now, USB_DWC3_DUAL_ROLE=y or USB_DWC3_GADGET=y will make things worse, since 
it will compile

dwc3/gadget.c and dwc3/ep0.c
This lets the compilation to break since usb/gadget/** is still compiling as 
module.
But the errors it throws for functions are already exported with 
EXPORT_SYMBOL_GPL(), then why these errors then.


A possible flaw with this could be that "USB_DWC3_HOST, USB_DWC3_GADGET and 
USB_DWC3_DUAL_ROLE"
are still 'bool' type configs. But making this as 'tristate' too doesn't 
makes our life easier.
Ideally dwc3/gadget.c and dwc3/ep0.c should be compiling as modules when 
USB_GADGET=m.
But then we have functions like dwc3_host_init() and dwc3_gadget_init() and 
other similar functions in dwc3/core.c which give

compilation break.

Help please  :-)


Thanks
Vivek 


--
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: dwc3 on omap5432 no SuperSpeed host mode

[Ben Dooks]

On 08/05/13 18:02, Felipe Balbi wrote:

Hi,

On Wed, May 08, 2013 at 05:52:50PM +0200, Ben Dooks wrote:

On 08/05/13 17:45, Sebastian Andrzej Siewior wrote:

* Ben Dooks | 2013-05-07 22:06:33 [+0200]:


We are using an OMAP5432 ES2.0 on an UEVM board
and running into issues with the dwc3 usb.


Sorry, I can't help at all. I don't have the board and I never had one.
I had ES1.0 but I never got dwc3 to work.


I have better news, re-based to 3.8.11 and it has now enumerated
the USB3 card reader at SuperSpeed.

It seems the board is very picky about what it will play host to
as neither of the mini-b to A adapters I have work. I am using
a mini B to mini B cable to run the card reader.

I have still got the disable CMD_RESET patch in.


yeah, there are a few issues regarding CMD_RESET bit on the XHCI side
with that IP. We're still trying to find a proper workaround.


Is replacing the xhci-hcd.c reset command with a call to the dwc3
driver not enough? I will leave this for the moment if it is being
worked on.

Even if we are just working in gadget mode, having the xhci-hcd driver
around causes the system to stop working.


On your mini-b to A adapters, make sure ID pin is grounded, if it's not
then the Vbus regulator won't switch to bypass mode, that's something
workable in SW, however, just lack of time to implement.


I've forced the palmas-pmic to run Vbus all the time at the moment,
as it didn't have any sort of controls for SMSP10 output 1.

Thankyou for the response.

--
Ben Dooks   http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
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: dwc3 on omap5432 no SuperSpeed host mode

[Felipe Balbi]

Hi,

On Wed, May 08, 2013 at 05:52:50PM +0200, Ben Dooks wrote:
> On 08/05/13 17:45, Sebastian Andrzej Siewior wrote:
> >* Ben Dooks | 2013-05-07 22:06:33 [+0200]:
> >
> >>We are using an OMAP5432 ES2.0 on an UEVM board
> >>and running into issues with the dwc3 usb.
> >
> >Sorry, I can't help at all. I don't have the board and I never had one.
> >I had ES1.0 but I never got dwc3 to work.
> 
> I have better news, re-based to 3.8.11 and it has now enumerated
> the USB3 card reader at SuperSpeed.
> 
> It seems the board is very picky about what it will play host to
> as neither of the mini-b to A adapters I have work. I am using
> a mini B to mini B cable to run the card reader.
> 
> I have still got the disable CMD_RESET patch in.

yeah, there are a few issues regarding CMD_RESET bit on the XHCI side
with that IP. We're still trying to find a proper workaround.

On your mini-b to A adapters, make sure ID pin is grounded, if it's not
then the Vbus regulator won't switch to bypass mode, that's something
workable in SW, however, just lack of time to implement.

-- 
balbi


signature.asc
Description: Digital signature

Re: dwc3 on omap5432 no SuperSpeed host mode

[Ben Dooks]

On 08/05/13 17:45, Sebastian Andrzej Siewior wrote:

* Ben Dooks | 2013-05-07 22:06:33 [+0200]:


We are using an OMAP5432 ES2.0 on an UEVM board
and running into issues with the dwc3 usb.


Sorry, I can't help at all. I don't have the board and I never had one.
I had ES1.0 but I never got dwc3 to work.


I have better news, re-based to 3.8.11 and it has now enumerated
the USB3 card reader at SuperSpeed.

It seems the board is very picky about what it will play host to
as neither of the mini-b to A adapters I have work. I am using
a mini B to mini B cable to run the card reader.

I have still got the disable CMD_RESET patch in.

--
Ben Dooks   http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
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/8] USB: serial: add generic wait_until_sent implementation

[Johan Hovold]

Add generic wait_until_sent implementation which polls for empty
hardware buffers using the new port-operation tx_empty.

The generic implementation will be used for all sub-drivers that
implement tx_empty but does not define wait_until_sent.

Signed-off-by: Johan Hovold 
---

v2: make sure to handle B0

 drivers/usb/serial/generic.c| 31 +++
 drivers/usb/serial/usb-serial.c |  2 ++
 include/linux/usb/serial.h  |  3 +++
 3 files changed, 36 insertions(+)

diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 297665f..ba45170 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -253,6 +253,37 @@ int usb_serial_generic_chars_in_buffer(struct tty_struct 
*tty)
 }
 EXPORT_SYMBOL_GPL(usb_serial_generic_chars_in_buffer);
 
+void usb_serial_generic_wait_until_sent(struct tty_struct *tty, long timeout)
+{
+   struct usb_serial_port *port = tty->driver_data;
+   unsigned int bps;
+   unsigned long period;
+   unsigned long expire;
+
+   bps = tty_get_baud_rate(tty);
+   if (!bps)
+   bps = 9600; /* B0 */
+   /*
+* Use a poll-period of roughly the time it takes to send one
+* character or at least one jiffy.
+*/
+   period = max_t(unsigned long, (10 * HZ / bps), 1);
+   period = min_t(unsigned long, period, timeout);
+
+   dev_dbg(&port->dev, "%s - timeout = %u ms, period = %u ms\n",
+   __func__, jiffies_to_msecs(timeout),
+   jiffies_to_msecs(period));
+   expire = jiffies + timeout;
+   while (!port->serial->type->tx_empty(port)) {
+   schedule_timeout_interruptible(period);
+   if (signal_pending(current))
+   break;
+   if (time_after(jiffies, expire))
+   break;
+   }
+}
+EXPORT_SYMBOL_GPL(usb_serial_generic_wait_until_sent);
+
 static int usb_serial_generic_submit_read_urb(struct usb_serial_port *port,
int index, gfp_t mem_flags)
 {
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index 31d2768..60caf9c 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -1333,6 +1333,8 @@ static void usb_serial_operations_init(struct 
usb_serial_driver *device)
set_to_generic_if_null(device, close);
set_to_generic_if_null(device, write_room);
set_to_generic_if_null(device, chars_in_buffer);
+   if (device->tx_empty)
+   set_to_generic_if_null(device, wait_until_sent);
set_to_generic_if_null(device, read_bulk_callback);
set_to_generic_if_null(device, write_bulk_callback);
set_to_generic_if_null(device, process_read_urb);
diff --git a/include/linux/usb/serial.h b/include/linux/usb/serial.h
index afbb7ee..302ddf5 100644
--- a/include/linux/usb/serial.h
+++ b/include/linux/usb/serial.h
@@ -269,6 +269,7 @@ struct usb_serial_driver {
void (*break_ctl)(struct tty_struct *tty, int break_state);
int  (*chars_in_buffer)(struct tty_struct *tty);
void (*wait_until_sent)(struct tty_struct *tty, long timeout);
+   bool (*tx_empty)(struct usb_serial_port *port);
void (*throttle)(struct tty_struct *tty);
void (*unthrottle)(struct tty_struct *tty);
int  (*tiocmget)(struct tty_struct *tty);
@@ -328,6 +329,8 @@ extern void usb_serial_generic_close(struct usb_serial_port 
*port);
 extern int usb_serial_generic_resume(struct usb_serial *serial);
 extern int usb_serial_generic_write_room(struct tty_struct *tty);
 extern int usb_serial_generic_chars_in_buffer(struct tty_struct *tty);
+extern void usb_serial_generic_wait_until_sent(struct tty_struct *tty,
+   long timeout);
 extern void usb_serial_generic_read_bulk_callback(struct urb *urb);
 extern void usb_serial_generic_write_bulk_callback(struct urb *urb);
 extern void usb_serial_generic_throttle(struct tty_struct *tty);
-- 
1.8.2.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

Phy and gpio_vbus breakage in 3.9

[Robert Jarzmik]

Hi guys,

I tried the 3.9 kernel and on bootup sequence I have a panic.
I don't have a serial console available without USB, so no direct logs can be
provided.

What I have is the line where the breakage happens :
drivers/usb/otg.c:133
if (IS_ERR(phy) || !try_module_get(phy->dev->driver->owner)) {

Here in my config I have this config :
 - one phy : gpio_vbus.c
 - one UDC controller : pxa27x_udc.c

The backtrace I see on the phone's screen is something like :
 - do_one_initcall
 udc_init
   platform_driver_probe
 platform_driver_register
   driver_register
 bus_add_driver
   driver_attach
 bus_for_each_dev
   __driver_attach
 driver_probe_device
   platform_drv_probe
 pxa_udc_probe
   usb_get_phy
... here my screen has scrolled over ...

I don't know what happens and it is extermely painfull for me to debug (no
console, no keyboard, could be barely worse), so I hope one of you will have an
idea.
I had a quick glance, and I didn't see in gpio_vbus.c phy->dev populated
... that might be the origin of the panic ... or not.

Cheers.

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

Re: [PATCH 2/7] USB: serial: add generic wait_until_sent implementation

[Johan Hovold]

On Wed, May 08, 2013 at 06:25:13PM +0400, Stas Sergeev wrote:
> 05.05.2013 22:32, Johan Hovold пишет:
> > Add generic wait_until_sent implementation which polls for empty
> > hardware buffers using the new port-operation tx_empty.
> >
> > The generic implementation will be used for all sub-drivers that
> > implement tx_empty but does not define wait_until_sent.
> Hi Johan.
> 
> The customer reports an Oops below.
> Does that ring any bells?
> Well, there is only one division in usb_serial_generic_wait_until_sent(),
> anyway. :)

Yes, you're right I forgot about B0. I'll send a v2.

Thanks for catching this,
Johan
--
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: dwc3 on omap5432 no SuperSpeed host mode

[Sebastian Andrzej Siewior]

* Ben Dooks | 2013-05-07 22:06:33 [+0200]:

>We are using an OMAP5432 ES2.0 on an UEVM board
>and running into issues with the dwc3 usb.

Sorry, I can't help at all. I don't have the board and I never had one.
I had ES1.0 but I never got dwc3 to work.

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

Re: [PATCH v4] usb host: Faraday USB2.0 FUSBH200-HCD driver

[Greg KH]

On Wed, May 08, 2013 at 10:40:08AM -0400, Alan Stern wrote:
> On Wed, 8 May 2013, Yuan-Hsin Chen wrote:
> 
> > Hi,
> > 
> > Are there any advice?
> > Thanks.
> > 
> > On Fri, Apr 26, 2013 at 5:37 PM, Yuan-Hsin Chen  wrote:
> > > FUSBH200-HCD is an USB2.0 hcd for Faraday FUSBH200.
> > > FUSBH200 is an ehci-like controller with some differences.
> > > First, register layout of FUSBH200 is incompatible with EHCI.
> > > Furthermore, FUSBH200 is lack of siTDs which means iTDs
> > > are used for both HS and FS ISO transfer.
> 
> As far as I'm concerned, this can be merged.

Ok, I'll queue it up after 3.10-rc1 is 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] USB: xHCI: override bogus bulk wMaxPacketSize values

[Alan Stern]

This patch shortens the logic in xhci_endpoint_init() by moving common
calculations involving max_packet and max_burst outside the switch
statement, rather than repeating the same code in multiple
case-specific statements.  It also replaces two usages of max_packet
which were clearly intended to be max_burst all along.

More importantly, it compensates for a common bug in high-speed bulk
endpoint descriptors.  In many devices there is a bulk endpoint having
a wMaxPacketSize value smaller than 512, which is forbidden by the USB
spec.  Some xHCI controllers can't handle this and refuse to accept
the endpoint.  This patch changes the max_packet value to 512, which
allows the controller to use the endpoint properly.

In practice the bogus maxpacket size doesn't matter, because none of
the transfers sent via these endpoints are longer than the maxpacket
value anyway.

Signed-off-by: Alan Stern 
Reported-and-tested-by: "Aurélien Leblond" 
CC: 

---

Question: Should this be handled in usbcore instead?  The code that
parses endpoint descriptors already warns about high-speed bulk
endpoints with maxpacket different from 512.  It could easily override
the bogus values.

Also: This probably won't work in cases where the bogus maxpacket
value is _larger_ than 512.  I vaguely recall seeing a device with a
bulk maxpacket size of 1024.  But such an endpoint is unlikely to work
under an xHCI controller in any case, although it might work with
EHCI.


[as1678]

 drivers/usb/host/xhci-mem.c |   17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

Index: usb-3.9/drivers/usb/host/xhci-mem.c
===
--- usb-3.9.orig/drivers/usb/host/xhci-mem.c
+++ usb-3.9/drivers/usb/host/xhci-mem.c
@@ -1423,15 +1423,17 @@ int xhci_endpoint_init(struct xhci_hcd *
ep_ctx->ep_info2 |= cpu_to_le32(xhci_get_endpoint_type(udev, ep));
 
/* Set the max packet size and max burst */
+   max_packet = GET_MAX_PACKET(usb_endpoint_maxp(&ep->desc));
+   max_burst = 0;
switch (udev->speed) {
case USB_SPEED_SUPER:
-   max_packet = usb_endpoint_maxp(&ep->desc);
-   ep_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(max_packet));
/* dig out max burst from ep companion desc */
-   max_packet = ep->ss_ep_comp.bMaxBurst;
-   ep_ctx->ep_info2 |= cpu_to_le32(MAX_BURST(max_packet));
+   max_burst = ep->ss_ep_comp.bMaxBurst;
break;
case USB_SPEED_HIGH:
+   /* Some devices get this wrong */
+   if (usb_endpoint_xfer_bulk(&ep->desc))
+   max_packet = 512;
/* bits 11:12 specify the number of additional transaction
 * opportunities per microframe (USB 2.0, section 9.6.6)
 */
@@ -1439,17 +1441,16 @@ int xhci_endpoint_init(struct xhci_hcd *
usb_endpoint_xfer_int(&ep->desc)) {
max_burst = (usb_endpoint_maxp(&ep->desc)
 & 0x1800) >> 11;
-   ep_ctx->ep_info2 |= cpu_to_le32(MAX_BURST(max_burst));
}
-   /* Fall through */
+   break;
case USB_SPEED_FULL:
case USB_SPEED_LOW:
-   max_packet = GET_MAX_PACKET(usb_endpoint_maxp(&ep->desc));
-   ep_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(max_packet));
break;
default:
BUG();
}
+   ep_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(max_packet) |
+   MAX_BURST(max_burst));
max_esit_payload = xhci_get_max_esit_payload(xhci, udev, ep);
ep_ctx->tx_info = 
cpu_to_le32(MAX_ESIT_PAYLOAD_FOR_EP(max_esit_payload));
 

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

Re: [PATCH v4] usb host: Faraday USB2.0 FUSBH200-HCD driver

[Yuan-Hsin Chen]

Hi,

On Wed, May 8, 2013 at 10:40 PM, Alan Stern  wrote:
> On Wed, 8 May 2013, Yuan-Hsin Chen wrote:
>
>> Hi,
>>
>> Are there any advice?
>> Thanks.
>>
>> On Fri, Apr 26, 2013 at 5:37 PM, Yuan-Hsin Chen  wrote:
>> > FUSBH200-HCD is an USB2.0 hcd for Faraday FUSBH200.
>> > FUSBH200 is an ehci-like controller with some differences.
>> > First, register layout of FUSBH200 is incompatible with EHCI.
>> > Furthermore, FUSBH200 is lack of siTDs which means iTDs
>> > are used for both HS and FS ISO transfer.
>
> As far as I'm concerned, this can be merged.

Thanks for your great help.

>
> Alan Stern
>

Yuan-Hsin
--
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: set device dma_mask without reference to global data

[Arnd Bergmann]

On Wednesday 08 May 2013, Alan Stern wrote:
> > The first occurence was apparently in 3.3, but only in ehci-tegra.c,
> > while the other drivers subsequently copied the bug.
> 
> An alternative solution -- perhaps not better but also not relying on
> coherent_dma_mask -- is to clear pdev->dev.dma_mask in the remove
> routine if it points to the static mask value.
> 

Yes, I thought about that, but couldn't see any advantage one way
or the other and this one seemed simpler.

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

Re: [PATCH 1/2] staging: dwc2: when dma is disabled, clear dev->dma_mask

[Matthijs Kooijman]

> > > +   if (hsotg->core_params->dma_enable <= 0)
> > > +   hcd->self.uses_dma = 0;
> > > +
> > > hcd->has_tt = 1;
> > >  
> > > spin_lock_init(&hsotg->lock);
> 
> This is okay providing you do it before calling usb_add_hcd().

Great, thanks!

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

Re: [PATCH v4] usb host: Faraday USB2.0 FUSBH200-HCD driver

[Alan Stern]

On Wed, 8 May 2013, Yuan-Hsin Chen wrote:

> Hi,
> 
> Are there any advice?
> Thanks.
> 
> On Fri, Apr 26, 2013 at 5:37 PM, Yuan-Hsin Chen  wrote:
> > FUSBH200-HCD is an USB2.0 hcd for Faraday FUSBH200.
> > FUSBH200 is an ehci-like controller with some differences.
> > First, register layout of FUSBH200 is incompatible with EHCI.
> > Furthermore, FUSBH200 is lack of siTDs which means iTDs
> > are used for both HS and FS ISO transfer.

As far as I'm concerned, this can be merged.

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: Linux USB file storage gadget with new UDC

[Alan Stern]

On Wed, 8 May 2013, victor yeo wrote:

> >> Is the kagen2_ep_queue function gotten interrupted here? So the
> >> kagen2_ep_queue and interrupt routine need spinlock for
> >> synchronisation?
> >
> > That's right.  Interrupts can occur at almost any time (on
> > multiprocessor systems they can occur even when interrupts are disabled
> > on some of the CPUs).
> 
> I am confused. I add the spinlock functions to kagen2_ep_queue function.
> 
>   spin_lock_irqsave(&dev->lock, flags);
>   ..
>   spin_unlock_irqrestore(&dev->lock, flags);
> 
> When kagen2_ep_queue function is called, the error "BUG: scheduling
> while atomic: swapper/0/0x0002" occurs. I test the same spinlock
> functions in other device module. It is ok in other device module.

While the function holds a spinlock, it is not allowed to sleep.  

The BUG occurs because kagen2_ep_queue must call some function that can 
sleep.  But since you did not provide the rest of the BUG message 
(including the stack trace), I can't tell what function it calls.

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/2] staging: dwc2: when dma is disabled, clear dev->dma_mask

[Alan Stern]

On Wed, 8 May 2013, Matthijs Kooijman wrote:

> Hi Greg,
> 
> > Greg, is it ok for a HCD to modify hcd->self.uses_dma like this?
> perhaps you missed this question in my previous mail? :-)
> 
> Gr.
> 
> Matthijs
> 
> > diff --git a/drivers/staging/dwc2/hcd.c b/drivers/staging/dwc2/hcd.c
> > index d9a2055..18a91de 100644
> > --- a/drivers/staging/dwc2/hcd.c
> > +++ b/drivers/staging/dwc2/hcd.c
> > @@ -2766,6 +2766,9 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
> > if (!hcd)
> > goto error1;
> >  
> > +   if (hsotg->core_params->dma_enable <= 0)
> > +   hcd->self.uses_dma = 0;
> > +
> > hcd->has_tt = 1;
> >  
> > spin_lock_init(&hsotg->lock);

This is okay providing you do it before calling usb_add_hcd().

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 2/7] USB: serial: add generic wait_until_sent implementation

[Stas Sergeev]

05.05.2013 22:32, Johan Hovold пишет:

Add generic wait_until_sent implementation which polls for empty
hardware buffers using the new port-operation tx_empty.

The generic implementation will be used for all sub-drivers that
implement tx_empty but does not define wait_until_sent.

Hi Johan.

The customer reports an Oops below.
Does that ring any bells?
Well, there is only one division in usb_serial_generic_wait_until_sent(),
anyway. :)

---
May  8 08:23:06 localhost kernel: [   19.086679] divide error:  [#1] SMP
May  8 08:23:06 localhost kernel: [   19.086801] Modules linked in: 
ip6t_REJECT nf_conntrack_ipv6 nf_conntrack_ipv4 nf_defrag_
ipv6 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables 
coretemp e1000e kvm snd_hda_codec_hdmi snd_hda_codec_real
tek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm crc32c_intel 
snd_page_alloc snd_timer iTCO_wdt pcspkr iTCO_vendor_support sn
d i2c_i801 microcode ptp of_i2c usblp soundcore lpc_ich pps_core 
ftdi_sio raid1 i915 video i2c_algo_bit drm_kms_helper drm i2c

_core
May  8 08:23:06 localhost kernel: [   19.088296] CPU: 0 PID: 2554 Comm: 
dosemu.bin Not tainted 3.9.0+ #1
May  8 08:23:06 localhost kernel: [   19.088344] Hardware name: MSI 
MS-9899/MS-9899, BIOS V1.0b13 11/30/2012
May  8 08:23:06 localhost kernel: [   19.088393] task: f6b572c0 ti: 
f6a2c000 task.ti: f6a2c000
May  8 08:23:06 localhost kernel: [   19.088440] EIP: 0060:[] 
EFLAGS: 00010246 CPU: 0
May  8 08:23:06 localhost kernel: [   19.088489] EIP is at 
usb_serial_generic_wait_until_sent+0x2f/0xe0
May  8 08:23:06 localhost kernel: [   19.088537] EAX: 2710 EBX: 
f6a40400 ECX:  EDX: 
May  8 08:23:06 localhost kernel: [   19.088585] ESI: 0001 EDI: 
7fff EBP: f6a2dd60 ESP: f6a2dd30
May  8 08:23:06 localhost kernel: [   19.088634]  DS: 007b ES: 007b FS: 
00d8 GS: 00e0 SS: 0068
May  8 08:23:06 localhost kernel: [   19.088679] CR0: 80050033 CR2: 
0818cf69 CR3: 3139b000 CR4: 000407d0
May  8 08:23:06 localhost kernel: [   19.088725] DR0:  DR1: 
 DR2:  DR3: 

May  8 08:23:06 localhost kernel: [   19.088774] DR6: 0ff0 DR7: 0400
May  8 08:23:06 localhost kernel: [   19.088843] Stack:
May  8 08:23:06 localhost kernel: [   19.088910]  0015 f5fe2620 
 0206 0206 f6a2dd70 c07f3d88 f1a030c0
May  8 08:23:06 localhost kernel: [   19.089305]  f6a2dd60 f39bc180 
f39bc1b8 f1b5e000 f6a2dd90 c07f11ed f39bc180 7fff
May  8 08:23:06 localhost kernel: [   19.089703]  f6a2dd90 c07f147d 
7fff f6a40400 0015 7fff f1b5e000 7fff

May  8 08:23:06 localhost kernel: [   19.090096] Call Trace:
May  8 08:23:06 localhost kernel: [   19.090167]  [] ? 
usb_serial_generic_chars_in_buffer+0x68/0xa0
May  8 08:23:06 localhost kernel: [   19.090243]  [] 
serial_wait_until_sent+0x7d/0xc0
May  8 08:23:06 localhost kernel: [   19.090315]  [] ? 
serial_chars_in_buffer+0x3d/0x70
May  8 08:23:06 localhost kernel: [   19.090389]  [] 
tty_wait_until_sent+0xc0/0xe0
May  8 08:23:06 localhost kernel: [   19.090464]  [] ? 
tty_ldisc_deref+0x36/0x90
May  8 08:23:06 localhost kernel: [   19.090537]  [] 
set_termios+0x13f/0x260
May  8 08:23:06 localhost kernel: [   19.090608]  [] 
tty_mode_ioctl+0x403/0x510
May  8 08:23:06 localhost kernel: [   19.090681]  [] ? 
generic_file_aio_write+0xa9/0xd0
May  8 08:23:06 localhost kernel: [   19.090754]  [] 
n_tty_ioctl_helper+0x30/0x100
May  8 08:23:06 localhost kernel: [   19.090826]  [] 
n_tty_ioctl+0x32/0xe0
May  8 08:23:06 localhost kernel: [   19.090898]  [] ? 
n_tty_set_room+0x130/0x130
May  8 08:23:06 localhost kernel: [   19.090971]  [] 
tty_ioctl+0x27d/0xa40
May  8 08:23:06 localhost kernel: [   19.091043]  [] ? 
n_tty_set_room+0x130/0x130
May  8 08:23:06 localhost kernel: [   19.091116]  [] ? 
handle_pte_fault+0x80/0x7e0
May  8 08:23:06 localhost kernel: [   19.091191]  [] ? 
do_sync_write+0x97/0xd0
May  8 08:23:06 localhost kernel: [   19.091263]  [] ? 
no_tty+0x30/0x30
May  8 08:23:06 localhost kernel: [   19.091335]  [] 
do_vfs_ioctl+0x77/0x590
May  8 08:23:06 localhost kernel: [   19.091407]  [] ? 
__sb_end_write+0x31/0x70
May  8 08:23:06 localhost kernel: [   19.091479]  [] ? 
vfs_write+0x165/0x1c0
May  8 08:23:06 localhost kernel: [   19.091552]  [] 
SyS_ioctl+0x78/0x90
May  8 08:23:06 localhost kernel: [   19.091623]  [] 
sysenter_do_call+0x12/0x22
May  8 08:23:06 localhost kernel: [   19.091694] Code: 56 53 83 e4 f8 83 
ec 20 66 66 66 66 90 be 01 00 00 00 8b 98 78 01 00 00
 83 e8 80 89 d7 e8 ba 13 f2 ff 31 d2 89 c1 b8 10 27 00 00  f1 85 c0 
0f 45 f0 39 fe 0f 47 f7 f6 05 9a 00 c4 c0 04 75 49
May  8 08:23:06 localhost kernel: [   19.094241] EIP: [] 
usb_serial_generic_wait_until_sent+0x2f/0xe0 SS:ESP 0068:f6

a2dd30
May  8 08:23:06 localhost kernel: [   19.094443] ---[ end trace 
571b299bbe1655fd ]---

May  8 08:23:09 localhost lcdcontroller.sh[598]: Goodbye
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org

Re: [PATCH] USB: set device dma_mask without reference to global data

[Alan Stern]

On Wed, 8 May 2013, Arnd Bergmann wrote:

> On Wednesday 08 May 2013, Greg Kroah-Hartman wrote:
> > On Tue, May 07, 2013 at 04:53:52PM -0600, Stephen Warren wrote:
> > > From: Stephen Warren 
> 
> > > Suggested-by: Arnd Bergmann 
> > > Signed-off-by: Stephen Warren 
> > 
> > So this needs to go in for 3.10, right?  Any older kernels as well?  If
> > so, which ones?
> 
> The fix should definitely go into 3.10, but I'd suggest waiting with
> the backport for a couple of -rc releases to avoid possible regressions.
> We know that the current code is broken, but few people fully understand
> what is going on with coherent_dma_mask, so it might cause new problems
> in combination with some other unknown bug, and I don't see this as
> urgent: none of the ARM defconfigs build this driver as a loadable
> module and there is no bug in the built-in case. For some reason, only
> the ARM back-end drivers are broken.
> 
> The first occurence was apparently in 3.3, but only in ehci-tegra.c,
> while the other drivers subsequently copied the bug.

An alternative solution -- perhaps not better but also not relying on
coherent_dma_mask -- is to clear pdev->dev.dma_mask in the remove
routine if it points to the static mask value.

Alan Stern

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

Re: [PATCH] USB: set device dma_mask without reference to global data

[Arnd Bergmann]

On Wednesday 08 May 2013, Rob Herring wrote:
> On 05/08/2013 02:11 AM, Matthijs Kooijman wrote:

> > https://lkml.org/lkml/2012/12/4/54
> > 
> > And here's the previous attempt, to which Rob Herring refers in a reply.
> > 
> > https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-March/013180.html
> 
> I believe most of the issues have been around supporting ARM LPAE
> systems. There is a much more simple approach to address this by using
> the dma_addr_t size to set the coherent_dma_mask which I have queued for
> 3.11:
> 
> https://patchwork-mail1.kernel.org/patch/2495861/

Hmm, this approach seems wrong -- a lot of devices I expect cannot
actually do DMA to addresses beyond 4GB. A better default would
be to use a 32 bit mask for all devices and override the ones that
actually matter for performance and are known to be 64-bit DMA
capable.

Laura, you obviously tried this code on an LPAE-enabled system. Have
you had a look in the hardware manual which DMA masters in the
system are actually 64-bit capable?

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

Re: [PATCH] USB: set device dma_mask without reference to global data

[Rob Herring]

On 05/08/2013 02:11 AM, Matthijs Kooijman wrote:
> Hi folks,
> 
> I also bumped into the question of how to set the dma_mask when enabling
> the dwc2 driver on the ramips target and found there didn't seem to be
> any clear way to get a dma_mask.
> 
> It seems to me that in the pre-DT era, a platform_device would get a
> dma_mask when it was defined in the board / soc code, which makes sense
> since that code knows if a dma_mask is required and what its value
> should be (it seems to me that a driver can only know it needs a
> dma_mask, but not what value it should have?).
> 
>>> This probably could be initialized from some DT property. However,
>>> there's no such property defined right now, and considering that DT is
>>> supposed to be an ABI, we'd always need the code in this patch as a
>>> fallback for DTs that were created before any such property was defined.
> It seems there has already been a patch to implement this. For
> reference, this seems to be the most recent version:
> 
> https://lkml.org/lkml/2012/12/4/54
> 
> And here's the previous attempt, to which Rob Herring refers in a reply.
> 
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-March/013180.html

I believe most of the issues have been around supporting ARM LPAE
systems. There is a much more simple approach to address this by using
the dma_addr_t size to set the coherent_dma_mask which I have queued for
3.11:

https://patchwork-mail1.kernel.org/patch/2495861/

This does not set dma_mask though. There's always been some mystery
around why there are separate masks. I think for most systems dma_mask
can be set to coherent_dma_mask based on what Arnd found:

http://pastebin.com/E7fFVJyq

This can always be overridden by a platform with a bus notifier or by a
driver if needed.

Rob

> 
>>> Equally, since the data is SoC-specific rather than board-specific, and
>>> is even fairly unlikely to vary between SoC versions since these values
>>> are all 0x anyway, I don't really see much point in putting it
>>> into DT, rather than just putting the static data into the driver.
>>
>> I mean there is already dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> at function of_platform_device_create, why can't add
>> dev->dev.dma_mask = &dev->dev.coherent_dma_mask after that?
> Perhaps it would sense to set the 32-bit mask as a default, but allow to
> override this mask from the devicetree for boards that need another
> value? Or perhaps override it from the soc code instead?
> 
> For the ramips target, the MIPS folks suggested another approach: The
> soc code finds the platform_device generated by DT and adds the
> dma_mask:
> 
> http://www.linux-mips.org/archives/linux-mips/2013-04/msg00162.html
> 
>> If DT core can do above things, can we delete dma_mask assignment
>> at every driver?
> That would seem like a likeably goal to me :-)
> 
> 
> Gr.
> 
> Matthijs
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

--
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/1] usb: chipidea: Improve kconfig

[Peter Chen]

Randy Dunlap  reported below problem
at i386:
> drivers/built-in.o: In function `ci_hdrc_host_init':
> (.text+0x2ce75c): undefined reference to `ehci_init_driver'

> When USB_EHCI_HCD=m and USB_CHIPIDEA=y.

In fact, this problem is existed at all platforms which are using
chipidea driver. The root cause of this problem is the chipidea host
uses symbol exported from ehci-hcd, but chipidea core
does not depends on USB_EHCI_HCD. So, chipidea driver
will not be compiled as module if USB_EHCI_HCD=m.

It is very hard to give a perfect solution since chipidea core
depends on USB || USB_GADGET, and chipdiea host depends on
both USB_EHCI_HCD and USB_CHIPIDEA, the same problem exists for
gadget.

To fix this problem, we had to have below assumptions:

- If USB_EHCI_HCD=y && USB_GADGET=y, USB_CHIPIDEA can be 'y'.

- If USB_EHCI_HCD=m && USB_GADGET=y, USB_CHIPIDEA=m
or USB_CHIPIDEA_HOST can't be seen if USB_CHIPIDEA=y.
It will cause compile error as no glue layer for ehci.
> error: #error "missing bus glue for ehci-hcd"
So, we had to compile USB_CHIPIDEA=m if USB_EHCI_HCD=m,
current ehci hcd core guarantee it.

- If USB_EHCI_HCD=y && USB_GADGET=m, USB_CHIPIDEA=m
or USB_CHIPIDEA_UDC can't be seen if USB_CHIPIDEA=y.
Of cos, the gadget will out of working at this situation,
so the user had to compile USB_CHIPIDEA=m.

- USB_EHCI_HCD=m && USB_GADGET=m, we can't see
USB_CHIPIDEA_HOST and USB_CHIPIDEA_UDC unless
USB_CHIPIDEA=m.

The reason why it has abvoe assumptions:
- If both ehci core and gadget core build as module,
the chipidea has to build as module.
- If one of ehci core or gadget core is built in, another
is built as module, we can only enable the function which
is built in, or enable both roles as modules (USB_CHIPIDEA=m),
since chipidea driver is unify core driver, the host or udc
is not a individual driver.

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/Kconfig |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index 608a2ae..eb2aa2e 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -12,15 +12,15 @@ if USB_CHIPIDEA
 
 config USB_CHIPIDEA_UDC
bool "ChipIdea device controller"
-   depends on USB_GADGET=y || USB_GADGET=USB_CHIPIDEA
+   depends on USB_GADGET=y || USB_CHIPIDEA=m
help
  Say Y here to enable device controller functionality of the
  ChipIdea driver.
 
 config USB_CHIPIDEA_HOST
bool "ChipIdea host controller"
-   depends on USB=y || USB=USB_CHIPIDEA
-   depends on USB_EHCI_HCD
+   depends on USB=y
+   depends on USB_EHCI_HCD=y || USB_CHIPIDEA=m
select USB_EHCI_ROOT_HUB_TT
help
  Say Y here to enable host controller functionality of the
-- 
1.7.0.4


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

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

>> > It is likely that this bug occurs because you don't use a spinlock in
>> > kagen2_ep_queue.  Does the interrupt handler routine use a spinlock?
>>
>> Spinlock is Not used in interrupt handler routine.
>
> Then that's the reason for this bug.
>
>> >[start_transfer] 53425355 10d
>> >ept1 out queue len 0x200, buffer 0xc1304000
>> >g_file_storage gadget: bulk-out, length 31:
>>
>> Is the kagen2_ep_queue function gotten interrupted here? So the
>> kagen2_ep_queue and interrupt routine need spinlock for
>> synchronisation?
>
> That's right.  Interrupts can occur at almost any time (on
> multiprocessor systems they can occur even when interrupts are disabled
> on some of the CPUs).

I am confused. I add the spinlock functions to kagen2_ep_queue function.

  spin_lock_irqsave(&dev->lock, flags);
  ..
  spin_unlock_irqrestore(&dev->lock, flags);

When kagen2_ep_queue function is called, the error "BUG: scheduling
while atomic: swapper/0/0x0002" occurs. I test the same spinlock
functions in other device module. It is ok in other device module.

thanks,
victor
--
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 13/15] chipidea: Allow user to select PCI/IMX options

[Alexander Shishkin]

Jiri Slaby  writes:

> From: Jeff Mahoney 
>
> The chipidea driver currently has needless ifneq rules in the makefile
> for things that should be config options.

Please elaborate on the "should be" part.

> This can be problematic,
> especially in the IMX case, since the OF_DEVICE dependency will be met
> on powerpc systems - which don't actually support the hardware via that
> method.

That's all right, but these things should still compile on powerpc and
get more compilation testing like that. On the other hand, if the
compilation does break, we're probably looking at a bug in ci13xxx_imx,
which needs fixing.

> This patch adds _PCI and _IMX config options to allow the user to
> select whether to build the modules.

I would really like to avoid unnecessary config options in the chipidea
driver, so my question is: is there a real bug or compilation breakage
that is triggered in the current state of things?

> +config USB_CHIPIDEA_PCI
> + bool "ChipIdea PCI support"
> + depends on PCI
> + help
> +   This option enables ChipIdea support on PCI.

I totally don't understand this: we have CONFIG_USB_CHIPIDEA and
CONFIG_PCI, which already enable chipidea support on PCI. This helps in
the case when you have both options enabled, but still don't want the
ci13xxx_pci module to be built, but it doesn't justify an extra option.

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

Re: XHCI and USB 2 soundcard

[Aurélien Leblond]

On Mon, May 6, 2013 at 7:52 PM, Alan Stern  wrote:
> On Mon, 6 May 2013, [ISO-8859-1] Aurélien Leblond wrote:
>
>> Hello all,
>>
>> I have two usb soundcards at home and my laptop has both EHCI and XHCI
>> usb ports.
>>
>> The M-Audio Fast-Track Ultra (USB 2) is not recognized by ALSA when
>> plugged on a USB 3 (XHCI) port on the kernel 3.9.
>>
>> I'm trying to figure out where the problem lies to report the issue to
>> the proper team: is it with XHCI or with ALSA?
>
> Neither one.  The problem is in the device.

No surprises there - the dev of the usb-audio module had to write a
great deal of code for this soundcard. It doesn't seem to respect much
standard.

>
>> In dmesg, this is what happens when the FTU is plugged:
>> [  107.461175] usb 3-1: new high-speed USB device number 3 using xhci_hcd
>> [  107.481695] usb 3-1: config 1 interface 3 altsetting 0 bulk
>> endpoint 0x7 has invalid maxpacket 8
>> [  107.481705] usb 3-1: config 1 interface 3 altsetting 0 bulk
>> endpoint 0x87 has invalid maxpacket 8
>
> See those warnings?  They indicate that the device has invalid entries
> in its endpoint descriptors.  The xHCI hardware can't cope with those
> invalid entries.
>
>> [  107.483384] usb 3-1: New USB device found, idVendor=0763, idProduct=2080
>> [  107.483392] usb 3-1: New USB device strings: Mfr=1, Product=2, 
>> SerialNumber=0
>> [  107.483398] usb 3-1: Product: Fast Track Ultra
>> [  107.483403] usb 3-1: Manufacturer: M-Audio
>> [  107.483886] xhci_hcd :04:00.0: ERROR: unexpected command
>> completion code 0x11.
>> [  107.483899] usb 3-1: can't set config #1, error -22
>
> This error is the result.  It prevents the system from using the
> device.
>
> Now, the xhci-hcd driver ought to be smart enough to compensate for
> mistakes like this (they are relatively common).  Does the patch below
> help?
>
> Alan Stern
>
>
>
> Index: usb-3.9/drivers/usb/host/xhci-mem.c
> ===
> --- usb-3.9.orig/drivers/usb/host/xhci-mem.c
> +++ usb-3.9/drivers/usb/host/xhci-mem.c
> @@ -1423,15 +1423,17 @@ int xhci_endpoint_init(struct xhci_hcd *
> ep_ctx->ep_info2 |= cpu_to_le32(xhci_get_endpoint_type(udev, ep));
>
> /* Set the max packet size and max burst */
> +   max_packet = GET_MAX_PACKET(usb_endpoint_maxp(&ep->desc));
> +   max_burst = 0;
> switch (udev->speed) {
> case USB_SPEED_SUPER:
> -   max_packet = usb_endpoint_maxp(&ep->desc);
> -   ep_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(max_packet));
> /* dig out max burst from ep companion desc */
> -   max_packet = ep->ss_ep_comp.bMaxBurst;
> -   ep_ctx->ep_info2 |= cpu_to_le32(MAX_BURST(max_packet));
> +   max_burst = ep->ss_ep_comp.bMaxBurst;
> break;
> case USB_SPEED_HIGH:
> +   /* Some devices get this wrong */
> +   if (usb_endpoint_xfer_bulk(&ep->desc))
> +   max_packet = 512;
> /* bits 11:12 specify the number of additional transaction
>  * opportunities per microframe (USB 2.0, section 9.6.6)
>  */
> @@ -1439,17 +1441,16 @@ int xhci_endpoint_init(struct xhci_hcd *
> usb_endpoint_xfer_int(&ep->desc)) {
> max_burst = (usb_endpoint_maxp(&ep->desc)
>  & 0x1800) >> 11;
> -   ep_ctx->ep_info2 |= cpu_to_le32(MAX_BURST(max_burst));
> }
> -   /* Fall through */
> +   break;
> case USB_SPEED_FULL:
> case USB_SPEED_LOW:
> -   max_packet = GET_MAX_PACKET(usb_endpoint_maxp(&ep->desc));
> -   ep_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(max_packet));
> break;
> default:
> BUG();
> }
> +   ep_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(max_packet) |
> +   MAX_BURST(max_burst));
> max_esit_payload = xhci_get_max_esit_payload(xhci, udev, ep);
> ep_ctx->tx_info = 
> cpu_to_le32(MAX_ESIT_PAYLOAD_FOR_EP(max_esit_payload));
>
>


Tested it in kernel 9.0 and it fixes the problem!
The soundcard is detected and the probing of the snd-usb module is triggered.

Thanks a lot Alan!
If there is anything you would like me to test or a trace you would
like me to do to ensure everything is working ok, let me know.

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

Re: [PATCH 0/2] usb: gadget/uvc: remove connect/disconnect calls on open/release

[Peter Chen]

On Wed, May 8, 2013 at 4:01 PM, Vladimir Zapolskiy
 wrote:
> Hi Peter,
>
>
> On 05/07/13 04:39, Peter Chen wrote:
>>
>> On Fri, May 3, 2013 at 6:13 AM, Vladimir Zapolskiy
>>   wrote:
>>>
>>> This change removes calls of
>>> uvc_function_connect()/uvc_function_disconnect()
>>> functions from open()/close() syscalls.
>>>
>>> This is a bugfix in g_webcam module, in some test scenarios (e.g. UDC in
>>> suspend mode or OTG in host mode) straightforward control of D+ pull-up
>>> might lead to system's misbehaviour.
>>>
>>
>> When UDC is in suspend mode, pull-up dp is controller's behavior.
>> Can you give an explanation how the system will go to abnormal
>> when UDC in suspend mode or OTG in host mode?
>
>
> one of the examples:
>
> 1. boot a kernel with runtime pm and g_webcam support, UDC driver supports
>runtime PM, no USB cable connected to a board
> 2. UDC goes to suspend mode, because there is no USB connections
> 3. g_webcam registers itself, /dev/video0 node is created
> 4. udev forks v4l_id, which opens /dev/video0 to query V4L2 capabilities
> 5. on open() UVC gadget commands UDC to pull-up D+ line, there is
>no connected USB cable though
> 6. the system stalls/panics after an attempt to access mapped UDC
>registers while UDC controller is in suspend.
>
> A regular .pullup function from a UDC controller driver looks like:
>
> ---8<---
> static int omap_pullup(struct usb_gadget *gadget, int is_on)
> {
> struct omap_udc *udc;
> unsigned long   flags;
>
> udc = container_of(gadget, struct omap_udc, gadget);
> spin_lock_irqsave(&udc->lock, flags);
> udc->softconnect = (is_on != 0);
> if (can_pullup(udc))
> pullup_enable(udc);
> else
> pullup_disable(udc);
> spin_unlock_irqrestore(&udc->lock, flags);
> return 0;
> }
> ---8<---
>
> can_pullup() is false, pullup_disable() attempts to read/write to
> controller's registers, which causes system crash.
>
> There is definitely a bug, and according to Laurent's explanation UDC
> drivers should be fixed, I'll check that version.
>

Yes, it is UDC's bug. for UDC, which support runtime-pm, it should
consider the exported APIs might be called when udc is in suspend mode.


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

Re: [PATCH 0/2] usb: gadget/uvc: remove connect/disconnect calls on open/release

[Vladimir Zapolskiy]

Hi Peter,

On 05/07/13 04:39, Peter Chen wrote:

On Fri, May 3, 2013 at 6:13 AM, Vladimir Zapolskiy
  wrote:

This change removes calls of uvc_function_connect()/uvc_function_disconnect()
functions from open()/close() syscalls.

This is a bugfix in g_webcam module, in some test scenarios (e.g. UDC in
suspend mode or OTG in host mode) straightforward control of D+ pull-up
might lead to system's misbehaviour.



When UDC is in suspend mode, pull-up dp is controller's behavior.
Can you give an explanation how the system will go to abnormal
when UDC in suspend mode or OTG in host mode?


one of the examples:

1. boot a kernel with runtime pm and g_webcam support, UDC driver supports
   runtime PM, no USB cable connected to a board
2. UDC goes to suspend mode, because there is no USB connections
3. g_webcam registers itself, /dev/video0 node is created
4. udev forks v4l_id, which opens /dev/video0 to query V4L2 capabilities
5. on open() UVC gadget commands UDC to pull-up D+ line, there is
   no connected USB cable though
6. the system stalls/panics after an attempt to access mapped UDC
   registers while UDC controller is in suspend.

A regular .pullup function from a UDC controller driver looks like:

---8<---
static int omap_pullup(struct usb_gadget *gadget, int is_on)
{
struct omap_udc *udc;
unsigned long   flags;

udc = container_of(gadget, struct omap_udc, gadget);
spin_lock_irqsave(&udc->lock, flags);
udc->softconnect = (is_on != 0);
if (can_pullup(udc))
pullup_enable(udc);
else
pullup_disable(udc);
spin_unlock_irqrestore(&udc->lock, flags);
return 0;
}
---8<---

can_pullup() is false, pullup_disable() attempts to read/write to
controller's registers, which causes system crash.

There is definitely a bug, and according to Laurent's explanation UDC
drivers should be fixed, I'll check that version.

With best wishes,
Vladimir


Most probably a root cause of some reported system freezes on g_webcam
module probe [1] is related to the issue described above, for instance
if udev's v4l_id helper opens a new V4L2 device node to query device
capabilities.

Alternatively to this chage checks may be added to UDC driver's .pullup
functions, however presence of pullup controls from uvcvideo seems to
be redundant.

[1] http://kerneltrap.org/mailarchive/linux-usb/2010/12/29/6268355/thread

Vladimir Zapolskiy (2):
   usb: gadget/uvc: remove connect/disconnect calls on open/release
   usb: gadget/uvc: remove connection/disconnection routines

  drivers/usb/gadget/f_uvc.c|   24 
  drivers/usb/gadget/uvc.h  |3 ---
  drivers/usb/gadget/uvc_v4l2.c |5 -
  3 files changed, 32 deletions(-)

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




-
BR,
Peter Chen

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

Re: [PATCH 1/2] staging: dwc2: when dma is disabled, clear dev->dma_mask

[Matthijs Kooijman]

Hi Greg,

> Greg, is it ok for a HCD to modify hcd->self.uses_dma like this?
perhaps you missed this question in my previous mail? :-)

Gr.

Matthijs

> diff --git a/drivers/staging/dwc2/hcd.c b/drivers/staging/dwc2/hcd.c
> index d9a2055..18a91de 100644
> --- a/drivers/staging/dwc2/hcd.c
> +++ b/drivers/staging/dwc2/hcd.c
> @@ -2766,6 +2766,9 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
> if (!hcd)
> goto error1;
>  
> +   if (hsotg->core_params->dma_enable <= 0)
> +   hcd->self.uses_dma = 0;
> +
> hcd->has_tt = 1;
>  
> spin_lock_init(&hsotg->lock);
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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: set device dma_mask without reference to global data

[Matthijs Kooijman]

Hi,

> For the ramips target, the MIPS folks suggested another approach: The
> soc code finds the platform_device generated by DT and adds the
> dma_mask:
> 
> http://www.linux-mips.org/archives/linux-mips/2013-04/msg00162.html

For completeness: It seems this approach is not going to be used after
all. The approach (not this particular patch) was conceived to get ehci
support on ramips, but now that echi also sets a default mask and it
turns out that the other setup needed is best done through a phy device,
this approach is probably not needed anymore for ehci. For dwc2, I guess
it should also set up a dma_mask like ehci does (at least until we sort
out this thread) :-)

Gr.

Matthijs
--
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: set device dma_mask without reference to global data

[Arnd Bergmann]

On Wednesday 08 May 2013, Peter Chen wrote:
> >
> > This probably could be initialized from some DT property. However,
> > there's no such property defined right now, and considering that DT is
> > supposed to be an ABI, we'd always need the code in this patch as a
> > fallback for DTs that were created before any such property was defined.
> >
> > Equally, since the data is SoC-specific rather than board-specific, and
> > is even fairly unlikely to vary between SoC versions since these values
> > are all 0x anyway, I don't really see much point in putting it
> > into DT, rather than just putting the static data into the driver.
> 
> I mean there is already dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> at function of_platform_device_create, why can't add
> dev->dev.dma_mask = &dev->dev.coherent_dma_mask after that?
> 
> If DT core can do above things, can we delete dma_mask assignment
> at every driver?

It probably should. The main thing is that the dma_mask setting in
of_platform (and elsewhere) is a mess and that nobody so far had the
guts to try to get it right for good.

Setting a 32 bit DMA mask is /probably/ the right default on all
ARM systems, but there are caveats:

- Once you get to systems with larger than 32 bit addressing (powerpc64,
  arm64, arm32 with LPAE), it's not so obvious: you may have some devices
  that need a 32 bit mask and some that need a 64 bit mask.

- Some (very rare these days, thankfully) devices require a mask that is
  less than 32 bits. Since that knowledge is device specific, not platform
  specific, it should probably stay in the driver.

- There are cases (I know them only on powerpc, but they probably exist
  on ARM and other places too) where the mapping from bus addresses to
  physical addresses is not linear. There is a device-tree binding for
  a "dma-ranges" property that can accurately describe the specific
  mapping. Actually using this on architecture independent code requires
  not only setting the dma_mask but also supporting the remapping
  in the dma_map_ops.

- Things get more interesting in combination with an IOMMU. If we have
  an IOMMU, I think we should set the dma_mask pointer to the mask of
  the IOMMU and set the map_ops accordingly.

- Whether we actually need coherent_dma_mask these days is another hard
  question to answer. I suspect that the only thing really needing it
  was some version of the Itanium based Altix machine for its PCI
  devices and we'd be better off finding a simpler solution for platform
  devices. For all practical purposes I think coherent_dma_mask must be
  the same as dma_mask.

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

Re: [PATCH] USB: set device dma_mask without reference to global data

[Matthijs Kooijman]

Hi folks,

I also bumped into the question of how to set the dma_mask when enabling
the dwc2 driver on the ramips target and found there didn't seem to be
any clear way to get a dma_mask.

It seems to me that in the pre-DT era, a platform_device would get a
dma_mask when it was defined in the board / soc code, which makes sense
since that code knows if a dma_mask is required and what its value
should be (it seems to me that a driver can only know it needs a
dma_mask, but not what value it should have?).

> > This probably could be initialized from some DT property. However,
> > there's no such property defined right now, and considering that DT is
> > supposed to be an ABI, we'd always need the code in this patch as a
> > fallback for DTs that were created before any such property was defined.
It seems there has already been a patch to implement this. For
reference, this seems to be the most recent version:

https://lkml.org/lkml/2012/12/4/54

And here's the previous attempt, to which Rob Herring refers in a reply.

https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-March/013180.html

> > Equally, since the data is SoC-specific rather than board-specific, and
> > is even fairly unlikely to vary between SoC versions since these values
> > are all 0x anyway, I don't really see much point in putting it
> > into DT, rather than just putting the static data into the driver.
>
> I mean there is already dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> at function of_platform_device_create, why can't add
> dev->dev.dma_mask = &dev->dev.coherent_dma_mask after that?
Perhaps it would sense to set the 32-bit mask as a default, but allow to
override this mask from the devicetree for boards that need another
value? Or perhaps override it from the soc code instead?

For the ramips target, the MIPS folks suggested another approach: The
soc code finds the platform_device generated by DT and adds the
dma_mask:

http://www.linux-mips.org/archives/linux-mips/2013-04/msg00162.html

> If DT core can do above things, can we delete dma_mask assignment
> at every driver?
That would seem like a likeably goal to me :-)


Gr.

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