[GIT PULL] USB fixes for v4.5-rc6
Hi Greg, here's what I hope to be the last pull request for current -rc cycle. Let me know if you want any changes on the contents. cheers The following changes since commit 18558cae0272f8fd9647e69d3fec1565a7949865: Linux 4.5-rc4 (2016-02-14 13:05:20 -0800) are available in the git repository at: http://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v4.5-rc6 for you to fetch changes up to 3b2435192fe917a826c91c8b34032428d6efdfc7: MAINTAINERS: drop OMAP USB and MUSB maintainership (2016-02-23 08:51:39 +0200) usb: fixes for v4.5-rc6 The most important fixes here are: a) yet another fix to dwc3's EP transfer resource assignment logic. This time around we will be pre-allocating transfer resources to avoid any future issues; b) two DMA fixes for the old MUSB driver. c) dwc2's data toggle fix for FS Other than these, we have a few other minor fixes elsewhere. Andrzej Hajda (1): usb: gadget: fsl_qe_udc: fix IS_ERR_VALUE usage Cristian Birsan (2): usb: musb: Fix DMA desired mode for Mentor DMA engine usb: musb: fix DMA for host mode Felipe Balbi (1): MAINTAINERS: drop OMAP USB and MUSB maintainership Geert Uytterhoeven (1): usb: dwc2: USB_DWC2 should depend on HAS_DMA Ivan T. Ivanov (1): usb: phy: msm: Trigger USB state detection work in DRD mode John Youn (2): usb: dwc2: Add extra delay when forcing dr_mode usb: dwc3: Fix assignment of EP transfer resources Marek Szyprowski (2): usb: gadget: remove driver from pending list on probe error usb: gadget: gadgetfs: unregister gadget only if it got successfully registered Simon Appleby (1): usb: gadget: net2280: fix endpoint max packet for super speed connections Tang, Jianqiang (1): usb: dwc2: host: fix the data toggle error in full speed descriptor dma Vardan Mikayelyan (1): usb: dwc2: host: fix logical omissions in dwc2_process_non_isoc_desc MAINTAINERS | 7 ++-- drivers/usb/dwc2/Kconfig| 1 + drivers/usb/dwc2/core.c | 6 drivers/usb/dwc2/hcd_ddma.c | 23 ++-- drivers/usb/dwc2/hcd_intr.c | 8 + drivers/usb/dwc3/core.h | 1 - drivers/usb/dwc3/ep0.c | 5 --- drivers/usb/dwc3/gadget.c | 70 +++-- drivers/usb/gadget/legacy/inode.c | 7 ++-- drivers/usb/gadget/udc/fsl_qe_udc.c | 2 +- drivers/usb/gadget/udc/net2280.h| 15 ++-- drivers/usb/gadget/udc/udc-core.c | 3 +- drivers/usb/musb/musb_host.c| 8 ++--- drivers/usb/phy/phy-msm-usb.c | 20 +++ 14 files changed, 108 insertions(+), 68 deletions(-) -- balbi signature.asc Description: PGP signature
Re: [PATCH 8/9] usb: dwc3: Remove impossible check for of_clk_get_parent_count() < 0
Hi, Stephen Boyd writes: > The check for < 0 is impossible now that > of_clk_get_parent_count() returns an unsigned int. Simplify the > code and update the types. > > Cc: Felipe Balbi > Cc: > Signed-off-by: Stephen Boyd > --- > > Please ack so this can go through clk tree along with patch 1. sure, no problem ;-) patch looks okay Acked-by: Felipe Balbi -- balbi signature.asc Description: PGP signature
Freezable workqueue blocks non-freezable workqueue during the system resume process
Hi Tejun Heo and Florian Mickler, I have a question that during the system resume process, the freezable workqueue can be thawed if there is a non-freezable workqueue is blocked (At uninterruptable state)? My case like below, I have a USB OTG (Micro-AB) cable is at USB Micro-B port, and there is a USB driver on it, and un-plug this cable can wake up system from the suspend. There is a non-freezable workqueue ci_otg will be scheduled after disconnecting OTG cable, and in its worker ci_otg_work, it will try to disconnect USB drive, and flush disk information. But flush disk information is done by freezable workqueue writeback, it seeems workqueue writeback is never got chance to execute, the workqueue ci_otg is waiting there forever, and the system is deadlock. Both change workqueue ci_otg as freezable or change workqueue writeback as non-freezable can fix this problem. The call stack like below: [ 546.987379] writeback S c07de74c 012 2 0x [ 546.993804] Backtrace: [ 546.996307] [] (__schedule) from [] (schedule+0x48/0xa0) [ 547.003370] r10:ef14bc80 r9:ef14ca00 r8: r7:c0045c90 r6:ef14bc80 r5:ef14bc98 [ 547.011325] r4:ef164000 [ 547.013907] [] (schedule) from [] (rescuer_thread+0x290/0x308) [ 547.021490] r4: r3:0008 [ 547.025136] [] (rescuer_thread) from [] (kthread+0xdc/0xf8) [ 547.032459] r10: r9: r8: r7:c0045c90 r6:ef14bc80 r5:ef1526c0 [ 547.040412] r4: [ 547.042993] [] (kthread) from [] (ret_from_fork+0x14/0x24) [ 547.050229] r7: r6: r5:c004b9d8 r4:ef1526c0 [ 555.178869] kworker/u2:13 D c07de74c 0 826 2 0x [ 555.185310] Workqueue: ci_otg ci_otg_work [ 555.189353] Backtrace: [ 555.191849] [] (__schedule) from [] (schedule+0x48/0xa0) [ 555.198912] r10:ee471ba0 r9: r8: r7:0002 r6:ee47 r5:ee471ba4 [ 555.206867] r4:ee47 [ 555.209453] [] (schedule) from [] (schedule_timeout+0x15c/0x1e0) [ 555.217212] r4:7fff r3:edc2b000 [ 555.220862] [] (schedule_timeout) from [] (wait_for_common+0x94/0x144) [ 555.229140] r8: r7:0002 r6:ee47 r5:ee471ba4 r4:7fff [ 555.235980] [] (wait_for_common) from [] (wait_for_completion+0x18/0x1c) [ 555.244430] r10:0001 r9:c0b5563c r8:c0042e48 r7:ef086000 r6:eea4372c r5:ef131b00 [ 555.252383] r4: [ 555.254970] [] (wait_for_completion) from [] (flush_work+0x19c/0x234) [ 555.263177] [] (flush_work) from [] (flush_delayed_work+0x48/0x4c) [ 555.271106] r8:ed5b5000 r7:c0b38a3c r6:eea439cc r5:eea4372c r4:eea4372c [ 555.277958] [] (flush_delayed_work) from [] (bdi_unregister+0x84/0xec) [ 555.286236] r4:eea43520 r3:2153 [ 555.289885] [] (bdi_unregister) from [] (blk_cleanup_queue+0x180/0x29c) [ 555.298250] r5:eea43808 r4:eea43400 [ 555.301909] [] (blk_cleanup_queue) from [] (__scsi_remove_device+0x48/0xb8) [ 555.310623] r7: r6:2153 r5:ededa950 r4:ededa800 [ 555.316403] [] (__scsi_remove_device) from [] (scsi_forget_host+0x64/0x68) [ 555.325028] r5:ededa800 r4:ed5b5000 [ 555.328689] [] (scsi_forget_host) from [] (scsi_remove_host+0x78/0x104) [ 555.337054] r5:ed5b5068 r4:ed5b5000 [ 555.340709] [] (scsi_remove_host) from [] (usb_stor_disconnect+0x50/0xb4) [ 555.349247] r6:ed5b56e4 r5:ed5b5818 r4:ed5b5690 r3:0008 [ 555.355025] [] (usb_stor_disconnect) from [] (usb_unbind_interface+0x78/0x25c) [ 555.363997] r8:c13919b4 r7:edd3c000 r6:edd3c020 r5:ee551c68 r4:ee551c00 r3:c04cdf7c [ 555.371892] [] (usb_unbind_interface) from [] (__device_release_driver+0x8c/0x118) [ 555.381213] r10:0001 r9:edd90c00 r8:c13919b4 r7:ee551c68 r6:c0b546e0 r5:c0b5563c [ 555.389167] r4:edd3c020 [ 555.391752] [] (__device_release_driver) from [] (device_release_driver+0x28/0x34) [ 555.401071] r5:edd3c020 r4:edd3c054 [ 555.404721] [] (device_release_driver) from [] (bus_remove_device+0xe0/0x110) [ 555.413607] r5:edd3c020 r4:ef17f04c [ 555.417253] [] (bus_remove_device) from [] (device_del+0x114/0x21c) [ 555.425270] r6:edd3c028 r5:edd3c020 r4:ee551c00 r3: [ 555.431045] [] (device_del) from [] (usb_disable_device+0xa4/0x1e8) [ 555.439061] r8:edd3c000 r7:eded8000 r6: r5:0001 r4:ee551c00 [ 555.445906] [] (usb_disable_device) from [] (usb_disconnect+0x74/0x224) [ 555.454271] r9:edd90c00 r8:ee551000 r7:ee551c68 r6:ee551c9c r5:ee551c00 r4:0001 [ 555.462156] [] (usb_disconnect) from [] (usb_disconnect+0x1d8/0x224) [ 555.470259] r10:0001 r9:edd9 r8:ee471e2c r7:ee551468 r6:ee55149c r5:ee551400 [ 555.478213] r4:0001 [ 555.480797] [] (usb_disconnect) from [] (usb_remove_hcd+0xa0/0x1ac) [ 555.488813] r10:0001 r9:ee471eb0 r8: r7:ef3d9500 r6:eded810c r5:eded80b0 [ 555.496765] r4:eded8000 [ 555.499351] [] (usb_remove_hcd) from [] (host_stop+0x28/0x64) [ 555.506847] r6:eeb50010 r5:eded8000 r4:eeb51010 [ 555.511563] [] (host_stop) from [] (ci_otg_work+0xc4/0x124) [ 555
Re: [PATCH] usb: chipidea: Configure DMA properties and ops from DT
On Mon, Feb 22, 2016 at 02:07:50PM -0800, Bjorn Andersson wrote: > On Mon 22 Feb 02:03 PST 2016, Srinivas Kandagatla wrote: > > > I'm still puzzled to why the chipidea lives as a child device of the msm > device; but as this is a rather common structure I believe this still > needs to be figured out. > Chipidea is core driver; msm driver is glue layer, it has something platform related. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Error While Connecting Pendrive
Hi, I am getting following error while connecting my pendrive, [ 3793.220454] scsi 5:0:0:0: Direct-Access Kingston DataTraveler 2.0 1.00 PQ: 0 ANSI: 4 [ 3793.220543] device: 'target5:0:0': device_add [ 3793.220562] bus: 'scsi': add device target5:0:0 [ 3793.220590] PM: Adding info for scsi:target5:0:0 [ 3793.220641] device: '5:0:0:0': device_add [ 3793.220676] bus: 'scsi': add device 5:0:0:0 [ 3793.220690] PM: Adding info for scsi:5:0:0:0 [ 3793.220703] bus: 'scsi': driver_probe_device: matched device 5:0:0:0 with driver sd [ 3793.220706] bus: 'scsi': really_probe: probing driver sd with device 5:0:0:0 [ 3793.220711] sd 5:0:0:0: no default pinctrl state [ 3793.220723] device: '5:0:0:0': device_add [ 3793.220754] PM: Adding info for No Bus:5:0:0:0 [ 3793.220771] driver: 'sd': driver_bound: bound to device '5:0:0:0' [ 3793.220774] bus: 'scsi': really_probe: bound device 5:0:0:0 to driver sd [ 3793.220778] device: '5:0:0:0': device_add [ 3793.220796] PM: Adding info for No Bus:5:0:0:0 [ 3793.220812] device: 'sg4': device_add [ 3793.220834] PM: Adding info for No Bus:sg4 [ 3793.220896] sd 5:0:0:0: Attached scsi generic sg4 type 0 [ 3793.220918] device: '5:0:0:0': device_add [ 3793.220943] PM: Adding info for No Bus:5:0:0:0 [ 3793.221427] sd 5:0:0:0: [sdc] 30233588 512-byte logical blocks: (15.4 GB/14.4 GiB) [ 3793.222072] sd 5:0:0:0: [sdc] Write Protect is off [ 3793.222079] sd 5:0:0:0: [sdc] Mode Sense: 45 00 00 00 [ 3793.222706] sd 5:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 3793.222724] device: '8:32': device_add [ 3793.222768] PM: Adding info for No Bus:8:32 [ 3793.222816] device: 'sdc': device_add [ 3793.222853] PM: Adding info for No Bus:sdc [ 3793.238835] sd 5:0:0:0: [sdc] Attached SCSI removable disk [ 3922.968041] usb 1-3: reset high-speed USB device number 5 using ehci-pci [ 3923.100302] usb 1-3: device firmware changed [ 3923.100376] usb 1-3: USB disconnect, device number 5 [ 3923.100382] device: 'ep_81': device_unregister [ 3923.100412] PM: Removing info for No Bus:ep_81 [ 3923.100421] device: 'ep_02': device_unregister [ 3923.100439] PM: Removing info for No Bus:ep_02 [ 3923.100464] bus: 'usb': remove device 1-3:1.0 [ 3923.100477] device: '5:0:0:0': device_unregister [ 3923.100553] PM: Removing info for No Bus:5:0:0:0 [ 3923.100595] device: '5:0:0:0': device_create_release [ 3923.100598] device: '5:0:0:0': device_unregister [ 3923.100621] device: 'sg4': device_unregister [ 3923.104519] PM: Removing info for No Bus:sg4 [ 3923.104569] device: 'sg4': device_create_release [ 3923.104588] PM: Removing info for No Bus:5:0:0:0 [ 3923.104648] bus: 'scsi': remove device 5:0:0:0 [ 3923.104682] PM: Removing info for No Bus:5:0:0:0 [ 3923.108086] sd 5:0:0:0: [sdc] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [ 3923.108094] sd 5:0:0:0: [sdc] CDB: Write(10) 2a 00 00 00 00 10 00 00 f0 00 [ 3923.108098] blk_update_request: I/O error, dev sdc, sector 16 [ 3923.108103] Buffer I/O error on dev sdc, logical block 4, lost async page write [ 3923.108107] Buffer I/O error on dev sdc, logical block 5, lost async page write [ 3923.108115] Buffer I/O error on dev sdc, logical block 6, lost async page write [ 3923.108117] Buffer I/O error on dev sdc, logical block 7, lost async page write [ 3923.108120] Buffer I/O error on dev sdc, logical block 8, lost async page write [ 3923.108122] Buffer I/O error on dev sdc, logical block 9, lost async page write [ 3923.108125] Buffer I/O error on dev sdc, logical block 10, lost async page write [ 3923.108128] Buffer I/O error on dev sdc, logical block 11, lost async page write [ 3923.108131] Buffer I/O error on dev sdc, logical block 12, lost async page write [ 3923.108133] Buffer I/O error on dev sdc, logical block 13, lost async page write [ 3923.113422] sd 5:0:0:0: [sdc] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [ 3923.113434] sd 5:0:0:0: [sdc] CDB: Write(10) 2a 00 00 00 01 00 00 00 f0 00 [ 3923.113437] blk_update_request: I/O error, dev sdc, sector 256 I am unable to mount it.What could be the issue? Can I recover it? I am using Ubuntu 14.04 (64-bits) with Kernel version 4.2.2. -- -- Regards, Anil Nair -- To unsubscribe from this list: send the line "unsubscribe 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: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537
On Mon, 22 Feb 2016 16:22:59 -0500 (EST) Alan Stern wrote: > Unfortunately I really need to see the stuff that shows up before the > first couple of pictures. Is there any way you can use a serial > console or network console to capture the log data? Unfortunately no :( > Failing that, the patch below does the same thing as the previous patch > but it adds a 5-second delay after each line is sent to the log. Maybe > you'll be able to photograph something useful during those delays. Ok, the following picture shows more lines at the beginning, but it missed some lines (I tried to shoot as fast as I could): http://imgur.com/Pri9dso And this one shows lines from your patch: http://imgur.com/fv3X2hE Unfortunately I couldn't use "shift+PgUp" because it would return those lines instead of going back at the screen buffer. And the behaviour is not constant. I mean, sometimes it shows these errors. Sometimes, it returns with a blank screen. -- Linux 4.4.2-dirty: Blurry Fish Butt http://www.youtube.com/DanielFragaBR http://exchangewar.info Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: chipidea: Configure DMA properties and ops from DT
On Mon 22 Feb 02:03 PST 2016, Srinivas Kandagatla wrote:
>
>
> On 22/02/16 05:32, Bjorn Andersson wrote:
> >On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set
> >to be able to do DMA allocations, so use the of_dma_configure() helper
> >to populate the dma properties and assign an appropriate dma_ops.
> >
> >Signed-off-by: Bjorn Andersson
> >---
> > drivers/usb/chipidea/core.c | 4
> > 1 file changed, 4 insertions(+)
> >
> >diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> >index 7404064b9bbc..047b9d4e67aa 100644
> >--- a/drivers/usb/chipidea/core.c
> >+++ b/drivers/usb/chipidea/core.c
> >@@ -62,6 +62,7 @@
> > #include
> > #include
> > #include
> >+#include
> > #include
> > #include
> > #include
> >@@ -834,6 +835,9 @@ struct platform_device *ci_hdrc_add_device(struct device
> >*dev,
> > pdev->dev.dma_parms = dev->dma_parms;
> > dma_set_coherent_mask(&pdev->dev, dev->coherent_dma_mask);
> >
> >+if (IS_ENABLED(CONFIG_OF) && dev->of_node)
> >+of_dma_configure(&pdev->dev, dev->of_node);
> >+
> Would we hit the same issue if we are on non Device tree platforms like ACPI
> or platform device style itself?
>
As far as I can see, yes.
>
> > ret = platform_device_add_resources(pdev, res, nres);
> > if (ret)
> > goto err;
> >
>
> I think this is the side effect of commit
> 1dccb598df549d892b6450c261da54cdd7af44b4(arm64: simplify dma_get_ops)
>
I agree, before that we would have hit:
__generic_dma_ops() {
..
else if (acpi_disabled)
return dma_ops;
...
}
with dma_ops being swiotlb_dma_ops from arm64_dma_init().
But this would not have saved us in the ACPI case, i.e. the result would
have been as with my suggested patch. Poking Arnd here to see if he has
any input.
> None of the drivers call of_dma_configure() explicitly, which makes me feel
> that we are doing something wrong. TBH, this should be handled in more
> generic way rather than driver like this having an explicit call to
> of_dma_configure().
>
I agree, trying to figure out if it should be inherited or something.
>
> On the other hand, I think we could also solve the issue by using correct
> device(parent device) while allocating dma/dma-pool.
>
Unfortunately this solves the allocation part, but in udc-core we try to
map and unmap buffers based on the gadget's parent pointer (i.e. the
chipidea device).
I'm still puzzled to why the chipidea lives as a child device of the msm
device; but as this is a rather common structure I believe this still
needs to be figured out.
@Arnd, the Qualcomm (msm) chipidea driver instantiates a chipidea
device, which tries to do DMA mapping operations on ARM64 and fails,
because we don't have dma_ops specified on the child. Using
of_dma_configure() we can populate the child with appropriate settings
and ops, but we would be the first driver doing so. Do you have any
pointers to follow on what to do here?
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe 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: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537
On Mon, 22 Feb 2016, Daniel Fraga wrote:
> On Mon, 22 Feb 2016 14:30:32 -0500 (EST)
> Alan Stern wrote:
>
> > Well, I'm still puzzled. I tried running that patch on my system
> > (under 4.5-rc2) and it worked perfectly.
> >
> > So let's try for a little more detail. Please apply this patch instead
> > of the earlier one. Also, add no_console_suspend to the boot command
> > line, do
> >
> > echo 7 >/proc/sys/kernel/printk
> >
> > and start the suspend from a VT console rather than a GUI.
>
> Ok Alan, here's what I got (I took 6 pictures of the screen
> because there's no way to use the keyboard):
>
> 1) http://imgur.com/7bpA2i4
>
> 2) http://imgur.com/2kmLaJb
>
> 3) http://imgur.com/6wYPZZK
>
> 4) http://imgur.com/S42nV4Q
>
> 5) http://imgur.com/VHNl6My
>
> 6) http://imgur.com/dYCdqWn
Unfortunately I really need to see the stuff that shows up before the
first couple of pictures. Is there any way you can use a serial
console or network console to capture the log data?
Failing that, the patch below does the same thing as the previous patch
but it adds a 5-second delay after each line is sent to the log. Maybe
you'll be able to photograph something useful during those delays.
Alan Stern
Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -1427,6 +1427,7 @@ static int hid_post_reset(struct usb_int
struct usb_host_interface *interface = intf->cur_altsetting;
int status;
char *rdesc;
+ extern int alantest;
/* Fetch and examine the HID report descriptor. If this
* has changed, then rebind. Since usbcore's check of the
@@ -1457,7 +1458,10 @@ static int hid_post_reset(struct usb_int
clear_bit(HID_RESET_PENDING, &usbhid->iofl);
spin_unlock_irq(&usbhid->lock);
hid_set_idle(dev, intf->cur_altsetting->desc.bInterfaceNumber, 0, 0);
+ alantest = 1;
status = hid_start_in(hid);
+ alantest = 0;
+ dev_info(&intf->dev, "post reset hid_start_in -> %d\n", status);
if (status < 0)
hid_io_error(hid);
usbhid_restart_queues(usbhid);
Index: usb-4.4/drivers/usb/core/urb.c
===
--- usb-4.4.orig/drivers/usb/core/urb.c
+++ usb-4.4/drivers/usb/core/urb.c
@@ -184,6 +184,9 @@ EXPORT_SYMBOL_GPL(usb_unanchor_urb);
/*---*/
+int alantest;
+EXPORT_SYMBOL(alantest);
+
/**
* usb_submit_urb - issue an asynchronous transfer request for an endpoint
* @urb: pointer to the urb describing the request
@@ -332,8 +335,16 @@ int usb_submit_urb(struct urb *urb, gfp_
int is_out;
unsigned intallowed;
+ if (alantest) {
+ pr_info("alantest: urb %p\n", urb);
+ mdelay(5000);
+ pr_info("alantest: udev %p\n", urb->dev);
+ mdelay(5000);
+ }
+ if (alantest) { dev_info(&urb->dev->dev, "submit A\n"); mdelay(5000); }
if (!urb || !urb->complete)
return -EINVAL;
+ if (alantest) { dev_info(&urb->dev->dev, "submit B\n"); mdelay(5000); }
if (urb->hcpriv) {
WARN_ONCE(1, "URB %p submitted while active\n", urb);
return -EBUSY;
@@ -395,6 +406,7 @@ int usb_submit_urb(struct urb *urb, gfp_
* but drivers only control those sizes for ISO.
* while we're checking, initialize return status.
*/
+ if (alantest) { dev_info(&urb->dev->dev, "submit C\n"); mdelay(5000); }
if (xfertype == USB_ENDPOINT_XFER_ISOC) {
int n, len;
@@ -433,6 +445,7 @@ int usb_submit_urb(struct urb *urb, gfp_
if (sg->length % max)
return -EINVAL;
}
+ if (alantest) { dev_info(&urb->dev->dev, "submit D\n"); mdelay(5000); }
/* the I/O buffer must be mapped/unmapped, except when length=0 */
if (urb->transfer_buffer_length > INT_MAX)
@@ -487,6 +500,7 @@ int usb_submit_urb(struct urb *urb, gfp_
case USB_ENDPOINT_XFER_ISOC:
case USB_ENDPOINT_XFER_INT:
/* too small? */
+ if (alantest) { dev_info(&urb->dev->dev, "submit E\n"); mdelay(5000); }
switch (dev->speed) {
case USB_SPEED_WIRELESS:
if ((urb->interval < 6)
@@ -497,6 +511,7 @@ int usb_submit_urb(struct urb *urb, gfp_
return -EINVAL;
break;
}
+ if (alantest) { dev_info(&urb->dev->dev, "submit F\n"); mdelay(5000); }
/* too big? */
switch (dev->speed) {
case USB_SPEED_SUPER: /* units are 125us */
@@ -532,6 +547,7 @@ int usb_submit_urb(struct urb *urb,
[PATCH 8/9] usb: dwc3: Remove impossible check for of_clk_get_parent_count() < 0
The check for < 0 is impossible now that of_clk_get_parent_count() returns an unsigned int. Simplify the code and update the types. Cc: Felipe Balbi Cc: Signed-off-by: Stephen Boyd --- Please ack so this can go through clk tree along with patch 1. drivers/usb/dwc3/dwc3-of-simple.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-of-simple.c b/drivers/usb/dwc3/dwc3-of-simple.c index 9c9f74155066..974335377d9f 100644 --- a/drivers/usb/dwc3/dwc3-of-simple.c +++ b/drivers/usb/dwc3/dwc3-of-simple.c @@ -42,6 +42,7 @@ static int dwc3_of_simple_probe(struct platform_device *pdev) struct device *dev = &pdev->dev; struct device_node *np = dev->of_node; + unsigned intcount; int ret; int i; @@ -49,11 +50,11 @@ static int dwc3_of_simple_probe(struct platform_device *pdev) if (!simple) return -ENOMEM; - ret = of_clk_get_parent_count(np); - if (ret < 0) - return ret; + count = of_clk_get_parent_count(np); + if (!count) + return -ENOENT; - simple->num_clocks = ret; + simple->num_clocks = count; simple->clks = devm_kcalloc(dev, simple->num_clocks, sizeof(struct clk *), GFP_KERNEL); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe 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/9] Change return type of of_clk_get_parent_count() to unsigned
Russell King recently pointed out that of_clk_get_parent_count() can return a negative number if the "clocks" property isn't present in a node. Upon investigating all the callers of this API, none of the them seem to care about that case, and furthermore some callers are assigning the return value to an unsigned int which could cause very large numbers of parents to be used. This series changes the API to return an unsigned int from 0 (no parents) to N, thereby avoiding any problems with negative return values. Cc: Boris Brezillon Cc: Yoshinori Sato Cc: Cc: Gabriel Fernandez Cc: Maxime Ripard Cc: Chen-Yu Tsai Cc: Tero Kristo Cc: Felipe Balbi Cc: Cc: Hans de Goede Cc: Jean-Christophe Plagniol-Villard Cc: Tomi Valkeinen Cc: Stephen Boyd (9): clk: Make of_clk_get_parent_count() return unsigned ints clk: at91: Remove impossible checks for of_clk_get_parent_count() clk: gpio: Remove impossible check for of_clk_get_parent_count() < 0 clk: h8300: Remove impossible check for of_clk_get_parent_count() clk: st: Remove impossible check for of_clk_get_parent_count() < 0 clk: sunxi: Use proper type for of_clk_get_parent_count() return value clk: ti: Update for of_clk_get_parent_count() returning unsigned int usb: dwc3: Remove impossible check for of_clk_get_parent_count() < 0 simplefb: Remove impossible check for of_clk_get_parent_count() < 0 drivers/clk/at91/clk-generated.c| 4 ++-- drivers/clk/at91/clk-main.c | 4 ++-- drivers/clk/at91/clk-master.c | 4 ++-- drivers/clk/at91/clk-programmable.c | 4 ++-- drivers/clk/at91/clk-slow.c | 6 +++--- drivers/clk/at91/clk-smd.c | 4 ++-- drivers/clk/at91/clk-usb.c | 4 ++-- drivers/clk/clk-gpio.c | 6 ++ drivers/clk/clk.c | 16 ++-- drivers/clk/h8300/clk-div.c | 4 ++-- drivers/clk/h8300/clk-h8s2678.c | 4 ++-- drivers/clk/st/clk-flexgen.c| 4 ++-- drivers/clk/st/clkgen-mux.c | 4 ++-- drivers/clk/sunxi/clk-sun6i-ar100.c | 2 +- drivers/clk/ti/clockdomain.c| 2 +- drivers/clk/ti/composite.c | 8 drivers/clk/ti/dpll.c | 2 +- drivers/clk/ti/mux.c| 4 ++-- drivers/usb/dwc3/dwc3-of-simple.c | 9 + drivers/video/fbdev/simplefb.c | 4 ++-- include/linux/clk-provider.h| 2 +- 21 files changed, 56 insertions(+), 45 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe 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: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537
On Mon, 22 Feb 2016 14:30:32 -0500 (EST) Alan Stern wrote: > Well, I'm still puzzled. I tried running that patch on my system > (under 4.5-rc2) and it worked perfectly. > > So let's try for a little more detail. Please apply this patch instead > of the earlier one. Also, add no_console_suspend to the boot command > line, do > > echo 7 >/proc/sys/kernel/printk > > and start the suspend from a VT console rather than a GUI. Ok Alan, here's what I got (I took 6 pictures of the screen because there's no way to use the keyboard): 1) http://imgur.com/7bpA2i4 2) http://imgur.com/2kmLaJb 3) http://imgur.com/6wYPZZK 4) http://imgur.com/S42nV4Q 5) http://imgur.com/VHNl6My 6) http://imgur.com/dYCdqWn Thank you. -- Linux 4.4.2-dirty: Blurry Fish Butt http://www.youtube.com/DanielFragaBR http://exchangewar.info Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL -- To unsubscribe from this list: send the line "unsubscribe 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: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537
On Fri, 19 Feb 2016, Alan Stern wrote:
> On Fri, 19 Feb 2016, Daniel Fraga wrote:
>
> > On Fri, 19 Feb 2016 14:13:25 -0500 (EST)
> > Alan Stern wrote:
> >
> > > -22 is -EINVAL, so we need to figure out which of the many possible
> > > EINVAL errors you're getting. Try the patch below.
> >
> > I applied your patch, but when it wakes up from S3, the system
> > is stalled: nothing works. No keyboard, no mouse...
> >
> > And nothing in the log.
>
> Probably something about the patch causes a runtime error and that
> causes the resume to fail. I'll try some testing on my machine and get
> back to you next week...
Well, I'm still puzzled. I tried running that patch on my system
(under 4.5-rc2) and it worked perfectly.
So let's try for a little more detail. Please apply this patch instead
of the earlier one. Also, add no_console_suspend to the boot command
line, do
echo 7 >/proc/sys/kernel/printk
and start the suspend from a VT console rather than a GUI.
Alan Stern
Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -1427,6 +1427,7 @@ static int hid_post_reset(struct usb_int
struct usb_host_interface *interface = intf->cur_altsetting;
int status;
char *rdesc;
+ extern int alantest;
/* Fetch and examine the HID report descriptor. If this
* has changed, then rebind. Since usbcore's check of the
@@ -1457,7 +1458,10 @@ static int hid_post_reset(struct usb_int
clear_bit(HID_RESET_PENDING, &usbhid->iofl);
spin_unlock_irq(&usbhid->lock);
hid_set_idle(dev, intf->cur_altsetting->desc.bInterfaceNumber, 0, 0);
+ alantest = 1;
status = hid_start_in(hid);
+ alantest = 0;
+ dev_info(&intf->dev, "post reset hid_start_in -> %d\n", status);
if (status < 0)
hid_io_error(hid);
usbhid_restart_queues(usbhid);
Index: usb-4.4/drivers/usb/core/urb.c
===
--- usb-4.4.orig/drivers/usb/core/urb.c
+++ usb-4.4/drivers/usb/core/urb.c
@@ -184,6 +184,9 @@ EXPORT_SYMBOL_GPL(usb_unanchor_urb);
/*---*/
+int alantest;
+EXPORT_SYMBOL(alantest);
+
/**
* usb_submit_urb - issue an asynchronous transfer request for an endpoint
* @urb: pointer to the urb describing the request
@@ -332,8 +335,14 @@ int usb_submit_urb(struct urb *urb, gfp_
int is_out;
unsigned intallowed;
+ if (alantest) {
+ pr_info("alantest: urb %p\n", urb);
+ pr_info("alantest: udev %p\n", urb->dev);
+ }
+ if (alantest) dev_info(&urb->dev->dev, "submit A\n");
if (!urb || !urb->complete)
return -EINVAL;
+ if (alantest) dev_info(&urb->dev->dev, "submit B\n");
if (urb->hcpriv) {
WARN_ONCE(1, "URB %p submitted while active\n", urb);
return -EBUSY;
@@ -395,6 +404,7 @@ int usb_submit_urb(struct urb *urb, gfp_
* but drivers only control those sizes for ISO.
* while we're checking, initialize return status.
*/
+ if (alantest) dev_info(&urb->dev->dev, "submit C\n");
if (xfertype == USB_ENDPOINT_XFER_ISOC) {
int n, len;
@@ -433,6 +443,7 @@ int usb_submit_urb(struct urb *urb, gfp_
if (sg->length % max)
return -EINVAL;
}
+ if (alantest) dev_info(&urb->dev->dev, "submit D\n");
/* the I/O buffer must be mapped/unmapped, except when length=0 */
if (urb->transfer_buffer_length > INT_MAX)
@@ -487,6 +498,7 @@ int usb_submit_urb(struct urb *urb, gfp_
case USB_ENDPOINT_XFER_ISOC:
case USB_ENDPOINT_XFER_INT:
/* too small? */
+ if (alantest) dev_info(&urb->dev->dev, "submit E\n");
switch (dev->speed) {
case USB_SPEED_WIRELESS:
if ((urb->interval < 6)
@@ -497,6 +509,7 @@ int usb_submit_urb(struct urb *urb, gfp_
return -EINVAL;
break;
}
+ if (alantest) dev_info(&urb->dev->dev, "submit F\n");
/* too big? */
switch (dev->speed) {
case USB_SPEED_SUPER: /* units are 125us */
@@ -532,6 +545,7 @@ int usb_submit_urb(struct urb *urb, gfp_
default:
return -EINVAL;
}
+ if (alantest) dev_info(&urb->dev->dev, "submit G\n");
if (dev->speed != USB_SPEED_WIRELESS) {
/* Round down to a power of 2, no more than max */
urb->interval = min(max, 1 << ilog2(urb->interval));
--
To
Re: [PATCH] Support HP lt4114 LTE Module (Huawei ME206V-561)
On Sun, 2016-02-21 at 12:44 +0700, Lars Melin wrote: > On 2016-02-20 03:34, Dan Williams wrote: > > On Fri, 2016-02-19 at 18:21 +0100, Bjørn Mork wrote: > > > Dan Williams writes: > > > > On Fri, 2016-02-19 at 21:20 +0700, Lars Melin wrote: > > > > > > > > > cfg #1 > > > > > MI_00 HP Mobile Connect - PC UI Interface > > > > > MI_01 HP Mobile Connect - Application Interface > > > > > MI_02 HP Mobile Connect - Modem > > > > > MI_03 HP Mobile Connect - Network Card (jungo ncm) > > > > > MI_04 HP Mobile Connect - GPS Interface > > > > > > > > > > cfg#2 > > > > > MI_00 HP Mobile Connect - Network Card (cdc_ether) > > > > > MI_02 HP Mobile Connect - Modem > > > > > MI_03 HP Mobile Connect - Application Interface > > > > > MI_04 HP Mobile Connect - PC UI Interface > > > > > MI_05 HP Mobile Connect - GPS Interface > > > > > > > > > > cfg#3 > > > > > MI_00 HP Mobile Connect - Network Card (cdc_mbim) > > > > > MI_02 HP Mobile Connect - GPS Interface > > > > > > > > Bjorn, with these devices that technically "support" a bunch of > > > > different modes, what should our advice be on mode select? > > > > Personally > > > > I'd love to switch modems that support MBIM into MBIM by > > > > default... > > > > > > Yup, me too. That is the configuration with a class driver and > > > standardized management, allowing it to work without any device > > > or > > > vendor specific support. It is also the configuration used by > > > current > > > Windows versions and therefore most likely tested. > > > > > > I don't think such a policy is suitable for the kernel, > > > though. In > > > fact, I don't think the current kernel policy is appropriate for > > > the > > > kernel either :) But we'll have to leave that as it is. > > > > > > Do you think it is possible to create a catch-all udev rule > > > preferring > > > MBIM? I guess we'll need some helper for that, since it means > > > making > > > a > > > choice based on the attributes of an inactive configuration. > > > > usb_modeswitch would be the most logical helper. > > > > Dan > > > > usb_modeswitch does already handle one module under Huawei's own id > so > it should also be able to switch the HP branded ones. > There are more HP branded modules which we may see in the future and > I'll make sure that they will be added to usb_modeswitch as soon as I > know their interface layout. > HP's own drivers tells what kind of interfaces are available but not > in > which config they are present or in which order within a config. > There is at least some useful info in them about baseline drivers: > > Remark="HP"/> > Remark="HP"/> > Remark="HP"/> > Remark="HP"/> > Remark="HP"/> > Remark="HP"/> > Remark="HP"/> > Remark="HP"/> > Remark="HP"/> > Remark="HP"/> > > which makes me think that lt4114 should not be in qcserial but in > option > instead. Yes, since it's an Intel XMM 7160 device, it should not be in qcserial. Dan -- To unsubscribe from this list: send the line "unsubscribe 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] Support HP lt4114 LTE Module (Huawei ME206V-561)
On Mon, 2016-02-22 at 18:03 +0700, Lars Melin wrote: > On 2016-02-21 10:09, Daniel Johnson wrote: > > On Fri, Feb 19, 2016 at 12:27 AM, Bjørn Mork wrote: > > > One of them is likely a QCDM port if this is really a Qualcomm > > > based > > > device. The other might be an inactive NMEA port. Serial > > > doesn't > > > necessarily imply AT commands... > > > > I found the FCC ID for the device. > > QISME206V-561 > > > > Searching for this at the FCC website revealed internal photos. > > Looks > > like it's Intel based. The significant non intel parts seem to be > > DRAM, and a radio amplifier. > > https://www.fcc.gov/general/fcc-id-search-page > > -- > > To unsubscribe from this list: send the line "unsubscribe linux- > > usb" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > The serial interfaces should be handled by the option serial driver > which btw already has support for it. > > qcserial will fight with option for ownership of the interfaces so > the > currently defined DEVICE_HWI(0x03f0, 0x581d) should be taken out of > qcserial. Bjorn? If it's an Intel device, which it certainly looks like from the FCC photos, then it should not be in qcserial at all. The Windows driver config and the usb-devices dumps indicate that instead of the normal Intel cdc-acm/mbim configuration that this device uses a Huawei- specific layout like their Qualcomm-based devices. So this device should probably go into 'option' for Cfg#1 (Jungo) and Cfg#2 (cdc_ether) and it'll certainly need locking on specific Class/SubClass/Protocol to ensure that option only claims the serial interfaces and not the ethernet/ncm ones. Dan > /Lars > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver migration
On Mon, Feb 22, 2016 at 07:34:08AM +, tilman wrote: > > Hello > > > You can use ftrace to help you watch the flow of your driver before it > > crashes, or just printk, as you have found out, is the best way to debug > > things. > Thanks for the hints. I will give ftrace a go. > It takes me around 5-7 minutes to see the kernel crash, and then reboot, > make changes, and try again (more if I use eclipse). I am wondering, if > there are ways to allow faster turnaround times. Maybe, it would be an > option to run the tests in an emulator, such as qemu? Any experience with > that? Using an emulator doesn't usually work for working with a "real device" like you are doing now. You might be able to map your device into qemu, as it does have USB support, but I have never tried that out. I suggest staying away from eclipse, that's not needed for kernel development. Other than that, it's just normal debugging, good luck with that :) 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] usb: move usb_calc_bus_time into common code
John, On Fri, Feb 19, 2016 at 6:55 PM, John Youn wrote: > On 2/19/2016 2:48 PM, Doug Anderson wrote: >> Hi, >> >> On Fri, Feb 19, 2016 at 1:52 PM, Alan Stern >> wrote: >>> On Fri, 19 Feb 2016, Arnd Bergmann wrote: >>> The dwc2 dual-role USB controller driver has started calling usb_calc_bus_time, and does so regardless of whether it is being built as a host controller or gadget. In case all >>> >>> Out of curiosity... Why does dwc2 need to calculate bus times when it >>> is in device mode? >> >> Hoo boy. it doesn't. Nor does it need to properly set the even/odd >> frame in device mode. >> >> Basically dwc2's "core.c" has a whole bunch of stuff in it that's host >> only and isn't guarded with any #ifdef. ...yet that file is included >> in gadget-only builds. It's a bit of a mess. Take a gander at all of >> the "dwc2_hc_xxx" functions sitting in "drivers/usb/dwc2/core.c". >> >> Long term that needs to be cleaned up, but such a cleanup is going to >> be a bit of churn so we'd need to schedule it for a time when not much >> else is going on (and presumably it should be done by John or in close >> coordination with him so it can get Acked / landed quickly to avoid >> conflicts?). To do this we'd have to figure out why some things are >> in "core.c" and some in "hcd.c" and if it makes sense to move them all >> to "hcd.c" or if we need a new "core_hc.c" or something... All of >> that design predates me. >> > > Yeah, that stuff has been bugging me for a while. I have a branch that > started a lot of clean-ups, but it's never been a great time to merge > it. > >> In any case I guess we need a solution for right now, huh? >> >> One terribly lame hack would be to just make a dummy no-op >> "dwc2_hc_set_even_odd_frame()" if host mode is disabled. That doesn't >> really fix the root problem of lots of host mode code being compiled >> in a gadget-only driver. It also adds an ugly "#ifdef". ...but it >> does get around the current compile error. >> >> >> What do folks think? >> > > I think if we can fix it for -next in dwc2 by moving all host code out > of core then we should do it that way. I'll see if I can revive my > patches. It looks like Felipe has dropped my series out of his testing/next to avoid this issue (thanks Felipe!). I'm interested in getting this resolved as soon as possible to get things back in. Is there anything you'd like me to do to help? -Doug -- To unsubscribe from this list: send the line "unsubscribe 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: Nokia N900: musb is in wrong state after boot
For what it's worth, I tried running the MUSB via the twl4030 on Linux-Next (I don't remember which snapshot), and it was broken for me on a DM3730 (OMAP 3630), but Kernel 4.4.2 worked. Are you using Linux-Next or one of the stable kernels? I can try again later this week with a newer linux-next when I have more time to see if it's still there. Once I realized the stable kernel worked, I stoped since I was just testing some device tree stuff. adam On Mon, Feb 22, 2016 at 9:36 AM, Bin Liu wrote: > Hi, > > On Mon, Feb 22, 2016 at 10:54:21AM +0200, Felipe Balbi wrote: >> >> Hi, >> >> Pali Rohár writes: >> > On Monday 22 February 2016 09:31:50 Felipe Balbi wrote: >> >> Pali Rohár writes: >> >> >> >> > On Tuesday 26 January 2016 18:26:32 Tony Lindgren wrote: >> >> >> * Pali Rohár [160126 06:35]: >> >> >> > On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote: >> >> >> > > * joerg Reisenweber [160121 11:35]: >> >> >> > > > On Thu 21 January 2016 11:21:13 Tony Lindgren wrote: >> >> >> > > > > Do you have some pointer >> >> >> > > > > to the "certain resistor value on ID to GND" spec? Is it >> >> >> > > > > maybe part of the carkit related parts of the USB spec? >> >> >> > > > >> >> >> > > > ""Three additional ID pin states are defined[4] at the nominal >> >> >> > > > resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect >> >> >> > > > to the ground pin. These permit the device to work with USB >> >> >> > > > Accessory Charger Adapters that allows the OTG device to be >> >> >> > > > attached to both a charger and another device simultaneously. >> >> >> > > > [6]"" >> >> >> > > > https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs >> >> >> > > >> >> >> > > OK thanks. So it's the "accessory charger" part of the >> >> >> > > battery charging specification 1.1. >> >> >> > >> >> >> > So, Tony, do you have some idea what needs to be changed and how to >> >> >> > fix peripheral mode after boot on Nokia N900? >> >> >> >> >> >> No, I'm waiting to hear an educated guess from Felipe on this one. >> >> >> >> about why peripheral mode doesn't work on n900 ? No idea. that's always >> >> the default role of MUSB and last I checked, before stopping working on >> >> this, BBB was working just fine. >> >> >> >> N900 is odd in that it has two PHYs (1701 handles data lines while >> >> twl4030 handles power lines, IIRC), but peripheral should be working. >> >> >> >> The only reason for MUSB to not start would be that it's not detecting >> >> VBUS being above session valid threshold, however twl4030 should have an >> >> IRQ for that. >> >> >> >> What happens when cable is attached ? Any IRQs anywhere firing ? >> >> >> > >> > Just to note, when I call echo peripheral > mode then detecting usb >> > cable starts working and usb peripheral mode also works fine (also >> > after disconnecting and connecting usb cable again). Read my first >> > post in this thread, there are also some logs: >> > https://lkml.org/lkml/2016/1/9/69 >> >> interesting... that softconnect interface looks odd. We _know_ the value >> of softconnect from musb->softconnect. /me reads commit which added >> it... Oh okay, that's only valid for host mode. Argh! > > softconnet bit is only valid for *peripheral* mode, but the bit is not > set in this case, so the host will not be able to detect the device. > > Pali, > > Is this never worked or just broken recently? If latter, possible to > git-bisect to find out which patch causes softconnect bit not set? > > Regards, > -Bin. > >> >> Okay, the session bit is _NOT_ set when it should be. Note that DevCtl >> reads as 0x98. Bit 0 is Session bit and that's not set. MUSB _is_ in the >> device mode (bit 7 set). >> >> For some reason DevCtl didn't get set. Care to add a print to >> musb_gadget_pullup() to see when/if it's called ? >> >> BTW, Bin will be maintaining MUSB going forward. >> >> -- >> balbi > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nokia N900: musb is in wrong state after boot
Hi, On Mon, Feb 22, 2016 at 10:54:21AM +0200, Felipe Balbi wrote: > > Hi, > > Pali Rohár writes: > > On Monday 22 February 2016 09:31:50 Felipe Balbi wrote: > >> Pali Rohár writes: > >> > >> > On Tuesday 26 January 2016 18:26:32 Tony Lindgren wrote: > >> >> * Pali Rohár [160126 06:35]: > >> >> > On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote: > >> >> > > * joerg Reisenweber [160121 11:35]: > >> >> > > > On Thu 21 January 2016 11:21:13 Tony Lindgren wrote: > >> >> > > > > Do you have some pointer > >> >> > > > > to the "certain resistor value on ID to GND" spec? Is it > >> >> > > > > maybe part of the carkit related parts of the USB spec? > >> >> > > > > >> >> > > > ""Three additional ID pin states are defined[4] at the nominal > >> >> > > > resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect > >> >> > > > to the ground pin. These permit the device to work with USB > >> >> > > > Accessory Charger Adapters that allows the OTG device to be > >> >> > > > attached to both a charger and another device simultaneously. > >> >> > > > [6]"" > >> >> > > > https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs > >> >> > > > >> >> > > OK thanks. So it's the "accessory charger" part of the > >> >> > > battery charging specification 1.1. > >> >> > > >> >> > So, Tony, do you have some idea what needs to be changed and how to > >> >> > fix peripheral mode after boot on Nokia N900? > >> >> > >> >> No, I'm waiting to hear an educated guess from Felipe on this one. > >> > >> about why peripheral mode doesn't work on n900 ? No idea. that's always > >> the default role of MUSB and last I checked, before stopping working on > >> this, BBB was working just fine. > >> > >> N900 is odd in that it has two PHYs (1701 handles data lines while > >> twl4030 handles power lines, IIRC), but peripheral should be working. > >> > >> The only reason for MUSB to not start would be that it's not detecting > >> VBUS being above session valid threshold, however twl4030 should have an > >> IRQ for that. > >> > >> What happens when cable is attached ? Any IRQs anywhere firing ? > >> > > > > Just to note, when I call echo peripheral > mode then detecting usb > > cable starts working and usb peripheral mode also works fine (also > > after disconnecting and connecting usb cable again). Read my first > > post in this thread, there are also some logs: > > https://lkml.org/lkml/2016/1/9/69 > > interesting... that softconnect interface looks odd. We _know_ the value > of softconnect from musb->softconnect. /me reads commit which added > it... Oh okay, that's only valid for host mode. Argh! softconnet bit is only valid for *peripheral* mode, but the bit is not set in this case, so the host will not be able to detect the device. Pali, Is this never worked or just broken recently? If latter, possible to git-bisect to find out which patch causes softconnect bit not set? Regards, -Bin. > > Okay, the session bit is _NOT_ set when it should be. Note that DevCtl > reads as 0x98. Bit 0 is Session bit and that's not set. MUSB _is_ in the > device mode (bit 7 set). > > For some reason DevCtl didn't get set. Care to add a print to > musb_gadget_pullup() to see when/if it's called ? > > BTW, Bin will be maintaining MUSB going forward. > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB oops regression caused by -stable patch
Thanks, that fixes it. Tested on 4.5.0-rc5 and 3.18.27. Just to be
clear, I tested it *without* reverting d8f00cd685f5. So this patch is
in addition to d8f00cd685f5 instead of replacing it.
Tested-by: Tony Battersby
On 02/21/2016 09:27 PM, Du, Changbin wrote:
> Thanks for reporting, Tony. It was remiss of me.
> There is another BOS free operation in label re_enumerate. This cause a
> double-free of BOS.
> USB2 doesn't have BOS desc, so you cannot reproduce it.
>
> I am on a travel. It is appreciated if you can help try below fix.
>
> Hi, Greg, I will commit a final patch once returned from travel.
>
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -5501,8 +5501,10 @@ done:
> return 0;
>
> re_enumerate:
> - usb_release_bos_descriptor(udev);
> - udev->bos = bos;
> + if (udev->bos != bos) {
> + usb_release_bos_descriptor(udev);
> + udev->bos = bos;
> + }
>
> Best Regards,
> Du, Changbin
>
>> On Fri, Feb 19, 2016 at 09:39:57AM -0500, Tony Battersby wrote:
>>> This upstream commit is causing an oops:
>>> d8f00cd685f5 ("usb: hub: do not clear BOS field during reset device")
>>>
>>> This patch has already been included in several -stable kernels. Here
>>> are the affected kernels:
>>> 4.5.0-rc4 (current git)
>>> 4.4.2
>>> 4.3.6 (currently in review)
>>> 4.1.18
>>> 3.18.27
>>> 3.14.61
>>>
>>> How to reproduce the problem:
>>> Boot kernel with slub debugging enabled (otherwise memory corruption
>>> will cause random oopses later instead of immediately)
>>> Plug in USB 3.0 disk to xhci USB 3.0 port
>>> dd if=/dev/sdc of=/dev/null bs=65536
>>> (where /dev/sdc is the USB 3.0 disk)
>>> Unplug USB cable while dd is still going
>>> Oops is immediate:
>> Not good, thanks for letting us know. I've now reverted this and will
>> get the fix into 4.5-rc6.
>>
>> 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] Support HP lt4114 LTE Module (Huawei ME206V-561)
On 2016-02-21 10:09, Daniel Johnson wrote: On Fri, Feb 19, 2016 at 12:27 AM, Bjørn Mork wrote: One of them is likely a QCDM port if this is really a Qualcomm based device. The other might be an inactive NMEA port. Serial doesn't necessarily imply AT commands... I found the FCC ID for the device. QISME206V-561 Searching for this at the FCC website revealed internal photos. Looks like it's Intel based. The significant non intel parts seem to be DRAM, and a radio amplifier. https://www.fcc.gov/general/fcc-id-search-page -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html The serial interfaces should be handled by the option serial driver which btw already has support for it. qcserial will fight with option for ownership of the interfaces so the currently defined DEVICE_HWI(0x03f0, 0x581d) should be taken out of qcserial. Bjorn? /Lars -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: dwc3: drop FIFO resizing logic
Hi,
Kishon Vijay Abraham I writes:
>> Kishon Vijay Abraham I writes:
>> On Thursday 04 February 2016 05:48 PM, Felipe Balbi wrote:
>>> That FIFO resizing logic was added to support OMAP5
>>> ES1.0 which had a bogus default FIFO size. I can't
>>> remember the exact size of default FIFO, but it was
>>> less than one bulk superspeed packet (<1024) which
>>> would prevent USB3 from ever working on OMAP5 ES1.0.
>>>
>>> However, OMAP5 ES1.0 support has been dropped by
>>> commit aa2f4b16f830 ("ARM: OMAP5: id: Remove ES1.0
>>> support") which renders FIFO resizing unnecessary.
>>>
>>> Signed-off-by: Felipe Balbi
>>
>> tested this series on both dra7-evm and dra72-evm using mass storage
>> gadget and
>> msc.sh
>
> both HS and SS ?
yes.. but the logs here were for only SS.
>
>> dra72-evm: http://pastebin.ubuntu.com/14887997/
>> dra7-evm: http://pastebin.ubuntu.com/14887975/
>>
>> Tested-by: Kishon Vijay Abraham I
>>
>> Let me know if you want me to do any other testing on dra7.
>
> yeah, run testusb for a week or so, that usually catches odd bugs.
Okay. I'll start the test before I go for vacation next week.
>>>
>>> Looks like the test couldn't complete and I see dumps [1] in my host
>>> PC. Here's the output of testusb [2].
>>>
>>> [1] -> http://pastebin.ubuntu.com/15169114/
>>> [2] -> http://pastebin.ubuntu.com/15169116/
>>
>> Does this also happen without this patch applied ?
>
> yeah. I could see that even without the patch.
>
> I think I should update my host PC kernel and check (maybe it got
> fixed with the latest xhci driver).
yeah, please do that and let me know ;-)
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH 1/2] usb: dwc3: drop FIFO resizing logic
Hi,
On Monday 22 February 2016 02:07 PM, Felipe Balbi wrote:
>
> Hi,
>
> Kishon Vijay Abraham I writes:
> On Thursday 04 February 2016 05:48 PM, Felipe Balbi wrote:
>> That FIFO resizing logic was added to support OMAP5
>> ES1.0 which had a bogus default FIFO size. I can't
>> remember the exact size of default FIFO, but it was
>> less than one bulk superspeed packet (<1024) which
>> would prevent USB3 from ever working on OMAP5 ES1.0.
>>
>> However, OMAP5 ES1.0 support has been dropped by
>> commit aa2f4b16f830 ("ARM: OMAP5: id: Remove ES1.0
>> support") which renders FIFO resizing unnecessary.
>>
>> Signed-off-by: Felipe Balbi
>
> tested this series on both dra7-evm and dra72-evm using mass storage
> gadget and
> msc.sh
both HS and SS ?
>>>
>>> yes.. but the logs here were for only SS.
> dra72-evm: http://pastebin.ubuntu.com/14887997/
> dra7-evm: http://pastebin.ubuntu.com/14887975/
>
> Tested-by: Kishon Vijay Abraham I
>
> Let me know if you want me to do any other testing on dra7.
yeah, run testusb for a week or so, that usually catches odd bugs.
>>>
>>> Okay. I'll start the test before I go for vacation next week.
>>
>> Looks like the test couldn't complete and I see dumps [1] in my host
>> PC. Here's the output of testusb [2].
>>
>> [1] -> http://pastebin.ubuntu.com/15169114/
>> [2] -> http://pastebin.ubuntu.com/15169116/
>
> Does this also happen without this patch applied ?
yeah. I could see that even without the patch.
I think I should update my host PC kernel and check (maybe it got fixed with
the latest xhci driver).
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: chipidea: Configure DMA properties and ops from DT
On 22/02/16 05:32, Bjorn Andersson wrote:
On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set
to be able to do DMA allocations, so use the of_dma_configure() helper
to populate the dma properties and assign an appropriate dma_ops.
Signed-off-by: Bjorn Andersson
---
drivers/usb/chipidea/core.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 7404064b9bbc..047b9d4e67aa 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -62,6 +62,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -834,6 +835,9 @@ struct platform_device *ci_hdrc_add_device(struct device
*dev,
pdev->dev.dma_parms = dev->dma_parms;
dma_set_coherent_mask(&pdev->dev, dev->coherent_dma_mask);
+ if (IS_ENABLED(CONFIG_OF) && dev->of_node)
+ of_dma_configure(&pdev->dev, dev->of_node);
+
Would we hit the same issue if we are on non Device tree platforms like
ACPI or platform device style itself?
ret = platform_device_add_resources(pdev, res, nres);
if (ret)
goto err;
I think this is the side effect of commit
1dccb598df549d892b6450c261da54cdd7af44b4(arm64: simplify dma_get_ops)
None of the drivers call of_dma_configure() explicitly, which makes me
feel that we are doing something wrong. TBH, this should be handled in
more generic way rather than driver like this having an explicit call to
of_dma_configure().
On the other hand, I think we could also solve the issue by using
correct device(parent device) while allocating dma/dma-pool.
>cut<-
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 6e53c24..0293ed5 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1844,13 +1844,13 @@ static int udc_start(struct ci_hdrc *ci)
INIT_LIST_HEAD(&ci->gadget.ep_list);
/* alloc resources */
- ci->qh_pool = dma_pool_create("ci_hw_qh", dev,
+ ci->qh_pool = dma_pool_create("ci_hw_qh", dev->parent,
sizeof(struct ci_hw_qh),
64, CI_HDRC_PAGE_SIZE);
if (ci->qh_pool == NULL)
return -ENOMEM;
- ci->td_pool = dma_pool_create("ci_hw_td", dev,
+ ci->td_pool = dma_pool_create("ci_hw_td", dev->parent,
sizeof(struct ci_hw_td),
64, CI_HDRC_PAGE_SIZE);
if (ci->td_pool == NULL) {
>cut<-
--srini
--
To unsubscribe from this list: send the line "unsubscribe 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 v3] usb: host: Host drivers relying on DMA should depend on HAS_DMA
If NO_DMA=y: ERROR: "bad_dma_ops" [drivers/usb/host/xhci-plat-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/xhci-mtk.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ohci-platform.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ehci-platform.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/ehci-hcd.ko] undefined! Add dependencies on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven --- v3: - Rebased against usb-next of usb.git, v2: - Reword one-line summary. --- drivers/usb/host/Kconfig | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 438dcf6289b08f82..81bb7d471f4eb51b 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -18,7 +18,7 @@ config USB_C67X00_HCD config USB_XHCI_HCD tristate "xHCI HCD (USB 3.0) support" - depends on HAS_IOMEM + depends on HAS_DMA && HAS_IOMEM ---help--- The eXtensible Host Controller Interface (xHCI) is standard for USB 3.0 "SuperSpeed" host controller hardware. @@ -73,7 +73,7 @@ endif # USB_XHCI_HCD config USB_EHCI_HCD tristate "EHCI HCD (USB 2.0) support" - depends on HAS_IOMEM + depends on HAS_DMA && HAS_IOMEM ---help--- The Enhanced Host Controller Interface (EHCI) is standard for USB 2.0 "high speed" (480 Mbit/sec, 60 Mbyte/sec) host controller hardware. @@ -368,8 +368,7 @@ config USB_ISP1362_HCD config USB_FOTG210_HCD tristate "FOTG210 HCD support" - depends on USB - depends on HAS_IOMEM + depends on USB && HAS_DMA && HAS_IOMEM ---help--- Faraday FOTG210 is an OTG controller which can be configured as an USB2.0 host. It is designed to meet USB2.0 EHCI specification @@ -391,7 +390,7 @@ config USB_MAX3421_HCD config USB_OHCI_HCD tristate "OHCI HCD (USB 1.1) support" - depends on HAS_IOMEM + depends on HAS_DMA && HAS_IOMEM ---help--- The Open Host Controller Interface (OHCI) is a standard for accessing USB 1.1 host controller hardware. It does more in hardware than Intel's -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nokia N900: musb is in wrong state after boot
Hi, Pali Rohár writes: > On Monday 22 February 2016 09:31:50 Felipe Balbi wrote: >> Pali Rohár writes: >> >> > On Tuesday 26 January 2016 18:26:32 Tony Lindgren wrote: >> >> * Pali Rohár [160126 06:35]: >> >> > On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote: >> >> > > * joerg Reisenweber [160121 11:35]: >> >> > > > On Thu 21 January 2016 11:21:13 Tony Lindgren wrote: >> >> > > > > Do you have some pointer >> >> > > > > to the "certain resistor value on ID to GND" spec? Is it >> >> > > > > maybe part of the carkit related parts of the USB spec? >> >> > > > >> >> > > > ""Three additional ID pin states are defined[4] at the nominal >> >> > > > resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect >> >> > > > to the ground pin. These permit the device to work with USB >> >> > > > Accessory Charger Adapters that allows the OTG device to be >> >> > > > attached to both a charger and another device simultaneously. >> >> > > > [6]"" >> >> > > > https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs >> >> > > >> >> > > OK thanks. So it's the "accessory charger" part of the >> >> > > battery charging specification 1.1. >> >> > >> >> > So, Tony, do you have some idea what needs to be changed and how to >> >> > fix peripheral mode after boot on Nokia N900? >> >> >> >> No, I'm waiting to hear an educated guess from Felipe on this one. >> >> about why peripheral mode doesn't work on n900 ? No idea. that's always >> the default role of MUSB and last I checked, before stopping working on >> this, BBB was working just fine. >> >> N900 is odd in that it has two PHYs (1701 handles data lines while >> twl4030 handles power lines, IIRC), but peripheral should be working. >> >> The only reason for MUSB to not start would be that it's not detecting >> VBUS being above session valid threshold, however twl4030 should have an >> IRQ for that. >> >> What happens when cable is attached ? Any IRQs anywhere firing ? >> > > Just to note, when I call echo peripheral > mode then detecting usb > cable starts working and usb peripheral mode also works fine (also > after disconnecting and connecting usb cable again). Read my first > post in this thread, there are also some logs: > https://lkml.org/lkml/2016/1/9/69 interesting... that softconnect interface looks odd. We _know_ the value of softconnect from musb->softconnect. /me reads commit which added it... Oh okay, that's only valid for host mode. Argh! Okay, the session bit is _NOT_ set when it should be. Note that DevCtl reads as 0x98. Bit 0 is Session bit and that's not set. MUSB _is_ in the device mode (bit 7 set). For some reason DevCtl didn't get set. Care to add a print to musb_gadget_pullup() to see when/if it's called ? BTW, Bin will be maintaining MUSB going forward. -- balbi signature.asc Description: PGP signature
Re: Nokia N900: musb is in wrong state after boot
Hi, Pali Rohár writes: > On Monday 22 February 2016 09:31:50 Felipe Balbi wrote: >> Pali Rohár writes: >> >> > On Tuesday 26 January 2016 18:26:32 Tony Lindgren wrote: >> >> * Pali Rohár [160126 06:35]: >> >> > On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote: >> >> > > * joerg Reisenweber [160121 11:35]: >> >> > > > On Thu 21 January 2016 11:21:13 Tony Lindgren wrote: >> >> > > > > Do you have some pointer >> >> > > > > to the "certain resistor value on ID to GND" spec? Is it >> >> > > > > maybe part of the carkit related parts of the USB spec? >> >> > > > >> >> > > > ""Three additional ID pin states are defined[4] at the nominal >> >> > > > resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect >> >> > > > to the ground pin. These permit the device to work with USB >> >> > > > Accessory Charger Adapters that allows the OTG device to be >> >> > > > attached to both a charger and another device simultaneously. >> >> > > > [6]"" >> >> > > > https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs >> >> > > >> >> > > OK thanks. So it's the "accessory charger" part of the >> >> > > battery charging specification 1.1. >> >> > >> >> > So, Tony, do you have some idea what needs to be changed and how to >> >> > fix peripheral mode after boot on Nokia N900? >> >> >> >> No, I'm waiting to hear an educated guess from Felipe on this one. >> >> about why peripheral mode doesn't work on n900 ? No idea. that's always >> the default role of MUSB and last I checked, before stopping working on >> this, BBB was working just fine. >> >> N900 is odd in that it has two PHYs (1701 handles data lines while >> twl4030 handles power lines, IIRC), but peripheral should be working. >> >> The only reason for MUSB to not start would be that it's not detecting >> VBUS being above session valid threshold, however twl4030 should have an >> IRQ for that. >> >> What happens when cable is attached ? Any IRQs anywhere firing ? >> > > Just to note, when I call echo peripheral > mode then detecting usb > cable starts working and usb peripheral mode also works fine (also > after disconnecting and connecting usb cable again). Read my first > post in this thread, there are also some logs: > https://lkml.org/lkml/2016/1/9/69 interesting... that softconnect interface looks odd. We _know_ the value of softconnect from musb->softconnect. /me reads commit which added it... Oh okay, that's only valid for host mode. Argh! Okay, the session bit is _NOT_ set when it should be. Note that DevCtl reads as 0x98. Bit 0 is Session bit and that's not set. MUSB _is_ in the device mode (bit 7 set). For some reason DevCtl didn't get set. Care to add a print to musb_gadget_pullup() to see when/if it's called ? BTW, Bin will be maintaining MUSB going forward. -- balbi signature.asc Description: PGP signature
Re: [HELP] USB 3.0 PCI Endpoint problem
Hi, Joao Pinto writes: > Hi to all! > I am testing a PCIe Root Complex prototyping setup in which I have a USB 3.0 > host as a PCI Endpoint. > Running in an ARC CPU platform it works well, but when running in an emulated > ARM64 (this is done by a Synopsys virtualization tool) the endpoint > initialization fails as can be seen in the following log: > > xhci_hcd :01:00.0: xHCI Host Controller > xhci_hcd :01:00.0: new USB bus registered, assigned bus number 1 > xhci_hcd :01:00.0: xHCI capability registers at ff80002c4000: > xhci_hcd :01:00.0: CAPLENGTH AND HCIVERSION 0x960020: > xhci_hcd :01:00.0: CAPLENGTH: 0x20 > xhci_hcd :01:00.0: HCIVERSION: 0x96 > xhci_hcd :01:00.0: HCSPARAMS 1: 0x4000820 > xhci_hcd :01:00.0: Max device slots: 32 > xhci_hcd :01:00.0: Max interrupters: 8 > xhci_hcd :01:00.0: Max ports: 4 > xhci_hcd :01:00.0: HCSPARAMS 2: 0x11 > xhci_hcd :01:00.0: Isoc scheduling threshold: 1 > xhci_hcd :01:00.0: Maximum allowed segments in event ring: 1 > xhci_hcd :01:00.0: HCSPARAMS 3 0x0: > xhci_hcd :01:00.0: Worst case U1 device exit latency: 0 > xhci_hcd :01:00.0: Worst case U2 device exit latency: 0 > xhci_hcd :01:00.0: HCC PARAMS 0x14042cb: > xhci_hcd :01:00.0: HC generates 64 bit addresses > xhci_hcd :01:00.0: FIXME: more HCCPARAMS debugging > xhci_hcd :01:00.0: RTSOFF 0x600: > xhci_hcd :01:00.0: xHCI operational registers at ff80002c4020: > xhci_hcd :01:00.0: USBCMD 0x0: > xhci_hcd :01:00.0: HC is being stopped > xhci_hcd :01:00.0: HC has finished hard reset > xhci_hcd :01:00.0: Event Interrupts disabled > xhci_hcd :01:00.0: Host System Error Interrupts disabled > xhci_hcd :01:00.0: HC has finished light reset > xhci_hcd :01:00.0: USBSTS 0x9: > xhci_hcd :01:00.0: Event ring is not empty > xhci_hcd :01:00.0: No Host System Error > xhci_hcd :01:00.0: HC is halted > xhci_hcd :01:00.0: ff80002c4420 port status reg = 0x2a0 > xhci_hcd :01:00.0: ff80002c4424 port power reg = 0x0 > xhci_hcd :01:00.0: ff80002c4428 port link reg = 0x0 > xhci_hcd :01:00.0: ff80002c442c port reserved reg = 0x0 > xhci_hcd :01:00.0: ff80002c4430 port status reg = 0x2a0 > xhci_hcd :01:00.0: ff80002c4434 port power reg = 0x0 > xhci_hcd :01:00.0: ff80002c4438 port link reg = 0x0 > xhci_hcd :01:00.0: ff80002c443c port reserved reg = 0x0 > xhci_hcd :01:00.0: ff80002c4440 port status reg = 0x2a0 > xhci_hcd :01:00.0: ff80002c port power reg = 0x0 > xhci_hcd :01:00.0: ff80002c4448 port link reg = 0x0 > xhci_hcd :01:00.0: ff80002c444c port reserved reg = 0x0 > xhci_hcd :01:00.0: ff80002c4450 port status reg = 0x2a0 > xhci_hcd :01:00.0: ff80002c4454 port power reg = 0x0 > xhci_hcd :01:00.0: ff80002c4458 port link reg = 0x0 > xhci_hcd :01:00.0: ff80002c445c port reserved reg = 0x0 > xhci_hcd :01:00.0: // Halt the HC > xhci_hcd :01:00.0: Resetting HCD > xhci_hcd :01:00.0: // Reset the HC > xhci_hcd :01:00.0: Wait for controller to be ready for doorbell rings > xhci_hcd :01:00.0: Reset complete > xhci_hcd :01:00.0: Enabling 64-bit DMA addresses. > xhci_hcd :01:00.0: Calling HCD init > xhci_hcd :01:00.0: xhci_init > xhci_hcd :01:00.0: xHCI doesn't need link TRB QUIRK > xhci_hcd :01:00.0: Supported page size register = 0x1 > xhci_hcd :01:00.0: Supported page size of 4K > xhci_hcd :01:00.0: HCD page size set to 4K > xhci_hcd :01:00.0: // xHC can handle at most 32 device slots. > xhci_hcd :01:00.0: // Setting Max device slots reg = 0x20. > xhci_hcd :01:00.0: // Device context base array address = 0xfcafb000 > (DMA), > ff80002c7000 (virt) > xhci_hcd :01:00.0: Allocated command ring at ffc07db28cc0 > xhci_hcd :01:00.0: First segment DMA is 0xfc42c000 > xhci_hcd :01:00.0: // Setting command ring address to 0x20 > xhci_hcd :01:00.0: // xHC command ring deq ptr low bits + flags = > @ > xhci_hcd :01:00.0: // xHC command ring deq ptr high bits = @ > xhci_hcd :01:00.0: // Doorbell array is located at offset 0x800 from cap > regs base addr > xhci_hcd :01:00.0: // xHCI capability registers at ff80002c4000: > xhci_hcd :01:00.0: // @ff80002c4000 = 0x960020 (CAPLENGTH AND > HCIVERSION) > xhci_hcd :01:00.0: // CAPLENGTH: 0x20 > xhci_hcd :01:00.0: // xHCI operational registers at ff80002c4020: > xhci_hcd :01:00.0: // @ff80002c4018 = 0x600 RTSOFF > xhci_hcd :01:00.0: // xHCI runtime registers at ff80002c4600: > xhci_hcd :01:00.0: // @ff80002c4014 = 0x800 DBOFF > xhci_hcd :01:00.0: // Doorbell array at ff80002c4800: > xhci_hcd :01:00.0: xHCI runtime registers at ff80002c4600: > xhci_hcd :01:00.0: ff80002c4600: Microframe index = 0x0 > xhci_hcd :01:00.0: // Allocating event
Re: [PATCH 1/2] usb: dwc3: drop FIFO resizing logic
Hi,
Kishon Vijay Abraham I writes:
On Thursday 04 February 2016 05:48 PM, Felipe Balbi wrote:
> That FIFO resizing logic was added to support OMAP5
> ES1.0 which had a bogus default FIFO size. I can't
> remember the exact size of default FIFO, but it was
> less than one bulk superspeed packet (<1024) which
> would prevent USB3 from ever working on OMAP5 ES1.0.
>
> However, OMAP5 ES1.0 support has been dropped by
> commit aa2f4b16f830 ("ARM: OMAP5: id: Remove ES1.0
> support") which renders FIFO resizing unnecessary.
>
> Signed-off-by: Felipe Balbi
tested this series on both dra7-evm and dra72-evm using mass storage
gadget and
msc.sh
>>>
>>> both HS and SS ?
>>
>> yes.. but the logs here were for only SS.
>>>
dra72-evm: http://pastebin.ubuntu.com/14887997/
dra7-evm: http://pastebin.ubuntu.com/14887975/
Tested-by: Kishon Vijay Abraham I
Let me know if you want me to do any other testing on dra7.
>>>
>>> yeah, run testusb for a week or so, that usually catches odd bugs.
>>
>> Okay. I'll start the test before I go for vacation next week.
>
> Looks like the test couldn't complete and I see dumps [1] in my host
> PC. Here's the output of testusb [2].
>
> [1] -> http://pastebin.ubuntu.com/15169114/
> [2] -> http://pastebin.ubuntu.com/15169116/
Does this also happen without this patch applied ?
--
balbi
signature.asc
Description: PGP signature
Re: Nokia N900: musb is in wrong state after boot
On Monday 22 February 2016 09:31:50 Felipe Balbi wrote: > Pali Rohár writes: > > > On Tuesday 26 January 2016 18:26:32 Tony Lindgren wrote: > >> * Pali Rohár [160126 06:35]: > >> > On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote: > >> > > * joerg Reisenweber [160121 11:35]: > >> > > > On Thu 21 January 2016 11:21:13 Tony Lindgren wrote: > >> > > > > Do you have some pointer > >> > > > > to the "certain resistor value on ID to GND" spec? Is it > >> > > > > maybe part of the carkit related parts of the USB spec? > >> > > > > >> > > > ""Three additional ID pin states are defined[4] at the nominal > >> > > > resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect > >> > > > to the ground pin. These permit the device to work with USB > >> > > > Accessory Charger Adapters that allows the OTG device to be > >> > > > attached to both a charger and another device simultaneously. > >> > > > [6]"" > >> > > > https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs > >> > > > >> > > OK thanks. So it's the "accessory charger" part of the > >> > > battery charging specification 1.1. > >> > > >> > So, Tony, do you have some idea what needs to be changed and how to > >> > fix peripheral mode after boot on Nokia N900? > >> > >> No, I'm waiting to hear an educated guess from Felipe on this one. > > about why peripheral mode doesn't work on n900 ? No idea. that's always > the default role of MUSB and last I checked, before stopping working on > this, BBB was working just fine. > > N900 is odd in that it has two PHYs (1701 handles data lines while > twl4030 handles power lines, IIRC), but peripheral should be working. > > The only reason for MUSB to not start would be that it's not detecting > VBUS being above session valid threshold, however twl4030 should have an > IRQ for that. > > What happens when cable is attached ? Any IRQs anywhere firing ? > Just to note, when I call echo peripheral > mode then detecting usb cable starts working and usb peripheral mode also works fine (also after disconnecting and connecting usb cable again). Read my first post in this thread, there are also some logs: https://lkml.org/lkml/2016/1/9/69 -- Pali Rohár pali.ro...@gmail.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
[PATCH] usb: dwc2: Use kmem_cache_free()
Here, free memory is allocated using kmem_cache_zalloc. So, use kmem_cache_free instead of kfree. This is done using Coccinelle and semantic patch used is as follows: // @@ expression x,E,c; @@ x = \(kmem_cache_alloc\|kmem_cache_zalloc\|kmem_cache_alloc_node\)(c,...) ... when != x = E when != &x ?-kfree(x) +kmem_cache_free(c,x) // Signed-off-by: Amitoj Kaur Chawla --- drivers/usb/dwc2/hcd_ddma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc2/hcd_ddma.c b/drivers/usb/dwc2/hcd_ddma.c index 36606fc..d6ebd16 100644 --- a/drivers/usb/dwc2/hcd_ddma.c +++ b/drivers/usb/dwc2/hcd_ddma.c @@ -111,7 +111,7 @@ static int dwc2_desc_list_alloc(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh, dma_unmap_single(hsotg->dev, qh->desc_list_dma, qh->desc_list_sz, DMA_FROM_DEVICE); - kfree(qh->desc_list); + kmem_cache_free(desc_cache, qh->desc_list); qh->desc_list = NULL; return -ENOMEM; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: commit 4b61b4f205eabfc9f863f805858aa5b32deb3de5 - usb: add HAS_IOMEM dependency to USB_APPLEDISPLAY
On Sat, 2016-02-20 at 14:50 -0800, Greg Kroah-Hartman wrote: > On Sat, Feb 20, 2016 at 11:44:38PM +0100, Vegard Nossum wrote: > > On 02/20/2016 11:22 PM, Greg Kroah-Hartman wrote: > > >On Tue, Feb 16, 2016 at 05:43:32PM +0100, Oliver Neukum wrote: > > >>On Tue, 2016-02-16 at 13:12 +0100, Vegard Nossum wrote: > > >>>The problem is that USB_APPLEDISPLAY has 'select > > >>>BACKLIGHT_LCD_SUPPORT', > > >>>but BACKLIGHT_LCD_SUPPORT has a dependency on HAS_IOMEM: > > >>> > > >>> menu "Graphics support" > > >>> depends on HAS_IOMEM > > >> > > >>It seems to me that this particular dependency is clearly wrong. > > >>Even an S390 can use USB graphics devices. That suggests an > > >>outright reversion of this particular change. > > > > > >Now reverted. > > > > > > > Just to be clear, you're reverting commit > > e25df1205f37c7bff3ab14fdfc8a5249f3c69c82 (which I believe is the commit > > Oliver was referring to) too, right? > > Nope, I reverted this USB one. It is better to have a false unmet dependency than a falsely disabled driver. Looking at this a bit closer, it seems to me that the backlight drivers put the dependency one level to high and it is necessay to check each backlight driver separatly. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: dwc3: drop FIFO resizing logic
Hi Felipe,
On Wednesday 10 February 2016 03:47 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Wednesday 10 February 2016 03:43 PM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Kishon Vijay Abraham I writes:
>>> Hi Felipe,
>>>
>>> On Thursday 04 February 2016 05:48 PM, Felipe Balbi wrote:
That FIFO resizing logic was added to support OMAP5
ES1.0 which had a bogus default FIFO size. I can't
remember the exact size of default FIFO, but it was
less than one bulk superspeed packet (<1024) which
would prevent USB3 from ever working on OMAP5 ES1.0.
However, OMAP5 ES1.0 support has been dropped by
commit aa2f4b16f830 ("ARM: OMAP5: id: Remove ES1.0
support") which renders FIFO resizing unnecessary.
Signed-off-by: Felipe Balbi
>>>
>>> tested this series on both dra7-evm and dra72-evm using mass storage gadget
>>> and
>>> msc.sh
>>
>> both HS and SS ?
>
> yes.. but the logs here were for only SS.
>>
>>> dra72-evm: http://pastebin.ubuntu.com/14887997/
>>> dra7-evm: http://pastebin.ubuntu.com/14887975/
>>>
>>> Tested-by: Kishon Vijay Abraham I
>>>
>>> Let me know if you want me to do any other testing on dra7.
>>
>> yeah, run testusb for a week or so, that usually catches odd bugs.
>
> Okay. I'll start the test before I go for vacation next week.
Looks like the test couldn't complete and I see dumps [1] in my host PC. Here's
the output of testusb [2].
[1] -> http://pastebin.ubuntu.com/15169114/
[2] -> http://pastebin.ubuntu.com/15169116/
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
