Re: [PATCH 1/4] usb/dwc3: remove custom unique id handling
On 10/29/2012 09:06 PM, Felipe Balbi wrote: Hi, Hi, On Mon, Oct 29, 2012 at 06:09:53PM +0100, Sebastian Andrzej Siewior wrote: The lockless implementation of the unique id is quite impressive (:P) but dirver's core can handle it, we can remove it and make our code a little smaller. Cc: Anton Tikhomirov Signed-off-by: Sebastian Andrzej Siewior Very nice :-) Can you implement a similar one for musb ? Sure. Keep in mind that this was untested due to ENODEV :) 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, v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but USB_SUPPORT disabled
>>> On 29.10.12 at 23:17, Alan Stern wrote: > On Mon, 29 Oct 2012, Jan Beulich wrote: > >> Since there's no possible caller of dbgp_external_startup() and >> dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and >> exporting these functions in that case. This eliminates a build error >> under the conditions listed in the subject, introduced with the merge >> f1c6872e4980bc4078cfaead05f892b3d78dea64. >> >> Reported-by: Randy Dunlap >> Signed-off-by: Jan Beulich >> Cc: Stefano Stabellini >> Cc: Alan Stern >> --- >> v2: Switch the dependency from USB_SUPPORT to USB_EHCI_HCD as requested >> by Alan (albeit I don't really agree to that change). > > Considering that the rest of ehci-dbgp.c is specific to EHCI hardware, > using USB_EHCI_HCD seems to me like a reasonable thing to do. > >> --- >> arch/x86/kernel/cpu/perf_event_p6.c |2 +- > > What's up with this? I had to fix an unrelated build issue, and while I removed the resulting change from the patch, I forgot to update the diffstat (I had lumped that change into the same patch). So please ignore this wrong piece of information. Jan >> drivers/usb/early/ehci-dbgp.c | 15 +-- >> 2 files changed, 10 insertions(+), 7 deletions(-) > > Acked-by: Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but USB_SUPPORT disabled
>>> On 29.10.12 at 17:50, Greg KH wrote: > On Mon, Oct 29, 2012 at 04:45:54PM +, Jan Beulich wrote: >> Since there's no possible caller of dbgp_external_startup() and >> dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and >> exporting these functions in that case. This eliminates a build error >> under the conditions listed in the subject, introduced with the merge >> f1c6872e4980bc4078cfaead05f892b3d78dea64. > > That's a merge commit, is that where the problem happened because Linus > did the merge resolution incorrectly, or is it really due to some other > patch that added this feature incorrectly? It was indeed the merge that broke things (Linus just followed the recommendation from Stefano, which weren't consistent with the rest of the code). Jan > If the latter, please provide that git commit id. > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: host to host usb transfer
Dnia poniedziałek, 29 października 2012 o 23:57:04 Michal Nazarewicz napisał(a): > On Mon, Oct 29 2012, Marek Floriańczyk wrote: > > I have seen this usb-gadget subsystem before but I have never used > > this. It looks like it could server the purpose, surely my tablet is > > visible as an device, and it has Linux inside after all, but it is > > also complex, and it will not be easy. I would like to make it work, > > it would be really clean solution to my problem, however at this > > moment it's probably to much for me. > > It's actually quite easy to use if you don't need to do anything > non-standard. If you have a device with a supported UDC (USB Device > Controller) and all you need is Ethernet, you just need to compile the > g_ether gadget (either built-in or as a module which you load) and > you're pretty much all set. Similarly for serial which Alan suggested. Hello I thought about this yesterday. There is something I don't quite understand. So lets assume I have UDC and I have compiled g_ether gadget, configured this and it works. How to use it? I mean I have Linux with this g_ether gadget that emulates eth on USB, but this is still usb cable connected to it, lets assume the other computer is windows (or linux) should I plug this USB cable and also compile similar gadget on it? then usb cable is only medium and I have two ethernet interfaces on both ends, or is this something totally different? best regards Marek -- To unsubscribe from this list: send the line "unsubscribe 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: Large files/folders copying ends with I/O error in mass storage
On Mon, Oct 29, 2012 at 8:39 PM, Alan Stern wrote: > On Mon, 29 Oct 2012, megha dey wrote: > >> Hi, >> This is the patch I have applied. >> >> http://marc.info/?l=linux-usb&m=132024464410783&w=2 >> >> From the trace attached,we see that write_10(highlighted command) is >> taking about 10 seconds,by which time the host is timing out.The host >> then sends the next test_unit_ready command without getting the status >> for the previous write.Thus,here we get 2 CBW's without an intervening >> CSW. > > It's not at all clear why the WRITE(10) took so long. Was the FUA bit > turned on? What happens if you install the mass-storage gadget driver > with nofua module parameter enabled? > > Also, it is clear from this trace that the host is buggy. The > Bulk-Only spec states that when a command is aborted (as this one was), > the host must issue a Reset command to the device. > > Alan Stern > Hi, This scenario apears on all standard windows XP PC's and can be simulated by putting some delay in vfs_write .Also in my case,FUA bit is not set (nofua is already enabled).This issue only comes with slower cards (class 2). -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: ncm: correct endianess conversion
Convert USB descriptor's fields to CPU byte order before using locally in USB
NCM gadget driver.
Tested on MIPS32 big-endian device.
Signed-off-by: Dmytro Milinevskyy
---
drivers/usb/gadget/f_ncm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/f_ncm.c b/drivers/usb/gadget/f_ncm.c
index b651b52..0b9e2ad 100644
--- a/drivers/usb/gadget/f_ncm.c
+++ b/drivers/usb/gadget/f_ncm.c
@@ -102,7 +102,7 @@ static inline unsigned ncm_bitrate(struct usb_gadget *g)
USB_CDC_NCM_NTB32_SUPPORTED)
static struct usb_cdc_ncm_ntb_parameters ntb_parameters = {
- .wLength = sizeof ntb_parameters,
+ .wLength = cpu_to_le16(sizeof(ntb_parameters)),
.bmNtbFormatsSupported = cpu_to_le16(FORMATS_SUPPORTED),
.dwNtbInMaxSize = cpu_to_le32(NTB_DEFAULT_IN_SIZE),
.wNdpInDivisor = cpu_to_le16(4),
@@ -869,15 +869,15 @@ static struct sk_buff *ncm_wrap_ntb(struct gether *port,
struct sk_buff *skb2;
int ncb_len = 0;
__le16 *tmp;
- int div = ntb_parameters.wNdpInDivisor;
- int rem = ntb_parameters.wNdpInPayloadRemainder;
- int pad;
- int ndp_align = ntb_parameters.wNdpInAlignment;
- int ndp_pad;
+ int div, rem, pad, ndp_align, ndp_pad;
unsignedmax_size = ncm->port.fixed_in_len;
struct ndp_parser_opts *opts = ncm->parser_opts;
unsignedcrc_len = ncm->is_crc ? sizeof(uint32_t) : 0;
+ div = le16_to_cpu(ntb_parameters.wNdpInDivisor);
+ rem = le16_to_cpu(ntb_parameters.wNdpInPayloadRemainder);
+ ndp_align = le16_to_cpu(ntb_parameters.wNdpInAlignment);
+
ncb_len += opts->nth_size;
ndp_pad = ALIGN(ncb_len, ndp_align) - ncb_len;
ncb_len += ndp_pad;
--
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 v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
On Tuesday 30 October 2012 11:21:33 Ming Lei wrote:
> On Mon, Oct 29, 2012 at 11:41 PM, Alan Stern
> wrote:
> > On Mon, 29 Oct 2012, Ming Lei wrote:
> >
> >> The patch introduces the flag of memalloc_noio_resume in
> >> 'struct dev_pm_info' to help PM core to teach mm not allocating
> >> memory with GFP_KERNEL flag for avoiding probable deadlock
> >> problem.
> >>
> >> As explained in the comment, any GFP_KERNEL allocation inside
> >> runtime_resume on any one of device in the path from one block
> >> or network device to the root device in the device tree may cause
> >> deadlock, the introduced pm_runtime_set_memalloc_noio() sets or
> >> clears the flag on device of the path recursively.
> >>
> >> This patch also introduces pm_runtime_get_memalloc_noio() because
> >> the flag may be accessed in block device's error handling path
> >> (for example, usb device reset)
> >
> >> +/*
> >> + * pm_runtime_get_memalloc_noio - Get a device's memalloc_noio flag.
> >> + * @dev: Device to handle.
> >> + *
> >> + * Return the device's memalloc_noio flag.
> >> + *
> >> + * The device power lock is held because bitfield is not SMP-safe.
> >> + */
> >> +bool pm_runtime_get_memalloc_noio(struct device *dev)
> >> +{
> >> + bool ret;
> >> + spin_lock_irq(&dev->power.lock);
> >> + ret = dev->power.memalloc_noio_resume;
> >> + spin_unlock_irq(&dev->power.lock);
> >> + return ret;
> >> +}
> >
> > You don't need to acquire and release a spinlock just to read the
> > value. Reading bitfields _is_ SMP-safe; writing them is not.
>
> Thanks for your review.
>
> As you pointed out before, the flag need to be checked before
> resetting usb devices, so the lock should be held to make another
> context(CPU) see the updated value suppose one context(CPU)
> call pm_runtime_set_memalloc_noio() to change the flag at the
> same time.
>
> The lock needn't to be held when the function is called inside
> pm_runtime_set_memalloc_noio(), so the bitfield flag should
> be checked directly without holding power lock in dev_memalloc_noio().
Hi,
how is this to work with power management domains?
And I may be dense, but disks are added in slave_configure().
This seems to be a race to me.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb audio race at disconnect time
At Tue, 30 Oct 2012 11:52:33 +0100, Matthieu CASTET wrote: > > > Takashi Iwai a écrit : > >> Thanks, > >> > >> the first tests seems ok. > >> We will do more strees test. > > > > Do you have any good/bad test result? > > If no regression is seen, I'm going to apply the patches for 3.7-rc4. > The patches fix the races. > > But I saw a failure I didn't saw before during stress test [1]. Hm, it's a list corruption, so everything is possible, including my patch... > It is hard to say if it is related to your patches : > - we test on a older kernel version and I backported usbaudio from 3.7 with > your > patches > - the start of the trace is missing and it is difficult to understand the list > corruption. Yeah, if you can catch the first trace, let me know. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
Hi, On Tue, Oct 30, 2012 at 6:57 PM, Oliver Neukum wrote: > how is this to work with power management domains? Could you explain it in a bit detail? Why is PM domain involved? Suppose PM domain is involved, its domain runtime_resume callback is still run in the context with PF_MEMALLOC_NOIO flag set if the affected 'device' is passed to the callback. > And I may be dense, but disks are added in slave_configure(). > This seems to be a race to me. Sorry, could you describe what is the race? Suppose drivers set correct parent device to the disk device(gendisk), then add the disk into device model via register_disk(), the solution should be fine. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb/musb: remove hand-crafted id handling
This replaced the handcrafted id handling by the PLATFORM_DEVID_AUTO
value which should do the same thing.
This patch probably also fixes ux500 because I did not find the "musbid"
variable to remove. And we close a tiny-unlikely race window becuase the
old code gave the id back before device was destroyed in the remove
case.
Cc: B, Ravi
Cc: Ajay Kumar Gupta
Cc: Santhapuri, Damodar
Cc: Mian Yousaf Kaukab
Cc: Bob Liu
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/musb/am35x.c | 18 ++
drivers/usb/musb/blackfin.c | 18 ++
drivers/usb/musb/da8xx.c | 18 ++
drivers/usb/musb/davinci.c | 18 ++
drivers/usb/musb/musb_core.c | 30 --
drivers/usb/musb/musb_core.h |2 --
drivers/usb/musb/musb_dsps.c | 17 +++--
drivers/usb/musb/omap2430.c | 24 +---
drivers/usb/musb/tusb6010.c | 18 ++
drivers/usb/musb/ux500.c | 17 ++---
10 files changed, 20 insertions(+), 160 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 614cc9e..4a48c2d 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -465,7 +465,6 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
struct clk *clk;
int ret = -ENOMEM;
- int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -473,18 +472,10 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
goto err0;
}
- /* get the musb id */
- musbid = musb_get_id(&pdev->dev, GFP_KERNEL);
- if (musbid < 0) {
- dev_err(&pdev->dev, "failed to allocate musb id\n");
- ret = -ENOMEM;
- goto err1;
- }
-
- musb = platform_device_alloc("musb-hdrc", musbid);
+ musb = platform_device_alloc("musb-hdrc", PLATFORM_DEVID_AUTO);
if (!musb) {
dev_err(&pdev->dev, "failed to allocate musb device\n");
- goto err2;
+ goto err1;
}
phy_clk = clk_get(&pdev->dev, "fck");
@@ -513,7 +504,6 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
goto err6;
}
- musb->id= musbid;
musb->dev.parent= &pdev->dev;
musb->dev.dma_mask = &am35x_dmamask;
musb->dev.coherent_dma_mask = am35x_dmamask;
@@ -563,9 +553,6 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
err3:
platform_device_put(musb);
-err2:
- musb_put_id(&pdev->dev, musbid);
-
err1:
kfree(glue);
@@ -577,7 +564,6 @@ static int __devexit am35x_remove(struct platform_device
*pdev)
{
struct am35x_glue *glue = platform_get_drvdata(pdev);
- musb_put_id(&pdev->dev, glue->musb->id);
platform_device_del(glue->musb);
platform_device_put(glue->musb);
clk_disable(glue->clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 8c16a22..ab2c63b 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -455,7 +455,6 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
struct bfin_glue*glue;
int ret = -ENOMEM;
- int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -463,21 +462,12 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
goto err0;
}
- /* get the musb id */
- musbid = musb_get_id(&pdev->dev, GFP_KERNEL);
- if (musbid < 0) {
- dev_err(&pdev->dev, "failed to allocate musb id\n");
- ret = -ENOMEM;
- goto err1;
- }
-
- musb = platform_device_alloc("musb-hdrc", musbid);
+ musb = platform_device_alloc("musb-hdrc", PLATFORM_DEVID_AUTO);
if (!musb) {
dev_err(&pdev->dev, "failed to allocate musb device\n");
- goto err2;
+ goto err1;
}
- musb->id= musbid;
musb->dev.parent= &pdev->dev;
musb->dev.dma_mask = &bfin_dmamask;
musb->dev.coherent_dma_mask = bfin_dmamask;
@@ -513,9 +503,6 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
err3:
platform_device_put(musb);
-err2:
- musb_put_id(&pdev->dev, musbid);
-
err1:
kfree(glue);
@@ -527,7 +514,6 @@ static int __devexit bfin_remove(struct platform_device
*pdev)
{
struct bfin_glue*glue = platform_get_drvdata(pdev);
- musb_put_id(&pdev->dev, glue->musb->id);
platform_device_del(glue->musb);
platform_device_put(glue->musb);
[PATCH v2 2/4] usb/dummy_hdc: prepare for multiple instances
This patch replaces the single pdev variable by an array. One change:
The device id is no longer -1 (i.e. none) but 0.
This is prepation work for multiple instances of the dummy_hcd + udc
which should help to test gadget framework with multiple UDCs.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/gadget/dummy_hcd.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index 89a4f7f..c8db231 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
@@ -2757,9 +2757,9 @@ static struct platform_driver dummy_hcd_driver = {
};
/*-*/
-
-static struct platform_device *the_udc_pdev;
-static struct platform_device *the_hcd_pdev;
+#define MAX_NUM_UDC1
+static struct platform_device *the_udc_pdev[MAX_NUM_UDC];
+static struct platform_device *the_hcd_pdev[MAX_NUM_UDC];
static int __init init(void)
{
@@ -2771,11 +2771,11 @@ static int __init init(void)
if (!mod_data.is_high_speed && mod_data.is_super_speed)
return -EINVAL;
- the_hcd_pdev = platform_device_alloc(driver_name, -1);
- if (!the_hcd_pdev)
+ the_hcd_pdev[0] = platform_device_alloc(driver_name, 0);
+ if (!the_hcd_pdev[0])
return retval;
- the_udc_pdev = platform_device_alloc(gadget_name, -1);
- if (!the_udc_pdev)
+ the_udc_pdev[0] = platform_device_alloc(gadget_name, 0);
+ if (!the_udc_pdev[0])
goto err_alloc_udc;
retval = platform_driver_register(&dummy_hcd_driver);
@@ -2785,7 +2785,7 @@ static int __init init(void)
if (retval < 0)
goto err_register_udc_driver;
- retval = platform_device_add(the_hcd_pdev);
+ retval = platform_device_add(the_hcd_pdev[0]);
if (retval < 0)
goto err_add_hcd;
if (!the_controller.hs_hcd ||
@@ -2797,10 +2797,10 @@ static int __init init(void)
retval = -EINVAL;
goto err_add_udc;
}
- retval = platform_device_add(the_udc_pdev);
+ retval = platform_device_add(the_udc_pdev[0]);
if (retval < 0)
goto err_add_udc;
- if (!platform_get_drvdata(the_udc_pdev)) {
+ if (!platform_get_drvdata(the_udc_pdev[0])) {
/*
* The udc was added successfully but its probe function failed
* for some reason.
@@ -2811,25 +2811,25 @@ static int __init init(void)
return retval;
err_probe_udc:
- platform_device_del(the_udc_pdev);
+ platform_device_del(the_udc_pdev[0]);
err_add_udc:
- platform_device_del(the_hcd_pdev);
+ platform_device_del(the_hcd_pdev[0]);
err_add_hcd:
platform_driver_unregister(&dummy_udc_driver);
err_register_udc_driver:
platform_driver_unregister(&dummy_hcd_driver);
err_register_hcd_driver:
- platform_device_put(the_udc_pdev);
+ platform_device_put(the_udc_pdev[0]);
err_alloc_udc:
- platform_device_put(the_hcd_pdev);
+ platform_device_put(the_hcd_pdev[0]);
return retval;
}
module_init(init);
static void __exit cleanup(void)
{
- platform_device_unregister(the_udc_pdev);
- platform_device_unregister(the_hcd_pdev);
+ platform_device_unregister(the_udc_pdev[0]);
+ platform_device_unregister(the_hcd_pdev[0]);
platform_driver_unregister(&dummy_udc_driver);
platform_driver_unregister(&dummy_hcd_driver);
}
--
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
Re: host to host usb transfer
On Tue, Oct 30, 2012 at 4:24 PM, Marek Floriańczyk wrote: > So lets assume I have UDC and I have compiled g_ether gadget, configured this > and it works. How to use it? >From view of OS, it is a common ethernet interface. > I mean I have Linux with this g_ether gadget that emulates eth on USB, but > this is still usb cable connected to it, lets assume the other computer is > windows (or linux) should I plug this USB cable and also compile similar > gadget on it? then usb cable is only medium and I have two ethernet interfaces No, windows supports cdc-ether gadget or rndis ether gadget, which will be recognized as ethernet interface without other software involved. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] usb/dummy_hcd: assign endpoint on enqeue on host side
* Alan Stern | 2012-10-29 12:04:10 [-0400]:
>Was that really the problem? My memory is not what it was three weeks
>ago...
>
>If so, there's a simpler solution. The list_for_each_entry_safe()
>loop in dummy_timer() should not consider URBs that were added after
>the loop started. That ought to be easy enough to implement. (One
>solution: Increment a counter each time dummy_timer() runs, and store a
>copy of the counter value in each urbp during submission. Exit the
>loop when the stored counter value in urbp is equal to the current
>counter.)
>
>This will prevent you from getting into an infinite loop in atomic
>context. Of course, the resubmission problem would still exist, but
>that's true with non-emulated gadgets too.
>
>Alan Stern
Okay. So now I added an interval check. It looks better. However if you
prefer the "don't check URBs that were added during completion" way then
I could try that. This would start that I remove the "restart:" label
which is used after URB completion.
---
dummy_urb_enqueue() now assigns the endpoint to the qh structure if it
finds one. Plus in case of an INT URB we track the interval so we don't
schedule the packet too often.
If UDC disables the endpoint (on the device side) the endpoint information
is removed from the qh as well. I think real HW would timeout on
transfer (and return -EPROTO).
With this change the, the busy loop which occurs if the host always
re-queues an INT URB in the completion is gone because we "skip" this qh
until the interval.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/gadget/dummy_hcd.c | 145
1 file changed, 102 insertions(+), 43 deletions(-)
diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index 2c27566..89a4f7f 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
@@ -94,6 +94,14 @@ struct dummy_request {
struct usb_request req;
};
+struct dummy_qh {
+ struct list_head urbp_list;
+ struct list_head qh_list;
+ struct dummy_ep *ep;
+ unsigned long next_io;
+ unsigned delay_j;
+};
+
static inline struct dummy_ep *usb_ep_to_dummy_ep(struct usb_ep *_ep)
{
return container_of(_ep, struct dummy_ep, ep);
@@ -557,7 +565,9 @@ static int dummy_enable(struct usb_ep *_ep,
static int dummy_disable(struct usb_ep *_ep)
{
struct dummy_ep *ep;
+ struct dummy_qh *qh;
struct dummy*dum;
+ struct dummy_hcd*dum_hcd;
unsigned long flags;
int retval;
@@ -565,8 +575,17 @@ static int dummy_disable(struct usb_ep *_ep)
if (!_ep || !ep->desc || _ep->name == ep0name)
return -EINVAL;
dum = ep_to_dummy(ep);
+ dum_hcd = gadget_to_dummy_hcd(&dum->gadget);
spin_lock_irqsave(&dum->lock, flags);
+
+ list_for_each_entry(qh, &dum_hcd->qh_list, qh_list) {
+ if (qh->ep == ep) {
+ qh->ep = NULL;
+ break;
+ }
+ }
+
ep->desc = NULL;
ep->stream_en = 0;
retval = 0;
@@ -1161,10 +1180,32 @@ static int dummy_validate_stream(struct dummy_hcd
*dum_hcd, struct urb *urb)
return 0;
}
-struct dummy_qh {
- struct list_head urbp_list;
- struct list_head qh_list;
-};
+#define is_active(dum_hcd) ((dum_hcd->port_status & \
+ (USB_PORT_STAT_CONNECTION | USB_PORT_STAT_ENABLE | \
+ USB_PORT_STAT_SUSPEND)) \
+ == (USB_PORT_STAT_CONNECTION | USB_PORT_STAT_ENABLE))
+
+static struct dummy_ep *find_endpoint(struct dummy *dum, u8 address)
+{
+ int i;
+
+ if (!is_active((dum->gadget.speed == USB_SPEED_SUPER ?
+ dum->ss_hcd : dum->hs_hcd)))
+ return NULL;
+ if ((address & ~USB_DIR_IN) == 0)
+ return &dum->ep[0];
+ for (i = 1; i < DUMMY_ENDPOINTS; i++) {
+ struct dummy_ep *ep = &dum->ep[i];
+
+ if (!ep->desc)
+ continue;
+ if (ep->desc->bEndpointAddress == address)
+ return ep;
+ }
+ return NULL;
+}
+
+#undef is_active
struct dummy_qh *qh_append_urb(struct dummy_hcd *dum_hcd, struct urb *urb)
{
@@ -1174,12 +1215,13 @@ struct dummy_qh *qh_append_urb(struct dummy_hcd
*dum_hcd, struct urb *urb)
if (qh)
return qh;
- qh = kmalloc(sizeof(*qh), GFP_ATOMIC);
+ qh = kzalloc(sizeof(*qh), GFP_ATOMIC);
if (!qh)
return qh;
list_add_tail(&qh->qh_list, &dum_hcd->qh_list);
INIT_LIST_HEAD(&qh->urbp_list);
urb->ep->hcpriv = qh;
+
return qh;
}
@@ -1196,13 +1238,41 @@ static void dummy_disable_ep(struct usb_hcd *hcd,
struct usb_host_endpoint *ep)
goto out;
qh = ep->hcpriv;
- list_del(&qh->qh_list)
Re: Problem with OHCI on OMAP4430
Alan, On Mon, Oct 29, 2012 at 8:54 PM, Alan Stern wrote: > On Mon, 29 Oct 2012, Mohan V wrote: > >> > I'm not going to be able to help very much with an Android kernel. >> > Does the same problem occur with a vanilla non-Android 3.6 kernel? If >> > it doesn't, that indicates the problem was caused by some >> > Android-specific changes. >> > >> With the vanilla 3.6 kernel, the device connected to OHCI port is not even >> detected. The below messages are seen: >> >> [5.343780] usb 2-2: new low-speed USB device number 5 using ohci-omap3 >> [5.351776] ohci-omap3 ohci-omap3.0: urb ee7f83c0 path 2 ep0out >> 5ec2 cc 5 --> status -62 >> [5.570770] ohci-omap3 ohci-omap3.0: urb ee7f83c0 path 2 ep0out >> 5ec2 cc 5 --> status -62 >> [5.789062] usb 2-2: device not accepting address 5, error -62 >> [5.795288] hub 2-0:1.0: unable to enumerate USB device on port 2 > > It looks like the device was detected just fine but the host was > unable to communicate with it. I don't know why; maybe a clock or > power line wasn't turned on properly or a PHY wasn't enabled. > >> We think it may not be hardware issue, since the device gets detected on >> android-3.0 kernel. The support for OHCI on OMAP4430 SDP board >> seems to be missing in Linux mainline (3.6). >> >> We ported some OMAP specific patches from android kernel, with this the >> device gets detected only if it is connected at boot. >> If the system is booted and then device is connected, it doesn't get >> detected. > > Doesn't get detected, or does get detected but then doesn't > communicate? > The device does not get detected. > Perhaps you should send some questions to the maintainers of the > various ohci-omap drivers or the Android maintainers. > Keshava, can you please comment? >> > Are you referring to this part of the log? >> > >> >> Device not getting detected when >> >> connected--- >> >> >> >> / # [ 135.621002] usbhs_wakeup: Enabling clocks >> >> [ 135.625762] usbhs_runtime_resume:++ >> >> [ 135.630371] usbhs_runtime_resume:-- >> >> [ 135.638183] USB IO PAD Wakeup event triggered## >> >> [ 135.644958] usbhs_runtime_suspend:++ >> >> [ 135.649749] usbhs_runtime_suspend:- >> > >> > It appears that ohci_irq() didn't run. Did >> > ohci_finish_controller_resume() get called? >> > >> This function is not used in ohci-omap3.c and is used only in ohci-omap.c. >> Is it necessary to call this function? > > It is necessary if the driver supports suspend/resume. As far as I can > tell, the ohci-omap3 driver does not have this support (at least, not > in the 3.6 kernel) whereas the ohci-omap driver does. > > What driver produced the "usbhs_runtime_suspend" and > "usbhs_runtime_resume" messages above? (No such messages are present > in ohci-omap3.c.) Apparently that driver _does_ support > suspend/resume. > This driver is USBHS core driver for OMAP EHCI and OHCI (drivers/mfd/omap-usb-host.c) Thanks, Mohan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] USB fixes for v3.7-rc4
Hi Greg,
Judging by how things are going, this is likely to be my last pull request
for v3.7-rc cycle, unless someone finds a big regression which we really must
fix during v3.7-rc.
It's rather small; just a revert, a Kconfig change and the addition of a
variable to a function. In fact, it's so small that I've added the full
combined diff below FYI.
Let me know if you want me to change anything.
cheers
The following changes since commit 1cb60156defa4f23d5318ea1ddd400f25b2d0ce5:
usb: renesas_usbhs: fixup dma transfer stall (2012-10-23 09:44:37 +0300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
tags/fixes-for-v3.7-rc4
for you to fetch changes up to f6bc8c29383456b89ac1b6f1aa768d195670fb53:
usb: otg: Fix build errors if USB_MUSB_OMAP2PLUS is selected as module
(2012-10-30 14:37:07 +0200)
usb: fixes for v3.7-rc4
We're reverting MUSB Mode 1 DMA patch which caused many regressions. Meanwhile
Roger is cooking a better version of that patch, which will hopefully be ready
for v3.8 merge window.
We also fix an undeclared error in ux5000_remove() and another build error
when we try to build USB_MUSB_OMAP2PLUS as a module.
Felipe Balbi (1):
Revert "usb: musb: use DMA mode 1 whenever possible"
Roger Quadros (1):
usb: otg: Fix build errors if USB_MUSB_OMAP2PLUS is selected as module
Wei Yongjun (1):
usb: musb: ux500: fix 'musbid' undeclared error in ux500_remove()
drivers/usb/musb/musb_gadget.c | 30 ++
drivers/usb/musb/ux500.c | 2 +-
drivers/usb/otg/Kconfig| 4 ++--
3 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index d0b87e7..b6b84da 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -707,11 +707,12 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
fifo_count = musb_readw(epio, MUSB_RXCOUNT);
/*
-* use mode 1 only if we expect data of at least ep packet_sz
-* and have not yet received a short packet
+* Enable Mode 1 on RX transfers only when short_not_ok flag
+* is set. Currently short_not_ok flag is set only from
+* file_storage and f_mass_storage drivers
*/
- if ((request->length - request->actual >= musb_ep->packet_sz) &&
- (fifo_count >= musb_ep->packet_sz))
+
+ if (request->short_not_ok && fifo_count == musb_ep->packet_sz)
use_mode_1 = 1;
else
use_mode_1 = 0;
@@ -727,6 +728,27 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
c = musb->dma_controller;
channel = musb_ep->dma;
+ /* We use DMA Req mode 0 in rx_csr, and DMA controller operates in
+* mode 0 only. So we do not get endpoint interrupts due to DMA
+* completion. We only get interrupts from DMA controller.
+*
+* We could operate in DMA mode 1 if we knew the size of the tranfer
+* in advance. For mass storage class, request->length = what the host
+* sends, so that'd work. But for pretty much everything else,
+* request->length is routinely more than what the host sends. For
+* most these gadgets, end of is signified either by a short packet,
+* or filling the last byte of the buffer. (Sending extra data in
+* that last pckate should trigger an overflow fault.) But in mode 1,
+* we don't get DMA completion interrupt for short packets.
+*
+* Theoretically, we could enable DMAReq irq (MUSB_RXCSR_DMAMODE = 1),
+* to get endpoint interrupt on every DMA req, but that didn't seem
+* to work reliably.
+*
+* REVISIT an updated g_file_storage can set req->short_not_ok, which
+* then becomes usable as a runtime "use mode 1" hint...
+*/
+
/* Experimental: Mode1 works with mass storage
use cases */
if (use_mode_1) {
csr |= MUSB_RXCSR_AUTOCLEAR;
diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c
index d62a91f..0e62f50 100644
--- a/drivers/usb/musb/ux500.c
+++ b/drivers/usb/musb/ux500.c
@@ -65,7 +65,7 @@ static int __devinit ux500_probe(struct platform_device *pdev)
struct platform_device *musb;
struct ux500_glue *glue;
struct clk *clk;
-
+ int musbid;
int ret = -ENOMEM;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
diff --git a
Re: host to host usb transfer
Dnia wtorek, 30 października 2012 o 13:19:26 Ming Lei napisał(a): > On Tue, Oct 30, 2012 at 4:24 PM, Marek Floriańczyk > > wrote: > > So lets assume I have UDC and I have compiled g_ether gadget, configured > > this and it works. How to use it? > > From view of OS, it is a common ethernet interface. > > > I mean I have Linux with this g_ether gadget that emulates eth on USB, > > but this is still usb cable connected to it, lets assume the other > > computer is windows (or linux) should I plug this USB cable and also > > compile similar gadget on it? then usb cable is only medium and I have > > two ethernet interfaces > > No, windows supports cdc-ether gadget or rndis ether gadget, which will > be recognized as ethernet interface without other software involved. So this interface is recognized on windows as his own interface? Ip on this interface is configured as it was set by Linux box g_ether driver? And you can connect to this ip from application on windows? Sorry if my questions are a bit lame, but all howtos says how to configure ether gadget on Linux, not how to use this in practice. Does anyone know some Howto/example/description how this actually works? best regards Marek -- To unsubscribe from this list: send the line "unsubscribe 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: host to host usb transfer
On Tue, Oct 30 2012, Marek Floriańczyk wrote: > So this interface is recognized on windows as his own interface? Ip on this > interface is configured as it was set by Linux box g_ether driver? And you > can > connect to this ip from application on windows? Windows sees it as a new network interface, and you need to configure it as any other network interface, ie. set IP address. If you really wanted, you could run DHCP on the USB device so that Windows can get IP address automatically (not 100% if it will or do you need to set it to use DHPC first; I'm not an expert with Windows). -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- pgpWBPGPls2hf.pgp Description: PGP signature
Re: host to host usb transfer
Dnia wtorek, 30 października 2012 o 14:51:33 Michal Nazarewicz napisał(a): > On Tue, Oct 30 2012, Marek Floriańczyk wrote: > > So this interface is recognized on windows as his own interface? Ip on > > this interface is configured as it was set by Linux box g_ether driver? > > And you can connect to this ip from application on windows? > > Windows sees it as a new network interface, and you need to configure it > as any other network interface, ie. set IP address. OK, and I connect to this IP address from windows, and then I'm actually connected to application listening on Linux box g_ether interface? Lets leave windows on side for a moment. How about if I would like to connect to this Linux box with g_ether gadget from other Linux machine ? Do I also need g_ether module on the other machine? best regards Marek -- To unsubscribe from this list: send the line "unsubscribe 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: HDD spins up to slow for USB and/or Mass-Storage Driver
On Fri, 26 Oct 2012, Alan Stern wrote: > On Fri, 26 Oct 2012, Sarah Sharp wrote: > > > On Fri, Oct 26, 2012 at 03:01:32PM -0700, Sarah Sharp wrote: > > > The USB core isn't dropping the endpoints before it calls > > > xhci_check_bandwidth. I remember running into this bug a while back, > > > and I even started on a fix, but then couldn't reproduce the problem. > > > I found the branch with the old fix on it, but it still needs a bit of > > > work. I'll send you a patch on Monday. > > > > Matthias, can you try the attached patch? You should be able to echo 1 > > to the configuration file after this is applied. > > It seems that this patch should go farther than it does. > > Basically, what you are doing amounts to splitting > usb_hcd_alloc_bandwidth() up into two separate routines: one for > altsetting changes and one for config changes. But that's not how the > new code is structured and as a result it ends up looking rather > tortuous. > > Also, I don't like the way we repeat that "find altsetting 0 or use the > first altsetting" logic in several places. We should have a single > routine that determines which alternate interfaces will be installed as > part of a new config. After more thought, it seems that the problem goes deeper. When changing bandwidth settings, you need to figure out which endpoints to remove and which to add. (The code for doing this really should go message.c, not hcd.c, but never mind that for now.) This is complicated by the fact that we are dealing with two different views of the set of active endpoints: the device's view (which is pretty much the same as usbcore's) and the HC's view. It is inevitable that the two views will get out of sync from time to time, because there's no way to update the bandwidth allocation while simultaneously telling the device to switch configs. That's the underlying cause of the original problem. When usb_hcd_alloc_bandwidth sees that a config is being removed, it uses the udev->ep_in and udev->ep_out arrays to figure out which endpoints are going away. This means it is using usbcore's view. But it is sending that information to xhci-hcd, which uses the HC's view. When the two views disagree, it doesn't work. In particular, the views disagree when a Set-Config request fails. The ep_in and ep_out arrays don't get updated until later, when usb_enable_interface runs, but the bandwidth has already been allocated. The easiest fix is probably to move the whole "Initialize the new interface structures..." loop in usb_set_configuration up above the usb_control_msg call. The error recovery would have to be updated accordingly, of course. 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 v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
On Tue, 30 Oct 2012, Ming Lei wrote:
> >> +bool pm_runtime_get_memalloc_noio(struct device *dev)
> >> +{
> >> + bool ret;
> >> + spin_lock_irq(&dev->power.lock);
> >> + ret = dev->power.memalloc_noio_resume;
> >> + spin_unlock_irq(&dev->power.lock);
> >> + return ret;
> >> +}
> >
> > You don't need to acquire and release a spinlock just to read the
> > value. Reading bitfields _is_ SMP-safe; writing them is not.
>
> Thanks for your review.
>
> As you pointed out before, the flag need to be checked before
> resetting usb devices, so the lock should be held to make another
> context(CPU) see the updated value suppose one context(CPU)
> call pm_runtime_set_memalloc_noio() to change the flag at the
> same time.
Okay, I see your point. But acquiring the lock here doesn't solve the
problem. Suppose a thread is about to reset a USB mass-storage device.
It acquires the lock and sees that the noio flag is clear. But before
it can issue the reset, another thread sets the noio flag.
I'm not sure what the best solution is.
> The lock needn't to be held when the function is called inside
> pm_runtime_set_memalloc_noio(), so the bitfield flag should
> be checked directly without holding power lock in dev_memalloc_noio().
Yes.
A couple of other things... Runtime resume can be blocked by runtime
suspend, if a resume is requested while the suspend is in progress.
Therefore the runtime suspend code also needs to save-set-restore the
noio flag.
Also, we should set the noio flag at the start of
usb_stor_control_thread, because everything that thread does can
potentially block an I/O operation.
Lastly, pm_runtime_get_memalloc_noio always returns false when
CONFIG_PM_RUNTIME is disabled. But we still need to prevent I/O during
usb_reset_device even when there's no runtime PM. Maybe the simplest
answer is always to set noio during resets. That would also help with
the race described above.
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: During xHC Initialization (device is not connected), when HC-RESET is asserted, software is not expecting WRC or PRC bit set
On Tue, 30 Oct 2012, Bhavik Kothari wrote:
> Hi Alan,
>
> Please find attached patch file. We have made a patch file in Linux 3.6.1
> version.
>
> Let us know your inputs.
> --- a/linux-3.6.1/drivers/usb/core/hub.c 2012-10-07 21:11:28.0
> +0530
> +++ b/linux-3.6.1/drivers/usb/core/hub.c 2012-10-30 11:23:17.121599414
> +0530
> @@ -1078,6 +1078,14 @@ static void hub_activate(struct usb_hub
> clear_port_feature(hub->hdev, port1,
> USB_PORT_FEAT_C_BH_PORT_RESET);
> }
> + /* Clear Port Reset bit (PORT_RC) */
This comment isn't needed. It's pretty easy to see what bit the
clear_port_feature() call below affects.
> + if ((portchange & USB_PORT_STAT_C_RESET) &&
> +hub_is_superspeed(hub->hdev)) {
You don't need to test for SuperSpeed. Clearing the C_RESET bit is
okay even with non-SuperSpeed hubs.
> + need_debounce_delay = true;
> + clear_port_feature(hub->hdev, port1,
> +USB_PORT_FEAT_C_RESET);
> + }
> +
Otherwise it looks okay.
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: Large files/folders copying ends with I/O error in mass storage
On Tue, 30 Oct 2012, megha dey wrote: > >> From the trace attached,we see that write_10(highlighted command) is > >> taking about 10 seconds,by which time the host is timing out.The host > >> then sends the next test_unit_ready command without getting the status > >> for the previous write.Thus,here we get 2 CBW's without an intervening > >> CSW. > > > > It's not at all clear why the WRITE(10) took so long. Was the FUA bit > > turned on? What happens if you install the mass-storage gadget driver > > with nofua module parameter enabled? > > > > Also, it is clear from this trace that the host is buggy. The > > Bulk-Only spec states that when a command is aborted (as this one was), > > the host must issue a Reset command to the device. > > > > Alan Stern > > > > Hi, > This scenario apears on all standard windows XP PC's and can be > simulated by putting some delay in vfs_write .Also in my case,FUA bit > is not set (nofua is already enabled).This issue only comes with > slower cards (class 2). I don't know what more we can do about this. The host is buggy and the card is too slow for the host. Under those circumstances it doesn't seem possible to avoid a problem. 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 v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern wrote: > > Okay, I see your point. But acquiring the lock here doesn't solve the > problem. Suppose a thread is about to reset a USB mass-storage device. > It acquires the lock and sees that the noio flag is clear. But before > it can issue the reset, another thread sets the noio flag. If the USB mass-storage device is being reseted, the flag should be set already generally. If the flag is still unset, that means the disk/network device isn't added into system(or removed just now), so memory allocation with block I/O should be allowed during the reset. Looks it isn't one problem, isn't it? > I'm not sure what the best solution is. > >> The lock needn't to be held when the function is called inside >> pm_runtime_set_memalloc_noio(), so the bitfield flag should >> be checked directly without holding power lock in dev_memalloc_noio(). > > Yes. > > A couple of other things... Runtime resume can be blocked by runtime > suspend, if a resume is requested while the suspend is in progress. > Therefore the runtime suspend code also needs to save-set-restore the > noio flag. Looks the simplest approach is to handle the noio flag thing at the start and end of rpm_resume. > Also, we should set the noio flag at the start of > usb_stor_control_thread, because everything that thread does can > potentially block an I/O operation. Yes, it should be done, and all GFP_NOIO in usbcore should be converted into GFP_KERNEL together. And the work shouldn't be started until the patchset is merged. > Lastly, pm_runtime_get_memalloc_noio always returns false when > CONFIG_PM_RUNTIME is disabled. But we still need to prevent I/O during > usb_reset_device even when there's no runtime PM. Maybe the simplest > answer is always to set noio during resets. That would also help with > the race described above. I have thought about this. IMO, pm_runtime_get_memalloc_noio should return true always if CONFIG_PM_RUNTIME is unset. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with OHCI on OMAP4430
On Tue, 30 Oct 2012, Mohan V wrote: > >> >> Device not getting detected when > >> >> connected--- > >> >> > >> >> / # [ 135.621002] usbhs_wakeup: Enabling clocks > >> >> [ 135.625762] usbhs_runtime_resume:++ > >> >> [ 135.630371] usbhs_runtime_resume:-- > >> >> [ 135.638183] USB IO PAD Wakeup event triggered## > >> >> [ 135.644958] usbhs_runtime_suspend:++ > >> >> [ 135.649749] usbhs_runtime_suspend:- > >> > > >> > It appears that ohci_irq() didn't run. Did > >> > ohci_finish_controller_resume() get called? > >> > > >> This function is not used in ohci-omap3.c and is used only in ohci-omap.c. > >> Is it necessary to call this function? > > > > It is necessary if the driver supports suspend/resume. As far as I can > > tell, the ohci-omap3 driver does not have this support (at least, not > > in the 3.6 kernel) whereas the ohci-omap driver does. > > > > What driver produced the "usbhs_runtime_suspend" and > > "usbhs_runtime_resume" messages above? (No such messages are present > > in ohci-omap3.c.) Apparently that driver _does_ support > > suspend/resume. > > > This driver is USBHS core driver for OMAP EHCI and OHCI > (drivers/mfd/omap-usb-host.c) Okay. I don't understand why the usbhs_runtime_suspend routine ever got called. Since ohci-omap3 never allows the OHCI controller to be suspended, the parent platform device should never get suspended either. What do the various files in the /sys/devices/.../ohci-omap3.0/power directory show? What about the corresponding files in the power subdirectory of the parent device? 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 v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
On Wed, Oct 31, 2012 at 12:00 AM, Ming Lei wrote: > > Looks the simplest approach is to handle the noio flag thing at the start and > end of rpm_resume. Sorry, that doesn't work, runtime_suspend need that too because memory allocation with block I/O might deadlock when doing I/O on the same device. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
On Wednesday 31 October 2012 00:00:56 Ming Lei wrote: > On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern > wrote: > > > > > Okay, I see your point. But acquiring the lock here doesn't solve the > > problem. Suppose a thread is about to reset a USB mass-storage device. > > It acquires the lock and sees that the noio flag is clear. But before > > it can issue the reset, another thread sets the noio flag. > > If the USB mass-storage device is being reseted, the flag should be set > already generally. If the flag is still unset, that means the disk/network > device isn't added into system(or removed just now), so memory allocation > with block I/O should be allowed during the reset. Looks it isn't one problem, > isn't it? I am afraid it is, because a disk may just have been probed as the deviceis being reset. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB fixes for v3.7-rc4
On Tue, Oct 30, 2012 at 02:47:50PM +0200, Felipe Balbi wrote: > Hi Greg, > > Judging by how things are going, this is likely to be my last pull request > for v3.7-rc cycle, unless someone finds a big regression which we really must > fix during v3.7-rc. > > It's rather small; just a revert, a Kconfig change and the addition of a > variable to a function. In fact, it's so small that I've added the full > combined diff below FYI. > > Let me know if you want me to change anything. > > cheers > > The following changes since commit 1cb60156defa4f23d5318ea1ddd400f25b2d0ce5: > > usb: renesas_usbhs: fixup dma transfer stall (2012-10-23 09:44:37 +0300) Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
On Wed, 31 Oct 2012, Ming Lei wrote: > On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern > wrote: > > > > > Okay, I see your point. But acquiring the lock here doesn't solve the > > problem. Suppose a thread is about to reset a USB mass-storage device. > > It acquires the lock and sees that the noio flag is clear. But before > > it can issue the reset, another thread sets the noio flag. > > If the USB mass-storage device is being reseted, the flag should be set > already generally. If the flag is still unset, that means the disk/network > device isn't added into system(or removed just now), so memory allocation > with block I/O should be allowed during the reset. Looks it isn't one problem, > isn't it? As Oliver said, it can be a problem. > > Lastly, pm_runtime_get_memalloc_noio always returns false when > > CONFIG_PM_RUNTIME is disabled. But we still need to prevent I/O during > > usb_reset_device even when there's no runtime PM. Maybe the simplest > > answer is always to set noio during resets. That would also help with > > the race described above. > > I have thought about this. IMO, pm_runtime_get_memalloc_noio should > return true always if CONFIG_PM_RUNTIME is unset. That's okay as long as the only user of pm_runtime_get_memalloc_noio (apart from the runtime PM core) is usbcore. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Removing the use of VLAIS from the Linux Kernel
The use of variable length arrays in structs (VLAIS) in the Linux Kernel code precludes the use of compilers which don't implement VLAIS (for instance the Clang compiler). The LLVMLinux Project is working towards the ability of providing the Linux kernel developer the choice of using the Clang compiler toolchain. This is a part of a series of patches which remove the use of VLAIS from crypto code, dm-crypt, jbd2, libcrc32c, netfilter, and usb gadget. Other patches to allow Clang to be used will follow. Behan Webster (2): Helper macros used for replacing the use of VLAIS Remove VLAIS usage from gadget code drivers/usb/gadget/f_fs.c | 106 ++--- include/linux/valign.h| 87 + 2 files changed, 148 insertions(+), 45 deletions(-) create mode 100644 include/linux/valign.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Remove VLAIS usage from gadget code
The use of variable length arrays in structs (VLAIS) in the Linux Kernel code
precludes the use of compilers which don't implement VLAIS (for instance the
Clang compiler). This patch instead calculates offsets into the kmalloc-ed
memory buffer using macros from valign.h.
Signed-off-by: Behan Webster
---
drivers/usb/gadget/f_fs.c | 106 ++---
1 file changed, 61 insertions(+), 45 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 64c4ec1..ca6cacc 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1875,6 +1876,15 @@ error:
return ret;
}
+static void __ffs_init_stringtabs(struct usb_gadget_strings **stringtabs,
+ struct usb_gadget_strings *t, unsigned len)
+{
+ do {
+ *stringtabs++ = t++;
+ } while (--len);
+ *stringtabs = NULL;
+}
+
static int __ffs_data_got_strings(struct ffs_data *ffs,
char *const _data, size_t len)
{
@@ -1911,31 +1921,26 @@ static int __ffs_data_got_strings(struct ffs_data *ffs,
/* Allocate everything in one chunk so there's less maintenance. */
{
- struct {
- struct usb_gadget_strings *stringtabs[lang_count + 1];
- struct usb_gadget_strings stringtab[lang_count];
- struct usb_string strings[lang_count*(needed_count+1)];
- } *d;
- unsigned i = 0;
-
- d = kmalloc(sizeof *d, GFP_KERNEL);
+ int strtabslen = paddedsize(0, lang_count+1,
+ struct usb_gadget_strings *, struct usb_gadget_strings);
+ int strtablen = paddedsize(strtabslen, lang_count,
+ struct usb_gadget_strings, struct usb_string);
+ int strlen = paddedsize(strtabslen + strtablen,
+ lang_count*(needed_count+1), struct usb_string, int);
+
+ stringtabs = kmalloc(strtabslen + strtablen + strlen,
+ GFP_KERNEL);
if (unlikely(!d)) {
kfree(_data);
return -ENOMEM;
}
- stringtabs = d->stringtabs;
- t = d->stringtab;
- i = lang_count;
- do {
- *stringtabs++ = t++;
- } while (--i);
- *stringtabs = NULL;
-
- stringtabs = d->stringtabs;
- t = d->stringtab;
- s = d->strings;
+ t = paddedstart(stringtabs, strtabslen,
+ struct usb_gadget_strings);
+ s = paddedstart(t, strtablen, struct usb_string);
strings = s;
+
+ __ffs_init_stringtabs(stringtabs, t, lang_count);
}
/* For each language */
@@ -2209,17 +2214,23 @@ static int ffs_func_bind(struct usb_configuration *c,
int ret;
- /* Make it a single chunk, less management later on */
- struct {
- struct ffs_ep eps[ffs->eps_count];
- struct usb_descriptor_header
- *fs_descs[full ? ffs->fs_descs_count + 1 : 0];
- struct usb_descriptor_header
- *hs_descs[high ? ffs->hs_descs_count + 1 : 0];
- short inums[ffs->interfaces_count];
- char raw_descs[high ? ffs->raw_descs_length
- : ffs->raw_fs_descs_length];
- } *data;
+ struct ffs_ep *eps;
+ struct usb_descriptor_header **fs_descs;
+ struct usb_descriptor_header **hs_descs;
+ short *inums;
+ char *raw_descs;
+
+ int epslen = paddedsize(0, ffs->eps_count,
+ struct ffs_ep, struct usb_descriptor_header);
+ int fsdlen = paddedsize(epslen, full ? ffs->fs_descs_count + 1 : 0,
+ struct usb_descriptor_header,
+ struct usb_descriptor_header);
+ int hsdlen = paddedsize(fsdlen, high ? ffs->hs_descs_count + 1 : 0,
+ struct usb_descriptor_header, short);
+ int inumlen = paddedsize(hsdlen, ffs->interfaces_count, short, char);
+ int rawlen = paddedsize(inumlen,
+ high ? ffs->raw_descs_length : ffs->raw_fs_descs_length,
+ char, int);
ENTER();
@@ -2227,21 +2238,28 @@ static int ffs_func_bind(struct usb_configuration *c,
if (unlikely(!(full | high)))
return -ENOTSUPP;
- /* Allocate */
- data = kmalloc(sizeof *data, GFP_KERNEL);
+ /* Allocate a single chunk, less management later on */
+ eps = kmalloc(epslen+fsdlen+hsdlen+inumlen+rawlen, GFP_KERNEL);
if (unlikely(!data))
return -ENOMEM;
+ /* Calculate start of each variable in the allo
[PATCH 1/2] Helper macros used for replacing the use of VLAIS
The use of variable length arrays in structs (VLAIS) in the Linux Kernel code precludes the use of compilers which don't implement VLAIS (for instance the Clang compiler). This new header file contains macros which can be used to calculate the size and offset of variables in an allocated buffer of memory taking into account alignment issues. Signed-off-by: Behan Webster --- include/linux/valign.h | 87 1 file changed, 87 insertions(+) create mode 100644 include/linux/valign.h diff --git a/include/linux/valign.h b/include/linux/valign.h new file mode 100644 index 000..b39381b --- /dev/null +++ b/include/linux/valign.h @@ -0,0 +1,87 @@ +/* + * Variable alignment macros used to break up a larger chunk of memory into + * smaller variables. Meant to be used to replace the use of Variable Length + * Arrays In Structures (VLAIS) + * + * Copyright (C) 2012 Behan Webster + */ + +#ifndef _VALIGN_H_ +#define _VALIGN_H_ + +/** + * truncalign() - Align a memory address by truncation + * @num: Address or size to align + * @padwidth: Number of byte upon which to align + * + * Truncate an address or size to a particular memory alignment. + * Used by truncalign(). + */ +#define truncalign(num, padwidth) ((long)(num) & ~((padwidth)-1)) + +/** + * padalign() - Align a memory address by padding + * @num: Address or size to align + * @padwidth: Number of byte upon which to align + * + * Pad out an address or size to a particular memory alignment + * Used by paddedsize() and paddedstart(). + */ +#define padalign(num, padwidth) \ + truncalign((long)(num) + ((padwidth)-1), padwidth) + +/** + * paddedsize() - Calculate the size of an chunk of aligned memory + * @offset:Unaligned offset to the start of the chunk size being calculated + * @num: The number of variables in the array of "type" (can be 1) + * @type: The type of variables in the array + * @nexttype: The type of the next variable in the large piece of memory + * + * Calculate the size that a variable (or array) will take as a part of a + * larger piece of memory. Takes into account a potentially unaligned offset + * into the larger piece of allocated memory, the alignment of the variable + * type, and the alignement of the type of the variable to be used after that. + * + * Example: size_t l = paddedsize(1, 2, short, int); + * + * The example above would give you a padded size of 6 bytes: 2x 16-bit shorts, + * starting at 2 bytes into the buffer (the offset of 1 byte being padded out + * to 2 bytes) followed by 2 bytes of padding so that the next type (a 32-bit + * int) would be 32-bit aligned. looking like this: + * + * 0: O.SS SS.. + *\-/ <-- 2 shorts + 2 bytes of padding = size of 6 bytes + * + * O = The offset + * . = Padding bytes + * S = 2 shorts + * i = int which will theoretically be next + */ +#define paddedsize(offset, num, type, nexttype) (padalign((offset) \ + + (num) * sizeof(type), __alignof__(nexttype)) - (offset)) + +/** + * paddedstart() - Calculate the start of a chunk of aligned memory + * @ptr: Pointer from which to calculate the start of the chunk + * @offset:Offset from the ptr to the start of the chunk being calculated + * @type: The type of variable in the chunk of memory + * + * Calculate the start address of a variable based on the offset from an + * address, aligned based on the type of the variable specified. + * + * Example: char *data = kmalloc(size, GFP_KERNEL); + * long *var = paddedstart(data, 12, long); + * + * The example above on a 64-bit machine would return the equivalent of + * &buffer[16] since a long needs to be 8 byte aligned. + * + * 0: + * ^ <-- The start address of the long + * O = The offset + * . = Padding bytes + * L = The long + */ +#define paddedstart(ptr, offset, type) \ + (type *)padalign((long)(ptr)+(offset), __alignof__(type)) + +#endif -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: host to host usb transfer
On Tue, Oct 30 2012, Marek Floriańczyk wrote: > Lets leave windows on side for a moment. How about if I would like to connect > to this Linux box with g_ether gadget from other Linux machine ? Do I also > need g_ether module on the other machine? No. g_ether is USB gadget, it is functional only on the USB device. USB host, needs a host side driver. Your Linux box should detect it automatically and create a new “usb0” network interface when you connect your USB device running g_ether. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- pgpXCvtA5TAbM.pgp Description: PGP signature
Re: usb audio race at disconnect time
On Tue, 30 Oct 2012, Matthieu CASTET wrote: > But I saw a failure I didn't saw before during stress test [1]. > It is hard to say if it is related to your patches : > - we test on a older kernel version and I backported usbaudio from 3.7 with > your > patches > - the start of the trace is missing and it is difficult to understand the list > corruption. > > Matthieu > > [1] > <4>[ 570.313385] bf40: c06ae6a0 c06ae684 0003 0003 8012bd80 413fc082 > > <4>[ 570.313385] bf60: 3b9ac9ff c065bf78 c014f224 c014f230 6053 > <4>[ 570.313415] [] (__irq_svc+0x48/0xa8) from [] > (omap3_enter_idle+0x104/0x134) > <4>[ 570.313446] [] (omap3_enter_idle+0x104/0x134) from > [] > (cpuidle_idle_call+0xa4/0x108) > <4>[ 570.313476] [] (cpuidle_idle_call+0xa4/0x108) from > [] > (cpu_idle+0x40/0x94) > <4>[ 570.313476] [] (cpu_idle+0x40/0x94) from [] > (start_kernel+0x280/0x2e0) > <4>[ 570.313507] unwind: Unknown symbol address c0108984 > <4>[ 570.313507] unwind: Index not found c0108984 > <4>[ 570.313507] ---[ end trace 069f4a4f8aedac20 ]--- > <4>[ 570.324859] [ cut here ] > <4>[ 570.324890] WARNING: at /kernel/omap/lib/list_debug.c:30 > __list_add+0x60/0x80() > <4>[ 570.324920] Process swapper (0) > <4>[ 570.324920] list_add corruption. prev->next should be next (d76f3e50), > but > was ced0bd98. (prev=ced0bb18). > <4>[ 570.324951] Modules linked in: blackberry cdc_acm sierra option usb_wwan > hso omap3_isp tnx_mxt_ts cp210x pl2303 usbserial 88w8688_wlan tun omap_hsmmc > <4>[ 570.325012] [] (unwind_backtrace+0x0/0xf0) from [] > (warn_slowpath_common+0x6c/0x88) > <4>[ 570.325012] [] (warn_slowpath_common+0x6c/0x88) from > [] (warn_slowpath_fmt+0x2c/0x3c) > <4>[ 570.325042] [] (warn_slowpath_fmt+0x2c/0x3c) from [] > (__list_add+0x60/0x80) > <4>[ 570.325073] [] (__list_add+0x60/0x80) from [] > (usb_hcd_link_urb_to_ep+0x88/0xb8) > <4>[ 570.325103] [] (usb_hcd_link_urb_to_ep+0x88/0xb8) from > [] (ehci_urb_enqueue+0x584/0xee0) > <4>[ 570.325103] [] (ehci_urb_enqueue+0x584/0xee0) from > [] > (usb_hcd_submit_urb+0x92c/0x960) This looks a lot like the list corruption reported here: http://marc.info/?l=linux-usb&m=135091910322511&w=2 That message and this one: http://marc.info/?l=linux-usb&m=135092888326443&w=2 contain a couple of diagnostic patches you might want to try. I haven't heard back from Artem on the second patch yet. If you can get this failure to occur reliably, it would help. 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
Workaround for AM35x advisory Advisory 1.1.20
Hi, just found out that those are still in my tree. Patch #4 touches musb_host.c. I can't validate that change, my board runs only in device mode. This fixes the PIO mode of AM35x. It is still broken in DMA mode. I have an workaround in my inbox and I need to apply and verify it first. So for now, everybody who is affected could switch to PIO mode :) 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
[PATCH 1/4] musb: read MUSB_POWER register only when required.
This is part of the workaround for AM35x advisory Advisory 1.1.20.
The advisory says that the IPSS bridge can't handle 8 & 16 bit read
access. An 8bit read access to MUSB_POWER results in an 32bit read
access which also reads INTRTX and therefore may lose interrupts.
This patch tries to minimize reads to MUSB_POWER and perform them only
when required.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/musb/musb_core.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 13a8d0e..84a46b5 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -437,12 +437,12 @@ void musb_hnp_stop(struct musb *musb)
*/
static irqreturn_t musb_stage0_irq(struct musb *musb, u8 int_usb,
- u8 devctl, u8 power)
+ u8 devctl)
{
struct usb_otg *otg = musb->xceiv->otg;
irqreturn_t handled = IRQ_NONE;
- dev_dbg(musb->controller, "<== Power=%02x, DevCtl=%02x,
int_usb=0x%x\n", power, devctl,
+ dev_dbg(musb->controller, "<== DevCtl=%02x, int_usb=0x%x\n", devctl,
int_usb);
/* in host mode, the peripheral may issue remote wakeup.
@@ -455,6 +455,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
if (devctl & MUSB_DEVCTL_HM) {
void __iomem *mbase = musb->mregs;
+ u8 power;
switch (musb->xceiv->state) {
case OTG_STATE_A_SUSPEND:
@@ -462,6 +463,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
* will stop RESUME signaling
*/
+ power = musb_readb(musb->mregs, MUSB_POWER);
if (power & MUSB_POWER_SUSPENDM) {
/* spurious */
musb->int_usb &= ~MUSB_INTR_SUSPEND;
@@ -625,8 +627,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
}
if (int_usb & MUSB_INTR_SUSPEND) {
- dev_dbg(musb->controller, "SUSPEND (%s) devctl %02x power
%02x\n",
- otg_state_string(musb->xceiv->state), devctl, power);
+ dev_dbg(musb->controller, "SUSPEND (%s) devctl %02x\n",
+ otg_state_string(musb->xceiv->state), devctl);
handled = IRQ_HANDLED;
switch (musb->xceiv->state) {
@@ -1530,12 +1532,11 @@ static irqreturn_t generic_interrupt(int irq, void
*__hci)
irqreturn_t musb_interrupt(struct musb *musb)
{
irqreturn_t retval = IRQ_NONE;
- u8 devctl, power;
+ u8 devctl;
int ep_num;
u32 reg;
devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
- power = musb_readb(musb->mregs, MUSB_POWER);
dev_dbg(musb->controller, "** IRQ %s usb%04x tx%04x rx%04x\n",
(devctl & MUSB_DEVCTL_HM) ? "host" : "peripheral",
@@ -1546,7 +1547,7 @@ irqreturn_t musb_interrupt(struct musb *musb)
*/
if (musb->int_usb)
retval |= musb_stage0_irq(musb, musb->int_usb,
- devctl, power);
+ devctl);
/* "stage 1" is handling endpoint irqs */
--
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
[PATCH 2/4] usb/musb: avoid FADDR read access
This is part of the workaround for AM35x advisory Advisory 1.1.20.
The advisory says that the IPSS bridge can't handle 8 & 16 bit read
access. An 8bit read access to FADDR results in an 32bit read
access which also reads INTRTX and therefore may lose interrupts.
This patch removes any reads to FADDR as they are not really required.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/musb/musb_gadget.c |3 +--
drivers/usb/musb/musb_gadget_ep0.c |6 ++
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index d0b87e7..b430f15 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -2154,10 +2154,9 @@ __acquires(musb->lock)
u8 devctl = musb_readb(mbase, MUSB_DEVCTL);
u8 power;
- dev_dbg(musb->controller, "<== %s addr=%x driver '%s'\n",
+ dev_dbg(musb->controller, "<== %s driver '%s'\n",
(devctl & MUSB_DEVCTL_BDEVICE)
? "B-Device" : "A-Device",
- musb_readb(mbase, MUSB_FADDR),
musb->gadget_driver
? musb->gadget_driver->driver.name
: NULL
diff --git a/drivers/usb/musb/musb_gadget_ep0.c
b/drivers/usb/musb/musb_gadget_ep0.c
index e40d764..c9c1ac4 100644
--- a/drivers/usb/musb/musb_gadget_ep0.c
+++ b/drivers/usb/musb/musb_gadget_ep0.c
@@ -673,10 +673,8 @@ irqreturn_t musb_g_ep0_irq(struct musb *musb)
csr = musb_readw(regs, MUSB_CSR0);
len = musb_readb(regs, MUSB_COUNT0);
- dev_dbg(musb->controller, "csr %04x, count %d, myaddr %d, ep0stage
%s\n",
- csr, len,
- musb_readb(mbase, MUSB_FADDR),
- decode_ep0stage(musb->ep0_state));
+ dev_dbg(musb->controller, "csr %04x, count %d, ep0stage %s\n",
+ csr, len, decode_ep0stage(musb->ep0_state));
if (csr & MUSB_CSR0_P_DATAEND) {
/*
--
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
[PATCH 4/4] usb/musb: Perform only write access on MUSB_INTRTXE
This is part of the workaround for AM35x advisory Advisory 1.1.20.
The advisory says that the IPSS bridge can't handle 8 & 16 bit read
access. An 16bit read access to MUSB_INTRTXE results in an 32bit read
access which also reads INTRRX and therefore may lose interrupts.
This patch uses a shadow register of MUSB_INTRTXE so we only perform
write access to it.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/musb/musb_core.c | 10 ++
drivers/usb/musb/musb_core.h |2 +-
drivers/usb/musb/musb_gadget.c | 17 +++--
drivers/usb/musb/musb_host.c |2 +-
4 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 3065618..78037bf 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -694,7 +694,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
if (is_peripheral_active(musb)) {
/* REVISIT HNP; just force disconnect */
}
- musb_writew(musb->mregs, MUSB_INTRTXE, musb->epmask);
+ musb->intrtxe = musb->epmask;
+ musb_writew(musb->mregs, MUSB_INTRTXE, musb->intrtxe);
musb->intrrxe = musb->epmask & 0xfffe;
musb_writew(musb->mregs, MUSB_INTRRXE, musb->intrrxe);
musb_writeb(musb->mregs, MUSB_INTRUSBE, 0xf7);
@@ -917,7 +918,8 @@ void musb_start(struct musb *musb)
dev_dbg(musb->controller, "<== devctl %02x\n", devctl);
/* Set INT enable registers, enable interrupts */
- musb_writew(regs, MUSB_INTRTXE, musb->epmask);
+ musb->intrtxe = musb->epmask;
+ musb_writew(regs, MUSB_INTRTXE, musb->intrtxe);
musb->intrrxe = musb->epmask & 0xfffe;
musb_writew(regs, MUSB_INTRRXE, musb->intrrxe);
musb_writeb(regs, MUSB_INTRUSBE, 0xf7);
@@ -957,6 +959,7 @@ static void musb_generic_disable(struct musb *musb)
/* disable interrupts */
musb_writeb(mbase, MUSB_INTRUSBE, 0);
+ musb->intrtxe = 0;
musb_writew(mbase, MUSB_INTRTXE, 0);
musb->intrrxe = 0;
musb_writew(mbase, MUSB_INTRRXE, 0);
@@ -2094,7 +2097,6 @@ static void musb_save_context(struct musb *musb)
musb->context.testmode = musb_readb(musb_base, MUSB_TESTMODE);
musb->context.busctl = musb_read_ulpi_buscontrol(musb->mregs);
musb->context.power = musb_readb(musb_base, MUSB_POWER);
- musb->context.intrtxe = musb_readw(musb_base, MUSB_INTRTXE);
musb->context.intrusbe = musb_readb(musb_base, MUSB_INTRUSBE);
musb->context.index = musb_readb(musb_base, MUSB_INDEX);
musb->context.devctl = musb_readb(musb_base, MUSB_DEVCTL);
@@ -2167,7 +2169,7 @@ static void musb_restore_context(struct musb *musb)
musb_writeb(musb_base, MUSB_TESTMODE, musb->context.testmode);
musb_write_ulpi_buscontrol(musb->mregs, musb->context.busctl);
musb_writeb(musb_base, MUSB_POWER, musb->context.power);
- musb_writew(musb_base, MUSB_INTRTXE, musb->context.intrtxe);
+ musb_writew(musb_base, MUSB_INTRTXE, musb->intrtxe);
musb_writew(musb_base, MUSB_INTRRXE, musb->intrrxe);
musb_writeb(musb_base, MUSB_INTRUSBE, musb->context.intrusbe);
musb_writeb(musb_base, MUSB_DEVCTL, musb->context.devctl);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 3e179ad..7fb4819 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -288,7 +288,6 @@ struct musb_csr_regs {
struct musb_context_registers {
u8 power;
- u16 intrtxe;
u8 intrusbe;
u16 frame;
u8 index, testmode;
@@ -314,6 +313,7 @@ struct musb {
u16 hwvers;
u16 intrrxe;
+ u16 intrtxe;
/* this hub status bit is reserved by USB 2.0 and not seen by usbcore */
#define MUSB_PORT_STAT_RESUME (1 << 31)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index bb684f0..28b9790 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1068,7 +1068,6 @@ static int musb_gadget_enable(struct usb_ep *ep,
*/
musb_ep_select(mbase, epnum);
if (usb_endpoint_dir_in(desc)) {
- u16 int_txe = musb_readw(mbase, MUSB_INTRTXE);
if (hw_ep->is_shared_fifo)
musb_ep->is_in = 1;
@@ -1080,8 +1079,8 @@ static int musb_gadget_enable(struct usb_ep *ep,
goto fail;
}
- int_txe |= (1 << epnum);
- musb_writew(mbase, MUSB_INTRTXE, int_txe);
+ musb->intrtxe |= (1 << epnum);
+ musb_writew(mbase, MUSB_INTRTXE, musb->intrtxe);
/* REVISIT if can_bulk_split(), use by updating "tmp";
* likewise high bandwidth periodic tx
@@ -1208,9 +1207,8 @@ static int musb_gadget_di
[PATCH 3/4] usb/musb: Perform only write access on MUSB_INTRRXE
This is part of the workaround for AM35x advisory Advisory 1.1.20.
The advisory says that the IPSS bridge can't handle 8 & 16 bit read
access. An 16bit read access to MUSB_INTRRXE results in an 32bit read
access which also reads INTRUSB and therefore may lose interrupts.
This patch uses a shadow register of MUSB_INTRRXE so we only perform
write access to it.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/musb/musb_core.c | 10 ++
drivers/usb/musb/musb_core.h |3 ++-
drivers/usb/musb/musb_gadget.c | 10 --
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 84a46b5..3065618 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -695,7 +695,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
/* REVISIT HNP; just force disconnect */
}
musb_writew(musb->mregs, MUSB_INTRTXE, musb->epmask);
- musb_writew(musb->mregs, MUSB_INTRRXE, musb->epmask & 0xfffe);
+ musb->intrrxe = musb->epmask & 0xfffe;
+ musb_writew(musb->mregs, MUSB_INTRRXE, musb->intrrxe);
musb_writeb(musb->mregs, MUSB_INTRUSBE, 0xf7);
musb->port1_status &= ~(USB_PORT_STAT_LOW_SPEED
|USB_PORT_STAT_HIGH_SPEED
@@ -917,7 +918,8 @@ void musb_start(struct musb *musb)
/* Set INT enable registers, enable interrupts */
musb_writew(regs, MUSB_INTRTXE, musb->epmask);
- musb_writew(regs, MUSB_INTRRXE, musb->epmask & 0xfffe);
+ musb->intrrxe = musb->epmask & 0xfffe;
+ musb_writew(regs, MUSB_INTRRXE, musb->intrrxe);
musb_writeb(regs, MUSB_INTRUSBE, 0xf7);
musb_writeb(regs, MUSB_TESTMODE, 0);
@@ -956,6 +958,7 @@ static void musb_generic_disable(struct musb *musb)
/* disable interrupts */
musb_writeb(mbase, MUSB_INTRUSBE, 0);
musb_writew(mbase, MUSB_INTRTXE, 0);
+ musb->intrrxe = 0;
musb_writew(mbase, MUSB_INTRRXE, 0);
/* off */
@@ -2092,7 +2095,6 @@ static void musb_save_context(struct musb *musb)
musb->context.busctl = musb_read_ulpi_buscontrol(musb->mregs);
musb->context.power = musb_readb(musb_base, MUSB_POWER);
musb->context.intrtxe = musb_readw(musb_base, MUSB_INTRTXE);
- musb->context.intrrxe = musb_readw(musb_base, MUSB_INTRRXE);
musb->context.intrusbe = musb_readb(musb_base, MUSB_INTRUSBE);
musb->context.index = musb_readb(musb_base, MUSB_INDEX);
musb->context.devctl = musb_readb(musb_base, MUSB_DEVCTL);
@@ -2166,7 +2168,7 @@ static void musb_restore_context(struct musb *musb)
musb_write_ulpi_buscontrol(musb->mregs, musb->context.busctl);
musb_writeb(musb_base, MUSB_POWER, musb->context.power);
musb_writew(musb_base, MUSB_INTRTXE, musb->context.intrtxe);
- musb_writew(musb_base, MUSB_INTRRXE, musb->context.intrrxe);
+ musb_writew(musb_base, MUSB_INTRRXE, musb->intrrxe);
musb_writeb(musb_base, MUSB_INTRUSBE, musb->context.intrusbe);
musb_writeb(musb_base, MUSB_DEVCTL, musb->context.devctl);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 4e9cf4e..3e179ad 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -288,7 +288,7 @@ struct musb_csr_regs {
struct musb_context_registers {
u8 power;
- u16 intrtxe, intrrxe;
+ u16 intrtxe;
u8 intrusbe;
u16 frame;
u8 index, testmode;
@@ -313,6 +313,7 @@ struct musb {
struct work_struct irq_work;
u16 hwvers;
+ u16 intrrxe;
/* this hub status bit is reserved by USB 2.0 and not seen by usbcore */
#define MUSB_PORT_STAT_RESUME (1 << 31)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index b430f15..bb684f0 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1108,7 +1108,6 @@ static int musb_gadget_enable(struct usb_ep *ep,
musb_writew(regs, MUSB_TXCSR, csr);
} else {
- u16 int_rxe = musb_readw(mbase, MUSB_INTRRXE);
if (hw_ep->is_shared_fifo)
musb_ep->is_in = 0;
@@ -1120,8 +1119,8 @@ static int musb_gadget_enable(struct usb_ep *ep,
goto fail;
}
- int_rxe |= (1 << epnum);
- musb_writew(mbase, MUSB_INTRRXE, int_rxe);
+ musb->intrrxe |= (1 << epnum);
+ musb_writew(mbase, MUSB_INTRRXE, musb->intrrxe);
/* REVISIT if can_bulk_combine() use by updating "tmp"
* likewise high bandwidth periodic rx
@@ -1214,9 +1213,8 @@ static int musb_gadget_disable(struct usb_ep *ep)
musb_writew(musb->mregs, MUSB_INTRTXE, int_txe);
musb_wr
Re: [PATCH v2 3/3] usb/dummy_hcd: assign endpoint on enqeue on host side
On Tue, 30 Oct 2012, Sebastian Andrzej Siewior wrote: > * Alan Stern | 2012-10-29 12:04:10 [-0400]: > > >Was that really the problem? My memory is not what it was three weeks > >ago... > > > >If so, there's a simpler solution. The list_for_each_entry_safe() > >loop in dummy_timer() should not consider URBs that were added after > >the loop started. That ought to be easy enough to implement. (One > >solution: Increment a counter each time dummy_timer() runs, and store a > >copy of the counter value in each urbp during submission. Exit the > >loop when the stored counter value in urbp is equal to the current > >counter.) > > > >This will prevent you from getting into an infinite loop in atomic > >context. Of course, the resubmission problem would still exist, but > >that's true with non-emulated gadgets too. > > > >Alan Stern > > Okay. So now I added an interval check. It looks better. However if you > prefer the "don't check URBs that were added during completion" way then > I could try that. This would start that I remove the "restart:" label > which is used after URB completion. Real HCDs might or might not check the status of URBs that were submitted during a completion. While it probably doesn't matter very much, I think we should not check them, on the theory that a just-submitted URB most likely hasn't had time to complete. > --- > dummy_urb_enqueue() now assigns the endpoint to the qh structure if it > finds one. Plus in case of an INT URB we track the interval so we don't > schedule the packet too often. In theory you should implement an entire scheduler for periodic transfers so that the bandwidth doesn't all get used up. In practice this isn't likely to matter much, because one device isn't likely to use all the bandwidth. > If UDC disables the endpoint (on the device side) the endpoint information > is removed from the qh as well. I think real HW would timeout on > transfer (and return -EPROTO). Yes. You should do the same thing. The host isn't supposed to know anything about what the device does, except for what it can learn over the bus. > With this change the, the busy loop which occurs if the host always > re-queues an INT URB in the completion is gone because we "skip" this qh > until the interval. Your patch uses jiffies for comparison of time intervals. This won't work well in situations where HZ is too small. It would be better to count the timer callbacks and let each callback correspond to one frame (or 8 uframes). Or maybe adjust it dynamically, based on the actual time interval between callbacks. 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] Helper macros used for replacing the use of VLAIS
On Tue, Oct 30, 2012 at 02:25:19PM -0400, Behan Webster wrote: > The use of variable length arrays in structs (VLAIS) in the Linux Kernel code > precludes the use of compilers which don't implement VLAIS (for instance the > Clang compiler). This new header file contains macros which can be used to > calculate the size and offset of variables in an allocated buffer of memory > taking into account alignment issues. > > Signed-off-by: Behan Webster > --- > include/linux/valign.h | 87 > > 1 file changed, 87 insertions(+) > create mode 100644 include/linux/valign.h You sent the same patch here, to two different trees (usb and networking). That's not good, what happens if they both apply them? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [trivial] usb: Fix typo in drivers/usb
On Fri, Oct 26, 2012 at 11:43:19PM +0900, Masanari Iida wrote: > Correct spelling typo in debug message within drivers/usb. > > Signed-off-by: Masanari Iida This no longer applies, please redo it against the latest linux-next tree. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Helper macros used for replacing the use of VLAIS
On 12-10-30 03:20 PM, Greg KH wrote: On Tue, Oct 30, 2012 at 02:25:19PM -0400, Behan Webster wrote: The use of variable length arrays in structs (VLAIS) in the Linux Kernel code precludes the use of compilers which don't implement VLAIS (for instance the Clang compiler). This new header file contains macros which can be used to calculate the size and offset of variables in an allocated buffer of memory taking into account alignment issues. Signed-off-by: Behan Webster --- include/linux/valign.h | 87 1 file changed, 87 insertions(+) create mode 100644 include/linux/valign.h You sent the same patch here, to two different trees (usb and networking). That's not good, what happens if they both apply them? Good point. My mistake. People in both subsystems needed to see the patch which is why I sent them. What would have been a better approach? And how can I fix this? Behan -- Behan Webster beh...@converseincode.com -- To unsubscribe from this list: send the line "unsubscribe 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] Helper macros used for replacing the use of VLAIS
On Tue, Oct 30, 2012 at 03:35:24PM -0400, Behan Webster wrote: > On 12-10-30 03:20 PM, Greg KH wrote: > >On Tue, Oct 30, 2012 at 02:25:19PM -0400, Behan Webster wrote: > >>The use of variable length arrays in structs (VLAIS) in the Linux Kernel > >>code > >>precludes the use of compilers which don't implement VLAIS (for instance the > >>Clang compiler). This new header file contains macros which can be used to > >>calculate the size and offset of variables in an allocated buffer of memory > >>taking into account alignment issues. > >> > >>Signed-off-by: Behan Webster > >>--- > >> include/linux/valign.h | 87 > >> > >> 1 file changed, 87 insertions(+) > >> create mode 100644 include/linux/valign.h > >You sent the same patch here, to two different trees (usb and > >networking). That's not good, what happens if they both apply them? > Good point. My mistake. > > People in both subsystems needed to see the patch which is why I sent them. > > What would have been a better approach? And how can I fix this? Send all 3 as a single series, to everyone and ask the different maintainers to work together to figure out who is going to apply what. Yeah, it's tough, but things like this are pretty rare, so they don't come up often. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d3cold breaks my usb 3.0 port (Lenovo X220)
On Sat, Oct 27, 2012 at 10:03:08PM -0700, Andrew Lutomirski wrote: > On Sat, Oct 27, 2012 at 9:59 PM, Andrew Lutomirski wrote: > > I have a Lenovo X220, and d3cold seems to break hotplug on xhci. This > > is 3.6.2-4.fc17.x86_64. > > > > The device is: > > > > 0e:00.0 USB Controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host > > > > Inserting a USB3 flash stick has absolutely no effect, other than some > > lights on the stick flickering for a couple seconds. When I wrote 0 > > to /sys/devices/pci:00/:00:1c.6/:0e:00.0/d3cold_allowed > > with the stick inserted, the kernel immediately detected it, and it > > worked. > > Eek. It's not what I thought it was. The problem persists regardless > of the setting of d3cold_allowed. The stick is only recognized when I > insert it and then *toggle* d3cold_allowed. Setting power/control to > "on" seems to fix it. Was that power/control for the PCI host controller? If you allow D3 cold, plug in the USB device, and then run `sudo lsusb -v`, is the device enumerated? It sounds like we're not getting an interrupt for the port status change event. That could be a problem with the host not being able to send the interrupt during D3, or it could be an xHCI driver problem. We've had bugs in the past where a previous port status change bit didn't cleared, and the xHC didn't send a new interrupt for the connect change. This issue smells similar to that. Can you recompile with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on? I'll need the dmesg just before the host controller goes into D3cold, when the hotplug event occurs, and after you trigger a D3 exit by setting power/control to on. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: host to host usb transfer
Hello, I think I got the picture more or less. So in order to use g_ether on this Linux box it should have USB peripheral controller, right? Standard PC computer has something called host controller. Are there computers that have usb host controller - to connect to them "regular" usb devices and also usb peripheral controller, so they could be connected as a device to PC computer? Right now I'm interrested in something called ebox 3350 http://robosavvy.com/store/product_info.php/manufacturers_id/29/products_id/1704 short info from this link above, it has: "USB Servo Bus interfaces (USB2Dynamixel or CM-700 for Robotis servos, USBSC32 for PWM servos, ...)" Does this look as it could support g_ether module ? If not can You propose some hardware similar to this, or to raspberry. I know my question is very vague, sorry, basically I need to run QtCore library, postgresql, openssl on this box. best regards Marek 2012/10/30, Michal Nazarewicz : > On Tue, Oct 30 2012, Marek Floriańczyk wrote: >> Lets leave windows on side for a moment. How about if I would like to >> connect >> to this Linux box with g_ether gadget from other Linux machine ? Do I also >> >> need g_ether module on the other machine? > > No. g_ether is USB gadget, it is functional only on the USB device. > > USB host, needs a host side driver. Your Linux box should detect it > automatically and create a new "usb0" network interface when you connect > your USB device running g_ether. > > -- > Best regards, _ _ > .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o > ..o | Computer Science, Michał "mina86" Nazarewicz(o o) > ooo +--ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 0/3] Removing the use of VLAIS from USB Gadget and netfilter
This is a V2 version of the patch set I previously sent out. Since the use of a new valign.h file spans both the USB and netfilter subsystems, I should have sent out all 3 patches to both trees at once. Assuming all is well, hopefully both subsystems can cooperate to get these patches in without causing conflicts. The use of variable length arrays in structs (VLAIS) in the Linux Kernel code precludes the use of compilers which don't implement VLAIS (for instance the Clang compiler). The LLVMLinux Project is working towards the ability of providing the Linux kernel developer the choice of using the Clang compiler toolchain. This is a part of a series of patches which remove the use of VLAIS from crypto code, dm-crypt, jbd2, libcrc32c, netfilter, and usb gadget. Other patches to allow Clang to be used to compile the Linux kernel will follow. Behan Webster (2): Helper macros used for replacing the use of VLAIS Remove VLAIS usage from gadget code Jan-Simon Möller (1): Remove VLAIS usage from netfilter drivers/usb/gadget/f_fs.c | 106 +-- include/linux/valign.h | 87 +++ net/netfilter/xt_repldata.h | 40 +--- 3 files changed, 172 insertions(+), 61 deletions(-) create mode 100644 include/linux/valign.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/3] Helper macros used for replacing the use of VLAIS
The use of variable length arrays in structs (VLAIS) in the Linux Kernel code precludes the use of compilers which don't implement VLAIS (for instance the Clang compiler). This new header file contains macros which can be used to calculate the size and offset of variables in an allocated buffer of memory taking into account alignment issues. Signed-off-by: Behan Webster --- include/linux/valign.h | 87 1 file changed, 87 insertions(+) create mode 100644 include/linux/valign.h diff --git a/include/linux/valign.h b/include/linux/valign.h new file mode 100644 index 000..b39381b --- /dev/null +++ b/include/linux/valign.h @@ -0,0 +1,87 @@ +/* + * Variable alignment macros used to break up a larger chunk of memory into + * smaller variables. Meant to be used to replace the use of Variable Length + * Arrays In Structures (VLAIS) + * + * Copyright (C) 2012 Behan Webster + */ + +#ifndef _VALIGN_H_ +#define _VALIGN_H_ + +/** + * truncalign() - Align a memory address by truncation + * @num: Address or size to align + * @padwidth: Number of byte upon which to align + * + * Truncate an address or size to a particular memory alignment. + * Used by truncalign(). + */ +#define truncalign(num, padwidth) ((long)(num) & ~((padwidth)-1)) + +/** + * padalign() - Align a memory address by padding + * @num: Address or size to align + * @padwidth: Number of byte upon which to align + * + * Pad out an address or size to a particular memory alignment + * Used by paddedsize() and paddedstart(). + */ +#define padalign(num, padwidth) \ + truncalign((long)(num) + ((padwidth)-1), padwidth) + +/** + * paddedsize() - Calculate the size of an chunk of aligned memory + * @offset:Unaligned offset to the start of the chunk size being calculated + * @num: The number of variables in the array of "type" (can be 1) + * @type: The type of variables in the array + * @nexttype: The type of the next variable in the large piece of memory + * + * Calculate the size that a variable (or array) will take as a part of a + * larger piece of memory. Takes into account a potentially unaligned offset + * into the larger piece of allocated memory, the alignment of the variable + * type, and the alignement of the type of the variable to be used after that. + * + * Example: size_t l = paddedsize(1, 2, short, int); + * + * The example above would give you a padded size of 6 bytes: 2x 16-bit shorts, + * starting at 2 bytes into the buffer (the offset of 1 byte being padded out + * to 2 bytes) followed by 2 bytes of padding so that the next type (a 32-bit + * int) would be 32-bit aligned. looking like this: + * + * 0: O.SS SS.. + *\-/ <-- 2 shorts + 2 bytes of padding = size of 6 bytes + * + * O = The offset + * . = Padding bytes + * S = 2 shorts + * i = int which will theoretically be next + */ +#define paddedsize(offset, num, type, nexttype) (padalign((offset) \ + + (num) * sizeof(type), __alignof__(nexttype)) - (offset)) + +/** + * paddedstart() - Calculate the start of a chunk of aligned memory + * @ptr: Pointer from which to calculate the start of the chunk + * @offset:Offset from the ptr to the start of the chunk being calculated + * @type: The type of variable in the chunk of memory + * + * Calculate the start address of a variable based on the offset from an + * address, aligned based on the type of the variable specified. + * + * Example: char *data = kmalloc(size, GFP_KERNEL); + * long *var = paddedstart(data, 12, long); + * + * The example above on a 64-bit machine would return the equivalent of + * &buffer[16] since a long needs to be 8 byte aligned. + * + * 0: + * ^ <-- The start address of the long + * O = The offset + * . = Padding bytes + * L = The long + */ +#define paddedstart(ptr, offset, type) \ + (type *)padalign((long)(ptr)+(offset), __alignof__(type)) + +#endif -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 3/3] Remove VLAIS usage from netfilter
From: Jan-Simon Möller
The use of variable length arrays in structs (VLAIS) in the Linux Kernel code
precludes the use of compilers which don't implement VLAIS (for instance the
Clang compiler). This patch instead calculates offsets into the kmalloc-ed
memory buffer using macros from valign.h.
Patch from series at
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120507/142707.html
by PaX Team.
Signed-off-by: Jan-Simon Möller
Cc: pagee...@freemail.hu
[Modified to use macros from valign.h]
Signed-off-by: Behan Webster
---
net/netfilter/xt_repldata.h | 40
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/net/netfilter/xt_repldata.h b/net/netfilter/xt_repldata.h
index 6efe4e5..d2b4232 100644
--- a/net/netfilter/xt_repldata.h
+++ b/net/netfilter/xt_repldata.h
@@ -5,31 +5,39 @@
* they serve as the hanging-off data accessed through repl.data[].
*/
+#include
+
#define xt_alloc_initial_table(type, typ2) ({ \
unsigned int hook_mask = info->valid_hooks; \
unsigned int nhooks = hweight32(hook_mask); \
unsigned int bytes = 0, hooknum = 0, i = 0; \
- struct { \
- struct type##_replace repl; \
- struct type##_standard entries[nhooks]; \
- struct type##_error term; \
- } *tbl = kzalloc(sizeof(*tbl), GFP_KERNEL); \
- if (tbl == NULL) \
+ int replsize = paddedsize(0, 1, \
+ struct type##_replace, struct type##_standard); \
+ int entsize = paddedsize(replsize, nhooks, \
+ struct type##_standard, struct type##_error); \
+ int termsize = paddedsize(replsize+entsize, 1, \
+ struct type##_error, int); \
+ struct type##_replace *repl = kzalloc(replsize+entsize+termsize, \
+ GFP_KERNEL); \
+ if (repl == NULL) \
return NULL; \
- strncpy(tbl->repl.name, info->name, sizeof(tbl->repl.name)); \
- tbl->term = (struct type##_error)typ2##_ERROR_INIT; \
- tbl->repl.valid_hooks = hook_mask; \
- tbl->repl.num_entries = nhooks + 1; \
- tbl->repl.size = nhooks * sizeof(struct type##_standard) + \
-sizeof(struct type##_error); \
+ struct type##_standard *entries = paddedstart(repl, replsize, \
+ struct type##_standard); \
+ struct type##_error *term = paddedstart(entries, entsize, \
+ struct type##_error); \
+ strncpy(repl->name, info->name, sizeof(repl->name)); \
+ *term = (struct type##_error)typ2##_ERROR_INIT; \
+ repl->valid_hooks = hook_mask; \
+ repl->num_entries = nhooks + 1; \
+ repl->size = entsize+termsize; \
for (; hook_mask != 0; hook_mask >>= 1, ++hooknum) { \
if (!(hook_mask & 1)) \
continue; \
- tbl->repl.hook_entry[hooknum] = bytes; \
- tbl->repl.underflow[hooknum] = bytes; \
- tbl->entries[i++] = (struct type##_standard) \
+ repl->hook_entry[hooknum] = bytes; \
+ repl->underflow[hooknum] = bytes; \
+ entries[i++] = (struct type##_standard) \
typ2##_STANDARD_INIT(NF_ACCEPT); \
bytes += sizeof(struct type##_standard); \
} \
- tbl; \
+ repl; \
})
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 2/3] Remove VLAIS usage from gadget code
The use of variable length arrays in structs (VLAIS) in the Linux Kernel code
precludes the use of compilers which don't implement VLAIS (for instance the
Clang compiler). This patch instead calculates offsets into the kmalloc-ed
memory buffer using macros from valign.h.
Signed-off-by: Behan Webster
---
drivers/usb/gadget/f_fs.c | 106 ++---
1 file changed, 61 insertions(+), 45 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 64c4ec1..ca6cacc 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1875,6 +1876,15 @@ error:
return ret;
}
+static void __ffs_init_stringtabs(struct usb_gadget_strings **stringtabs,
+ struct usb_gadget_strings *t, unsigned len)
+{
+ do {
+ *stringtabs++ = t++;
+ } while (--len);
+ *stringtabs = NULL;
+}
+
static int __ffs_data_got_strings(struct ffs_data *ffs,
char *const _data, size_t len)
{
@@ -1911,31 +1921,26 @@ static int __ffs_data_got_strings(struct ffs_data *ffs,
/* Allocate everything in one chunk so there's less maintenance. */
{
- struct {
- struct usb_gadget_strings *stringtabs[lang_count + 1];
- struct usb_gadget_strings stringtab[lang_count];
- struct usb_string strings[lang_count*(needed_count+1)];
- } *d;
- unsigned i = 0;
-
- d = kmalloc(sizeof *d, GFP_KERNEL);
+ int strtabslen = paddedsize(0, lang_count+1,
+ struct usb_gadget_strings *, struct usb_gadget_strings);
+ int strtablen = paddedsize(strtabslen, lang_count,
+ struct usb_gadget_strings, struct usb_string);
+ int strlen = paddedsize(strtabslen + strtablen,
+ lang_count*(needed_count+1), struct usb_string, int);
+
+ stringtabs = kmalloc(strtabslen + strtablen + strlen,
+ GFP_KERNEL);
if (unlikely(!d)) {
kfree(_data);
return -ENOMEM;
}
- stringtabs = d->stringtabs;
- t = d->stringtab;
- i = lang_count;
- do {
- *stringtabs++ = t++;
- } while (--i);
- *stringtabs = NULL;
-
- stringtabs = d->stringtabs;
- t = d->stringtab;
- s = d->strings;
+ t = paddedstart(stringtabs, strtabslen,
+ struct usb_gadget_strings);
+ s = paddedstart(t, strtablen, struct usb_string);
strings = s;
+
+ __ffs_init_stringtabs(stringtabs, t, lang_count);
}
/* For each language */
@@ -2209,17 +2214,23 @@ static int ffs_func_bind(struct usb_configuration *c,
int ret;
- /* Make it a single chunk, less management later on */
- struct {
- struct ffs_ep eps[ffs->eps_count];
- struct usb_descriptor_header
- *fs_descs[full ? ffs->fs_descs_count + 1 : 0];
- struct usb_descriptor_header
- *hs_descs[high ? ffs->hs_descs_count + 1 : 0];
- short inums[ffs->interfaces_count];
- char raw_descs[high ? ffs->raw_descs_length
- : ffs->raw_fs_descs_length];
- } *data;
+ struct ffs_ep *eps;
+ struct usb_descriptor_header **fs_descs;
+ struct usb_descriptor_header **hs_descs;
+ short *inums;
+ char *raw_descs;
+
+ int epslen = paddedsize(0, ffs->eps_count,
+ struct ffs_ep, struct usb_descriptor_header);
+ int fsdlen = paddedsize(epslen, full ? ffs->fs_descs_count + 1 : 0,
+ struct usb_descriptor_header,
+ struct usb_descriptor_header);
+ int hsdlen = paddedsize(fsdlen, high ? ffs->hs_descs_count + 1 : 0,
+ struct usb_descriptor_header, short);
+ int inumlen = paddedsize(hsdlen, ffs->interfaces_count, short, char);
+ int rawlen = paddedsize(inumlen,
+ high ? ffs->raw_descs_length : ffs->raw_fs_descs_length,
+ char, int);
ENTER();
@@ -2227,21 +2238,28 @@ static int ffs_func_bind(struct usb_configuration *c,
if (unlikely(!(full | high)))
return -ENOTSUPP;
- /* Allocate */
- data = kmalloc(sizeof *data, GFP_KERNEL);
+ /* Allocate a single chunk, less management later on */
+ eps = kmalloc(epslen+fsdlen+hsdlen+inumlen+rawlen, GFP_KERNEL);
if (unlikely(!data))
return -ENOMEM;
+ /* Calculate start of each variable in the allo
Re: host to host usb transfer
On Tue, Oct 30 2012, Marek Floriańczyk wrote: > So in order to use g_ether on this Linux box it should have USB > peripheral controller, right? UDC, USB Device Controller > Standard PC computer has something called host controller. HCI, Host Controller Interface > Are there computers that have usb host controller - to connect to them > "regular" usb devices and also usb peripheral controller, so they > could be connected as a device to PC computer? If by “computer” you mean a regular PC than I have never seen one that has that out of the box, but you can buy an extension card with an UDC. There's actually also something called USB OTG which can be used as both host and device (depending on what it's connected to), but I've actually never played with it. > Right now I'm interrested in something called ebox 3350 > http://robosavvy.com/store/product_info.php/manufacturers_id/29/products_id/1704 As far as I can see, it does not have UDC. Only HCI. > If not can You propose some hardware similar to this, or to raspberry. > I know my question is very vague, sorry, basically I need to run > QtCore library, postgresql, openssl on this box. You could take a look at Beagle Board, Beagle Bone or Panda Board. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- pgpwzkmzRSyjd.pgp Description: PGP signature
Re: [PATCH v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
On Wed, Oct 31, 2012 at 12:30 AM, Oliver Neukum wrote: >> If the USB mass-storage device is being reseted, the flag should be set >> already generally. If the flag is still unset, that means the disk/network >> device isn't added into system(or removed just now), so memory allocation >> with block I/O should be allowed during the reset. Looks it isn't one >> problem, >> isn't it? > > I am afraid it is, because a disk may just have been probed as the deviceis > being reset. Yes, it is probable, and sounds like similar with 'root_wait' problem, see prepare_namespace(): init/do_mounts.c, so looks no good solution for the problem, and maybe we have to set the flag always before resetting usb device. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
On Wed, Oct 31, 2012 at 10:08 AM, Ming Lei wrote: >> I am afraid it is, because a disk may just have been probed as the deviceis >> being reset. > > Yes, it is probable, and sounds like similar with 'root_wait' problem, see > prepare_namespace(): init/do_mounts.c, so looks no good solution > for the problem, and maybe we have to set the flag always before resetting > usb device. The below idea may help the problem which 'memalloc_noio' flag isn't set during usb_reset_device(). - for usb mass storage device, call pm_runtime_set_memalloc_noio(true) inside usb_stor_probe2() and uas_probe(), and call pm_runtime_set_memalloc_noio(false) inside uas_disconnect() and usb_stor_disconnect(). - for usb network device, register_netdev() is always called inside usb interface's probe(), looks no such problem. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Endpoint is not halted
Sarah,
This patch works for me. Would you please help submit and merge this patch ?
On Sat, Oct 27, 2012 at 1:51 AM, Sarah Sharp
wrote:
> On Fri, Oct 26, 2012 at 02:50:20PM +0800, Shimmer Huang wrote:
>> Sarah,
>>
>> We've found the TD_size issue when developing a new XHCI host controller
>> also:
>> 1. need fix xhci_td_remainder() and xhci_v1_0_td_remainder()
>
> What needed to be fixed in xhci_td_remainder()?
>
>> 2. we need to use DIV_ROUND_UP() instead of roundup() when we
>> calculating total_packet_count .
>> As in recent kernel versions, roundup() is defined as follow
>> #define roundup(x, y) ( \
>> { \
>> const typeof(y) __y = y;\
>> (((x) + (__y - 1)) / __y) * __y;\
>> } \
>> )
>>
>> And DIV_ROUND_UP is defined as
>> #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
>>
>> The function roundup() is used several times in xhci-ring.c to
>> calculate the number of packets needed:
>> total_packet_count = roundup(td_len,
>> usb_endpoint_maxp(&urb->ep->desc));
>>
>> total_packet_count = roundup(urb->transfer_buffer_length,
>> usb_endpoint_maxp(&urb->ep->desc));
>
> Yes, you're right about needing to use DIV_ROUND_UP() instead of
> roundup(). Obviously I didn't test this patch very well. :-/
>
> Chintan, I've updated that branch with the DIV_ROUND_UP() fix.
> Please test with that instead, by running:
>
> git fetch orgin
> git reset --hard for-usb-linus-queue
>
> And then recompile and try it out.
>
> Shimmer, the fix diff is attached. Please look it over and see if I've
> missed any of the TD size fixes you found during your xHCI host bring
> up. Did you happen to find any other issues in your testing?
Sarah, this patch contains all the fixes we found in our bringup.
We will continue to work with Linux xHCI driver and will report any issues
we found in xHCI driver to you and the mailing list. Thanks.
>
> Sarah Sharp
>
>>
>> On Fri, Oct 26, 2012 at 7:25 AM, Sarah Sharp
>> wrote:
>> > Hi Chintan,
>> >
>> > I think I have a fix for the TD size issue. Can you install a custom
>> > kernel and test it out on your host controller?
>> >
>> > The directions for building a custom kernel are here:
>> > http://kernelnewbies.org/KernelBuild
>> >
>> > Instead of running any of the commands in "Which kernel to build?"
>> > section, use these commands instead:
>> >
>> > git clone git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git -b
>> > for-usb-linus-queue
>> > cd xhci
>> >
>> > Use the "Duplicating your current config" section.
>> >
>> > If you have trouble booting the 3.7-rc2 kernel, let me know and I'll
>> > rebase the patch against a stable kernel version.
>> >
>> > Sarah Sharp
>> >
>> >
>> > On Thu, Oct 25, 2012 at 03:32:08PM -0700, Sarah Sharp wrote:
>> >> Going back over your example, it does look there is a couple bugs in the
>> >> Linux xHCI TD size calculations. Notes are below, I'll send you a patch
>> >> to test out on your host controller shortly.
>> >>
>> >> Thanks for catching this!
>> >>
>> >> Sarah Sharp
>> >>
>> >> On Thu, Oct 25, 2012 at 02:24:04PM -0700, Sarah Sharp wrote:
>> >> > On Fri, Oct 19, 2012 at 11:29:44AM +0530, Chintan Mehta wrote:
>> >> > > > > > 2. For Bulk Endpoint:
>> >> > > > > >
>> >> > > > > >- *Driver can put a TD with total TD transfer size less than
>> >> > > > maxpacket
>> >> > > > > >size and more than 1 TRB?*
>> >> > > > > >- For example, Maxpacketsize is 1K. And TD contains 3 TRBs
>> >> > > > > > as below:
>> >> > > > > > - 1st trb with TRB transfer length 600 Bytes, chain bit 1
>> >> > > > > > and
>> >> > > > > > TDSize 0
>> >> > > > > > - 2nd trb with TRB transfer length 200 Bytes, chain bit 1
>> >> > > > > > and
>> >> > > > > > TDSize 0
>> >> > > > > > - 3rd trb with TRB transfer length 100 Bytes, chain bit 0
>> >> > > > > > and
>> >> > > > > > TDSize 0
>> >> > > > > >- *What should be the value of TDSize in above TRBs of TD?*
>> >> > > >
>> >> > > > Again, see section 4.11.2.4.
>> >> > > >
>> >> > > > TRB 1 600 (600 + 200 + 100) >> 10 = 0
>> >> > > > TRB 2 200 (200 + 100) >> 10 = 0
>> >> > > > TRB 3 100 (100) >> 10 = 0
>> >>
>> >> Let's see what the TD size for a 1.0 host controller should be here.
>> >>
>> >> TD packet count =
>> >> roundup(TD size / max packet size) =
>> >> roundup(900 / 1024) = 1
>> >>
>> >> Packets Transferred (TRB 1) =
>> >> rounddown(TRB length sum(n) / max packet size)
>> >>
>> >> where TRB length sum is the sum of the trb lengths up to and including
>> >> this TRB, so
>> >>
>> >> Packets Transferred (TRB 1) = rounddown(600 / 1024) = 0
>> >>
>> >> TD size = (TD packet count - Packets Transferred)
>> >>
>> >> Therefore,
>> >>
>> >> TD size(TRB 1) = (1 - 0) = 1
>> >>
>> >> Packets Transferred (TRB 2) =
>> >> rounddown((600 + 200) / 1024) = 0
>> >> TD size(TRB 2) = (1 - 0) = 1
>> >>
>> >> The TD size for
Linux USB gadget mass storage
Hi, I am using Linux USB gadget mass storage. I meet with problem in file_storage.c. The bh->outreq->context in get_next_command() is not equal to bh. victor CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and may be protected by legal privilege. If you are not the intended addressee (or authorized to receive for the addressee). be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation. KeyASIC Inc. -- To unsubscribe from this list: send the line "unsubscribe 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 usb-next 4/4] USB: option: idVendor and idProduct are __le16
The exception is needed on big endian systems too. Signed-off-by: Bjørn Mork --- drivers/usb/serial/option.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c index 0969260..330ac1c 100644 --- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -1359,9 +1359,9 @@ static int option_probe(struct usb_serial *serial, * Don't bind network interface on Samsung GT-B3730, it is handled by * a separate module. */ - if (dev_desc->idVendor == SAMSUNG_VENDOR_ID && - dev_desc->idProduct == SAMSUNG_PRODUCT_GT_B3730 && - iface_desc->bInterfaceClass != USB_CLASS_CDC_DATA) + if (dev_desc->idVendor == cpu_to_le16(SAMSUNG_VENDOR_ID) && + dev_desc->idProduct == cpu_to_le16(SAMSUNG_PRODUCT_GT_B3730) && + iface_desc->bInterfaceClass != USB_CLASS_CDC_DATA) return -ENODEV; /* Store device id so we can use it during attach. */ -- 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
[PATCH v2 usb-next 1/4] USB: option: never bind to a usb-storage interface
There are many modems in addition to the D-Link DWM 652 exposing the CD interface in modem mode, and some expose an integrated card reader as well. Always ignore these interfaces. Signed-off-by: Bjørn Mork --- drivers/usb/serial/option.c |9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c index 5dee7d6..6eaff45 100644 --- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -1341,13 +1341,8 @@ static int option_probe(struct usb_serial *serial, &serial->interface->cur_altsetting->desc; struct usb_device_descriptor *dev_desc = &serial->dev->descriptor; - /* -* D-Link DWM 652 still exposes CD-Rom emulation interface in modem -* mode. -*/ - if (dev_desc->idVendor == DLINK_VENDOR_ID && - dev_desc->idProduct == DLINK_PRODUCT_DWM_652 && - iface_desc->bInterfaceClass == 0x08) + /* Never bind to the CD-Rom emulation interface */ + if (iface_desc->bInterfaceClass == 0x08) return -ENODEV; /* Bandrich modem and AT command interface is 0xff */ -- 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
[PATCH v2 usb-next 2/4] USB: add USB_DEVICE_INTERFACE_CLASS macro
Matching on device and interface class with with unspecified subclass and protocol is sometimes useful. This is slightly different from USB_DEVICE_AND_INTERFACE_INFO which requires the full interface class/subclass/protocol triplet. Signed-off-by: Bjørn Mork --- include/linux/usb.h | 16 1 file changed, 16 insertions(+) diff --git a/include/linux/usb.h b/include/linux/usb.h index f51f998..689b14b 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -808,6 +808,22 @@ static inline int usb_make_path(struct usb_device *dev, char *buf, size_t size) .bcdDevice_hi = (hi) /** + * USB_DEVICE_INTERFACE_CLASS - describe a usb device with a specific interface class + * @vend: the 16 bit USB Vendor ID + * @prod: the 16 bit USB Product ID + * @cl: bInterfaceClass value + * + * This macro is used to create a struct usb_device_id that matches a + * specific interface class of devices. + */ +#define USB_DEVICE_INTERFACE_CLASS(vend, prod, cl) \ + .match_flags = USB_DEVICE_ID_MATCH_DEVICE | \ + USB_DEVICE_ID_MATCH_INT_CLASS, \ + .idVendor = (vend), \ + .idProduct = (prod), \ + .bInterfaceClass = (cl) + +/** * USB_DEVICE_INTERFACE_PROTOCOL - describe a usb device with a specific interface protocol * @vend: the 16 bit USB Vendor ID * @prod: the 16 bit USB Product ID -- 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
[PATCH v2 usb-next 0/4] Some trivial fixes for the option driver.
v2: moved the USB_DEVICE_INTERFACE_CLASS macro to usb.h as suggested by Oliver Neukum. Bjørn Mork (4): USB: option: never bind to a usb-storage interface USB: add USB_DEVICE_INTERFACE_CLASS macro USB: option: replace vendor probe rule with match flags USB: option: idVendor and idProduct are __le16 drivers/usb/serial/option.c | 86 +++ include/linux/usb.h | 16 2 files changed, 54 insertions(+), 48 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
[PATCH v2 usb-next 3/4] USB: option: replace vendor probe rule with match flags
No need for a vendor specific probe exception just to
match on the interface class.
Signed-off-by: Bjørn Mork
---
drivers/usb/serial/option.c | 71 ---
1 file changed, 33 insertions(+), 38 deletions(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 6eaff45..0969260 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -733,23 +733,23 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_620UW) },
{ USB_DEVICE(AXESSTEL_VENDOR_ID, AXESSTEL_PRODUCT_MV110H) },
{ USB_DEVICE(YISO_VENDOR_ID, YISO_PRODUCT_U893) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_C100_1) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_C100_2) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1004) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1005) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1006) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1007) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1008) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1009) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_100A) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_100B) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_100C) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_100D) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_100E) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_100F) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1010) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1011) },
- { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1012) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID,
BANDRICH_PRODUCT_C100_1, 0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID,
BANDRICH_PRODUCT_C100_2, 0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1004,
0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1005,
0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1006,
0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1007,
0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1008,
0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1009,
0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_100A,
0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_100B,
0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_100C,
0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_100D,
0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_100E,
0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_100F,
0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1010,
0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1011,
0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1012,
0xff) },
{ USB_DEVICE(KYOCERA_VENDOR_ID, KYOCERA_PRODUCT_KPC650) },
{ USB_DEVICE(KYOCERA_VENDOR_ID, KYOCERA_PRODUCT_KPC680) },
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6000)}, /* ZTE AC8700 */
@@ -1165,22 +1165,22 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(LONGCHEER_VENDOR_ID, ZOOM_PRODUCT_4597) },
{ USB_DEVICE(HAIER_VENDOR_ID, HAIER_PRODUCT_CE100) },
/* Pirelli */
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_C100_1)},
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_C100_2)},
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1004)},
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1005)},
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1006)},
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1007)},
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1008)},
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1009)},
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_100A)},
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_100B) },
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_100C) },
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_100D) },
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_100E) },
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_100F) },
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1011)},
- { USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1012)},
+ { USB_DEVICE_INTERFACE_CLASS(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_C100_1,
0xff) },
+ { USB_DEVICE_INTERFACE_CLASS(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_C100_2,
0xff
RE: Linux USB gadget mass storage
Hi, In file_storage.c, send_status(), if (transport_is_bbb()), I add the line bh->inreq->buf = bh -> buf, and in get_next_command(), if (transport_is_bbb()), I add the line bh->outreq->context = bh, to make the bh address to be the same. Is this patch ok? victor -Original Message- From: victor [mailto:vic...@keyasic.com] Sent: Wednesday, 31 October, 2012 1:04 PM To: 'linux-usb@vger.kernel.org' Subject: Linux USB gadget mass storage Hi, I am using Linux USB gadget mass storage. I meet with problem in file_storage.c. The bh->outreq->context in get_next_command() is not equal to bh. victor CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and may be protected by legal privilege. If you are not the intended addressee (or authorized to receive for the addressee). be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation. KeyASIC Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
