Re: [TESTPATCH] xhci: fix usb2 resume timing and races.
On 01.12.2015 17:47, Alan Stern wrote: On Mon, 30 Nov 2015, Mathias Nyman wrote: usb2 ports need to signal resume for 20ms before moving to U0 state. Both device and host can initiate resume. On host initated resume port is set to resume state, sleep 20ms, and finally set port to U0 state. That's an odd approach. The assumption in usbcore is that the HCD will not sleep here. On device initated resume a port status interrupt with a port in resume state in issued. The interrupt handler tags a resume_done[port] timestamp with current time + 20ms, and kick roothub timer. Root hub timer requests for port status, finds the port in resume state, checks if resume_done[port] timestamp passed, and set port to U0 state. ehci-hcd does the same thing, except that it also uses this resume_done timestamp with host-initiated resumes. There are a few issues with this approach, 1. A host initated resume will also generate a resume event, the event handler will find the port in resume state, believe it's a device initated and act accordingly. 2. A port status request might cut the 20ms resume signalling short if a get_port_status request is handled during the 20ms host resume. The port will be found in resume state. The timestamp is not set leading to time_after_eq(jiffoes, timestamp) returning true, as timestamp = 0. get_port_status will proceed with moving the port to U0. 3. If an error, or anything else happends to the port during device initated 20ms resume signalling it will leave all device resume parameters hanging uncleared preventing further resume. Fix this by using the existing resuming_ports bitfield to indicate if resume signalling timing is taken care of. Also check if the resume_done[port] is set before using it in time comparison. Also clear out any resume signalling related variables if port is not in U0 or Resume state. Wouldn't it be better to change the host-initiated resume mechanism to be consisten with device-initiated resumes? Or would that be too big a change for the time being? Alan Stern Yes, changing host initiated resume code would make sense. Hence the comment in the testpatch: /* Host initated resume doesn't time the resume * signalling using resume_done[]. * It manually sets RESUME state, sleeps 20ms * and sets U0 state. This should probably be * changed, but not right now, do nothing */ I was focusing more on clearing the stale resume related variables and didn't want to dig into the history of host initiated resume code at that moment. If ehci-hcd is using the timestamp + kick roothub approach for host resume, then I don't see why xhci can't do the same. -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/2] USB: quirks: Apply ALWAYS_POLL to all ELAN devices
Thank you all for your help on this. Adrien -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: pci-quirks: register USB mux found on Cherrytrail SOC
Hi Felipe, > IMHO, this should be creating a child device instead of calling > intel_usb_mux_register() directly. That way, your mux driver could > actually _be_ a driver. Seems like all you need to do from this point is > a register a simple platform_device which is a child of xhci, see > platform_device_register_simple() for how to do this. > > Or rather, platform_device_register_rsndata() passing xhci's device > pointer as parent. That was the plan originally, but unfortunately it does not work in this case. It creates conflict as platform_device_add() call will then claim part of io memory belonging to xHCI, making xHCI fail to probe. Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: pci-quirks: register USB mux found on Cherrytrail SOC
Hi,
> > @@ -1029,9 +1030,36 @@ static void quirk_usb_handoff_xhci(struct pci_dev
> > *pdev)
> > writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);
> >
> > hc_init:
> > - if (pdev->vendor == PCI_VENDOR_ID_INTEL)
> > + if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
> > usb_enable_intel_xhci_ports(pdev);
> >
> > + /*
> > +* Initialize the internal mux that shares a port between USB
> > +* Device Controller and xHCI on platforms that have it.
> > +*/
> > +#define XHCI_INTEL_VENDOR_CAPS 192
> > +#define XHCI_INTEL_USB_MUX_OFFSET 0x80d8
> > + ext_cap_offset = xhci_find_next_cap_offset(base,
> > + XHCI_HCC_PARAMS_OFFSET);
> > + ext_cap_offset = xhci_find_ext_cap_by_id(base, ext_cap_offset,
> > + XHCI_INTEL_VENDOR_CAPS);
>
> Hi Heikki,
>
> This helper has been replaced with xhci_find_next_ext_cap() in
> commit d5ddcdf(xhci: rework xhci extended capability list parsing functions).
>
> Need to fix this, otherwise it will not pass compile on top of usb-next.
Thanks Baolu. I'll fix it.
Cheers,
--
heikki
--
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] extcon: add driver for Intel USB mux
Hi David,
> > +void intel_usb_mux_unregister(struct intel_usb_mux *mux)
> > +{
>
> There are still 2 pending comments for this unregister function:
>
> 1) How about a protection against unbalanced unregistering? In case an
> user mistakenly unregisters twice or unregisters without a previous
> registering.
True. You already pointed that out in our off-list thread, but I
forgot. Sorry about that.
> 2) When unregistering, you need to clear the bit CFG0_SW_IDPIN_EN to
> set mux to automatic mode again. Or maybe you could save CFG0's initial
> value and set it again here. Anyway, when unregistering the mux driver
> you need to make sure the mux goes back to its original configuration.
This one is already been taken care of..
> > + extcon_unregister_notifier(&mux->edev, EXTCON_USB_HOST, &mux->nb);
> > + extcon_dev_unregister(&mux->edev);
> > + writel(mux->cfg0_ctx, mux->regs + INTEL_MUX_CFG0);
Thanks,
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux as a USB hub?
On Tue, Dec 01, 2015 at 06:17:54PM -0800, Greg KH wrote: > On Wed, Dec 02, 2015 at 01:02:28AM +, Rogan Dawes wrote: > > Thanks Greg. > > > > At a high level, what is needed to implement a new type of USB device > > gadget, > > such as a display link device? > > A lot of work :) > Heh! Ok, as a non C-programmer, I'm looking for the easiest way, then :-D > > I assume there is a small kernel portion that simply relays data to user > > space, > > and a user space component that processes that data and replies > > appropriately? > > The files Documentation/usb/gadget* should give you an idea of what is > needed here. But first, I suggest you read up on how USB works, it's a > lot more complex than I think you realize it is... I'm sure it is more complex that I realise, which is why I'm asking questions first. To explain what I am trying to achieve, and possibly the way in which I can go about it, to my understanding: As mentioned originally, I'm trying to come up with an IP KVM, as inexpensively as possible. Realising that the approach that I am following will not allow me to interact with any layers prior to a successfully booted operating system, what I am hoping to do is, at a minimum, be able to observe the DisplayLink traffic flowing from an external computer (i.e. not a VM) over the USB. As I understand it, I have a couple of options of achieving this: 1) Have Linux operate as a general purpose hub, and simply plug in a real displaylink adapter to the host ports, and observe the data flowing from one to the other. At least I don't have to worry about actually convincing upstream that I *am* a DisplayLink device. At this point, I can hopefully decode the data to reconstruct the framebuffer, and make it available via e.g. VNC. This seems to be a difficult option, as you have indicated. 2) Have Linux operate as some sort of proxy, in a special case of 1). No need to make it general purpose, so long as I can make it work for the DisplayLink adapter I have, I should be good. This may or may not be easier than 1). Again, with access to the data, I can reconstruct the framebuffer. 3) Making use of the Linux driver code already existing for the DisplayLink family, write a gadget driver to act as a DisplayLink device. Using a Windows VM and usbsnoop may make this easier during development. This is obviously the best case, but probably a lot more work than either 1 or 2. FWIW, while I'm OK with the result not being acceptable by kernel standards, I do plan to make the code freely available to anyone who would like to build on it. > > good luck, > > greg k-h Thanks for your time. I'm off to go read USB specs, and gadget documentation! :-D Rogan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux as a USB hub?
On Wed, Dec 2, 2015 at 7:29 AM, Rogan Dawes wrote: > On Tue, Dec 01, 2015 at 06:17:54PM -0800, Greg KH wrote: >> On Wed, Dec 02, 2015 at 01:02:28AM +, Rogan Dawes wrote: >> > Thanks Greg. >> > >> > At a high level, what is needed to implement a new type of USB device >> > gadget, >> > such as a display link device? > As mentioned originally, I'm trying to come up with an IP KVM, as > inexpensively as possible. Realising that the approach that I am following > will not allow me to interact with any layers prior to a successfully booted > operating system, what I am hoping to do is, at a minimum, be able to observe > the DisplayLink traffic flowing from an external computer (i.e. not a VM) > over the USB. > As I understand it, I have a couple of options of achieving this: > > 1) Have Linux operate as a general purpose hub, and simply plug in a real > displaylink adapter to the host ports, and observe the data flowing from one > to the other. At least I don't have to worry about actually convincing > upstream that I *am* a DisplayLink device. At this point, I can hopefully > decode the data to reconstruct the framebuffer, and make it available via > e.g. VNC. This seems to be a difficult option, as you have indicated. Linux has some built in gadget functions here: https://github.com/torvalds/linux/tree/master/drivers/usb/gadget/function but I haven't seen much discussion about creating a f_hub. > 2) Have Linux operate as some sort of proxy, in a special case of 1). No need > to make it general purpose, so long as I can make it work for the DisplayLink > adapter I have, I should be good. This may or may not be easier than 1). > Again, with access to the data, I can reconstruct the framebuffer. Might look at using a BeagleBone black with https://github.com/dominicgs/USBProxy as a mitm to observe the traffic. > 3) Making use of the Linux driver code already existing for the DisplayLink > family, write a gadget driver to act as a DisplayLink device. Using a Windows > VM and usbsnoop may make this easier during development. This is obviously > the best case, but probably a lot more work than either 1 or 2. Yea, I'd shoot for USBProxy, Dominic provides a in image for flashing the BeagleBone to do use it as a proxy for sniffing. > FWIW, while I'm OK with the result not being acceptable by kernel standards, > I do plan to make the code freely available to anyone who would like to build > on it. Another project that might be interesting for you to look at is https://github.com/pelya/android-keyboard-gadget , @pelya's approach is to use the camera on the phone, point it at the screen and show up as a keyboard/mouse gadget to the PC then export the KVM as a VNC server. I'm working on something similar but I want to support exporting USB devices as their bluetooth countparts and visa versa. Also looking into adding something similar to DriveDroid http://softwarebakery.com/projects/drivedroid to dynamically export installation media via mass_storage and network etc... https://github.com/ii/iikeyboard/wiki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux as a USB hub?
Thanks for the pointers, Chris! I'll check them all out. It sounds like the USBProxy is going to be the way to go. Rogan On Wed, Dec 02, 2015 at 09:10:10AM -0500, Chris McClimans wrote: > On Wed, Dec 2, 2015 at 7:29 AM, Rogan Dawes wrote: > > On Tue, Dec 01, 2015 at 06:17:54PM -0800, Greg KH wrote: > >> On Wed, Dec 02, 2015 at 01:02:28AM +, Rogan Dawes wrote: > >> > Thanks Greg. > >> > > >> > At a high level, what is needed to implement a new type of USB device > >> > gadget, > >> > such as a display link device? > > > As mentioned originally, I'm trying to come up with an IP KVM, as > > inexpensively as possible. Realising that the approach that I am following > > will not allow me to interact with any layers prior to a successfully > > booted operating system, what I am hoping to do is, at a minimum, be able > > to observe the DisplayLink traffic flowing from an external computer (i.e. > > not a VM) over the USB. > > > As I understand it, I have a couple of options of achieving this: > > > > 1) Have Linux operate as a general purpose hub, and simply plug in a real > > displaylink adapter to the host ports, and observe the data flowing from > > one to the other. At least I don't have to worry about actually convincing > > upstream that I *am* a DisplayLink device. At this point, I can hopefully > > decode the data to reconstruct the framebuffer, and make it available via > > e.g. VNC. This seems to be a difficult option, as you have indicated. > > Linux has some built in gadget functions here: > https://github.com/torvalds/linux/tree/master/drivers/usb/gadget/function > but I haven't seen much discussion about creating a f_hub. > > > 2) Have Linux operate as some sort of proxy, in a special case of 1). No > > need to make it general purpose, so long as I can make it work for the > > DisplayLink adapter I have, I should be good. This may or may not be easier > > than 1). Again, with access to the data, I can reconstruct the framebuffer. > > Might look at using a BeagleBone black with > https://github.com/dominicgs/USBProxy as a mitm to observe the traffic. > > > 3) Making use of the Linux driver code already existing for the DisplayLink > > family, write a gadget driver to act as a DisplayLink device. Using a > > Windows VM and usbsnoop may make this easier during development. This is > > obviously the best case, but probably a lot more work than either 1 or 2. > > Yea, I'd shoot for USBProxy, Dominic provides a in image for flashing > the BeagleBone to do use it as a proxy for sniffing. > > > FWIW, while I'm OK with the result not being acceptable by kernel > > standards, I do plan to make the code freely available to anyone who would > > like to build on it. > > Another project that might be interesting for you to look at is > https://github.com/pelya/android-keyboard-gadget , @pelya's approach > is to use the camera on the phone, point it at the screen and show up > as a keyboard/mouse gadget to the PC then export the KVM as a VNC > server. > > I'm working on something similar but I want to support exporting USB > devices as their bluetooth countparts and visa versa. Also looking > into adding something similar to DriveDroid > http://softwarebakery.com/projects/drivedroid to dynamically export > installation media via mass_storage and network etc... > https://github.com/ii/iikeyboard/wiki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: pci-quirks: register USB mux found on Cherrytrail SOC
Hi, Heikki Krogerus writes: > Hi Felipe, > >> IMHO, this should be creating a child device instead of calling >> intel_usb_mux_register() directly. That way, your mux driver could >> actually _be_ a driver. Seems like all you need to do from this point is >> a register a simple platform_device which is a child of xhci, see >> platform_device_register_simple() for how to do this. >> >> Or rather, platform_device_register_rsndata() passing xhci's device >> pointer as parent. > > That was the plan originally, but unfortunately it does not work in > this case. It creates conflict as platform_device_add() call will then > claim part of io memory belonging to xHCI, making xHCI fail to probe. okay, understood. -- balbi signature.asc Description: PGP signature
Re: USB resume issue
On Tue, 1 Dec 2015, Alan Cooper wrote: > I agree that for USB suspend modes, VBUS must be on, and our hardware > behaves that way for runtime suspend. The question is for system wide > suspend (S3/STR) can the system shut down the USB hardware entirely. Oh, okay, I misunderstood. > The ACPI spec and Linux Documents/power/states.txt seem to allow either > design. From states.txt under S3 mode: "In many cases, all peripheral buses > lose power when entering STR, so devices must be able to handle the > transition back to the On state". I'm not aware of any document stating whether USB buses should remain powered while an ACPI-based system is in S3. If it's not spelled out in the ACPI spec then it probably isn't mentioned anywhere. On the other hand, you should consider that if the bus isn't powered then remote wakeup will not work. This may be surprising to some users. Adapting wait_for_ss_port_enable() does seem like the best solution to the immediate 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: Linux as a USB hub?
On Wed, 2 Dec 2015, Rogan Dawes wrote: > Hi folks, > > I'm wondering if it is possible/reasonable to try to turn a linux > device with host and OTG ports into something that looks and acts > like a USB hub? Besides all the other responses you received, here's a short answer to your first question: No, it's not possible. There are several reasons for this. The most compelling is that the hardware isn't capable of doing what you want. In particular, the hardware found in USB OTG device controllers will respond only to packets sent to the controller's own address, whereas a hub needs to handle packets sent to any of the downstream devices' addresses. Other reasons include things like the timing restrictions on inter-packet delays. In principle it would be possible to do this using special USB hardware (i.e., integrate a hub into a Linux computer), but it isn't possible with standard host and OTG ports. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux as a USB hub?
On Wed, Dec 02, 2015 at 02:29:23PM +0200, Rogan Dawes wrote: > On Tue, Dec 01, 2015 at 06:17:54PM -0800, Greg KH wrote: > > On Wed, Dec 02, 2015 at 01:02:28AM +, Rogan Dawes wrote: > > > Thanks Greg. > > > > > > At a high level, what is needed to implement a new type of USB device > > > gadget, > > > such as a display link device? > > > > A lot of work :) > > > > Heh! Ok, as a non C-programmer, I'm looking for the easiest way, then :-D Hm, I strongly recommend learning C first, before doing any kernel stuff, that's going to be a requirement. And as Alan said, this isn't going to be possible, sorry, the hardware just does not work this way. 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: host: pci_quirks: fix memory leak, by adding iounmap
On Wed, Dec 02, 2015 at 09:08:06AM +0530, Saurabh Sengar wrote: > On 2 December 2015 at 04:05, Greg KH wrote: > > On Fri, Nov 06, 2015 at 05:46:30PM +0530, Saurabh Sengar wrote: > >> added iounmap inorder to free memory mapped to base before returning > >> > >> Signed-off-by: Saurabh Sengar > >> --- > >> drivers/usb/host/pci-quirks.c | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c > >> index f940056..332f687 100644 > >> --- a/drivers/usb/host/pci-quirks.c > >> +++ b/drivers/usb/host/pci-quirks.c > >> @@ -990,7 +990,7 @@ static void quirk_usb_handoff_xhci(struct pci_dev > >> *pdev) > >> /* We're reading garbage from the controller */ > >> dev_warn(&pdev->dev, > >>"xHCI controller failing to respond"); > >> - return; > >> + goto iounmap; > >> } > >> > >> if (!ext_cap_offset) > >> @@ -1061,7 +1061,7 @@ hc_init: > >>"xHCI HW did not halt within %d usec status = > >> 0x%x\n", > >>XHCI_MAX_HALT_USEC, val); > >> } > >> - > >> +iounmap: > >> iounmap(base); > >> } > >> > > > > Does not apply to the tree :( > > > This patch applies fine on top of > "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git". > Just now only I have re-verified. > Am I expected to send this patch on top of some other git tree/branch ? It will end up going in the usb.git tree, on the usb-next branch, and it conflicts with other xhci patches that just landed there ahead of yours. So it's not your fault, you did the right thing, just others also did work here so you need to redo yours as well, a normal thing in kernel development :) hope this helps explain things. 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: Infrastructure for zerocopy I/O
On Tue, 1 Dec 2015, Steinar H. Gunderson wrote:
> >> + usbm->mem = mem;
> >> + usbm->offset = virt_to_phys(mem);
> >> + usbm->size = size;
> >> + usbm->ps = ps;
> >> + spin_lock_irqsave(&ps->lock, flags);
> >> + list_add_tail(&usbm->memlist, &ps->memory_list);
> >> + spin_unlock_irqrestore(&ps->lock, flags);
> >> +
> >> + return usbm;
> >> +}
> > This subroutine should be merged into usbdev_mmap().
>
> Hm. Can you elaborate a bit on why? I thought it was nice to have it as a
> counterpoint to dec_use_count(), the deallocation function, and reasonably
> short.
Well, it's partly a matter of taste. But there's also a race: This
code adds usbm to ps->memory_list (making it available to URB
submissions running on other CPUs) before usbm has been completely
initialized (vm_start isn't set yet).
> > In fact, all the memory-oriented routines should be located together
> > in the source file. It's confusing to put some of them near the start
> > and others near the end.
>
> Is this about usbdev_mmap, or about usbdev_vm_{open,close}? I looked at the
> former as a syscall function and thus somehow better suited closer to e.g.
> the ioctl function. find_memory_area() can't be moved too far down since it's
> used from other places, unless you want me to do a forward declaration?
find_memory_area() is used in only one place. You can put everything
together if you move usbdev_mmap() and associated routines up near the
start of the file, after usbdev_read().
> >> + uurb_start >= iter->vm_start &&
> >> + uurb->buffer_length <= iter->vm_start - uurb_start +
> >> + (PAGE_SIZE << get_order(iter->size))) {
> > Shouldn't this be:
> >
> > uurb->start >= iter->vm_start &&
> > uurb->start < iter->vm_start + iter->size &&
> > uurb->buffer_length <= iter->vm_start + iter->size -
> > uurb->start) {
>
> I think both will work (modulo maybe issues with the PAGE_SIZE part?),
> but yours is clearer. Changed. (I assume you meant uurb_start, not
> uurb->start.)
(Yes, I did.) On further thought, testing uurb_start is sufficient.
If uurb->buffer_length then turns out to be too big, the function
should return an error (or rather, an ERR_PTR) and the URB submission
should fail.
> >>as->userurb = arg;
> >> - if (is_in && uurb->buffer_length > 0)
> >> + if (is_in && uurb->buffer_length > 0 && usbm == NULL)
> > I think you should keep this even when usbm is not NULL. No?
>
> No, then processcompl() will try to copy data there, which defeats the point
> of zerocopy. What other use would the userbuffer member have?
My mistake; for some reason I was thinking of as->urb->transfer_buffer
when I read as->userbuffer.
> >>as->userbuffer = uurb->buffer;
> >>else
> >>as->userbuffer = NULL;
> > When you use dma_zalloc_coherent(), you have to tell the USB core that
> > the buffer is already mapped for DMA by setting the URB_NO_TRANSFER_DMA_MAP
> > flag in urb->transfer_flags and by storing the DMA address in
> > urb->transfer_dma.
>
> Done. I have one question, though: Should I offset the transfer_dma address
> to match with the offset in the buffer, or is this just a handle? (I've
> assumed the latter, but I'm not at all sure it's correct.)
No, you do have to offset transfer_dma_address to match.
> >> + if (remap_pfn_range(vma, vma->vm_start,
> >> + virt_to_phys(usbm->mem) >> PAGE_SHIFT,
> >> + size, vma->vm_page_prot) < 0)
> >> + return -EAGAIN;
> > As Oliver pointed out, the memory needs to be reclaimed and accounted
> > for on the failure pathways.
>
> Done. (I saw you used a plural; is there more than this one?)
Well, alloc_urb_memory() also can fail.
> New patch attached. However, it's not working; I'm getting several of these
> messages:
>
> [ 28.796244] DMAR: Allocating domain for 2-2 failed
I don't know what the reason is for that. It may be that your kernel
isn't configured to allocate as much coherent memory as you are asking
for. We'll have to investigate further, maybe ask somebody who knows
more about how the DMA subsystem works.
---
> This is essentially a patch by Markus Rechberger with some updates.
> The original can be found at
>
> http://sundtek.de/support/devio_mmap_v0.4.diff
>
> This version has the following changes:
>
> - Rebased against a newer kernel (with some conflicts fixed).
> - Fixed all checkpatch violations and some style issues.
> - Fixes an issue where isochronous transfers would not really be
> zero-copy, but go through a pointless memcpy from one area to
> itself.
> - Ask for cached memory instead of uncached.
Actually, with dma_zalloc_coherent() you really are asking for
uncached memory (on systems where it makes a difference).
> - Drop the custom ioctl; use mmap only for allocation.
>
> Signed-off-by: S
Re: [PATCH] usb: host: pci_quirks: fix memory leak, by adding iounmap
Hi Greg, I am little unclear. Now, shall I resend my patch on top of usb.git tree or linux.git tree. Regards, Saurabh On 2 December 2015 at 21:15, Greg KH wrote: > On Wed, Dec 02, 2015 at 09:08:06AM +0530, Saurabh Sengar wrote: >> On 2 December 2015 at 04:05, Greg KH wrote: >> > On Fri, Nov 06, 2015 at 05:46:30PM +0530, Saurabh Sengar wrote: >> >> added iounmap inorder to free memory mapped to base before returning >> >> >> >> Signed-off-by: Saurabh Sengar >> >> --- >> >> drivers/usb/host/pci-quirks.c | 4 ++-- >> >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> >> >> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c >> >> index f940056..332f687 100644 >> >> --- a/drivers/usb/host/pci-quirks.c >> >> +++ b/drivers/usb/host/pci-quirks.c >> >> @@ -990,7 +990,7 @@ static void quirk_usb_handoff_xhci(struct pci_dev >> >> *pdev) >> >> /* We're reading garbage from the controller */ >> >> dev_warn(&pdev->dev, >> >>"xHCI controller failing to respond"); >> >> - return; >> >> + goto iounmap; >> >> } >> >> >> >> if (!ext_cap_offset) >> >> @@ -1061,7 +1061,7 @@ hc_init: >> >>"xHCI HW did not halt within %d usec status = >> >> 0x%x\n", >> >>XHCI_MAX_HALT_USEC, val); >> >> } >> >> - >> >> +iounmap: >> >> iounmap(base); >> >> } >> >> >> > >> > Does not apply to the tree :( >> >> >> This patch applies fine on top of >> "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git". >> Just now only I have re-verified. >> Am I expected to send this patch on top of some other git tree/branch ? > > It will end up going in the usb.git tree, on the usb-next branch, and it > conflicts with other xhci patches that just landed there ahead of yours. > So it's not your fault, you did the right thing, just others also did > work here so you need to redo yours as well, a normal thing in kernel > development :) > > hope this helps explain things. > > 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] usb: host: pci_quirks: fix memory leak, by adding iounmap
On Wed, Dec 02, 2015 at 09:25:53PM +0530, Saurabh Sengar wrote: > Hi Greg, > > I am little unclear. > Now, shall I resend my patch on top of usb.git tree or linux.git tree. The usb-next branch of the usb.git tree please. -- 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: dummy: Use platform_register/unregister_drivers()
From: Thierry Reding
These new helpers simplify implementing multi-driver modules and
properly handle failure to register one driver by unregistering all
previously registered drivers.
Signed-off-by: Thierry Reding
---
drivers/usb/gadget/udc/dummy_hcd.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
b/drivers/usb/gadget/udc/dummy_hcd.c
index dde44450dfa9..5ae6b60cc218 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -2692,6 +2692,11 @@ static struct platform_driver dummy_hcd_driver = {
},
};
+static struct platform_driver * const drivers[] = {
+ &dummy_hcd_driver,
+ &dummy_udc_driver,
+};
+
/*-*/
#define MAX_NUM_UDC2
static struct platform_device *the_udc_pdev[MAX_NUM_UDC];
@@ -2749,12 +2754,9 @@ static int __init init(void)
goto err_add_pdata;
}
- retval = platform_driver_register(&dummy_hcd_driver);
+ retval = platform_register_drivers(drivers, ARRAY_SIZE(drivers));
if (retval < 0)
goto err_add_pdata;
- retval = platform_driver_register(&dummy_udc_driver);
- if (retval < 0)
- goto err_register_udc_driver;
for (i = 0; i < mod_data.num; i++) {
retval = platform_device_add(the_hcd_pdev[i]);
@@ -2806,9 +2808,7 @@ err_add_udc:
for (i = 0; i < mod_data.num; i++)
platform_device_del(the_hcd_pdev[i]);
err_add_hcd:
- platform_driver_unregister(&dummy_udc_driver);
-err_register_udc_driver:
- platform_driver_unregister(&dummy_hcd_driver);
+ platform_unregister_drivers(drivers, ARRAY_SIZE(drivers));
err_add_pdata:
for (i = 0; i < mod_data.num; i++)
kfree(dum[i]);
@@ -2834,7 +2834,6 @@ static void __exit cleanup(void)
platform_device_unregister(the_hcd_pdev[i]);
kfree(dum);
}
- platform_driver_unregister(&dummy_udc_driver);
- platform_driver_unregister(&dummy_hcd_driver);
+ platform_unregister_drivers(drivers, ARRAY_SIZE(drivers));
}
module_exit(cleanup);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: Add connected retry on resume for non SS devices
Currently usb_port_resume waits for up to 2 seconds for CONNECT
status for SS devices only. This change will do the same thing for
non-SS devices even though the reason is a little different. This
will fix an issue where VBUS is turned off during system wide
"suspend to ram" and some 2.0 devices take greater than the current
max of 100ms to show connected after VBUS is enabled. This is most
commonly seen on hard drive based devices and USB3.0 devices plugged
into a 2.0 only port.
Signed-off-by: Al Cooper
---
drivers/usb/core/hub.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bdeadc1..d32824b 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3322,7 +3322,7 @@ static int finish_port_resume(struct usb_device *udev)
* This routine should only be called when persist is enabled for a SS
* device.
*/
-static int wait_for_ss_port_enable(struct usb_device *udev,
+static int wait_for_connected(struct usb_device *udev,
struct usb_hub *hub, int *port1,
u16 *portchange, u16 *portstatus)
{
@@ -3434,8 +3434,8 @@ int usb_port_resume(struct usb_device *udev, pm_message_t
msg)
}
}
- if (udev->persist_enabled && hub_is_superspeed(hub->hdev))
- status = wait_for_ss_port_enable(udev, hub, &port1, &portchange,
+ if (udev->persist_enabled)
+ status = wait_for_connected(udev, hub, &port1, &portchange,
&portstatus);
status = check_port_resume_type(udev,
--
1.9.0.138.g2de3478
--
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: dwc3: gadget: handle request->zero
So far, dwc3 has always missed request->zero
handling for every endpoint. Let's implement
that so we can handle cases where transfer must
be finished with a ZLP.
Note that dwc3 is a little special. Even though
we're dealing with a ZLP, we still need a buffer
of wMaxPacketSize bytes; to hide that detail from
every gadget driver, we have a preallocated buffer
of 1024 bytes (biggest bulk size) to use (and
share) among all endpoints.
Reported-by: Ravi B
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.h | 4
drivers/usb/dwc3/gadget.c | 51 +--
2 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 36f1cb74588c..c198e52ac9f7 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -37,6 +37,7 @@
#define DWC3_MSG_MAX 500
/* Global constants */
+#define DWC3_ZLP_BUF_SIZE 1024/* size of a superspeed bulk */
#define DWC3_EP0_BOUNCE_SIZE 512
#define DWC3_ENDPOINTS_NUM 32
#define DWC3_XHCI_RESOURCES_NUM2
@@ -632,6 +633,7 @@ struct dwc3_request {
unsigneddirection:1;
unsignedmapped:1;
unsignedqueued:1;
+ unsignedfree_on_complete:1;
};
/*
@@ -647,6 +649,7 @@ struct dwc3_scratchpad_array {
* @ctrl_req: usb control request which is used for ep0
* @ep0_trb: trb which is used for the ctrl_req
* @ep0_bounce: bounce buffer for ep0
+ * @zlp_buf: used when request->zero is set
* @setup_buf: used while precessing STD USB requests
* @ctrl_req_addr: dma address of ctrl_req
* @ep0_trb: dma address of ep0_trb
@@ -734,6 +737,7 @@ struct dwc3 {
struct usb_ctrlrequest *ctrl_req;
struct dwc3_trb *ep0_trb;
void*ep0_bounce;
+ void*zlp_buf;
void*scratchbuf;
u8 *setup_buf;
dma_addr_t ctrl_req_addr;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index e341f034296f..5a77e9925939 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1158,6 +1158,32 @@ out:
return ret;
}
+static void __dwc3_gadget_ep_zlp_complete(struct usb_ep *ep,
+ struct usb_request *request)
+{
+ dwc3_gadget_ep_free_request(ep, request);
+}
+
+static int __dwc3_gadget_ep_queue_zlp(struct dwc3 *dwc, struct dwc3_ep *dep)
+{
+ struct dwc3_request *req;
+ struct usb_request *request;
+ struct usb_ep *ep = &dep->endpoint;
+
+ dwc3_trace(trace_dwc3_gadget, "queueing ZLP\n");
+ request = dwc3_gadget_ep_alloc_request(ep, GFP_ATOMIC);
+ if (!request)
+ return -ENOMEM;
+
+ request->length = 0;
+ request->buf = dwc->zlp_buf;
+ request->complete = __dwc3_gadget_ep_zlp_complete;
+
+ req = to_dwc3_request(request);
+
+ return __dwc3_gadget_ep_queue(dep, req);
+}
+
static int dwc3_gadget_ep_queue(struct usb_ep *ep, struct usb_request *request,
gfp_t gfp_flags)
{
@@ -1171,6 +1197,17 @@ static int dwc3_gadget_ep_queue(struct usb_ep *ep,
struct usb_request *request,
spin_lock_irqsave(&dwc->lock, flags);
ret = __dwc3_gadget_ep_queue(dep, req);
+
+ /*
+* Okay, here's the thing, if gadget driver has requested for a ZLP by
+* setting request->zero, instead of doing magic, we will just queue an
+* extra usb_request ourselves so that it gets handled the same way as
+* any other request.
+*/
+ if (ret == 0 && request->zero && (request->length % ep->maxpacket == 0))
+ ret = __dwc3_gadget_ep_queue_zlp(dwc, dep);
+
+out:
spin_unlock_irqrestore(&dwc->lock, flags);
return ret;
@@ -2743,6 +2780,12 @@ int dwc3_gadget_init(struct dwc3 *dwc)
goto err3;
}
+ dwc->zlp_buf = kzalloc(DWC3_ZLP_BUF_SIZE, GFP_KERNEL);
+ if (!dwc->zlp_buf) {
+ ret = -ENOMEM;
+ goto err4;
+ }
+
dwc->gadget.ops = &dwc3_gadget_ops;
dwc->gadget.max_speed = USB_SPEED_SUPER;
dwc->gadget.speed = USB_SPEED_UNKNOWN;
@@ -2762,16 +2805,19 @@ int dwc3_gadget_init(struct dwc3 *dwc)
ret = dwc3_gadget_init_endpoints(dwc);
if (ret)
- goto err4;
+ goto err5;
ret = usb_add_gadget_udc(dwc->dev, &dwc->gadget);
if (ret) {
dev_err(dwc->dev, "failed to register udc\n");
- goto err4;
+ goto err5;
}
return 0;
+err5:
+ kfree(dwc->zlp_buf);
+
err4:
dwc3_gadget_free_endpoints(dwc);
dma_free_coherent(dwc->dev, DWC3_EP0_BOUNCE_SIZE,
@@ -2804,6 +2850,7 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
dwc->ep0_bounce, dwc->ep0_boun
Re: Linux as a USB hub?
On 12/02/2015 01:29 PM, Rogan Dawes wrote: On Tue, Dec 01, 2015 at 06:17:54PM -0800, Greg KH wrote: On Wed, Dec 02, 2015 at 01:02:28AM +, Rogan Dawes wrote: Thanks Greg. At a high level, what is needed to implement a new type of USB device gadget, such as a display link device? A lot of work :) Heh! Ok, as a non C-programmer, I'm looking for the easiest way, then :-D I assume there is a small kernel portion that simply relays data to user space, and a user space component that processes that data and replies appropriately? The files Documentation/usb/gadget* should give you an idea of what is needed here. But first, I suggest you read up on how USB works, it's a lot more complex than I think you realize it is... I'm sure it is more complex that I realise, which is why I'm asking questions first. To explain what I am trying to achieve, and possibly the way in which I can go about it, to my understanding: As mentioned originally, I'm trying to come up with an IP KVM, as inexpensively as possible. Realising that the approach that I am following will not allow me to interact with any layers prior to a successfully booted operating system, what I am hoping to do is, at a minimum, be able to observe the DisplayLink traffic flowing from an external computer (i.e. not a VM) over the USB. If I understood your idea correctly you would like to do something like rdp over USB, am I right? If yes then I'm currently running a project with students from Warsaw University of Technology and they are doing exactly this:) What we would like to do: - Use FunctionFS to emulate DisplayLink device - Use f_hid to pass input events - Maybe use f_ecm to share clipboard, file copy etc. Unfortunately currently we have only some very basic proof of concept. We have ffs daemon and ConfigFS config to setup and act like a display link with 640x480 monitor. So on a host side we see another monitor and on the device side we have an window in which we can see image from host. There are several problems. The most important one is display link host driver and protocol documentation. We have implemented our function based on open source display link driver (udl). Unfortunately the performance is very poor 1280x1024 is absolutely max what we can get if we don't want to have a slide show. udl driver itself has also some problems and NULL ptr dereferences. Moreover, Linux driver implements only very limited set of encodings while Windows driver has much more of them and it's very easy to see when you compare usb bandwidth used by widnows and linux driver. That's why we will try to improve udl driver. Currently we try to setup machine at university which will run linux and then windows in virtual machine. We would like to connect dl to this computer, pass it to virtual machine and then use usbmon + wireshark and try to figure out new encodings used by windows driver and add them to udl driver but probably it will take a lot of time... Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- 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: Add connected retry on resume for non SS devices
On Wed, 2 Dec 2015, Al Cooper wrote:
> Currently usb_port_resume waits for up to 2 seconds for CONNECT
> status for SS devices only. This change will do the same thing for
> non-SS devices even though the reason is a little different. This
> will fix an issue where VBUS is turned off during system wide
> "suspend to ram" and some 2.0 devices take greater than the current
> max of 100ms to show connected after VBUS is enabled. This is most
> commonly seen on hard drive based devices and USB3.0 devices plugged
> into a 2.0 only port.
>
> Signed-off-by: Al Cooper
> ---
> drivers/usb/core/hub.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index bdeadc1..d32824b 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -3322,7 +3322,7 @@ static int finish_port_resume(struct usb_device *udev)
> * This routine should only be called when persist is enabled for a SS
> * device.
> */
> -static int wait_for_ss_port_enable(struct usb_device *udev,
> +static int wait_for_connected(struct usb_device *udev,
> struct usb_hub *hub, int *port1,
> u16 *portchange, u16 *portstatus)
> {
Please update the comments at the head of this routine to match.
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 v2] usb: host: pci_quirks: fix memory leak, by adding iounmap
added iounmap inorder to free memory mapped to base before returning
Signed-off-by: Saurabh Sengar
---
v2: changed logic a bit, because of recent patches pushed to usb-next
drivers/usb/host/pci-quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 26cb8c8..2ac198c 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -992,7 +992,7 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
if ((ext_cap_offset + sizeof(val)) > len) {
/* We're reading garbage from the controller */
dev_warn(&pdev->dev, "xHCI controller failing to respond");
- return;
+ goto hc_init;
}
val = readl(base + ext_cap_offset);
--
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: Linux as a USB hub?
Krzysztof Opasiak writes: > That's why we will try to improve udl driver. Currently we try to > setup machine at university which will run linux and then windows in > virtual machine. We would like to connect dl to this computer, pass it > to virtual machine and then use usbmon + wireshark and try to figure > out new encodings used by windows driver and add them to udl driver > but probably it will take a lot of time... This might be old news to you, but there are actually very good open source(!) tools for USB sniffing in Windows: http://desowin.org/usbpcap/ So you don't need the additional complexity of a virtual machine. You can of course still analyze the dumps on Linux. Just feed them to Wireshark. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux as a USB hub?
On 12/02/2015 06:34 PM, Bjørn Mork wrote: Krzysztof Opasiak writes: That's why we will try to improve udl driver. Currently we try to setup machine at university which will run linux and then windows in virtual machine. We would like to connect dl to this computer, pass it to virtual machine and then use usbmon + wireshark and try to figure out new encodings used by windows driver and add them to udl driver but probably it will take a lot of time... This might be old news to you, but there are actually very good open source(!) tools for USB sniffing in Windows: http://desowin.org/usbpcap/ So you don't need the additional complexity of a virtual machine. You can of course still analyze the dumps on Linux. Just feed them to Wireshark. First of all thank you very much for reminding about that tool. I heard about it but never used it. Unfortunately I'm a little bit afraid that it may generate some problems. We need to interact with windows graphics to generate some well-defined payload to device and try to analyse it. So I'm simply afraid that launching and manipulating some additional tools on the same system may generate some unwanted traffic:( -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux as a USB hub?
On Wed, Dec 02, 2015 at 10:12:26AM -0500, Alan Stern wrote: > On Wed, 2 Dec 2015, Rogan Dawes wrote: > > > Hi folks, > > > > I'm wondering if it is possible/reasonable to try to turn a linux > > device with host and OTG ports into something that looks and acts > > like a USB hub? > > Besides all the other responses you received, here's a short answer to > your first question: No, it's not possible. > > There are several reasons for this. The most compelling is that the > hardware isn't capable of doing what you want. In particular, the > hardware found in USB OTG device controllers will respond only to > packets sent to the controller's own address, whereas a hub needs to > handle packets sent to any of the downstream devices' addresses. > > Other reasons include things like the timing restrictions on > inter-packet delays. In principle it would be possible to do this > using special USB hardware (i.e., integrate a hub into a Linux > computer), but it isn't possible with standard host and OTG ports. > > Alan Stern > Thanks for the explanation, Alan. I'm going to try the USBProxy route suggested by Chris first. I have read the documentation for the USB gadgets (multi, hid, printer, serial), but noted that there seem to be quite a few more gadgets available in the source nowadays. e.g. audio, webcam . Are there any plans to document these at some stage? Also, I saw "dummy_hcd.c", which sounds interesting. Rogan Rogan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux as a USB hub?
On Wed, Dec 02, 2015 at 06:00:21PM +0100, Krzysztof Opasiak wrote: > > > On 12/02/2015 01:29 PM, Rogan Dawes wrote: > >As mentioned originally, I'm trying to come up with an IP KVM, as > >inexpensively as possible. Realising that the approach that I am following > >will not allow me to interact with any layers prior to a successfully booted > >operating system, what I am hoping to do is, at a minimum, be able to > >observe the DisplayLink traffic flowing from an external computer (i.e. not > >a VM) over the USB. > > > > If I understood your idea correctly you would like to do something > like rdp over USB, am I right? > > If yes then I'm currently running a project with students from > Warsaw University of Technology and they are doing exactly this:) > > What we would like to do: > - Use FunctionFS to emulate DisplayLink device > - Use f_hid to pass input events > - Maybe use f_ecm to share clipboard, file copy etc. > > Unfortunately currently we have only some very basic proof of > concept. We have ffs daemon and ConfigFS config to setup and act > like a display link with 640x480 monitor. So on a host side we see > another monitor and on the device side we have an window in which we > can see image from host. > > There are several problems. The most important one is display link > host driver and protocol documentation. We have implemented our > function based on open source display link driver (udl). > Unfortunately the performance is very poor 1280x1024 is absolutely > max what we can get if we don't want to have a slide show. udl > driver itself has also some problems and NULL ptr dereferences. > Moreover, Linux driver implements only very limited set of encodings > while Windows driver has much more of them and it's very easy to see > when you compare usb bandwidth used by widnows and linux driver. > > That's why we will try to improve udl driver. Currently we try to > setup machine at university which will run linux and then windows in > virtual machine. We would like to connect dl to this computer, pass > it to virtual machine and then use usbmon + wireshark and try to > figure out new encodings used by windows driver and add them to udl > driver but probably it will take a lot of time... > > Best regards, Hi, Yes, this is exactly what I am trying to implement. To be honest, I'd be quite happy with a single frame per second, but it sounds like you are way ahead of where I am. Is there any chance in getting a look at your code? Rogan -- 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] extcon: add driver for Intel USB mux
Hi Heikki,
On Wed, Dec 02, 2015 at 12:27:10PM +0200, Heikki Krogerus wrote:
> Hi David,
>
>
>
> > > +void intel_usb_mux_unregister(struct intel_usb_mux *mux)
> > > +{
> >
> > There are still 2 pending comments for this unregister function:
> >
> > 1) How about a protection against unbalanced unregistering? In case an
> > user mistakenly unregisters twice or unregisters without a previous
> > registering.
>
> True. You already pointed that out in our off-list thread, but I
> forgot. Sorry about that.
>
> > 2) When unregistering, you need to clear the bit CFG0_SW_IDPIN_EN to
> > set mux to automatic mode again. Or maybe you could save CFG0's initial
> > value and set it again here. Anyway, when unregistering the mux driver
> > you need to make sure the mux goes back to its original configuration.
>
> This one is already been taken care of..
>
> > > + extcon_unregister_notifier(&mux->edev, EXTCON_USB_HOST, &mux->nb);
> > > + extcon_dev_unregister(&mux->edev);
> > > + writel(mux->cfg0_ctx, mux->regs + INTEL_MUX_CFG0);
>
>
Of course :)
Sorry I missed this part.
Br, David
--
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: Regression, was [PATCH 4/4] USB: host: ohci-at91: merge loops in ohci_hcd_at91_drv_probe
Hi Peter,
On 01/12/2015 at 18:17:16 +0100, Peter Rosin wrote :
> [] (ohci_hcd_at91_overcurrent_irq) from []
> (handle_irq_event_percpu+0x78/0x140)
> [] (handle_irq_event_percpu) from []
> (handle_irq_event+0x2c/0x40)
> [] (handle_irq_event) from []
> (handle_simple_irq+0x6c/0x80)
> [] (handle_simple_irq) from []
> (generic_handle_irq+0x2c/0x3c)
> [] (generic_handle_irq) from []
> (gpio_irq_handler+0xa4/0x12c)
> [] (gpio_irq_handler) from []
> (generic_handle_irq+0x2c/0x3c)
> [] (generic_handle_irq) from []
> (__handle_domain_irq+0x54/0xa8)
> [] (__handle_domain_irq) from [] (__irq_svc+0x40/0x54)
> [] (__irq_svc) from [] (__setup_irq+0x248/0x530)
> [] (__setup_irq) from [] (request_threaded_irq+0xc4/0x144)
> [] (request_threaded_irq) from []
> (ohci_hcd_at91_drv_probe+0x460/0x518)
> [] (ohci_hcd_at91_drv_probe) from []
> (platform_drv_probe+0x44/0xa4)
> [] (platform_drv_probe) from []
> (driver_probe_device+0x1fc/0x43c)
> [] (driver_probe_device) from []
> (__driver_attach+0x8c/0x90)
> [] (__driver_attach) from [] (bus_for_each_dev+0x6c/0xa0)
> [] (bus_for_each_dev) from [] (bus_add_driver+0x1d0/0x268)
> [] (bus_add_driver) from [] (driver_register+0x78/0xf8)
> [] (driver_register) from [] (do_one_initcall+0xb8/0x1f0)
> [] (do_one_initcall) from []
> (kernel_init_freeable+0x138/0x1d8)
> [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe8)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x2c)
> Code: e5916058 e1a08000 e3a04000 e2865008 (e5b50004)
> ---[ end trace e66fbc480972ac43 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
> ---[ end Kernel panic - not syncing: Fatal exception in interrupt
I think I understood what happens. Can you try the following patch?
8<--
>From 402f8444bc92d218edc63dcc3c87459981a56c31 Mon Sep 17 00:00:00 2001
From: Alexandre Belloni
Date: Wed, 2 Dec 2015 18:49:34 +0100
Subject: [PATCH] USB: host: ohci-at91: fix a crash in
ohci_hcd_at91_overcurrent_irq
Signed-off-by: Alexandre Belloni
---
drivers/usb/host/ohci-at91.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 342ffd140122..8c6e15bd6ff0 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -473,6 +473,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
if (!pdata)
return -ENOMEM;
+ pdev->dev.platform_data = pdata;
+
if (!of_property_read_u32(np, "num-ports", &ports))
pdata->ports = ports;
@@ -483,6 +485,7 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
*/
if (i >= pdata->ports) {
pdata->vbus_pin[i] = -EINVAL;
+ pdata->overcurrent_pin[i] = -EINVAL;
continue;
}
@@ -513,10 +516,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
}
at91_for_each_port(i) {
- if (i >= pdata->ports) {
- pdata->overcurrent_pin[i] = -EINVAL;
- continue;
- }
+ if (i >= pdata->ports)
+ break;
pdata->overcurrent_pin[i] =
of_get_named_gpio_flags(np, "atmel,oc-gpio", i, &flags);
@@ -552,8 +553,6 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
}
}
- pdev->dev.platform_data = pdata;
-
device_init_wakeup(&pdev->dev, 1);
return usb_hcd_at91_probe(&ohci_at91_hc_driver, pdev);
}
--
2.5.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] usb: dwc3: gadget: handle request->zero
Felipe Balbi writes:
> So far, dwc3 has always missed request->zero
> handling for every endpoint. Let's implement
> that so we can handle cases where transfer must
> be finished with a ZLP.
>
> Note that dwc3 is a little special. Even though
> we're dealing with a ZLP, we still need a buffer
> of wMaxPacketSize bytes; to hide that detail from
> every gadget driver, we have a preallocated buffer
> of 1024 bytes (biggest bulk size) to use (and
> share) among all endpoints.
>
> Reported-by: Ravi B
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/dwc3/core.h | 4
> drivers/usb/dwc3/gadget.c | 51
> +--
> 2 files changed, 53 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 36f1cb74588c..c198e52ac9f7 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -37,6 +37,7 @@
> #define DWC3_MSG_MAX 500
>
> /* Global constants */
> +#define DWC3_ZLP_BUF_SIZE1024/* size of a superspeed bulk */
> #define DWC3_EP0_BOUNCE_SIZE 512
> #define DWC3_ENDPOINTS_NUM 32
> #define DWC3_XHCI_RESOURCES_NUM 2
> @@ -632,6 +633,7 @@ struct dwc3_request {
> unsigneddirection:1;
> unsignedmapped:1;
> unsignedqueued:1;
> + unsignedfree_on_complete:1;
unnecessary flag. Forgot to remove it when cleaning up the patch. I'll
send v2.
--
balbi
signature.asc
Description: PGP signature
[PATCH v2] usb: dwc3: gadget: handle request->zero
So far, dwc3 has always missed request->zero
handling for every endpoint. Let's implement
that so we can handle cases where transfer must
be finished with a ZLP.
Note that dwc3 is a little special. Even though
we're dealing with a ZLP, we still need a buffer
of wMaxPacketSize bytes; to hide that detail from
every gadget driver, we have a preallocated buffer
of 1024 bytes (biggest bulk size) to use (and
share) among all endpoints.
Reported-by: Ravi B
Signed-off-by: Felipe Balbi
---
since v1:
- remove unnecessary 'free_on_complete' flag
drivers/usb/dwc3/core.h | 3 +++
drivers/usb/dwc3/gadget.c | 51 +--
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 36f1cb74588c..29130682e547 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -37,6 +37,7 @@
#define DWC3_MSG_MAX 500
/* Global constants */
+#define DWC3_ZLP_BUF_SIZE 1024/* size of a superspeed bulk */
#define DWC3_EP0_BOUNCE_SIZE 512
#define DWC3_ENDPOINTS_NUM 32
#define DWC3_XHCI_RESOURCES_NUM2
@@ -647,6 +648,7 @@ struct dwc3_scratchpad_array {
* @ctrl_req: usb control request which is used for ep0
* @ep0_trb: trb which is used for the ctrl_req
* @ep0_bounce: bounce buffer for ep0
+ * @zlp_buf: used when request->zero is set
* @setup_buf: used while precessing STD USB requests
* @ctrl_req_addr: dma address of ctrl_req
* @ep0_trb: dma address of ep0_trb
@@ -734,6 +736,7 @@ struct dwc3 {
struct usb_ctrlrequest *ctrl_req;
struct dwc3_trb *ep0_trb;
void*ep0_bounce;
+ void*zlp_buf;
void*scratchbuf;
u8 *setup_buf;
dma_addr_t ctrl_req_addr;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index e341f034296f..5a77e9925939 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1158,6 +1158,32 @@ out:
return ret;
}
+static void __dwc3_gadget_ep_zlp_complete(struct usb_ep *ep,
+ struct usb_request *request)
+{
+ dwc3_gadget_ep_free_request(ep, request);
+}
+
+static int __dwc3_gadget_ep_queue_zlp(struct dwc3 *dwc, struct dwc3_ep *dep)
+{
+ struct dwc3_request *req;
+ struct usb_request *request;
+ struct usb_ep *ep = &dep->endpoint;
+
+ dwc3_trace(trace_dwc3_gadget, "queueing ZLP\n");
+ request = dwc3_gadget_ep_alloc_request(ep, GFP_ATOMIC);
+ if (!request)
+ return -ENOMEM;
+
+ request->length = 0;
+ request->buf = dwc->zlp_buf;
+ request->complete = __dwc3_gadget_ep_zlp_complete;
+
+ req = to_dwc3_request(request);
+
+ return __dwc3_gadget_ep_queue(dep, req);
+}
+
static int dwc3_gadget_ep_queue(struct usb_ep *ep, struct usb_request *request,
gfp_t gfp_flags)
{
@@ -1171,6 +1197,17 @@ static int dwc3_gadget_ep_queue(struct usb_ep *ep,
struct usb_request *request,
spin_lock_irqsave(&dwc->lock, flags);
ret = __dwc3_gadget_ep_queue(dep, req);
+
+ /*
+* Okay, here's the thing, if gadget driver has requested for a ZLP by
+* setting request->zero, instead of doing magic, we will just queue an
+* extra usb_request ourselves so that it gets handled the same way as
+* any other request.
+*/
+ if (ret == 0 && request->zero && (request->length % ep->maxpacket == 0))
+ ret = __dwc3_gadget_ep_queue_zlp(dwc, dep);
+
+out:
spin_unlock_irqrestore(&dwc->lock, flags);
return ret;
@@ -2743,6 +2780,12 @@ int dwc3_gadget_init(struct dwc3 *dwc)
goto err3;
}
+ dwc->zlp_buf = kzalloc(DWC3_ZLP_BUF_SIZE, GFP_KERNEL);
+ if (!dwc->zlp_buf) {
+ ret = -ENOMEM;
+ goto err4;
+ }
+
dwc->gadget.ops = &dwc3_gadget_ops;
dwc->gadget.max_speed = USB_SPEED_SUPER;
dwc->gadget.speed = USB_SPEED_UNKNOWN;
@@ -2762,16 +2805,19 @@ int dwc3_gadget_init(struct dwc3 *dwc)
ret = dwc3_gadget_init_endpoints(dwc);
if (ret)
- goto err4;
+ goto err5;
ret = usb_add_gadget_udc(dwc->dev, &dwc->gadget);
if (ret) {
dev_err(dwc->dev, "failed to register udc\n");
- goto err4;
+ goto err5;
}
return 0;
+err5:
+ kfree(dwc->zlp_buf);
+
err4:
dwc3_gadget_free_endpoints(dwc);
dma_free_coherent(dwc->dev, DWC3_EP0_BOUNCE_SIZE,
@@ -2804,6 +2850,7 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
dwc->ep0_bounce, dwc->ep0_bounce_addr);
kfree(dwc->setup_buf);
+ kfree(dwc->zlp_buf);
dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
dwc->ep0_trb,
[PATCH 00/18] usb: dwc2: Reduce probe delays
This series includes patches that were submitted earlier by Douglas Anderson and Yunzhi Li to reduce delays during probe and get the correct reset values of the hardware configuration registers. These are patches 1-6 in this series. I have additionally added patches to clean up the code around that area, and have further reduced the delays by: - Taking into account the correct dr_mode - Skipping force mode when not needed - Removing unnecessary force mode from the gadget side - Reduce the force mode delay from 150 ms to 25 ms Tested on: - Synopsys HAPS, IP v3.20 - Altera SOCFPGA, IP v2.93 Appreciate testing on other platforms. Regards, John Douglas Anderson (4): usb: dwc2: Restore GUSBCFG in dwc2_get_hwparams() usb: dwc2: Avoid double-reset at boot time usb: dwc2: Speed dwc2_get_hwparams() on some host-only ports usb: dwc2: Avoid more calls to dwc2_core_reset() John Youn (12): usb: dwc2: Reorder AHBIDLE and CSFTRST in dwc2_core_reset() usb: dwc2: Rename dwc2_core_reset() usb: dwc2: Add dwc2_core_reset() usb: dwc2: Add functions to check the HW OTG config usb: dwc2: Fix dr_mode validation usb: dwc2: Move mode querying functions into core.h usb: dwc2: Move reset into dwc2_get_hwparams() usb: dwc2: Add functions to set and clear force mode usb: dwc2: Improve handling of host and device hwparams usb: dwc2: gadget: Use the common dwc2_core_reset() usb: dwc2: gadget: Remove force device mode usb: dwc2: Reduce delay when forcing mode in reset Yunzhi Li (2): usb: dwc2: reset dwc2 core before dwc2_get_hwparams() usb: dwc2: reduce dwc2 driver probe time drivers/usb/dwc2/core.c | 301 ++-- drivers/usb/dwc2/core.h | 30 - drivers/usb/dwc2/gadget.c | 68 +- drivers/usb/dwc2/hcd.c | 6 +- drivers/usb/dwc2/hcd.h | 12 -- drivers/usb/dwc2/platform.c | 81 ++-- 6 files changed, 340 insertions(+), 158 deletions(-) -- 2.6.3 -- 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 08/18] usb: dwc2: Rename dwc2_core_reset()
Renamed dwc2_core_reset() to dwc2_core_reset_and_force_mode(). This
describes what it is doing more accurately. This is in preparation of
introducing a plain dwc2_core_reset() function that only performs the
reset and doesn't force the mode.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 8
drivers/usb/dwc2/core.h | 2 +-
drivers/usb/dwc2/platform.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 2d2b538..24f9e80 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -481,7 +481,7 @@ static void dwc2_init_fs_ls_pclk_sel(struct dwc2_hsotg
*hsotg)
* Do core a soft reset of the core. Be careful with this because it
* resets all the internal state machines of the core.
*/
-int dwc2_core_reset(struct dwc2_hsotg *hsotg)
+int dwc2_core_reset_and_force_mode(struct dwc2_hsotg *hsotg)
{
u32 greset;
int count = 0;
@@ -561,7 +561,7 @@ static int dwc2_fs_phy_init(struct dwc2_hsotg *hsotg, bool
select_phy)
dwc2_writel(usbcfg, hsotg->regs + GUSBCFG);
/* Reset after a PHY select */
- retval = dwc2_core_reset(hsotg);
+ retval = dwc2_core_reset_and_force_mode(hsotg);
if (retval) {
dev_err(hsotg->dev,
@@ -640,7 +640,7 @@ static int dwc2_hs_phy_init(struct dwc2_hsotg *hsotg, bool
select_phy)
dwc2_writel(usbcfg, hsotg->regs + GUSBCFG);
/* Reset after setting the PHY parameters */
- retval = dwc2_core_reset(hsotg);
+ retval = dwc2_core_reset_and_force_mode(hsotg);
if (retval) {
dev_err(hsotg->dev,
"%s: Reset failed, aborting", __func__);
@@ -805,7 +805,7 @@ int dwc2_core_init(struct dwc2_hsotg *hsotg, bool
initial_setup)
* needed to in order to properly detect various parameters).
*/
if (!initial_setup) {
- retval = dwc2_core_reset(hsotg);
+ retval = dwc2_core_reset_and_force_mode(hsotg);
if (retval) {
dev_err(hsotg->dev, "%s(): Reset failed, aborting\n",
__func__);
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 28d0288..0b4c036 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -889,7 +889,7 @@ enum dwc2_halt_status {
* The following functions support initialization of the core driver component
* and the DWC_otg controller
*/
-extern int dwc2_core_reset(struct dwc2_hsotg *hsotg);
+extern int dwc2_core_reset_and_force_mode(struct dwc2_hsotg *hsotg);
extern void dwc2_core_host_init(struct dwc2_hsotg *hsotg);
extern int dwc2_enter_hibernation(struct dwc2_hsotg *hsotg);
extern int dwc2_exit_hibernation(struct dwc2_hsotg *hsotg, bool restore);
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 442cd0d..1c2f5f6 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -459,7 +459,7 @@ static int dwc2_driver_probe(struct platform_device *dev)
* Reset before dwc2_get_hwparams() then it could get power-on real
* reset value form registers.
*/
- dwc2_core_reset(hsotg);
+ dwc2_core_reset_and_force_mode(hsotg);
/* Detect config values from hardware */
retval = dwc2_get_hwparams(hsotg);
--
2.6.3
--
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 09/18] usb: dwc2: Add dwc2_core_reset()
dwc2_core_reset() was previously renamed to
dwc2_core_reset_and_force_mode(). Now add back dwc2_core_reset() which
performs only a basic core reset without forcing the mode.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 22 ++
drivers/usb/dwc2/core.h | 1 +
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 24f9e80..b7a733a 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -478,14 +478,12 @@ static void dwc2_init_fs_ls_pclk_sel(struct dwc2_hsotg
*hsotg)
}
/*
- * Do core a soft reset of the core. Be careful with this because it
- * resets all the internal state machines of the core.
+ * Performs a base controller soft reset.
*/
-int dwc2_core_reset_and_force_mode(struct dwc2_hsotg *hsotg)
+int dwc2_core_reset(struct dwc2_hsotg *hsotg)
{
u32 greset;
int count = 0;
- u32 gusbcfg;
dev_vdbg(hsotg->dev, "%s()\n", __func__);
@@ -517,6 +515,22 @@ int dwc2_core_reset_and_force_mode(struct dwc2_hsotg
*hsotg)
}
} while (!(greset & GRSTCTL_AHBIDLE));
+ return 0;
+}
+
+/*
+ * Do core a soft reset of the core. Be careful with this because it
+ * resets all the internal state machines of the core.
+ */
+int dwc2_core_reset_and_force_mode(struct dwc2_hsotg *hsotg)
+{
+ int retval;
+ u32 gusbcfg;
+
+ retval = dwc2_core_reset(hsotg);
+ if (retval)
+ return retval;
+
if (hsotg->dr_mode == USB_DR_MODE_HOST) {
gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 0b4c036..53c992a 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -889,6 +889,7 @@ enum dwc2_halt_status {
* The following functions support initialization of the core driver component
* and the DWC_otg controller
*/
+extern int dwc2_core_reset(struct dwc2_hsotg *hsotg);
extern int dwc2_core_reset_and_force_mode(struct dwc2_hsotg *hsotg);
extern void dwc2_core_host_init(struct dwc2_hsotg *hsotg);
extern int dwc2_enter_hibernation(struct dwc2_hsotg *hsotg);
--
2.6.3
--
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 06/18] usb: dwc2: Avoid more calls to dwc2_core_reset()
From: Douglas Anderson
Calls to dwc2_core_reset() are currently very slow, taking at least
150ms (possibly more). It behooves us to take as many of these calls
out as possible.
It turns out that the calls in dwc2_fs_phy_init() and dwc2_hs_phy_init()
should (as documented in the code) only be needed if we need to do a PHY
SELECT. That means that if we see that we can avoid the PHY SELECT then
we can avoid the reset.
This patch appears to successfully bypass two resets (one per USB
device) on rk3288-based ARM Chromebooks.
Signed-off-by: Douglas Anderson
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 40 +++-
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 9bf354d..c4af353 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -553,16 +553,20 @@ static int dwc2_fs_phy_init(struct dwc2_hsotg *hsotg,
bool select_phy)
*/
if (select_phy) {
dev_dbg(hsotg->dev, "FS PHY selected\n");
+
usbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
- usbcfg |= GUSBCFG_PHYSEL;
- dwc2_writel(usbcfg, hsotg->regs + GUSBCFG);
+ if (!(usbcfg & GUSBCFG_PHYSEL)) {
+ usbcfg |= GUSBCFG_PHYSEL;
+ dwc2_writel(usbcfg, hsotg->regs + GUSBCFG);
- /* Reset after a PHY select */
- retval = dwc2_core_reset(hsotg);
- if (retval) {
- dev_err(hsotg->dev, "%s() Reset failed, aborting",
- __func__);
- return retval;
+ /* Reset after a PHY select */
+ retval = dwc2_core_reset(hsotg);
+
+ if (retval) {
+ dev_err(hsotg->dev,
+ "%s: Reset failed, aborting", __func__);
+ return retval;
+ }
}
}
@@ -597,13 +601,13 @@ static int dwc2_fs_phy_init(struct dwc2_hsotg *hsotg,
bool select_phy)
static int dwc2_hs_phy_init(struct dwc2_hsotg *hsotg, bool select_phy)
{
- u32 usbcfg;
+ u32 usbcfg, usbcfg_old;
int retval = 0;
if (!select_phy)
return 0;
- usbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
+ usbcfg = usbcfg_old = dwc2_readl(hsotg->regs + GUSBCFG);
/*
* HS PHY parameters. These parameters are preserved during soft reset
@@ -631,14 +635,16 @@ static int dwc2_hs_phy_init(struct dwc2_hsotg *hsotg,
bool select_phy)
break;
}
- dwc2_writel(usbcfg, hsotg->regs + GUSBCFG);
+ if (usbcfg != usbcfg_old) {
+ dwc2_writel(usbcfg, hsotg->regs + GUSBCFG);
- /* Reset after setting the PHY parameters */
- retval = dwc2_core_reset(hsotg);
- if (retval) {
- dev_err(hsotg->dev, "%s() Reset failed, aborting",
- __func__);
- return retval;
+ /* Reset after setting the PHY parameters */
+ retval = dwc2_core_reset(hsotg);
+ if (retval) {
+ dev_err(hsotg->dev,
+ "%s: Reset failed, aborting", __func__);
+ return retval;
+ }
}
return retval;
--
2.6.3
--
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 02/18] usb: dwc2: reset dwc2 core before dwc2_get_hwparams()
From: Yunzhi Li
We initiate dwc2 usb controller in BIOS, dwc2_core_reset() should
be called before dwc2_get_hwparams() to reset core registers to
default value. Without this the FIFO setting might be incorrect
because calculating FIFO size need power-on value of
GRXFSIZ/GNPTXFSIZ/HPTXFSIZ registers.
This patch could avoid warnning massage like in rk3288 platform:
[2.074764] dwc2 ff58.usb: 256 invalid for
host_perio_tx_fifo_size. Check HW configuration.
Signed-off-by: Yunzhi Li
Signed-off-by: Douglas Anderson
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 2 +-
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/platform.c | 6 ++
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 7198f4e..8f112ce 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -481,7 +481,7 @@ static void dwc2_init_fs_ls_pclk_sel(struct dwc2_hsotg
*hsotg)
* Do core a soft reset of the core. Be careful with this because it
* resets all the internal state machines of the core.
*/
-static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
+int dwc2_core_reset(struct dwc2_hsotg *hsotg)
{
u32 greset;
int count = 0;
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index de3da75..e54c480 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -889,6 +889,7 @@ enum dwc2_halt_status {
* The following functions support initialization of the core driver component
* and the DWC_otg controller
*/
+extern int dwc2_core_reset(struct dwc2_hsotg *hsotg);
extern void dwc2_core_host_init(struct dwc2_hsotg *hsotg);
extern int dwc2_enter_hibernation(struct dwc2_hsotg *hsotg);
extern int dwc2_exit_hibernation(struct dwc2_hsotg *hsotg, bool restore);
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 7e7dfa2..442cd0d 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -455,6 +455,12 @@ static int dwc2_driver_probe(struct platform_device *dev)
if (retval)
return retval;
+ /*
+* Reset before dwc2_get_hwparams() then it could get power-on real
+* reset value form registers.
+*/
+ dwc2_core_reset(hsotg);
+
/* Detect config values from hardware */
retval = dwc2_get_hwparams(hsotg);
if (retval)
--
2.6.3
--
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 05/18] usb: dwc2: reduce dwc2 driver probe time
From: Yunzhi Li
I found that the probe function of dwc2 driver takes much time
when kernel boot up. There are many long delays in the probe
function these take almost 1 second.
This patch trying to reduce unnecessary delay time.
In dwc2_core_reset() I see it use two at least 20ms delays to
wait AHB idle and core soft reset, but dwc2 data book said that
dwc2 core soft reset and AHB idle just need a few clocks (I think
it refers to AHB clock, and AHB clock run at 150MHz in my RK3288
board), so 20ms is too long, delay 1us for wait AHB idle and soft
reset is enough.
And in dwc2_get_hwparams() it takes 150ms to wait ForceHostMode
and ForceDeviceMode valid but in data book it said software must
wait at least 25ms before the change to take effect, so I reduce
this time to 25ms~50ms. By the way, is there any state bit show
that the force mode take effect ? Could we poll curmod bit for
figuring out if the change take effect ?
It seems that usleep_range() at boot time will pick the longest
value in the range. In dwc2_core_reset() there is a very long
delay takes 200ms, and this function run twice when probe, could
any one tell me is this delay time resonable ?
I have tried this patch in my RK3288-evb board. It works well.
Signed-off-by: Yunzhi Li
Signed-off-by: Douglas Anderson
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 78b00c8..9bf354d 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -491,7 +491,7 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
/* Wait for AHB master IDLE state */
do {
- usleep_range(2, 4);
+ udelay(1);
greset = dwc2_readl(hsotg->regs + GRSTCTL);
if (++count > 50) {
dev_warn(hsotg->dev,
@@ -506,7 +506,7 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
greset |= GRSTCTL_CSFTRST;
dwc2_writel(greset, hsotg->regs + GRSTCTL);
do {
- usleep_range(2, 4);
+ udelay(1);
greset = dwc2_readl(hsotg->regs + GRSTCTL);
if (++count > 50) {
dev_warn(hsotg->dev,
@@ -537,7 +537,7 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
* NOTE: This long sleep is _very_ important, otherwise the core will
* not stay in host mode after a connector ID change!
*/
- usleep_range(15, 20);
+ usleep_range(15, 16);
return 0;
}
@@ -3131,7 +3131,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
dwc2_writel(gusbcfg | GUSBCFG_FORCEHOSTMODE,
hsotg->regs + GUSBCFG);
- usleep_range(10, 15);
+ usleep_range(25000, 5);
}
gnptxfsiz = dwc2_readl(hsotg->regs + GNPTXFSIZ);
@@ -3140,7 +3140,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
dev_dbg(hsotg->dev, "hptxfsiz=%08x\n", hptxfsiz);
if (hsotg->dr_mode != USB_DR_MODE_HOST) {
dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
- usleep_range(10, 15);
+ usleep_range(25000, 5);
}
/* hwcfg2 */
--
2.6.3
--
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 11/18] usb: dwc2: Fix dr_mode validation
The dr_mode parameter was being checked against how the dwc2 module
was being configured at compile time. But it wasn't checked against
the hardware capabilities, nor were the hardware capabilities checked
against the compilation parameters.
This commit adds those checks and adjusts dr_mode to an appropriate
value, if needed. If the hardware capabilities and module compilation
do not match then we fail as it wouldn't be possible to run properly.
The hardware, module, and dr_mode, can each be set to host, device,
or otg. Check that all these values are compatible and adjust the
value of dr_mode if possible.
The following table summarizes the behavior:
actual
HW MOD dr_mode dr_mode
--
HST HST any: HST
HST DEV any: ---
HST OTG any: HST
DEV HST any: ---
DEV DEV any: DEV
DEV OTG any: DEV
OTG HST any: HST
OTG DEV any: DEV
OTG OTG any: dr_mode
Signed-off-by: John Youn
---
drivers/usb/dwc2/platform.c | 79 ++---
1 file changed, 67 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 1c2f5f6..f18d50f 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -148,6 +148,70 @@ static const struct dwc2_core_params params_rk3066 = {
.hibernation= -1,
};
+/*
+ * Check the dr_mode against the module configuration and hardware
+ * capabilities.
+ *
+ * The hardware, module, and dr_mode, can each be set to host, device,
+ * or otg. Check that all these values are compatible and adjust the
+ * value of dr_mode if possible.
+ *
+ * actual
+ *HW MOD dr_mode dr_mode
+ * --
+ * HST HST any: HST
+ * HST DEV any: ---
+ * HST OTG any: HST
+ *
+ * DEV HST any: ---
+ * DEV DEV any: DEV
+ * DEV OTG any: DEV
+ *
+ * OTG HST any: HST
+ * OTG DEV any: DEV
+ * OTG OTG any: dr_mode
+ */
+static int dwc2_check_dr_mode(struct dwc2_hsotg *hsotg)
+{
+ enum usb_dr_mode old_mode, mode;
+
+ mode = usb_get_dr_mode(hsotg->dev);
+ if (mode == USB_DR_MODE_UNKNOWN)
+ mode = USB_DR_MODE_OTG;
+
+ old_mode = mode;
+
+ if (dwc2_hw_is_device(hsotg)) {
+ if (IS_ENABLED(CONFIG_USB_DWC2_HOST)) {
+ dev_err(hsotg->dev,
+ "Controller does not support host mode.\n");
+ return -EINVAL;
+ }
+ mode = USB_DR_MODE_PERIPHERAL;
+ } else if (dwc2_hw_is_host(hsotg)) {
+ if (IS_ENABLED(CONFIG_USB_DWC2_PERIPHERAL)) {
+ dev_err(hsotg->dev,
+ "Controller does not support device mode.\n");
+ return -EINVAL;
+ }
+ mode = USB_DR_MODE_HOST;
+ } else {
+ if (IS_ENABLED(CONFIG_USB_DWC2_HOST))
+ mode = USB_DR_MODE_HOST;
+ else if (IS_ENABLED(CONFIG_USB_DWC2_PERIPHERAL))
+ mode = USB_DR_MODE_PERIPHERAL;
+ }
+
+ if (mode != old_mode) {
+ dev_warn(hsotg->dev,
+ "Configuration mismatch. dr_mode forced to %s\n",
+ mode == USB_DR_MODE_HOST ? "host" : "device");
+ }
+
+ hsotg->dr_mode = mode;
+ return 0;
+}
+
static int __dwc2_lowlevel_hw_enable(struct dwc2_hsotg *hsotg)
{
struct platform_device *pdev = to_platform_device(hsotg->dev);
@@ -425,18 +489,9 @@ static int dwc2_driver_probe(struct platform_device *dev)
dev_dbg(&dev->dev, "mapped PA %08lx to VA %p\n",
(unsigned long)res->start, hsotg->regs);
- hsotg->dr_mode = usb_get_dr_mode(&dev->dev);
- if (IS_ENABLED(CONFIG_USB_DWC2_HOST) &&
- hsotg->dr_mode != USB_DR_MODE_HOST) {
- hsotg->dr_mode = USB_DR_MODE_HOST;
- dev_warn(hsotg->dev,
- "Configuration mismatch. Forcing host mode\n");
- } else if (IS_ENABLED(CONFIG_USB_DWC2_PERIPHERAL) &&
- hsotg->dr_mode != USB_DR_MODE_PERIPHERAL) {
- hsotg->dr_mode = USB_DR_MODE_PERIPHERAL;
- dev_warn(hsotg->dev,
- "Configuration mismatch. Forcing peripheral mode\n");
- }
+ retval = dwc2_check_dr_mode(hsotg);
+ if (retval)
+ return retval;
retval = dwc2_lowlevel_hw_init(hsotg);
if (retval)
--
2.6.3
--
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 13/18] usb: dwc2: Move reset into dwc2_get_hwparams()
The reset is required to get reset values of the hardware parameters but
the force mode is not. Move the base reset into dwc2_get_hwparams() and
do the reset and force mode afterwards.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 5 +
drivers/usb/dwc2/platform.c | 8 ++--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 382f563..7090050 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -3116,6 +3116,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
u32 hwcfg1, hwcfg2, hwcfg3, hwcfg4;
u32 hptxfsiz, grxfsiz, gnptxfsiz;
u32 gusbcfg = 0;
+ int retval;
/*
* Attempt to ensure this device is really a DWC_otg Controller.
@@ -3135,6 +3136,10 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
hw->snpsid >> 12 & 0xf, hw->snpsid >> 8 & 0xf,
hw->snpsid >> 4 & 0xf, hw->snpsid & 0xf, hw->snpsid);
+ retval = dwc2_core_reset(hsotg);
+ if (retval)
+ return retval;
+
hwcfg1 = dwc2_readl(hsotg->regs + GHWCFG1);
hwcfg2 = dwc2_readl(hsotg->regs + GHWCFG2);
hwcfg3 = dwc2_readl(hsotg->regs + GHWCFG3);
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index f18d50f..12826a1 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -510,12 +510,6 @@ static int dwc2_driver_probe(struct platform_device *dev)
if (retval)
return retval;
- /*
-* Reset before dwc2_get_hwparams() then it could get power-on real
-* reset value form registers.
-*/
- dwc2_core_reset_and_force_mode(hsotg);
-
/* Detect config values from hardware */
retval = dwc2_get_hwparams(hsotg);
if (retval)
@@ -524,6 +518,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
/* Validate parameter values */
dwc2_set_parameters(hsotg, params);
+ dwc2_core_reset_and_force_mode(hsotg);
+
if (hsotg->dr_mode != USB_DR_MODE_HOST) {
retval = dwc2_gadget_init(hsotg, irq);
if (retval)
--
2.6.3
--
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 10/18] usb: dwc2: Add functions to check the HW OTG config
Added functions to query the GHWCFG2.OTG_MODE. This tells us whether the
controller hardware is configured for OTG, device-only, or host-only.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 37 +
drivers/usb/dwc2/core.h | 13 +
2 files changed, 50 insertions(+)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index b7a733a..382f563 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -3323,6 +3323,43 @@ void dwc2_disable_global_interrupts(struct dwc2_hsotg
*hsotg)
dwc2_writel(ahbcfg, hsotg->regs + GAHBCFG);
}
+/* Returns the controller's GHWCFG2.OTG_MODE. */
+unsigned dwc2_op_mode(struct dwc2_hsotg *hsotg)
+{
+ u32 ghwcfg2 = dwc2_readl(hsotg->regs + GHWCFG2);
+
+ return (ghwcfg2 & GHWCFG2_OP_MODE_MASK) >>
+ GHWCFG2_OP_MODE_SHIFT;
+}
+
+/* Returns true if the controller is capable of DRD. */
+bool dwc2_hw_is_otg(struct dwc2_hsotg *hsotg)
+{
+ unsigned op_mode = dwc2_op_mode(hsotg);
+
+ return (op_mode == GHWCFG2_OP_MODE_HNP_SRP_CAPABLE) ||
+ (op_mode == GHWCFG2_OP_MODE_SRP_ONLY_CAPABLE) ||
+ (op_mode == GHWCFG2_OP_MODE_NO_HNP_SRP_CAPABLE);
+}
+
+/* Returns true if the controller is host-only. */
+bool dwc2_hw_is_host(struct dwc2_hsotg *hsotg)
+{
+ unsigned op_mode = dwc2_op_mode(hsotg);
+
+ return (op_mode == GHWCFG2_OP_MODE_SRP_CAPABLE_HOST) ||
+ (op_mode == GHWCFG2_OP_MODE_NO_SRP_CAPABLE_HOST);
+}
+
+/* Returns true if the controller is device-only. */
+bool dwc2_hw_is_device(struct dwc2_hsotg *hsotg)
+{
+ unsigned op_mode = dwc2_op_mode(hsotg);
+
+ return (op_mode == GHWCFG2_OP_MODE_SRP_CAPABLE_DEVICE) ||
+ (op_mode == GHWCFG2_OP_MODE_NO_SRP_CAPABLE_DEVICE);
+}
+
MODULE_DESCRIPTION("DESIGNWARE HS OTG Core");
MODULE_AUTHOR("Synopsys, Inc.");
MODULE_LICENSE("Dual BSD/GPL");
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 53c992a..2768f0c 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -1147,6 +1147,19 @@ extern int dwc2_lowlevel_hw_enable(struct dwc2_hsotg
*hsotg);
extern int dwc2_lowlevel_hw_disable(struct dwc2_hsotg *hsotg);
/*
+ * The following functions check the controller's OTG operation mode
+ * capability (GHWCFG2.OTG_MODE).
+ *
+ * These functions can be used before the internal hsotg->hw_params
+ * are read in and cached so they always read directly from the
+ * GHWCFG2 register.
+ */
+unsigned dwc2_op_mode(struct dwc2_hsotg *hsotg);
+bool dwc2_hw_is_otg(struct dwc2_hsotg *hsotg);
+bool dwc2_hw_is_host(struct dwc2_hsotg *hsotg);
+bool dwc2_hw_is_device(struct dwc2_hsotg *hsotg);
+
+/*
* Dump core registers and SPRAM
*/
extern void dwc2_dump_dev_registers(struct dwc2_hsotg *hsotg);
--
2.6.3
--
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 12/18] usb: dwc2: Move mode querying functions into core.h
These functions should go in core.h where they can be called from core,
device, or host.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.h | 12
drivers/usb/dwc2/hcd.h | 12
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 2768f0c..8f2a9ff 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -1160,6 +1160,18 @@ bool dwc2_hw_is_host(struct dwc2_hsotg *hsotg);
bool dwc2_hw_is_device(struct dwc2_hsotg *hsotg);
/*
+ * Returns the mode of operation, host or device
+ */
+static inline int dwc2_is_host_mode(struct dwc2_hsotg *hsotg)
+{
+ return (dwc2_readl(hsotg->regs + GINTSTS) & GINTSTS_CURMODE_HOST) != 0;
+}
+static inline int dwc2_is_device_mode(struct dwc2_hsotg *hsotg)
+{
+ return (dwc2_readl(hsotg->regs + GINTSTS) & GINTSTS_CURMODE_HOST) == 0;
+}
+
+/*
* Dump core registers and SPRAM
*/
extern void dwc2_dump_dev_registers(struct dwc2_hsotg *hsotg);
diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
index d893442..344b6f0 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -374,18 +374,6 @@ static inline void disable_hc_int(struct dwc2_hsotg
*hsotg, int chnum, u32 intr)
}
/*
- * Returns the mode of operation, host or device
- */
-static inline int dwc2_is_host_mode(struct dwc2_hsotg *hsotg)
-{
- return (dwc2_readl(hsotg->regs + GINTSTS) & GINTSTS_CURMODE_HOST) != 0;
-}
-static inline int dwc2_is_device_mode(struct dwc2_hsotg *hsotg)
-{
- return (dwc2_readl(hsotg->regs + GINTSTS) & GINTSTS_CURMODE_HOST) == 0;
-}
-
-/*
* Reads HPRT0 in preparation to modify. It keeps the WC bits 0 so that if they
* are read as 1, they won't clear when written back.
*/
--
2.6.3
--
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 03/18] usb: dwc2: Avoid double-reset at boot time
From: Douglas Anderson
In (usb: dwc2: reset dwc2 core before dwc2_get_hwparams()) we added an
extra reset to the probe path for the dwc2 USB controllers. This
allowed proper detection of parameters even if the firmware had already
used the USB part.
Unfortunately, this extra reset is quite slow and is affecting boot
speed. We can avoid the double-reset by skipping the extra reset that
would happen just after the one we added. Logic that explains why this
is safe:
* As of the CL mentioned above, we now always call dwc2_core_reset() in
dwc2_driver_probe() before dwc2_hcd_init().
* The only caller of dwc2_hcd_init() is dwc2_driver_probe(), so we're
guaranteed that dwc2_core_reset() was called before dwc2_hdc_init().
* dwc2_hdc_init() is the only caller that passes an irq other than -1 to
dwc2_core_init(). Thus if dwc2_core_init() is called with an irq
other than -1 we're guaranteed that dwc2_core_reset was called before
dwc2_core_init().
...this allows us to remove the dwc2_core_reset() in dwc2_core_init() if
irq is not < 0.
Note that since "irq" wasn't used in the function dwc2_core_init()
anyway and since select_phy was always set at exactly the same times we
could avoid the reset, we remove "irq" and rename "select_phy" to
"initial_setup" and adjust the callers accordingly.
Signed-off-by: Douglas Anderson
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 29 ++---
drivers/usb/dwc2/core.h | 2 +-
drivers/usb/dwc2/hcd.c | 6 +++---
3 files changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 8f112ce..fab8f4c 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -765,11 +765,10 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
* dwc2_core_init() - Initializes the DWC_otg controller registers and
* prepares the core for device mode or host mode operation
*
- * @hsotg: Programming view of the DWC_otg controller
- * @select_phy: If true then also set the Phy type
- * @irq:If >= 0, the irq to register
+ * @hsotg: Programming view of the DWC_otg controller
+ * @initial_setup: If true then this is the first init for this instance.
*/
-int dwc2_core_init(struct dwc2_hsotg *hsotg, bool select_phy, int irq)
+int dwc2_core_init(struct dwc2_hsotg *hsotg, bool initial_setup)
{
u32 usbcfg, otgctl;
int retval;
@@ -791,18 +790,26 @@ int dwc2_core_init(struct dwc2_hsotg *hsotg, bool
select_phy, int irq)
dwc2_writel(usbcfg, hsotg->regs + GUSBCFG);
- /* Reset the Controller */
- retval = dwc2_core_reset(hsotg);
- if (retval) {
- dev_err(hsotg->dev, "%s(): Reset failed, aborting\n",
- __func__);
- return retval;
+ /*
+* Reset the Controller
+*
+* We only need to reset the controller if this is a re-init.
+* For the first init we know for sure that earlier code reset us (it
+* needed to in order to properly detect various parameters).
+*/
+ if (!initial_setup) {
+ retval = dwc2_core_reset(hsotg);
+ if (retval) {
+ dev_err(hsotg->dev, "%s(): Reset failed, aborting\n",
+ __func__);
+ return retval;
+ }
}
/*
* This needs to happen in FS mode before any other programming occurs
*/
- retval = dwc2_phy_init(hsotg, select_phy);
+ retval = dwc2_phy_init(hsotg, initial_setup);
if (retval)
return retval;
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index e54c480..28d0288 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -927,7 +927,7 @@ extern void dwc2_read_packet(struct dwc2_hsotg *hsotg, u8
*dest, u16 bytes);
extern void dwc2_flush_tx_fifo(struct dwc2_hsotg *hsotg, const int num);
extern void dwc2_flush_rx_fifo(struct dwc2_hsotg *hsotg);
-extern int dwc2_core_init(struct dwc2_hsotg *hsotg, bool select_phy, int irq);
+extern int dwc2_core_init(struct dwc2_hsotg *hsotg, bool initial_setup);
extern void dwc2_enable_global_interrupts(struct dwc2_hsotg *hcd);
extern void dwc2_disable_global_interrupts(struct dwc2_hsotg *hcd);
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index ba9d4f0..c07693e4 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1412,7 +1412,7 @@ static void dwc2_conn_id_status_change(struct work_struct
*work)
dev_err(hsotg->dev,
"Connection id status change timed out\n");
hsotg->op_state = OTG_STATE_B_PERIPHERAL;
- dwc2_core_init(hsotg, false, -1);
+ dwc2_core_init(hsotg, false);
dwc2_enable_global_interrupts(hsotg);
spin_lock_irqsave(&hsotg->lock, flags);
dwc2_hsotg_core_i
[PATCH 07/18] usb: dwc2: Reorder AHBIDLE and CSFTRST in dwc2_core_reset()
According to the databook, the core soft reset should be done before
checking for AHBIDLE. The gadget version of core reset had it correct
but the hcd version did not. This fixes the hcd version.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index c4af353..2d2b538 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -489,32 +489,33 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
dev_vdbg(hsotg->dev, "%s()\n", __func__);
- /* Wait for AHB master IDLE state */
+ /* Core Soft Reset */
+ greset = dwc2_readl(hsotg->regs + GRSTCTL);
+ greset |= GRSTCTL_CSFTRST;
+ dwc2_writel(greset, hsotg->regs + GRSTCTL);
do {
udelay(1);
greset = dwc2_readl(hsotg->regs + GRSTCTL);
if (++count > 50) {
dev_warn(hsotg->dev,
-"%s() HANG! AHB Idle GRSTCTL=%0x\n",
+"%s() HANG! Soft Reset GRSTCTL=%0x\n",
__func__, greset);
return -EBUSY;
}
- } while (!(greset & GRSTCTL_AHBIDLE));
+ } while (greset & GRSTCTL_CSFTRST);
- /* Core Soft Reset */
+ /* Wait for AHB master IDLE state */
count = 0;
- greset |= GRSTCTL_CSFTRST;
- dwc2_writel(greset, hsotg->regs + GRSTCTL);
do {
udelay(1);
greset = dwc2_readl(hsotg->regs + GRSTCTL);
if (++count > 50) {
dev_warn(hsotg->dev,
-"%s() HANG! Soft Reset GRSTCTL=%0x\n",
+"%s() HANG! AHB Idle GRSTCTL=%0x\n",
__func__, greset);
return -EBUSY;
}
- } while (greset & GRSTCTL_CSFTRST);
+ } while (!(greset & GRSTCTL_AHBIDLE));
if (hsotg->dr_mode == USB_DR_MODE_HOST) {
gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
--
2.6.3
--
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 01/18] usb: dwc2: Restore GUSBCFG in dwc2_get_hwparams()
From: Douglas Anderson
Previously dwc2_get_hwparams() was changing GUSBCFG and not putting it
back the way it was (specifically it set and cleared FORCEHOSTMODE).
Since we want to move dwc2_core_reset() _before_ dwc2_get_hwparams() we
should make sure dwc2_get_hwparams() isn't messing with things in a
permanent way.
Since we're now looking at GUSBCFG, it's obvious that we shouldn't need
all the extra delays if FORCEHOSTMODE was already set. This will avoid
some delays for any ports that have forced host mode.
Signed-off-by: Douglas Anderson
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 66523fa..7198f4e 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -3121,18 +3121,20 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
/* Force host mode to get HPTXFSIZ / GNPTXFSIZ exact power on value */
gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
- gusbcfg |= GUSBCFG_FORCEHOSTMODE;
- dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
- usleep_range(10, 15);
+ if (!(gusbcfg & GUSBCFG_FORCEHOSTMODE)) {
+ dwc2_writel(gusbcfg | GUSBCFG_FORCEHOSTMODE,
+ hsotg->regs + GUSBCFG);
+ usleep_range(10, 15);
+ }
gnptxfsiz = dwc2_readl(hsotg->regs + GNPTXFSIZ);
hptxfsiz = dwc2_readl(hsotg->regs + HPTXFSIZ);
dev_dbg(hsotg->dev, "gnptxfsiz=%08x\n", gnptxfsiz);
dev_dbg(hsotg->dev, "hptxfsiz=%08x\n", hptxfsiz);
- gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
- gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
- dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
- usleep_range(10, 15);
+ if (!(gusbcfg & GUSBCFG_FORCEHOSTMODE)) {
+ dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
+ usleep_range(10, 15);
+ }
/* hwcfg2 */
hw->op_mode = (hwcfg2 & GHWCFG2_OP_MODE_MASK) >>
--
2.6.3
--
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 04/18] usb: dwc2: Speed dwc2_get_hwparams() on some host-only ports
From: Douglas Anderson
On some host-only DWC2 ports (like the one in rk3288) when we set
GUSBCFG_FORCEHOSTMODE in GUSBCFG and then read back, we don't see the
bit set. Presumably that's because the port is always forced to HOST
mode so there's no reason to implement these status bits.
Since we know dwc2_core_reset() is always called before
dwc2_get_hwparams() and we know dwc2_core_reset() should have set
GUSBCFG_FORCEHOSTMODE whenever hsotg->dr_mode == USB_DR_MODE_HOST, we
can just check hsotg->dr_mode to decide that we can skip the delays in
dwc2_get_hwparams().
Signed-off-by: Douglas Anderson
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index fab8f4c..78b00c8 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -3094,7 +3094,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
unsigned width;
u32 hwcfg1, hwcfg2, hwcfg3, hwcfg4;
u32 hptxfsiz, grxfsiz, gnptxfsiz;
- u32 gusbcfg;
+ u32 gusbcfg = 0;
/*
* Attempt to ensure this device is really a DWC_otg Controller.
@@ -3127,8 +3127,8 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
dev_dbg(hsotg->dev, "grxfsiz=%08x\n", grxfsiz);
/* Force host mode to get HPTXFSIZ / GNPTXFSIZ exact power on value */
- gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
- if (!(gusbcfg & GUSBCFG_FORCEHOSTMODE)) {
+ if (hsotg->dr_mode != USB_DR_MODE_HOST) {
+ gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
dwc2_writel(gusbcfg | GUSBCFG_FORCEHOSTMODE,
hsotg->regs + GUSBCFG);
usleep_range(10, 15);
@@ -3138,7 +3138,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
hptxfsiz = dwc2_readl(hsotg->regs + HPTXFSIZ);
dev_dbg(hsotg->dev, "gnptxfsiz=%08x\n", gnptxfsiz);
dev_dbg(hsotg->dev, "hptxfsiz=%08x\n", hptxfsiz);
- if (!(gusbcfg & GUSBCFG_FORCEHOSTMODE)) {
+ if (hsotg->dr_mode != USB_DR_MODE_HOST) {
dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
usleep_range(10, 15);
}
--
2.6.3
--
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 14/18] usb: dwc2: Add functions to set and clear force mode
Added functions to set force mode for host and device. These functions
will check the current mode and only force if needed.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 54 +
1 file changed, 54 insertions(+)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 7090050..caaff42 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -3105,6 +3105,60 @@ void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
dwc2_set_param_hibernation(hsotg, params->hibernation);
}
+/*
+ * Force host mode if not in host mode. Returns true if the mode was
+ * forced.
+ */
+static bool dwc2_force_host_if_needed(struct dwc2_hsotg *hsotg)
+{
+ u32 gusbcfg;
+
+ if (dwc2_is_host_mode(hsotg))
+ return false;
+
+ gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
+ gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
+ gusbcfg |= GUSBCFG_FORCEHOSTMODE;
+ dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
+ usleep_range(25000, 5);
+
+ return true;
+}
+
+/*
+ * Force device mode if not in device mode. Returns true if the mode
+ * was forced.
+ */
+static bool dwc2_force_device_if_needed(struct dwc2_hsotg *hsotg)
+{
+ u32 gusbcfg;
+
+ if (dwc2_is_device_mode(hsotg))
+ return false;
+
+ gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
+ gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
+ gusbcfg |= GUSBCFG_FORCEDEVMODE;
+ dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
+ usleep_range(25000, 5);
+
+ return true;
+}
+
+/*
+ * Clears the force mode bits.
+ */
+static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
+{
+ u32 gusbcfg;
+
+ gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
+ gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
+ gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
+ dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
+ usleep_range(25000, 5);
+}
+
/**
* During device initialization, read various hardware configuration
* registers and interpret the contents.
--
2.6.3
--
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 16/18] usb: dwc2: gadget: Use the common dwc2_core_reset()
The gadget was using its own version of core reset. Use the common one
in core.c.
Signed-off-by: John Youn
---
drivers/usb/dwc2/gadget.c | 52 ++-
1 file changed, 2 insertions(+), 50 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 0abf73c..ba56c2d 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2244,54 +2244,6 @@ static void dwc2_hsotg_irq_fifoempty(struct dwc2_hsotg
*hsotg, bool periodic)
GINTSTS_RXFLVL)
/**
- * dwc2_hsotg_corereset - issue softreset to the core
- * @hsotg: The device state
- *
- * Issue a soft reset to the core, and await the core finishing it.
- */
-static int dwc2_hsotg_corereset(struct dwc2_hsotg *hsotg)
-{
- int timeout;
- u32 grstctl;
-
- dev_dbg(hsotg->dev, "resetting core\n");
-
- /* issue soft reset */
- dwc2_writel(GRSTCTL_CSFTRST, hsotg->regs + GRSTCTL);
-
- timeout = 1;
- do {
- grstctl = dwc2_readl(hsotg->regs + GRSTCTL);
- } while ((grstctl & GRSTCTL_CSFTRST) && timeout-- > 0);
-
- if (grstctl & GRSTCTL_CSFTRST) {
- dev_err(hsotg->dev, "Failed to get CSftRst asserted\n");
- return -EINVAL;
- }
-
- timeout = 1;
-
- while (1) {
- u32 grstctl = dwc2_readl(hsotg->regs + GRSTCTL);
-
- if (timeout-- < 0) {
- dev_info(hsotg->dev,
-"%s: reset failed, GRSTCTL=%08x\n",
-__func__, grstctl);
- return -ETIMEDOUT;
- }
-
- if (!(grstctl & GRSTCTL_AHBIDLE))
- continue;
-
- break; /* reset done */
- }
-
- dev_dbg(hsotg->dev, "reset successful\n");
- return 0;
-}
-
-/**
* dwc2_hsotg_core_init - issue softreset to the core
* @hsotg: The device state
*
@@ -2307,7 +2259,7 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg
*hsotg,
kill_all_requests(hsotg, hsotg->eps_out[0], -ECONNRESET);
if (!is_usb_reset)
- if (dwc2_hsotg_corereset(hsotg))
+ if (dwc2_core_reset(hsotg))
return;
/*
@@ -3592,7 +3544,7 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
*/
msleep(25);
- dwc2_hsotg_corereset(hsotg);
+ dwc2_core_reset(hsotg);
ret = dwc2_hsotg_hw_cfg(hsotg);
if (ret) {
dev_err(hsotg->dev, "Hardware configuration failed: %d\n", ret);
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/18] usb: dwc2: Improve handling of host and device hwparams
This commit adds separate functions for getting the host and device
specific hardware params. These functions check whether the parameters
need to be read at all, depending on dr_mode, and they force the mode
only if necessary. This saves some delays during probe.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 93 +
drivers/usb/dwc2/core.h | 1 +
2 files changed, 71 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index caaff42..91d63a8 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -3159,17 +3159,76 @@ static void dwc2_clear_force_mode(struct dwc2_hsotg
*hsotg)
usleep_range(25000, 5);
}
+/*
+ * Gets host hardware parameters. Forces host mode if not currently in
+ * host mode. Should be called immediately after a core soft reset in
+ * order to get the reset values.
+ */
+static void dwc2_get_host_hwparams(struct dwc2_hsotg *hsotg)
+{
+ struct dwc2_hw_params *hw = &hsotg->hw_params;
+ u32 gnptxfsiz;
+ u32 hptxfsiz;
+ bool forced;
+
+ if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL)
+ return;
+
+ forced = dwc2_force_host_if_needed(hsotg);
+
+ gnptxfsiz = dwc2_readl(hsotg->regs + GNPTXFSIZ);
+ hptxfsiz = dwc2_readl(hsotg->regs + HPTXFSIZ);
+ dev_dbg(hsotg->dev, "gnptxfsiz=%08x\n", gnptxfsiz);
+ dev_dbg(hsotg->dev, "hptxfsiz=%08x\n", hptxfsiz);
+
+ if (forced)
+ dwc2_clear_force_mode(hsotg);
+
+ hw->host_nperio_tx_fifo_size = (gnptxfsiz & FIFOSIZE_DEPTH_MASK) >>
+ FIFOSIZE_DEPTH_SHIFT;
+ hw->host_perio_tx_fifo_size = (hptxfsiz & FIFOSIZE_DEPTH_MASK) >>
+ FIFOSIZE_DEPTH_SHIFT;
+}
+
+/*
+ * Gets device hardware parameters. Forces device mode if not
+ * currently in device mode. Should be called immediately after a core
+ * soft reset in order to get the reset values.
+ */
+static void dwc2_get_dev_hwparams(struct dwc2_hsotg *hsotg)
+{
+ struct dwc2_hw_params *hw = &hsotg->hw_params;
+ bool forced;
+ u32 gnptxfsiz;
+
+ if (hsotg->dr_mode == USB_DR_MODE_HOST)
+ return;
+
+ forced = dwc2_force_device_if_needed(hsotg);
+
+ gnptxfsiz = dwc2_readl(hsotg->regs + GNPTXFSIZ);
+ dev_dbg(hsotg->dev, "gnptxfsiz=%08x\n", gnptxfsiz);
+
+ if (forced)
+ dwc2_clear_force_mode(hsotg);
+
+ hw->dev_nperio_tx_fifo_size = (gnptxfsiz & FIFOSIZE_DEPTH_MASK) >>
+ FIFOSIZE_DEPTH_SHIFT;
+}
+
/**
* During device initialization, read various hardware configuration
* registers and interpret the contents.
+ *
+ * This should be called during driver probe. It will perform a core
+ * soft reset in order to get the reset values of the parameters.
*/
int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
{
struct dwc2_hw_params *hw = &hsotg->hw_params;
unsigned width;
u32 hwcfg1, hwcfg2, hwcfg3, hwcfg4;
- u32 hptxfsiz, grxfsiz, gnptxfsiz;
- u32 gusbcfg = 0;
+ u32 grxfsiz;
int retval;
/*
@@ -3206,23 +3265,6 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
dev_dbg(hsotg->dev, "hwcfg4=%08x\n", hwcfg4);
dev_dbg(hsotg->dev, "grxfsiz=%08x\n", grxfsiz);
- /* Force host mode to get HPTXFSIZ / GNPTXFSIZ exact power on value */
- if (hsotg->dr_mode != USB_DR_MODE_HOST) {
- gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
- dwc2_writel(gusbcfg | GUSBCFG_FORCEHOSTMODE,
- hsotg->regs + GUSBCFG);
- usleep_range(25000, 5);
- }
-
- gnptxfsiz = dwc2_readl(hsotg->regs + GNPTXFSIZ);
- hptxfsiz = dwc2_readl(hsotg->regs + HPTXFSIZ);
- dev_dbg(hsotg->dev, "gnptxfsiz=%08x\n", gnptxfsiz);
- dev_dbg(hsotg->dev, "hptxfsiz=%08x\n", hptxfsiz);
- if (hsotg->dr_mode != USB_DR_MODE_HOST) {
- dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
- usleep_range(25000, 5);
- }
-
/* hwcfg2 */
hw->op_mode = (hwcfg2 & GHWCFG2_OP_MODE_MASK) >>
GHWCFG2_OP_MODE_SHIFT;
@@ -3270,10 +3312,15 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
/* fifo sizes */
hw->host_rx_fifo_size = (grxfsiz & GRXFSIZ_DEPTH_MASK) >>
GRXFSIZ_DEPTH_SHIFT;
- hw->host_nperio_tx_fifo_size = (gnptxfsiz & FIFOSIZE_DEPTH_MASK) >>
- FIFOSIZE_DEPTH_SHIFT;
- hw->host_perio_tx_fifo_size = (hptxfsiz & FIFOSIZE_DEPTH_MASK) >>
- FIFOSIZE_DEPTH_SHIFT;
+
+ /*
+* Host/device specific hardware parameters. Reading these
+* parameters requires the controller to be in either host or
+* device mode. The mode will be forced, if necessary, to read
+* these values.
+
[PATCH 17/18] usb: dwc2: gadget: Remove force device mode
The forcing of device mode is not needed in the gadget init. This is
already taken care of in the probe just before this is called.
Signed-off-by: John Youn
---
drivers/usb/dwc2/gadget.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index ba56c2d..4e9fc92 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3531,19 +3531,6 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
else if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL)
hsotg->op_state = OTG_STATE_B_PERIPHERAL;
- /*
-* Force Device mode before initialization.
-* This allows correctly configuring fifo for device mode.
-*/
- __bic32(hsotg->regs + GUSBCFG, GUSBCFG_FORCEHOSTMODE);
- __orr32(hsotg->regs + GUSBCFG, GUSBCFG_FORCEDEVMODE);
-
- /*
-* According to Synopsys databook, this sleep is needed for the force
-* device mode to take effect.
-*/
- msleep(25);
-
dwc2_core_reset(hsotg);
ret = dwc2_hsotg_hw_cfg(hsotg);
if (ret) {
@@ -3553,9 +3540,6 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
dwc2_hsotg_init(hsotg);
- /* Switch back to default configuration */
- __bic32(hsotg->regs + GUSBCFG, GUSBCFG_FORCEDEVMODE);
-
hsotg->ctrl_buff = devm_kzalloc(hsotg->dev,
DWC2_CTRL_BUFF_SIZE, GFP_KERNEL);
if (!hsotg->ctrl_buff) {
--
2.6.3
--
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 18/18] usb: dwc2: Reduce delay when forcing mode in reset
The delay for force mode is only 25ms according to the databook. Signed-off-by: John Youn --- drivers/usb/dwc2/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c index 91d63a8..a6fddbf 100644 --- a/drivers/usb/dwc2/core.c +++ b/drivers/usb/dwc2/core.c @@ -552,7 +552,7 @@ int dwc2_core_reset_and_force_mode(struct dwc2_hsotg *hsotg) * NOTE: This long sleep is _very_ important, otherwise the core will * not stay in host mode after a connector ID change! */ - usleep_range(15, 16); + usleep_range(25000, 5); return 0; } -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux as a USB hub?
On Wed, Dec 02, 2015 at 06:47:43PM +0100, Krzysztof Opasiak wrote: > > > On 12/02/2015 06:34 PM, Bjørn Mork wrote: > >Krzysztof Opasiak writes: > > > >>That's why we will try to improve udl driver. Currently we try to > >>setup machine at university which will run linux and then windows in > >>virtual machine. We would like to connect dl to this computer, pass it > >>to virtual machine and then use usbmon + wireshark and try to figure > >>out new encodings used by windows driver and add them to udl driver > >>but probably it will take a lot of time... > > > >This might be old news to you, but there are actually very good open > >source(!) tools for USB sniffing in Windows: http://desowin.org/usbpcap/ > >So you don't need the additional complexity of a virtual machine. > > > >You can of course still analyze the dumps on Linux. Just feed them to > >Wireshark. > > > > First of all thank you very much for reminding about that tool. I > heard about it but never used it. > > Unfortunately I'm a little bit afraid that it may generate some > problems. We need to interact with windows graphics to generate some > well-defined payload to device and try to analyse it. So I'm simply > afraid that launching and manipulating some additional tools on the > same system may generate some unwanted traffic:( Yes, I was contemplating a script that would do something like set the screen resolution (if necessary), set the screen to Green, then Red, then blue for a defined period, then shut down the VM, in order to generate repeatable traffic to the displaylink device. Then, depending on how the fake implementation progresses, one could compare the traffic sent to the real device vs that sent to the fake. Rogan -- 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: Regression, was [PATCH 4/4] USB: host: ohci-at91: merge loops in ohci_hcd_at91_drv_probe
Hi Alexandre, On 2015-12-02 19:20, Alexandre Belloni wrote: > Hi Peter, > > On 01/12/2015 at 18:17:16 +0100, Peter Rosin wrote : >> [] (ohci_hcd_at91_overcurrent_irq) from [] >> (handle_irq_event_percpu+0x78/0x140) >> [] (handle_irq_event_percpu) from [] >> (handle_irq_event+0x2c/0x40) >> [] (handle_irq_event) from [] >> (handle_simple_irq+0x6c/0x80) >> [] (handle_simple_irq) from [] >> (generic_handle_irq+0x2c/0x3c) >> [] (generic_handle_irq) from [] >> (gpio_irq_handler+0xa4/0x12c) >> [] (gpio_irq_handler) from [] >> (generic_handle_irq+0x2c/0x3c) >> [] (generic_handle_irq) from [] >> (__handle_domain_irq+0x54/0xa8) >> [] (__handle_domain_irq) from [] (__irq_svc+0x40/0x54) >> [] (__irq_svc) from [] (__setup_irq+0x248/0x530) >> [] (__setup_irq) from [] >> (request_threaded_irq+0xc4/0x144) >> [] (request_threaded_irq) from [] >> (ohci_hcd_at91_drv_probe+0x460/0x518) >> [] (ohci_hcd_at91_drv_probe) from [] >> (platform_drv_probe+0x44/0xa4) >> [] (platform_drv_probe) from [] >> (driver_probe_device+0x1fc/0x43c) >> [] (driver_probe_device) from [] >> (__driver_attach+0x8c/0x90) >> [] (__driver_attach) from [] (bus_for_each_dev+0x6c/0xa0) >> [] (bus_for_each_dev) from [] >> (bus_add_driver+0x1d0/0x268) >> [] (bus_add_driver) from [] (driver_register+0x78/0xf8) >> [] (driver_register) from [] (do_one_initcall+0xb8/0x1f0) >> [] (do_one_initcall) from [] >> (kernel_init_freeable+0x138/0x1d8) >> [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe8) >> [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) >> Code: e5916058 e1a08000 e3a04000 e2865008 (e5b50004) >> ---[ end trace e66fbc480972ac43 ]--- >> Kernel panic - not syncing: Fatal exception in interrupt >> ---[ end Kernel panic - not syncing: Fatal exception in interrupt > > I think I understood what happens. Can you try the following patch? Seems to work here. Excellent! > 8<-- > From 402f8444bc92d218edc63dcc3c87459981a56c31 Mon Sep 17 00:00:00 2001 > From: Alexandre Belloni > Date: Wed, 2 Dec 2015 18:49:34 +0100 > Subject: [PATCH] USB: host: ohci-at91: fix a crash in > ohci_hcd_at91_overcurrent_irq > > Signed-off-by: Alexandre Belloni Reported-by: Peter Rosin Tested-by: Peter Rosin (and bisected-by if anyone cares...) Cheers, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: host: ohci-at91: fix a crash in ohci_hcd_at91_overcurrent_irq
The interrupt handler, ohci_hcd_at91_overcurrent_irq may be called right
after registration. At that time, pdev->dev.platform_data is not yet set,
leading to a NULL pointer dereference.
Fixes: e4df92279fd9 (USB: host: ohci-at91: merge loops in
ohci_hcd_at91_drv_probe)
Reported-by: Peter Rosin
Tested-by: Peter Rosin
Signed-off-by: Alexandre Belloni
---
drivers/usb/host/ohci-at91.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 342ffd140122..8c6e15bd6ff0 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -473,6 +473,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
if (!pdata)
return -ENOMEM;
+ pdev->dev.platform_data = pdata;
+
if (!of_property_read_u32(np, "num-ports", &ports))
pdata->ports = ports;
@@ -483,6 +485,7 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
*/
if (i >= pdata->ports) {
pdata->vbus_pin[i] = -EINVAL;
+ pdata->overcurrent_pin[i] = -EINVAL;
continue;
}
@@ -513,10 +516,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
}
at91_for_each_port(i) {
- if (i >= pdata->ports) {
- pdata->overcurrent_pin[i] = -EINVAL;
- continue;
- }
+ if (i >= pdata->ports)
+ break;
pdata->overcurrent_pin[i] =
of_get_named_gpio_flags(np, "atmel,oc-gpio", i, &flags);
@@ -552,8 +553,6 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
}
}
- pdev->dev.platform_data = pdata;
-
device_init_wakeup(&pdev->dev, 1);
return usb_hcd_at91_probe(&ohci_at91_hc_driver, pdev);
}
--
2.5.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: Linux as a USB hub?
On Wed, 2 Dec 2015, Rogan Dawes wrote: > I have read the documentation for the USB gadgets (multi, hid, > printer, serial), but noted that there seem to be quite a few more > gadgets available in the source nowadays. e.g. audio, webcam . Are > there any plans to document these at some stage? You'll have to ask the people who wrote those gadget drivers. > Also, I saw "dummy_hcd.c", which sounds interesting. It is. It's meant for testing more than anything else; it provides an emulated host and device controller pair, so you can test a gadget driver even on a computer that doesn't have any USB device hardware. 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 V2] usb: Add connected retry on resume for non SS devices
Currently usb_port_resume waits for up to 2 seconds for CONNECT
status for SS devices only. This change will do the same thing for
non-SS devices even though the reason is a little different. This
will fix an issue where VBUS is turned off during system wide
"suspend to ram" and some 2.0 devices take greater than the current
max of 100ms to show connected after VBUS is enabled. This is most
commonly seen on hard drive based devices and USB3.0 devices plugged
into a 2.0 only port.
Signed-off-by: Al Cooper
---
V2 - Change comment to reflect change to wait_for_connect()
- Add dev_dbg message that shows the actual wait time
drivers/usb/core/hub.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bdeadc1..00a0554 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3304,7 +3304,7 @@ static int finish_port_resume(struct usb_device *udev)
/*
* There are some SS USB devices which take longer time for link training.
* XHCI specs 4.19.4 says that when Link training is successful, port
- * sets CSC bit to 1. So if SW reads port status before successful link
+ * sets CCS bit to 1. So if SW reads port status before successful link
* training, then it will not find device to be present.
* USB Analyzer log with such buggy devices show that in some cases
* device switch on the RX termination after long delay of host enabling
@@ -3315,14 +3315,17 @@ static int finish_port_resume(struct usb_device *udev)
* routine implements a 2000 ms timeout for link training. If in a case
* link trains before timeout, loop will exit earlier.
*
+ * There are also some 2.0 hard drive based devices and 3.0 thumb
+ * drives that, when plugged into a 2.0 only port, take a long
+ * time to set CCS after VBUS enable.
+ *
* FIXME: If a device was connected before suspend, but was removed
* while system was asleep, then the loop in the following routine will
* only exit at timeout.
*
- * This routine should only be called when persist is enabled for a SS
- * device.
+ * This routine should only be called when persist is enabled.
*/
-static int wait_for_ss_port_enable(struct usb_device *udev,
+static int wait_for_connected(struct usb_device *udev,
struct usb_hub *hub, int *port1,
u16 *portchange, u16 *portstatus)
{
@@ -3335,6 +3338,7 @@ static int wait_for_ss_port_enable(struct usb_device
*udev,
delay_ms += 20;
status = hub_port_status(hub, *port1, portstatus, portchange);
}
+ dev_dbg(&udev->dev, "Waited %dms for CONNECT\n", delay_ms);
return status;
}
@@ -3434,8 +3438,8 @@ int usb_port_resume(struct usb_device *udev, pm_message_t
msg)
}
}
- if (udev->persist_enabled && hub_is_superspeed(hub->hdev))
- status = wait_for_ss_port_enable(udev, hub, &port1, &portchange,
+ if (udev->persist_enabled)
+ status = wait_for_connected(udev, hub, &port1, &portchange,
&portstatus);
status = check_port_resume_type(udev,
--
1.9.0.138.g2de3478
--
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 0/6] usb: bcma: add USB 3.0 support
On 12/01/2015 11:44 PM, Rafał Miłecki wrote: > On 1 December 2015 at 23:28, Greg KH wrote: >> On Fri, Oct 23, 2015 at 11:36:56PM +0200, Hauke Mehrtens wrote: >>> This patch adds support for the USB 3.0 controller in the bcm53xx Northstar >>> SoC. >>> These patches are based on top of usb-next. >>> >>> This also adds a fake doorbell quirk which is needed for this controller >>> >>> changes since: >>> v2: >>> * fix build error reported by kbuild test robot >>> v1: >>> * fix sparse error reported by kbuild test robot >>> >>> Hauke Mehrtens (1): >>> usb: xhci: plat: fix adding usb3-lpm-capable quirk >>> >>> Rafał Miłecki (5): >>> usb: xhci: add Broadcom specific fake doorbell >>> usb: bcma: make helper creating platform dev more generic >>> usb: bcma: use separated function for USB 2.0 initialization >>> usb: bcma: add USB 3.0 support >>> usb: bcma: fix setting VCC GPIO value >>> >>> drivers/usb/host/bcma-hcd.c | 314 >>> +++ >>> drivers/usb/host/xhci-plat.c | 17 ++- >>> drivers/usb/host/xhci.c | 57 ++- >>> drivers/usb/host/xhci.h | 1 + >>> include/linux/usb/xhci_pdriver.h | 1 + >>> 5 files changed, 350 insertions(+), 40 deletions(-) >> >> I need acks from Mathias for the xhci portions before I can accept the >> rest of this... >> >> Also, it doesn't apply to the tree anymore :( > > I was thinking we're going to drop this patchset and write some of the > code in a different way. Based on that belief I sent following > standalone patch: > [PATCH] USB: bcma: switch to GPIO descriptor for power control > which replaces (improves) "usb: bcma: fix setting VCC GPIO value". > > Assuming 2-3 patches from Hauke's patchset shouldn't be applied, maybe > it's indeed better to drop the whole set? > Hi, Yes I will send a new version. Hauke -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] usb: Add connected retry on resume for non SS devices
On Wed, 2 Dec 2015, Al Cooper wrote: > Currently usb_port_resume waits for up to 2 seconds for CONNECT > status for SS devices only. This change will do the same thing for > non-SS devices even though the reason is a little different. This > will fix an issue where VBUS is turned off during system wide > "suspend to ram" and some 2.0 devices take greater than the current > max of 100ms to show connected after VBUS is enabled. This is most > commonly seen on hard drive based devices and USB3.0 devices plugged > into a 2.0 only port. > > Signed-off-by: Al Cooper > --- > > V2 - Change comment to reflect change to wait_for_connect() >- Add dev_dbg message that shows the actual wait time 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: Linux as a USB hub?
On Wed, Dec 02, 2015 at 02:48:38PM -0500, Alan Stern wrote: > On Wed, 2 Dec 2015, Rogan Dawes wrote: > > > I have read the documentation for the USB gadgets (multi, hid, > > printer, serial), but noted that there seem to be quite a few more > > gadgets available in the source nowadays. e.g. audio, webcam . Are > > there any plans to document these at some stage? > > You'll have to ask the people who wrote those gadget drivers. > Fair enough! > > Also, I saw "dummy_hcd.c", which sounds interesting. > > It is. It's meant for testing more than anything else; it provides an > emulated host and device controller pair, so you can test a gadget > driver even on a computer that doesn't have any USB device hardware. > > Alan Stern > Any plans to document how to use that, since I see that you wrote it? :-) Regards, Rogan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] usb: uhci: replace dma_pool_alloc and memset with dma_pool_zalloc
Replace dma_pool_alloc and memset with a single call to dma_pool_zalloc. Caught by coccinelle. Signed-off-by: Geyslan G. Bem --- drivers/usb/host/uhci-q.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/host/uhci-q.c b/drivers/usb/host/uhci-q.c index da6f56d..c17ea15 100644 --- a/drivers/usb/host/uhci-q.c +++ b/drivers/usb/host/uhci-q.c @@ -248,11 +248,10 @@ static struct uhci_qh *uhci_alloc_qh(struct uhci_hcd *uhci, dma_addr_t dma_handle; struct uhci_qh *qh; - qh = dma_pool_alloc(uhci->qh_pool, GFP_ATOMIC, &dma_handle); + qh = dma_pool_zalloc(uhci->qh_pool, GFP_ATOMIC, &dma_handle); if (!qh) return NULL; - memset(qh, 0, sizeof(*qh)); qh->dma_handle = dma_handle; qh->element = UHCI_PTR_TERM(uhci); -- 2.6.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 2/3] usb: whci: replace dma_pool_alloc and memset with dma_pool_zalloc
Replace dma_pool_alloc and memset with a single call to dma_pool_zalloc. Caught by coccinelle. Signed-off-by: Geyslan G. Bem --- drivers/usb/host/whci/qset.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/host/whci/qset.c b/drivers/usb/host/whci/qset.c index dc31c42..3297473 100644 --- a/drivers/usb/host/whci/qset.c +++ b/drivers/usb/host/whci/qset.c @@ -30,10 +30,9 @@ struct whc_qset *qset_alloc(struct whc *whc, gfp_t mem_flags) struct whc_qset *qset; dma_addr_t dma; - qset = dma_pool_alloc(whc->qset_pool, mem_flags, &dma); + qset = dma_pool_zalloc(whc->qset_pool, mem_flags, &dma); if (qset == NULL) return NULL; - memset(qset, 0, sizeof(struct whc_qset)); qset->qset_dma = dma; qset->whc = whc; -- 2.6.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 3/3] usb: xhci: replace dma_pool_alloc and memset with dma_pool_zalloc
Replace dma_pool_alloc and memset with a single call to dma_pool_zalloc.
Caught by coccinelle.
Signed-off-by: Geyslan G. Bem
---
drivers/usb/host/xhci-mem.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index c48cbe7..d034f92 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -47,13 +47,12 @@ static struct xhci_segment *xhci_segment_alloc(struct
xhci_hcd *xhci,
if (!seg)
return NULL;
- seg->trbs = dma_pool_alloc(xhci->segment_pool, flags, &dma);
+ seg->trbs = dma_pool_zalloc(xhci->segment_pool, flags, &dma);
if (!seg->trbs) {
kfree(seg);
return NULL;
}
- memset(seg->trbs, 0, TRB_SEGMENT_SIZE);
/* If the cycle state is 0, set the cycle bit to 1 for all the TRBs */
if (cycle_state == 0) {
for (i = 0; i < TRBS_PER_SEGMENT; i++)
@@ -517,12 +516,12 @@ static struct xhci_container_ctx
*xhci_alloc_container_ctx(struct xhci_hcd *xhci
if (type == XHCI_CTX_TYPE_INPUT)
ctx->size += CTX_SIZE(xhci->hcc_params);
- ctx->bytes = dma_pool_alloc(xhci->device_pool, flags, &ctx->dma);
+ ctx->bytes = dma_pool_zalloc(xhci->device_pool, flags, &ctx->dma);
if (!ctx->bytes) {
kfree(ctx);
return NULL;
}
- memset(ctx->bytes, 0, ctx->size);
+
return ctx;
}
--
2.6.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
Re: Linux as a USB hub?
On Wed, 2 Dec 2015, Rogan Dawes wrote: > > > Also, I saw "dummy_hcd.c", which sounds interesting. > > > > It is. It's meant for testing more than anything else; it provides an > > emulated host and device controller pair, so you can test a gadget > > driver even on a computer that doesn't have any USB device hardware. > > > > Alan Stern > > > > Any plans to document how to use that, since I see that you wrote it? :-) I didn't write it (see the Copyright lines at the top of the source file), but I did contribute to it and I help maintain it. There are no plans to document it beyond what is already available at linux-usb.org or by reading the source code. Besides, it's so easy to use that it hardly needs any documentation. Basically, you just modprobe it. (There are some module parameters you can set if you want to force the emulated connection to be SuperSpeed vs. High speed vs. Full speed, or if you want to emulate more than one controller. Unless you're doing something special, you can ignore them.) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: whci: fhci: remove comparison to bool
Get rid of bool explicit comparisons.
Caught by Coccinelle.
Signed-off-by: Geyslan G. Bem
---
drivers/usb/host/fhci-tds.c | 2 +-
drivers/usb/host/whci/qset.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/fhci-tds.c b/drivers/usb/host/fhci-tds.c
index 1498061..f82ad5d 100644
--- a/drivers/usb/host/fhci-tds.c
+++ b/drivers/usb/host/fhci-tds.c
@@ -85,7 +85,7 @@ static struct usb_td __iomem *next_bd(struct usb_td __iomem
*base,
void fhci_push_dummy_bd(struct endpoint *ep)
{
- if (ep->already_pushed_dummy_bd == false) {
+ if (!ep->already_pushed_dummy_bd) {
u16 td_status = in_be16(&ep->empty_td->status);
out_be32(&ep->empty_td->buf_ptr, DUMMY_BD_BUFFER);
diff --git a/drivers/usb/host/whci/qset.c b/drivers/usb/host/whci/qset.c
index 3297473..5e48a60 100644
--- a/drivers/usb/host/whci/qset.c
+++ b/drivers/usb/host/whci/qset.c
@@ -395,7 +395,7 @@ static void urb_dequeue_work(struct work_struct *work)
struct whc *whc = qset->whc;
unsigned long flags;
- if (wurb->is_async == true)
+ if (wurb->is_async)
asl_update(whc, WUSBCMD_ASYNC_UPDATED
| WUSBCMD_ASYNC_SYNCED_DB
| WUSBCMD_ASYNC_QSET_RM);
--
2.6.3
--
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: ehci: ohci: use true/false for bool
When bool use true or false instead of 1 or 0.
Caught by coccinelle.
Signed-off-by: Geyslan G. Bem
---
drivers/usb/host/ehci-hcd.c | 2 +-
drivers/usb/host/ohci-hcd.c | 4 ++--
drivers/usb/host/u132-hcd.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 48c92bf..1b01967 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -98,7 +98,7 @@ module_param (park, uint, S_IRUGO);
MODULE_PARM_DESC (park, "park setting; 1-3 back-to-back async packets");
/* for flakey hardware, ignore overcurrent indicators */
-static bool ignore_oc = 0;
+static bool ignore_oc = false;
module_param (ignore_oc, bool, S_IRUGO);
MODULE_PARM_DESC (ignore_oc, "ignore bogus hardware overcurrent indications");
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 760cb57..5547dbf 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -99,13 +99,13 @@ static void io_watchdog_func(unsigned long _ohci);
/* Some boards misreport power switching/overcurrent */
-static bool distrust_firmware = 1;
+static bool distrust_firmware = true;
module_param (distrust_firmware, bool, 0);
MODULE_PARM_DESC (distrust_firmware,
"true to distrust firmware power/overcurrent setup");
/* Some boards leave IR set wrongly, since they fail BIOS/SMM handshakes */
-static bool no_handshake = 0;
+static bool no_handshake = false;
module_param (no_handshake, bool, 0);
MODULE_PARM_DESC (no_handshake, "true (not default) disables BIOS handshake");
diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
index 692ccc6..05c85c7 100644
--- a/drivers/usb/host/u132-hcd.c
+++ b/drivers/usb/host/u132-hcd.c
@@ -73,7 +73,7 @@ MODULE_LICENSE("GPL");
#define INT_MODULE_PARM(n, v) static int n = v;module_param(n, int, 0444)
INT_MODULE_PARM(testing, 0);
/* Some boards misreport power switching/overcurrent*/
-static bool distrust_firmware = 1;
+static bool distrust_firmware = true;
module_param(distrust_firmware, bool, 0);
MODULE_PARM_DESC(distrust_firmware, "true to distrust firmware
power/overcurren"
"t setup");
--
2.6.3
--
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: ehci: ohci: use true/false for bool
On Wed, Dec 02, 2015 at 06:50:41PM -0300, Geyslan G. Bem wrote: > When bool use true or false instead of 1 or 0. > > Caught by coccinelle. > > Signed-off-by: Geyslan G. Bem > --- > drivers/usb/host/ehci-hcd.c | 2 +- > drivers/usb/host/ohci-hcd.c | 4 ++-- > drivers/usb/host/u132-hcd.c | 2 +- > 3 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c > index 48c92bf..1b01967 100644 > --- a/drivers/usb/host/ehci-hcd.c > +++ b/drivers/usb/host/ehci-hcd.c > @@ -98,7 +98,7 @@ module_param (park, uint, S_IRUGO); > MODULE_PARM_DESC (park, "park setting; 1-3 back-to-back async packets"); > > /* for flakey hardware, ignore overcurrent indicators */ > -static bool ignore_oc = 0; > +static bool ignore_oc = false; No need to set this to "0/false" as that's what the default is. 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] usb: ehci: ohci: use true/false for bool
2015-12-02 18:58 GMT-03:00 Greg Kroah-Hartman : > On Wed, Dec 02, 2015 at 06:50:41PM -0300, Geyslan G. Bem wrote: >> When bool use true or false instead of 1 or 0. >> >> Caught by coccinelle. >> >> Signed-off-by: Geyslan G. Bem >> --- >> drivers/usb/host/ehci-hcd.c | 2 +- >> drivers/usb/host/ohci-hcd.c | 4 ++-- >> drivers/usb/host/u132-hcd.c | 2 +- >> 3 files changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c >> index 48c92bf..1b01967 100644 >> --- a/drivers/usb/host/ehci-hcd.c >> +++ b/drivers/usb/host/ehci-hcd.c >> @@ -98,7 +98,7 @@ module_param (park, uint, S_IRUGO); >> MODULE_PARM_DESC (park, "park setting; 1-3 back-to-back async packets"); >> >> /* for flakey hardware, ignore overcurrent indicators */ >> -static bool ignore_oc = 0; >> +static bool ignore_oc = false; > > No need to set this to "0/false" as that's what the default is. > > thanks, > > greg k-h Thanks Greg, sending v2. -- Regards, Geyslan G. Bem hackingbits.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 v2] usb: ehci: ohci: use true/false for bool
When declaring/initializing bool use true instead of 1. If it's false,
there's no need to explicit initialize it, once it's default.
Caught by coccinelle.
Signed-off-by: Geyslan G. Bem
---
drivers/usb/host/ehci-hcd.c | 2 +-
drivers/usb/host/ohci-hcd.c | 4 ++--
drivers/usb/host/u132-hcd.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 48c92bf..1b01967 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -98,7 +98,7 @@ module_param (park, uint, S_IRUGO);
MODULE_PARM_DESC (park, "park setting; 1-3 back-to-back async packets");
/* for flakey hardware, ignore overcurrent indicators */
-static bool ignore_oc = 0;
+static bool ignore_oc;
module_param (ignore_oc, bool, S_IRUGO);
MODULE_PARM_DESC (ignore_oc, "ignore bogus hardware overcurrent indications");
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 760cb57..5547dbf 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -99,13 +99,13 @@ static void io_watchdog_func(unsigned long _ohci);
/* Some boards misreport power switching/overcurrent */
-static bool distrust_firmware = 1;
+static bool distrust_firmware = true;
module_param (distrust_firmware, bool, 0);
MODULE_PARM_DESC (distrust_firmware,
"true to distrust firmware power/overcurrent setup");
/* Some boards leave IR set wrongly, since they fail BIOS/SMM handshakes */
-static bool no_handshake = 0;
+static bool no_handshake;
module_param (no_handshake, bool, 0);
MODULE_PARM_DESC (no_handshake, "true (not default) disables BIOS handshake");
diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
index 692ccc6..05c85c7 100644
--- a/drivers/usb/host/u132-hcd.c
+++ b/drivers/usb/host/u132-hcd.c
@@ -73,7 +73,7 @@ MODULE_LICENSE("GPL");
#define INT_MODULE_PARM(n, v) static int n = v;module_param(n, int, 0444)
INT_MODULE_PARM(testing, 0);
/* Some boards misreport power switching/overcurrent*/
-static bool distrust_firmware = 1;
+static bool distrust_firmware = true;
module_param(distrust_firmware, bool, 0);
MODULE_PARM_DESC(distrust_firmware, "true to distrust firmware
power/overcurren"
"t setup");
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: ehci: ohci: use true/false for bool
On Wed, Dec 02, 2015 at 07:09:19PM -0300, Geyslan G. Bem wrote: > When declaring/initializing bool use true instead of 1. If it's false, > there's no need to explicit initialize it, once it's default. > > Caught by coccinelle. > > Signed-off-by: Geyslan G. Bem > --- > drivers/usb/host/ehci-hcd.c | 2 +- > drivers/usb/host/ohci-hcd.c | 4 ++-- > drivers/usb/host/u132-hcd.c | 2 +- > 3 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c > index 48c92bf..1b01967 100644 > --- a/drivers/usb/host/ehci-hcd.c > +++ b/drivers/usb/host/ehci-hcd.c > @@ -98,7 +98,7 @@ module_param (park, uint, S_IRUGO); > MODULE_PARM_DESC (park, "park setting; 1-3 back-to-back async packets"); > > /* for flakey hardware, ignore overcurrent indicators */ > -static bool ignore_oc = 0; > +static bool ignore_oc; This should be a separate patch as it's doing something differently than what you describe. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: use BUG_ON() instead of BUG()
Replace BUG() with BUG_ON(). Caught by coccinelle. Signed-off-by: Geyslan G. Bem --- drivers/usb/host/oxu210hp-hcd.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c index 1f139d8..bc74aca 100644 --- a/drivers/usb/host/oxu210hp-hcd.c +++ b/drivers/usb/host/oxu210hp-hcd.c @@ -394,8 +394,7 @@ static void ehci_quiesce(struct oxu_hcd *oxu) u32 temp; #ifdef DEBUG - if (!HC_IS_RUNNING(oxu_to_hcd(oxu)->state)) - BUG(); + BUG_ON(!HC_IS_RUNNING(oxu_to_hcd(oxu)->state)); #endif /* wait for any schedule enables/disables to take effect */ @@ -1709,9 +1708,8 @@ static void start_unlink_async(struct oxu_hcd *oxu, struct ehci_qh *qh) #ifdef DEBUG assert_spin_locked(&oxu->lock); - if (oxu->reclaim || (qh->qh_state != QH_STATE_LINKED - && qh->qh_state != QH_STATE_UNLINK_WAIT)) - BUG(); + BUG_ON(oxu->reclaim || (qh->qh_state != QH_STATE_LINKED + && qh->qh_state != QH_STATE_UNLINK_WAIT)); #endif /* stop async schedule right now? */ -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: ehci: ohci: use true/false for bool
2015-12-02 19:16 GMT-03:00 Greg Kroah-Hartman : > On Wed, Dec 02, 2015 at 07:09:19PM -0300, Geyslan G. Bem wrote: >> When declaring/initializing bool use true instead of 1. If it's false, >> there's no need to explicit initialize it, once it's default. >> >> Caught by coccinelle. >> >> Signed-off-by: Geyslan G. Bem >> --- >> drivers/usb/host/ehci-hcd.c | 2 +- >> drivers/usb/host/ohci-hcd.c | 4 ++-- >> drivers/usb/host/u132-hcd.c | 2 +- >> 3 files changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c >> index 48c92bf..1b01967 100644 >> --- a/drivers/usb/host/ehci-hcd.c >> +++ b/drivers/usb/host/ehci-hcd.c >> @@ -98,7 +98,7 @@ module_param (park, uint, S_IRUGO); >> MODULE_PARM_DESC (park, "park setting; 1-3 back-to-back async packets"); >> >> /* for flakey hardware, ignore overcurrent indicators */ >> -static bool ignore_oc = 0; >> +static bool ignore_oc; > > This should be a separate patch as it's doing something differently than > what you describe. > > thanks, > > greg k-h Greg, I think that the v2 description is ok, the title is misleading indeed. I'll make a new one entitled "fix bool initialization". Anything else? Thanks. -- Regards, Geyslan G. Bem hackingbits.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: ehci: ohci: fix bool assignments
When assigning bool use true instead of 1. If declaring it as static and
it's false there's no need to initialize it, since static variables are
zeroed by default.
Caught by coccinelle.
Signed-off-by: Geyslan G. Bem
---
drivers/usb/host/ehci-hcd.c | 2 +-
drivers/usb/host/ohci-hcd.c | 4 ++--
drivers/usb/host/u132-hcd.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 48c92bf..1b01967 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -98,7 +98,7 @@ module_param (park, uint, S_IRUGO);
MODULE_PARM_DESC (park, "park setting; 1-3 back-to-back async packets");
/* for flakey hardware, ignore overcurrent indicators */
-static bool ignore_oc = 0;
+static bool ignore_oc;
module_param (ignore_oc, bool, S_IRUGO);
MODULE_PARM_DESC (ignore_oc, "ignore bogus hardware overcurrent indications");
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 760cb57..5547dbf 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -99,13 +99,13 @@ static void io_watchdog_func(unsigned long _ohci);
/* Some boards misreport power switching/overcurrent */
-static bool distrust_firmware = 1;
+static bool distrust_firmware = true;
module_param (distrust_firmware, bool, 0);
MODULE_PARM_DESC (distrust_firmware,
"true to distrust firmware power/overcurrent setup");
/* Some boards leave IR set wrongly, since they fail BIOS/SMM handshakes */
-static bool no_handshake = 0;
+static bool no_handshake;
module_param (no_handshake, bool, 0);
MODULE_PARM_DESC (no_handshake, "true (not default) disables BIOS handshake");
diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
index 692ccc6..05c85c7 100644
--- a/drivers/usb/host/u132-hcd.c
+++ b/drivers/usb/host/u132-hcd.c
@@ -73,7 +73,7 @@ MODULE_LICENSE("GPL");
#define INT_MODULE_PARM(n, v) static int n = v;module_param(n, int, 0444)
INT_MODULE_PARM(testing, 0);
/* Some boards misreport power switching/overcurrent*/
-static bool distrust_firmware = 1;
+static bool distrust_firmware = true;
module_param(distrust_firmware, bool, 0);
MODULE_PARM_DESC(distrust_firmware, "true to distrust firmware
power/overcurren"
"t setup");
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: ehci: ohci: use true/false for bool
2015-12-02 19:23 GMT-03:00 Geyslan G. Bem : > 2015-12-02 19:16 GMT-03:00 Greg Kroah-Hartman : >> On Wed, Dec 02, 2015 at 07:09:19PM -0300, Geyslan G. Bem wrote: >>> When declaring/initializing bool use true instead of 1. If it's false, >>> there's no need to explicit initialize it, once it's default. >>> >>> Caught by coccinelle. >>> >>> Signed-off-by: Geyslan G. Bem >>> --- >>> drivers/usb/host/ehci-hcd.c | 2 +- >>> drivers/usb/host/ohci-hcd.c | 4 ++-- >>> drivers/usb/host/u132-hcd.c | 2 +- >>> 3 files changed, 4 insertions(+), 4 deletions(-) >>> >>> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c >>> index 48c92bf..1b01967 100644 >>> --- a/drivers/usb/host/ehci-hcd.c >>> +++ b/drivers/usb/host/ehci-hcd.c >>> @@ -98,7 +98,7 @@ module_param (park, uint, S_IRUGO); >>> MODULE_PARM_DESC (park, "park setting; 1-3 back-to-back async packets"); >>> >>> /* for flakey hardware, ignore overcurrent indicators */ >>> -static bool ignore_oc = 0; >>> +static bool ignore_oc; >> >> This should be a separate patch as it's doing something differently than >> what you describe. >> >> thanks, >> >> greg k-h > > Greg, > > I think that the v2 description is ok, the title is misleading indeed. > I'll make a new one entitled "fix bool initialization". Anything else? Please ignore my last statements. Report to this: [PATCH] usb: ehci: ohci: fix bool assignments > > Thanks. > > -- > Regards, > > Geyslan G. Bem > hackingbits.com -- Regards, Geyslan G. Bem hackingbits.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: Infrastructure for zerocopy I/O
On Wed, Dec 02, 2015 at 10:54:52AM -0500, Alan Stern wrote: >> [ 28.796244] DMAR: Allocating domain for 2-2 failed > I don't know what the reason is for that. It may be that your kernel > isn't configured to allocate as much coherent memory as you are asking > for. We'll have to investigate further, maybe ask somebody who knows > more about how the DMA subsystem works. I'm thinking; maybe should the memory not be allocated against the USB device, but against the controller it hangs on? (Note that it complains about allocating the _domain_, not the memory itself.) Do you know if that's possible from this point in the code? /* Steinar */ -- Homepage: https://www.sesse.net/ -- 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: Infrastructure for zerocopy I/O
On Thu, Dec 03, 2015 at 12:51:14AM +0100, Steinar H. Gunderson wrote: > I'm thinking; maybe should the memory not be allocated against the USB > device, but against the controller it hangs on? (Note that it complains about > allocating the _domain_, not the memory itself.) Do you know if that's > possible from this point in the code? FWIW, I tried against &ps->dev->bus->controller, and it didn't give me any error messages, but still returns NULL. /* Steinar */ -- Homepage: https://www.sesse.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Two fix for dwc2 gadget driver
On 11/29/2015 9:29 PM, changbin...@intel.com wrote: > From: "Du, Changbin" > > With the first patch, enable a enabled ep will return -EBUSY. > The second patch forbid queuing on disabled ep to avoid panic. The usb_ep->enabled flag was added in 4.4. It looks like these same checks are also added at the API level in the usb_ep_enable() and usb_ep_disable(). In case this is bypassed we should probably add them in the gadget anyways but using the existing flag. Regards, John > > Du, Changbin (2): > usb: dwc2: add ep enabled flag to avoid double enable/disable > usb: dwc2: forbid queuing request to a disabled ep > > drivers/usb/dwc2/core.h | 1 + > drivers/usb/dwc2/gadget.c | 26 +- > 2 files changed, 26 insertions(+), 1 deletion(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] Two fix for dwc2 gadget driver
> On 11/29/2015 9:29 PM, changbin...@intel.com wrote: > > From: "Du, Changbin" > > > > With the first patch, enable a enabled ep will return -EBUSY. > > The second patch forbid queuing on disabled ep to avoid panic. > > > The usb_ep->enabled flag was added in 4.4. > > It looks like these same checks are also added at the API level in the > usb_ep_enable() and usb_ep_disable(). > > In case this is bypassed we should probably add them in the gadget > anyways but using the existing flag. > > Regards, > John > Hmm, just learnt the flag on gadget API layer. And I just see usb_ep_enable return success if it is already enabled. But I think it should return an error to inform the caller. Because the ep configuration may probably be changed. In this case, usb_ep_enable will do different behavior. Hmm, the usb_ep_queue doesn't check the enabled flag. Should be added. Let me have a try. Best Regards, Changbin -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: xhci: fix config fail of FS hub behind a HS hub with MTT
if a full speed hub connects to a high speed hub which
supports MTT, the MTT field of its slot context will be set
to 1 when xHCI driver setups an xHCI virtual device in
xhci_setup_addressable_virt_dev(); once usb core fetch its
hub descriptor, and need to update the xHC's internal data
structures for the device, the HUB field of its slot context
will be set to 1 too, meanwhile MTT is also set before,
this will cause configure endpoint command fail, so in the
case, we should clear MTT to 0 for full speed hub according
to section 6.2.2
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 6cbcd1e..27c8cf8 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4785,8 +4785,16 @@ int xhci_update_hub_device(struct usb_hcd *hcd, struct
usb_device *hdev,
ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG);
slot_ctx = xhci_get_slot_ctx(xhci, config_cmd->in_ctx);
slot_ctx->dev_info |= cpu_to_le32(DEV_HUB);
+ /*
+* refer to section 6.2.2: MTT should be 0 for full speed hub,
+* but it may be already set to 1 when setup an xHCI virtual
+* device, so clear it anyway.
+*/
if (tt->multi)
slot_ctx->dev_info |= cpu_to_le32(DEV_MTT);
+ else if (hdev->speed == USB_SPEED_FULL)
+ slot_ctx->dev_info &= cpu_to_le32(~DEV_MTT);
+
if (xhci->hci_version > 0x95) {
xhci_dbg(xhci, "xHCI version %x needs hub "
"TT think time and number of ports\n",
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: xhci-mtk: fix bpkts value of LS/HS periodic eps not behind TT
when a LS or FS device doesn't connect though a HS hub,
the @bPkts field of its periodic endpoint context should
be set to 1.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk-sch.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
index c30de7c..73f763c 100644
--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -275,8 +275,9 @@ static bool need_bw_sch(struct usb_host_endpoint *ep,
return false;
/*
-* for LS & FS periodic endpoints which its device don't attach
-* to TT are also ignored, root-hub will schedule them directly
+* for LS & FS periodic endpoints which its device is not behind
+* a TT are also ignored, root-hub will schedule them directly,
+* but need set @bpkts field of endpoint context to 1.
*/
if (is_fs_or_ls(speed) && !has_tt)
return false;
@@ -339,8 +340,17 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd *hcd, struct
usb_device *udev,
GET_MAX_PACKET(usb_endpoint_maxp(&ep->desc)),
usb_endpoint_dir_in(&ep->desc), ep);
- if (!need_bw_sch(ep, udev->speed, slot_ctx->tt_info & TT_SLOT))
+ if (!need_bw_sch(ep, udev->speed, slot_ctx->tt_info & TT_SLOT)) {
+ /*
+* set @bpkts to 1 if it is LS or FS periodic endpoint, and its
+* device does not connected through an external HS hub
+*/
+ if (usb_endpoint_xfer_int(&ep->desc)
+ || usb_endpoint_xfer_isoc(&ep->desc))
+ ep_ctx->reserved[0] |= cpu_to_le32(EP_BPKTS(1));
+
return 0;
+ }
bw_index = get_bw_index(xhci, udev, ep);
sch_bw = &sch_array[bw_index];
--
1.8.1.1.dirty
--
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
