Re: [RFC] USB: Fix persist resume of some SS USB devices
Hi David,
Thanks for your review.
On Tue, Jul 15, 2014 at 10:58:03PM +0800, David Laight wrote:
> From: Alan Stern
> > On Tue, 15 Jul 2014, Pratyush Anand wrote:
> ...
> > > +static int wait_for_ss_port_enable(struct usb_device *udev,
> > > + struct usb_hub *hub,
> > > + int *port1,
> > > + u16 *portchange,
> > > + u16 *portstatus)
> >
> > Continuation lines should be indented by 2 tab stops, not 5.
> >
> > > +{
> > > + int status, wait_count_20ms = 0;
> > > +
> > > + while (wait_count_20ms++ < 20) {
> > > + status = hub_port_status(hub, *port1, portstatus, portchange);
> > > + if (status || *portstatus & USB_PORT_STAT_CONNECTION)
> > > + return status;
> > > + msleep(20);
> > > + }
> > > + return hub_port_status(hub, *port1, portstatus, portchange);
> > > +}
> >
> > This might be a little clearer:
> >
> > int status = 0, delay_ms = 0;
> >
> > whle (delay_ms < 400) {
> > if (status || (*portstatus & USB_PORT_STAT_CONNECTION))
> > break;
> > msleep(20);
> > delay_ms += 20;
> > status = hub_port_status(hub, *port1, portstatus, portchange);
> > }
> > return status;
>
> I think I would write:
> for (ms_delay = 0; (ms_delay += 20) <= 400; msleep(20)) {
> status = hub_port_status(hub, *port1, portstatus, portchange);
> if (status)
> return status;
> if (*portstatus & USB_PORT_STAT_CONNECTION)
> return 0;
> }
> return 0;
I think Alan's loop will save call time of one hub_port_status in case
of good device, where CSC bit was already set before this function is
reached. Also its more readable for me. So may be I should go with that.
~Pratyush
>
> 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: [RFC] USB: Fix persist resume of some SS USB devices
Hi Alan, Thanks a lot for your review. On Tue, Jul 15, 2014 at 10:46:00PM +0800, Alan Stern wrote: > On Tue, 15 Jul 2014, Pratyush Anand wrote: > > > Problem Summary: Problem has been observed generally with PM states > > where VBUS goes off during suspend. There are some SS USB devices which > > takes slightly longer time for link training compared to many others. > > Such devices fails to reconnect with same old address which was > > associated with it before suspend. > > > > When system resumes, at some point of time (dpm_run_callback-> > > usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device-> > > usb_port_resume) SW reads hub status. If device is present, > > then it finishes port resume and re-enumerates device with same > > address. If device is not present, then SW thinks that device was > > removed during suspend and therefore does logical disconnection > > and removes all the resource allocated for this device. > > > > Now, if I put sufficient delay just before root hub status read in > > usb_resume_device then, SW sees always that device is present. In normal > > course(without any delay) SW sees that no device is present and then SW > > removes all resource associated with the device at this port. In the > > latter case, after sometime, device says that hey I am here, now host > > enumerates it, but with new address. > > > > Problem had been reproduced when I connect verbatim USB3.0 hard disc > > with my STiH407 XHCI host running with 3.10 kernel. > > > > I see that similar problem has been reported here. > > https://bugzilla.kernel.org/show_bug.cgi?id=53211 > > Reading above it seems that bug was not in 3.6.6 and was present in 3.8 > > and again it was not present for some in 3.12.6, while it was present for > > few others. I tested with 3.13-FC19 with i686 desktop, problem was still > > there. However, I was failed to reproduce it with 3.16-RC4 running at > > same i686 machine. I would say it is just a random observation. Problem for > > few > > devices is always there, as I am unable to find a proper fix for the > > issue. > > > > So, now question is what should be the amount of delay as per USB > > specification so that host is always able to recognize suspended device > > after resume. > > > > -- XHCI specs 4.19.4 says that when Link training is successful, > > port sets CSC bit to 1 (root hub controller says that device is > > present). So the delay should be the maximum amount of time from the > > moment when host enables VBUS to the moment it is able to perform Link > > Training. Unfortunately, I could not find any direct statement in USB > > specification for such timeout. Since path from VBUS on to U0 will > > follow, like this Rx.Detect.Quite->Rx.Detect.Active->Polling.LFPS-> > > Polling.ExEQ->Polling.Active->Polling.Configuration->Polling.Idle->U0, > > therefore we can set maximum delay as tRxDetectQuietTimeout (12 ms) + > > tPollingLFPSTimeout (360 ms) + tPollingActiveTimeout (12 ms) + > > tPollingConfigurationTimeout (12 ms) + tPollingIdleTimeout (2 ms) > > (398 =~ 400 ms). > > > > This patch implements above delay, but only for SS device and when > > persist is enabled. After every 10 ms SW reads port status and if it > > is enabled, SW exits delay loop. > > > > So, for the good device overhead is just the time to execute > > hub_port_status, while for the bad device penalty could be as long as > > 400 mS. > > > > Results: > > > > Verbatim USB SS hard disk connected with STiH407 USB host running 3.10 > > Kernel resumes in 461 msecs without this patch, but hard disk is > > assigned a new device address. Same system resumes in 790 msecs with > > this patch, but with old device address. > > What happens if you unplug the device while the system is asleep and > leave it unplugged during resume? Good catch. I need to take care of it. > > > > Signed-off-by: Pratyush Anand > > --- > > drivers/usb/core/hub.c | 37 + > > 1 file changed, 37 insertions(+) > > > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > > index 21b99b4..93495b7 100644 > > --- a/drivers/usb/core/hub.c > > +++ b/drivers/usb/core/hub.c > > @@ -3245,6 +3245,39 @@ static int finish_port_resume(struct usb_device > > *udev) > > } > > > > /* > > + * There are some SS USB devices which takes 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 > > + * training, then it will not find device to be present. > > + * Successful SS link training follows Rx.Detect.Quite->Rx.Detect.Active-> > > .Quiet? Will correct. > > > + * Polling.LFPS->Polling.ExEQ->Polling.Active->Polling.Configuration-> > > + * Polling.Idle->U0. > > + * Following routine waits for either till port is enable or a timeout > > + * of 400 ms whichever is earlier [tRxDetectQuietTimeout (12 ms) + > > + * tPollingLFPSTimeout (360 ms) + tPolli
Re: [PATCH v2 07/12] usb: chipidea: add a generic driver
On Tue, Jul 15, 2014 at 05:24:37PM +0200, Antoine Ténart wrote: > Hi, > > On Thu, Jul 03, 2014 at 08:17:34AM +0530, punnaiah choudary kalluri wrote: > > Since its a generic driver, support for configuring the dma_mask using > > dma_coerce_mask_and_coherent would be good. > > > > Should I add a DMA mask dt property? Or just not add this and wait for > someone needing it in his case? > As a dt property, since most of platforms will use it. For PIO mode, the property can be NULL. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/12] usb: chipidea: add a generic driver
On Tue, Jul 15, 2014 at 05:22:30PM +0200, Antoine Ténart wrote: > Hi guys, > > On Wed, Jul 02, 2014 at 01:10:00AM +, Peter Chen wrote: > > > On 07/01/2014 02:42 PM, Alexandre Belloni wrote: > > > > > > > Well, there is nothing specific about the Berlin CI. Some > > > > subsystems use the 'generic' keyword in these cases. Do you see a > > > > particular reason I should use some Berlin related compatible here? > > > > > > Not must, one suggestion is: can you change the compatible string > > > to "chipidea-usb-generic"? > > > > > > >>> I don't know about ChipIdea/ARC/DW's product portfolio but I guess > > > >>> the compatible should also carry '2.0' or 'usb2' in it. Or we just > > > >>> use some version number like 'chipidea,ci13000' or 'chipidea,ci13xxx'. > > > > > > >> The recommended format for compatible string is: > > > >> "manufacturer,model", I agree with "chipidea,ci13xxx", thanks. > > > > > > > I think we should probably avoid using wildcards in the compatible > > > > string. > > > > > > I'm sure wildcards shouldn't be allowed there. :-) > > > > Then, what's your guys recommend, how about "chipidea,usb2-generic"? > > So what do you think? "chipidea,ci13", "chipidea,usb2-generic" or > something else? > Do you agree to use "chipidea,usb2", And add ci13xxx at MODULE_DESCRIPTION? -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Iso trbs for xhci arrangement
> From: vichy [mailto:vichy@gmail.com] > Sent: Tuesday, July 15, 2014 1:42 AM > > > Please read section 3.2.11 in the xHCI spec, which is freely available on > > the web. > I found what you mean. > I dump "ep context", "ep ring" and "event ring" for handling short package. > > Driver prepare ep ring like below > xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx > xhci.0: @2796e160 279d 06f8 0625 //normal > xhci.0: @2796e170 279d06f8 0bf4 80021625 > > but event ring get below result > xhci.0: @278d1710 2796e150 0d0004fc 01038001 > xhci.0: @278d1720 2796e160 0100 01038001 > //event for normal > > My questions are > 1. The xhci controller seems not handle the normal TRB for short package. > as you can see the length of event package for normal package is 0. > am I correct? > 2. if above #1 is correct, how xhci controller get the left 0x6f8 data > in original normal package? This looks like a hardware bug to me. Which xHCI controller is this? > the controller did fire iso in token to get 0x4fc bytes, above > marked "", and if xhci controller didn't firing the left in tokens > to get 0x6f8 bytes, that mean the data we get from iso-in pipe is not > continuous, right? I would bet that no data was transferred at all, but the controller forgot to set the transfer length correctly for the chained normal TRB. Are you seeing an actual problem with this? If not, maybe the xHCI driver is written in such a way that this does not cause a problem. > 3. is there any relationship between below patch > https://lkml.org/lkml/2013/6/26/501 I doubt it. > appreciate your help, > > Endpoint 02 Context: > xhci.0: @e52e90c0 (virt) @27f660c0 (dma) 0x01 - ep_info > xhci.0: @e52e90c4 (virt) @27f660c4 (dma) 0x3fc0228 - ep_info2 > xhci.0: @e52e90c8 (virt) @27f660c8 (dma) 0x2796e001 - deq > xhci.0: @e52e90d0 (virt) @27f660d0 (dma) 0xbf40bf4 - tx_info > xhci.0: @e52e90d4 (virt) @27f660d4 (dma) 0x00 - rsvd[0] > xhci.0: @e52e90d8 (virt) @27f660d8 (dma) 0x00 - rsvd[1] > xhci.0: @e52e90dc (virt) @27f660dc (dma) 0x300 - rsvd[2] > > ep ring > xhci.0: @2796e110 279ccb34 0bf4 80021625 > xhci.0: @2796e120 279cd728 0bf4 80021625 > xhci.0: @2796e130 279ce31c 0bf4 80021625 > xhci.0: @2796e140 279cef10 0bf4 80021625 > xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx > xhci.0: @2796e160 279d 06f8 0625 //normal > xhci.0: @2796e170 279d06f8 0bf4 80021625 > > event ring: > xhci.0: @278d1700 2796e140 0d000bf4 01038001 > xhci.0: @278d1710 2796e150 0d0004fc 01038001 > xhci.0: @278d1720 2796e160 0100 01038001 //event for > normal > xhci.0: @278d1730 2796e170 0d000bf4 01038001 > xhci.0: @278d1740 2796e180 0d000bf4 01038001 Are these the entire rings, or did you just show a part of them? Because all the TRBs have the cycle bit set, which shouldn't happen AFAIK. -- Paul
Re: [PATCH v4 3/4] usb: gadget: pxa27x_udc: use devm_* helpers
Felipe Balbi writes: > > will do. Just give me a couple days as I'm dealing with a lot right now > ;-) Ok, no problem. That would give a bit of time for Mark to send his Acked-by, won't it Mark ? ;) Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uas regression in 3.15 with Lacie Rugged USB3 and NEC uPD720200
W dniu 15.07.2014 07:31, Julian Sikorski pisze: > W dniu 14.07.2014 23:59, Jonathan pisze: >> Julian, >> >> My issue appears to be related to the Etron xhci controller on my >> motherboard and not the ASMedia chipset in my USB dock. You can identify >> your xhci controller with the lspci command which will help to determine if >> we are actually having the same problem. >> >> Please see: >> >> https://bugzilla.kernel.org/show_bug.cgi?id=80101 >> >> Regards, >> >> Jonathan > > Hi Jonathan, > > looks like you were right that my problem might be a different one after > all. My USB3 controller is a NEC one: > > 02:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host > Controller [1033:0194] (rev 03) > > Best regards, > Julian I have also managed to reproduce the panic with the debug kernel. I have the entire crash dump available, please let me know if more information is required: [ 53.892814] usb 4-2: new SuperSpeed USB device number 2 using xhci_hcd [ 53.911733] usb 4-2: New USB device found, idVendor=059f, idProduct=1061 [ 53.911743] usb 4-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [ 53.911748] usb 4-2: Product: Rugged USB3-FW [ 53.911753] usb 4-2: Manufacturer: LaCie [ 53.911757] usb 4-2: SerialNumber: 157f928920fa [ 53.990079] usbcore: registered new interface driver usb-storage [ 54.004973] scsi6 : uas [ 54.005408] usbcore: registered new interface driver uas [ 54.006210] scsi 6:0:0:0: Direct-Access LaCieRugged FW USB3 051E PQ: 0 ANSI: 6 [ 54.008161] sd 6:0:0:0: Attached scsi generic sg2 type 0 [ 54.017063] sd 6:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) [ 54.017668] sd 6:0:0:0: [sdb] Write Protect is off [ 54.017673] sd 6:0:0:0: [sdb] Mode Sense: 43 00 00 00 [ 54.017997] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 54.018119] sd 6:0:0:0: uas_sense_old: urb length 26 disagrees with IU sense data length 510, using 18 bytes of sense data [ 85.060805] sd 6:0:0:0: uas_eh_abort_handler 8803120b7400 tag 0, inflight: IN [ 85.061835] sd 6:0:0:0: abort completed [ 85.062037] [ cut here ] [ 85.062191] kernel BUG at block/blk-core.c:2511! [ 85.062328] invalid opcode: [#1] SMP [ 85.062573] Modules linked in: uas usb_storage nf_conntrack_netbios_ns nf_conntrack_broadcast ccm ip6t_rpfilter ip6t_REJECT xt_conntrack bnep bluetooth ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw fuse iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal coretemp snd_hda_codec_realtek kvm_intel kvm arc4 snd_hda_codec_generic snd_hda_codec_hdmi crct10dif_pclmul iwldvm crc32_pclmul crc32c_intel mac80211 sdhci_pci uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core snd_hda_intel ghash_clmulni_intel videodev iwlwifi snd_hda_controller [ 85.066723] media snd_hda_codec sdhci cfg80211 snd_hwdep microcode jme snd_seq snd_seq_device snd_pcm mii serio_raw mmc_core jmb38x_ms rfkill memstick mei_me mei snd_timer shpchp lpc_ich i2c_i801 mfd_core i2c_core snd soundcore nfsd auth_rpcgss nfs_acl lockd sunrpc binfmt_misc firewire_ohci firewire_core crc_itu_t wmi video [ 85.069089] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.4-200.fc20.x86_64+debug #1 [ 85.069297] Hardware name: CLEVO P150HMx/P150HMx, BIOS 4.6.4 08/09/2011 [ 85.069509] task: 81c184c0 ti: 81c0 task.ti: 81c0 [ 85.069716] RIP: 0010:[] [] blk_finish_request+0xf0/0x100 [ 85.069987] RSP: 0018:880321e03da0 EFLAGS: 00010002 [ 85.070122] RAX: 0286 RBX: 88031b73d730 RCX: [ 85.070261] RDX: 880321e0eb20 RSI: fffb RDI: 88031b73d730 [ 85.071768] RBP: 880321e03db0 R08: R09: 0001 [ 85.071907] R10: 81c184c0 R11: 81c18d80 R12: fffb [ 85.072046] R13: 8803190625b0 R14: 0286 R15: 8803120b7400 [ 85.072186] FS: () GS:880321e0() knlGS: [ 85.072395] CS: 0010 DS: ES: CR0: 80050033 [ 85.072531] CR2: 7f6c210209c0 CR3: 01c11000 CR4: 000407f0 [ 85.072669] Stack: [ 85.072794] 88031b73d730 fffb 880321e03de0 81398722 [ 85.073205] 88031b73d730 0800 fffb 88031b73d730 [ 85.073615] 880321e03df0 81398750 880321e03e58 815265c1 [ 85.074024] Call Trace: [ 85.074151] [ 85.074210] [ 85.074387] [] blk_end_bidi_request+0x42/0x60 [ 85.074523] [] blk_end_request+0x10/0x20 [ 85.074664] [] scsi_io_completion+0x111/0x6a0 [ 85.074803] [] scsi_finish_command+0xb3/0x110 [
Re: [PATCH v4 3/4] usb: gadget: pxa27x_udc: use devm_* helpers
On Tue, Jul 15, 2014 at 07:50:35PM +0200, Robert Jarzmik wrote:
> Sergei Shtylyov writes:
>
> > Hello.
> >
> >> @@ -2524,35 +2518,21 @@ static int pxa_udc_probe(struct platform_device
> >> *pdev)
> >>pxa_eps_setup(udc);
> >>
> >>/* irq setup after old hardware state is cleaned up */
> >> - retval = request_irq(udc->irq, pxa_udc_irq,
> >> - IRQF_SHARED, driver_name, udc);
> >> + retval = devm_request_irq(&pdev->dev, udc->irq, pxa_udc_irq,
> >> +IRQF_SHARED, driver_name, udc);
> >>if (retval != 0) {
> >>dev_err(udc->dev, "%s: can't get irq %i, err %d\n",
> >>driver_name, udc->irq, retval);
> >> - goto err_irq;
> >> + return retval;
> >
> >You forgot clk_unprepare().
>
> Right. As I had said before, I wanted this serie to be the last. And this
> error
> was already present in the previous version.
>
> Therefore, let's drop this patch from the serie, I'll submit it apart. Felipe
> let's consider patch 1, 2 and 4 please.
will do. Just give me a couple days as I'm dealing with a lot right now
;-)
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv4 0/3] Gadget directory cleanup
Hi, On Tue, Jul 15, 2014 at 01:09:43PM +0200, Andrzej Pietrasiewicz wrote: > This is a follow-up to this thread: > > http://www.spinics.net/lists/linux-usb/msg107611.html > > The cleanup rearranges the way source code files are located in the > drivers/usb/gadget directory. New subdirectories are introduced: > > - "udc" for UDC chip drivers > - "function" for actual usb functions' implementations > - "legacy" for gadgets compiled as statically composed modules > > while at the gadget's root level there are files related to the composite > framework. > > These are the reasons for doing such a change: > > - there are ~130 source code files already in a clean tree > > - when all gadgets and some udc drivers are built as modules then, > including the by-products of the build (*.o, *.ko, *.mod.c, .*.cmd), > the number easily grows to ~500 files > > - files serving different purpose (udc chip drivers, actual gadget functions' > implementations, legacy gadgets) are located side-by-side which might cause > confusion > > - gadget's Kconfig and Makefile tend to be lengthy. > > After the patches are applied the gadget subdirectory looks much cleaner. > > Rebased onto Felipe's testing/next. > > v3..v4: changed the sequence modules are built so that for example > g_ether is not initialized before libcomposite and functions > if compiled-in were all build issues sorted now ? -- balbi signature.asc Description: Digital signature
Re: Possible bug in xhci-ring.c
Hi Maciej, On Tue, Jul 15, 2014 at 11:29 AM, Maciej Puzio wrote: > Julius, I tested the patch on kernel 3.2.61, on two USB 3.0 host > controllers (Asmedia and NEC), and four USB 3.0 devices (three of > which were previously triggering the issue, and one worked fine). On > the Asmedia controller, the patch fixes the regression, but with one > of the devices (Areca ARC-5040) I still occasionally get the following > messages in the log: > > Jul 15 12:34:50 ubuntu kernel: [ 1855.902804] usb 4-1: reset > SuperSpeed USB device number 2 using xhci_hcd > Jul 15 12:34:50 ubuntu kernel: [ 1855.920190] xhci_hcd :03:00.0: > xHCI xhci_drop_endpoint called with disabled ep 880423628480 > Jul 15 12:34:50 ubuntu kernel: [ 1855.920197] xhci_hcd :03:00.0: > xHCI xhci_drop_endpoint called with disabled ep 8804236284c0 > > These messages appear out of nowhere, seemingly without any cause, > usually some time after the device has been plugged in (time varies > from 30 sec to 30 min). This worries me a little, because these exact > messages were one of the symptoms of the regression. However, the > device seems to work fine and remains accessible. Without your patch, > such messages were logged every 30 seconds, and the device was not > accessible until they stopped. > I did not notice any problems with other devices on the Asmedia > controller (with the patch), nor with any devices on the NEC > controller (with or without the patch). I *think* those messages are harmless. I've seen them often enough in other logs, they shouldn't have anything to do with this bug. You would probably see them without either of my two patches as well. > I have not yet tested any other kernel version; I intend to compile > and test the newest available kernel tomorrow. Where should I add the > "Tested-by" tag? Just respond with 'Tested-by: Your Name ' to the patch email and the the maintainer should merge that into the commit message when he picks it up (at least that's how I've seen this done before). -- 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: Possible bug in xhci-ring.c
Julius, I tested the patch on kernel 3.2.61, on two USB 3.0 host controllers (Asmedia and NEC), and four USB 3.0 devices (three of which were previously triggering the issue, and one worked fine). On the Asmedia controller, the patch fixes the regression, but with one of the devices (Areca ARC-5040) I still occasionally get the following messages in the log: Jul 15 12:34:50 ubuntu kernel: [ 1855.902804] usb 4-1: reset SuperSpeed USB device number 2 using xhci_hcd Jul 15 12:34:50 ubuntu kernel: [ 1855.920190] xhci_hcd :03:00.0: xHCI xhci_drop_endpoint called with disabled ep 880423628480 Jul 15 12:34:50 ubuntu kernel: [ 1855.920197] xhci_hcd :03:00.0: xHCI xhci_drop_endpoint called with disabled ep 8804236284c0 These messages appear out of nowhere, seemingly without any cause, usually some time after the device has been plugged in (time varies from 30 sec to 30 min). This worries me a little, because these exact messages were one of the symptoms of the regression. However, the device seems to work fine and remains accessible. Without your patch, such messages were logged every 30 seconds, and the device was not accessible until they stopped. I did not notice any problems with other devices on the Asmedia controller (with the patch), nor with any devices on the NEC controller (with or without the patch). I have not yet tested any other kernel version; I intend to compile and test the newest available kernel tomorrow. Where should I add the "Tested-by" tag? > The patch is up here, I think you should've been CCed on it Indeed I was, the mail got misplaced among other linux-usb messages. Sorry about the confusion. Thanks a lot Maciej Puzio -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/4] usb: gadget: pxa27x_udc: use devm_* helpers
Sergei Shtylyov writes:
> Hello.
>
>> @@ -2524,35 +2518,21 @@ static int pxa_udc_probe(struct platform_device
>> *pdev)
>> pxa_eps_setup(udc);
>>
>> /* irq setup after old hardware state is cleaned up */
>> -retval = request_irq(udc->irq, pxa_udc_irq,
>> -IRQF_SHARED, driver_name, udc);
>> +retval = devm_request_irq(&pdev->dev, udc->irq, pxa_udc_irq,
>> + IRQF_SHARED, driver_name, udc);
>> if (retval != 0) {
>> dev_err(udc->dev, "%s: can't get irq %i, err %d\n",
>> driver_name, udc->irq, retval);
>> -goto err_irq;
>> +return retval;
>
>You forgot clk_unprepare().
Right. As I had said before, I wanted this serie to be the last. And this error
was already present in the previous version.
Therefore, let's drop this patch from the serie, I'll submit it apart. Felipe
let's consider patch 1, 2 and 4 please.
Cheers.
--
Robert
PS: The full rationale of the patch delaying :
There is another legacy problem with the clock which appeared with migration
towards clock infrastructure : preparing the clock is not enough, it should be
enabled as well right from the start, because the clock is fed to the UDC IP,
and without it the registers set up initially are lost.
Of course this problem was discovered because of "clock ignore unused" clocks
framework feature. It doesn't touch this driver yet as PXA is not ported to
clocks framework, yet it must be fixed, hence the delaying of this patch too.
--
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 0/8] usb: add support for the generic PHY framework
On Tue, 15 Jul 2014, Antoine Ténart wrote: > Hi all, > > This is an attempt to add more common USB code aware of the generic PHY > framework, while keeping the compatibility for the USB PHY one. It does > not add the full support, some USB PHY specific functions not being > available currently in the generic PHY subsystem (e.g. usb_phy_set_power()). > But it allows to use the generic PHY framework in other cases, and might > help others to convert their USB PHY drivers. > > A little background: I submitted a series to support USB on Berlin SoCs[1]. > One patch added a new PHY driver in drivers/usb/phy and Felipe asked it to > be in the generic PHY framework instead[2]. This PHY being used by a ChipIdea > driver, changes were needed in ChipIdea, OTG and HCD. > > This is done in 3 steps: > 1. moving the OTG state from the USB PHY structure to the OTG one > 2. renaming the field 'phy' to 'usb_phy' > 3. adding a field for the generic framework PHY and dissociating its >use from the USB PHY one > > Step 1 is in the first patch. Steps 2 and 3 are done for OTG, and ChipIdea > subsystems in patches 2-3 and 7-8. > > HCD generic PHY support was made by Sergei and Yoshihiro[1]. I added some > modifications to make this support consistent with this series in patches > 4-6. > > I tested it by using the ChipIdea driver I introduced, both with an USB PHY > and a PHY driver successfully. I also compiled a multi_v7 kernel (ARM), with > every driver I could enable in the USB section. > > I'd like more people to test and your inputs and suggestions on these changes. > > Feel free to add Ccs if others might be interested in this. If needed patches > can be squashed or divided, I tried there to group modifications by USB > framework parts (OTG, HCD, ChipIdea). > > Patches can also be found at: > git://git.free-electrons.com:users/antoine-tenart/linux.git usb-phy > > The series applies on top of Sergei and Yoshihiro generic PHY support in > HCD[1]. For the changes to hub.c, hcd.c, and the ehci and ohci drivers: Acked-by: Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/8] usb: rename phy to usb_phy in HCD
Hello. On 07/15/2014 06:39 PM, Antoine Ténart wrote: The USB PHY member of the HCD structure is renamed to 'usb_phy' and modifications are done in all drivers accessing it. Signed-off-by: Antoine Ténart I've been thru that and such change has been turned down already. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/12] usb: chipidea: add a generic driver
Hi, On Thu, Jul 03, 2014 at 08:17:34AM +0530, punnaiah choudary kalluri wrote: > Since its a generic driver, support for configuring the dma_mask using > dma_coerce_mask_and_coherent would be good. > Should I add a DMA mask dt property? Or just not add this and wait for someone needing it in his case? Antoine -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/12] usb: chipidea: add a generic driver
Hi guys, On Wed, Jul 02, 2014 at 01:10:00AM +, Peter Chen wrote: > > On 07/01/2014 02:42 PM, Alexandre Belloni wrote: > > > > > Well, there is nothing specific about the Berlin CI. Some > > > subsystems use the 'generic' keyword in these cases. Do you see a > > > particular reason I should use some Berlin related compatible here? > > > > Not must, one suggestion is: can you change the compatible string > > to "chipidea-usb-generic"? > > > > >>> I don't know about ChipIdea/ARC/DW's product portfolio but I guess > > >>> the compatible should also carry '2.0' or 'usb2' in it. Or we just > > >>> use some version number like 'chipidea,ci13000' or 'chipidea,ci13xxx'. > > > > >> The recommended format for compatible string is: > > >> "manufacturer,model", I agree with "chipidea,ci13xxx", thanks. > > > > > I think we should probably avoid using wildcards in the compatible > > > string. > > > > I'm sure wildcards shouldn't be allowed there. :-) > > Then, what's your guys recommend, how about "chipidea,usb2-generic"? So what do you think? "chipidea,ci13", "chipidea,usb2-generic" or something else? I tend to prefer something without the 'generic' keyword. After updating the compatible I'll send a v3 based on USB changes introducing the generic PHY support[1]. [1] https://lkml.org/lkml/2014/7/15/330 Antoine -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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
System freezes when plugging in / resume with USB3 Dock
I have two USB3 Docks (Asus HZ-1 at home, Toshiba Dynadock at office). Every day in the evening I put my laptop (Razer Blade Pro) into sleep with Asus USB dock plugged in. Next day in the morning I unplug the dock (laptop still sleeps) and move to the office where I plug in another USB3 dock (Toshiba). Then I resume the laptop. In the afternoon I do the same while moving home. Until kernel got upgraded to 3.15 I had no problems, since 3.15 my laptop freezes completely with 50% probability while resuming from sleep. Laptop also freezes sometimes when I simply plug the dock into the running system. Milan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] USB: Fix persist resume of some SS USB devices
From: Alan Stern
> On Tue, 15 Jul 2014, Pratyush Anand wrote:
...
> > +static int wait_for_ss_port_enable(struct usb_device *udev,
> > + struct usb_hub *hub,
> > + int *port1,
> > + u16 *portchange,
> > + u16 *portstatus)
>
> Continuation lines should be indented by 2 tab stops, not 5.
>
> > +{
> > + int status, wait_count_20ms = 0;
> > +
> > + while (wait_count_20ms++ < 20) {
> > + status = hub_port_status(hub, *port1, portstatus, portchange);
> > + if (status || *portstatus & USB_PORT_STAT_CONNECTION)
> > + return status;
> > + msleep(20);
> > + }
> > + return hub_port_status(hub, *port1, portstatus, portchange);
> > +}
>
> This might be a little clearer:
>
> int status = 0, delay_ms = 0;
>
> whle (delay_ms < 400) {
> if (status || (*portstatus & USB_PORT_STAT_CONNECTION))
> break;
> msleep(20);
> delay_ms += 20;
> status = hub_port_status(hub, *port1, portstatus, portchange);
> }
> return status;
I think I would write:
for (ms_delay = 0; (ms_delay += 20) <= 400; msleep(20)) {
status = hub_port_status(hub, *port1, portstatus, portchange);
if (status)
return status;
if (*portstatus & USB_PORT_STAT_CONNECTION)
return 0;
}
return 0;
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: [RFC] USB: Fix persist resume of some SS USB devices
On Tue, 15 Jul 2014, Pratyush Anand wrote: > Problem Summary: Problem has been observed generally with PM states > where VBUS goes off during suspend. There are some SS USB devices which > takes slightly longer time for link training compared to many others. > Such devices fails to reconnect with same old address which was > associated with it before suspend. > > When system resumes, at some point of time (dpm_run_callback-> > usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device-> > usb_port_resume) SW reads hub status. If device is present, > then it finishes port resume and re-enumerates device with same > address. If device is not present, then SW thinks that device was > removed during suspend and therefore does logical disconnection > and removes all the resource allocated for this device. > > Now, if I put sufficient delay just before root hub status read in > usb_resume_device then, SW sees always that device is present. In normal > course(without any delay) SW sees that no device is present and then SW > removes all resource associated with the device at this port. In the > latter case, after sometime, device says that hey I am here, now host > enumerates it, but with new address. > > Problem had been reproduced when I connect verbatim USB3.0 hard disc > with my STiH407 XHCI host running with 3.10 kernel. > > I see that similar problem has been reported here. > https://bugzilla.kernel.org/show_bug.cgi?id=53211 > Reading above it seems that bug was not in 3.6.6 and was present in 3.8 > and again it was not present for some in 3.12.6, while it was present for > few others. I tested with 3.13-FC19 with i686 desktop, problem was still > there. However, I was failed to reproduce it with 3.16-RC4 running at > same i686 machine. I would say it is just a random observation. Problem for > few > devices is always there, as I am unable to find a proper fix for the > issue. > > So, now question is what should be the amount of delay as per USB > specification so that host is always able to recognize suspended device > after resume. > > -- XHCI specs 4.19.4 says that when Link training is successful, > port sets CSC bit to 1 (root hub controller says that device is > present). So the delay should be the maximum amount of time from the > moment when host enables VBUS to the moment it is able to perform Link > Training. Unfortunately, I could not find any direct statement in USB > specification for such timeout. Since path from VBUS on to U0 will > follow, like this Rx.Detect.Quite->Rx.Detect.Active->Polling.LFPS-> > Polling.ExEQ->Polling.Active->Polling.Configuration->Polling.Idle->U0, > therefore we can set maximum delay as tRxDetectQuietTimeout (12 ms) + > tPollingLFPSTimeout (360 ms) + tPollingActiveTimeout (12 ms) + > tPollingConfigurationTimeout (12 ms) + tPollingIdleTimeout (2 ms) > (398 =~ 400 ms). > > This patch implements above delay, but only for SS device and when > persist is enabled. After every 10 ms SW reads port status and if it > is enabled, SW exits delay loop. > > So, for the good device overhead is just the time to execute > hub_port_status, while for the bad device penalty could be as long as > 400 mS. > > Results: > > Verbatim USB SS hard disk connected with STiH407 USB host running 3.10 > Kernel resumes in 461 msecs without this patch, but hard disk is > assigned a new device address. Same system resumes in 790 msecs with > this patch, but with old device address. What happens if you unplug the device while the system is asleep and leave it unplugged during resume? > Signed-off-by: Pratyush Anand > --- > drivers/usb/core/hub.c | 37 + > 1 file changed, 37 insertions(+) > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > index 21b99b4..93495b7 100644 > --- a/drivers/usb/core/hub.c > +++ b/drivers/usb/core/hub.c > @@ -3245,6 +3245,39 @@ static int finish_port_resume(struct usb_device *udev) > } > > /* > + * There are some SS USB devices which takes 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 > + * training, then it will not find device to be present. > + * Successful SS link training follows Rx.Detect.Quite->Rx.Detect.Active-> .Quiet? > + * Polling.LFPS->Polling.ExEQ->Polling.Active->Polling.Configuration-> > + * Polling.Idle->U0. > + * Following routine waits for either till port is enable or a timeout > + * of 400 ms whichever is earlier [tRxDetectQuietTimeout (12 ms) + > + * tPollingLFPSTimeout (360 ms) + tPollingActiveTimeout (12 ms) + > + * tPollingConfigurationTimeout (12 ms) + * tPollingIdleTimeout (2 ms)] > + * > + * 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, > + struct usb_hub *hub, > +
[PATCH v2 4/8] usb: rename phy to usb_phy in HCD
The USB PHY member of the HCD structure is renamed to 'usb_phy' and
modifications are done in all drivers accessing it.
Signed-off-by: Antoine Ténart
---
drivers/usb/chipidea/host.c | 2 +-
drivers/usb/core/hcd.c| 20 ++--
drivers/usb/core/hub.c| 8
drivers/usb/host/ehci-fsl.c | 16
drivers/usb/host/ehci-hub.c | 2 +-
drivers/usb/host/ehci-msm.c | 4 ++--
drivers/usb/host/ehci-tegra.c | 16
drivers/usb/host/ohci-omap.c | 20 ++--
include/linux/usb/hcd.h | 2 +-
9 files changed, 45 insertions(+), 45 deletions(-)
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index a93d950e9468..fc7541c906a2 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -59,7 +59,7 @@ static int host_start(struct ci_hdrc *ci)
hcd->has_tt = 1;
hcd->power_budget = ci->platdata->power_budget;
- hcd->phy = ci->transceiver;
+ hcd->usb_phy = ci->transceiver;
ehci = hcd_to_ehci(hcd);
ehci->caps = ci->hw_bank.cap;
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 28411493dd10..f0bfaad62280 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2632,7 +2632,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
int retval;
struct usb_device *rhdev;
- if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->phy) {
+ if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->usb_phy) {
struct usb_phy *phy = usb_get_phy_dev(hcd->self.controller, 0);
if (IS_ERR(phy)) {
@@ -2645,7 +2645,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
usb_put_phy(phy);
return retval;
}
- hcd->phy = phy;
+ hcd->usb_phy = phy;
hcd->remove_phy = 1;
}
}
@@ -2823,10 +2823,10 @@ err_create_buf:
hcd->gen_phy = NULL;
}
err_phy:
- if (hcd->remove_phy && hcd->phy) {
- usb_phy_shutdown(hcd->phy);
- usb_put_phy(hcd->phy);
- hcd->phy = NULL;
+ if (hcd->remove_phy && hcd->usb_phy) {
+ usb_phy_shutdown(hcd->usb_phy);
+ usb_put_phy(hcd->usb_phy);
+ hcd->usb_phy = NULL;
}
return retval;
}
@@ -2906,10 +2906,10 @@ void usb_remove_hcd(struct usb_hcd *hcd)
phy_put(hcd->gen_phy);
hcd->gen_phy = NULL;
}
- if (hcd->remove_phy && hcd->phy) {
- usb_phy_shutdown(hcd->phy);
- usb_put_phy(hcd->phy);
- hcd->phy = NULL;
+ if (hcd->remove_phy && hcd->usb_phy) {
+ usb_phy_shutdown(hcd->usb_phy);
+ usb_put_phy(hcd->usb_phy);
+ hcd->usb_phy = NULL;
}
usb_put_invalidate_rhdev(hcd);
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 21b99b4b4082..cf49c03b74a9 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4379,8 +4379,8 @@ hub_port_init (struct usb_hub *hub, struct usb_device
*udev, int port1,
if (retval)
goto fail;
- if (hcd->phy && !hdev->parent)
- usb_phy_notify_connect(hcd->phy, udev->speed);
+ if (hcd->usb_phy && !hdev->parent)
+ usb_phy_notify_connect(hcd->usb_phy, udev->speed);
/*
* Some superspeed devices have finished the link training process
@@ -4534,9 +4534,9 @@ static void hub_port_connect(struct usb_hub *hub, int
port1, u16 portstatus,
/* Disconnect any existing devices under this port */
if (udev) {
- if (hcd->phy && !hdev->parent &&
+ if (hcd->usb_phy && !hdev->parent &&
!(portstatus & USB_PORT_STAT_CONNECTION))
- usb_phy_notify_disconnect(hcd->phy, udev->speed);
+ usb_phy_notify_disconnect(hcd->usb_phy, udev->speed);
usb_disconnect(&port_dev->child);
}
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index cf2734b532a7..4bdcd3439d47 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -136,15 +136,15 @@ static int usb_hcd_fsl_probe(const struct hc_driver
*driver,
if (pdata->operating_mode == FSL_USB2_DR_OTG) {
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- hcd->phy = usb_get_phy(USB_PHY_TYPE_USB2);
+ hcd->usb_phy = usb_get_phy(USB_PHY_TYPE_USB2);
dev_dbg(&pdev->dev, "hcd=0x%p ehci=0x%p, phy=0x%p\n",
- hcd, ehci, hcd->phy);
+ hcd, ehci, hcd->usb_phy);
- if (!IS_ERR_OR_NULL(hcd->phy)) {
- retval = otg_set_host(hcd->phy->otg,
+ if (!IS_ERR_OR_NULL(hcd->usb_phy)) {
+ retval = otg_se
[PATCH v2 0/8] usb: add support for the generic PHY framework
Hi all, This is an attempt to add more common USB code aware of the generic PHY framework, while keeping the compatibility for the USB PHY one. It does not add the full support, some USB PHY specific functions not being available currently in the generic PHY subsystem (e.g. usb_phy_set_power()). But it allows to use the generic PHY framework in other cases, and might help others to convert their USB PHY drivers. A little background: I submitted a series to support USB on Berlin SoCs[1]. One patch added a new PHY driver in drivers/usb/phy and Felipe asked it to be in the generic PHY framework instead[2]. This PHY being used by a ChipIdea driver, changes were needed in ChipIdea, OTG and HCD. This is done in 3 steps: 1. moving the OTG state from the USB PHY structure to the OTG one 2. renaming the field 'phy' to 'usb_phy' 3. adding a field for the generic framework PHY and dissociating its use from the USB PHY one Step 1 is in the first patch. Steps 2 and 3 are done for OTG, and ChipIdea subsystems in patches 2-3 and 7-8. HCD generic PHY support was made by Sergei and Yoshihiro[1]. I added some modifications to make this support consistent with this series in patches 4-6. I tested it by using the ChipIdea driver I introduced, both with an USB PHY and a PHY driver successfully. I also compiled a multi_v7 kernel (ARM), with every driver I could enable in the USB section. I'd like more people to test and your inputs and suggestions on these changes. Feel free to add Ccs if others might be interested in this. If needed patches can be squashed or divided, I tried there to group modifications by USB framework parts (OTG, HCD, ChipIdea). Patches can also be found at: git://git.free-electrons.com:users/antoine-tenart/linux.git usb-phy The series applies on top of Sergei and Yoshihiro generic PHY support in HCD[1]. Thanks a lot! Antoine Changes since v1: - rebased the series on top of [1] (generic PHY support for HCD) - split s/phy/usb_phy/ renaming and generic PHY support in separate patches [1] https://www.mail-archive.com/linux-usb@vger.kernel.org/msg43471.html Antoine Ténart (8): usb: move the OTG state from the USB PHY to the OTG structure usb: rename phy to usb_phy in OTG usb: add support to the generic PHY framework in OTG usb: rename phy to usb_phy in HCD usb: rename gen_phy to phy in HCD usb: allow to supply the PHY in the drivers when using HCD usb: rename transceiver and phy to usb_phy in ChipIdea usb: chipidea: add support to the generic PHY framework in ChipIdea drivers/phy/phy-omap-usb2.c | 14 ++ drivers/usb/chipidea/ci.h | 7 ++- drivers/usb/chipidea/ci_hdrc_imx.c | 2 +- drivers/usb/chipidea/ci_hdrc_msm.c | 8 ++-- drivers/usb/chipidea/core.c | 71 ++- drivers/usb/chipidea/debug.c| 5 +- drivers/usb/chipidea/host.c | 18 --- drivers/usb/chipidea/otg_fsm.c | 18 +++ drivers/usb/chipidea/udc.c | 4 +- drivers/usb/common/usb-otg-fsm.c| 8 ++-- drivers/usb/core/hcd.c | 45 +- drivers/usb/core/hub.c | 8 ++-- drivers/usb/host/ehci-fsl.c | 16 +++ drivers/usb/host/ehci-hub.c | 2 +- drivers/usb/host/ehci-msm.c | 4 +- drivers/usb/host/ehci-tegra.c | 16 +++ drivers/usb/host/ohci-omap.c| 20 drivers/usb/musb/am35x.c| 28 +-- drivers/usb/musb/blackfin.c | 18 +++ drivers/usb/musb/da8xx.c| 28 +-- drivers/usb/musb/davinci.c | 18 +++ drivers/usb/musb/musb_core.c| 94 ++-- drivers/usb/musb/musb_dsps.c| 26 +- drivers/usb/musb/musb_gadget.c | 36 +++--- drivers/usb/musb/musb_host.c| 8 ++-- drivers/usb/musb/musb_virthub.c | 22 - drivers/usb/musb/omap2430.c | 30 ++-- drivers/usb/musb/tusb6010.c | 40 drivers/usb/musb/ux500.c| 10 ++-- drivers/usb/phy/phy-ab8500-usb.c| 16 +++ drivers/usb/phy/phy-fsl-usb.c | 23 - drivers/usb/phy/phy-generic.c | 6 +-- drivers/usb/phy/phy-gpio-vbus-usb.c | 12 ++--- drivers/usb/phy/phy-isp1301-omap.c | 10 ++-- drivers/usb/phy/phy-msm-usb.c | 95 +++-- drivers/usb/phy/phy-mv-usb.c| 50 +-- drivers/usb/phy/phy-samsung-usb2.c | 2 +- drivers/usb/phy/phy-tahvo.c | 8 ++-- drivers/usb/phy/phy-ulpi.c | 6 +-- include/linux/usb/chipidea.h| 4 +- include/linux/usb/hcd.h | 6 ++- include/linux/usb/otg.h | 7 ++- include/linux/usb/phy.h | 1 - 43 files changed, 469 insertions(+), 401 deletions(-) -- 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 M
[PATCH v2 6/8] usb: allow to supply the PHY in the drivers when using HCD
This patch modify the generic code handling PHYs to allow them to be
supplied from the drivers. This adds checks to ensure no PHY was already
there when looking for one in the generic code. This also makes sure we
do not modify its state in the generic HCD functions, it it was
provided by the driver.
Signed-off-by: Antoine Ténart
---
drivers/usb/core/hcd.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 228bad89f09b..ce9ea309ab0f 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2650,7 +2650,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
}
}
- if (IS_ENABLED(CONFIG_GENERIC_PHY)) {
+ if (IS_ENABLED(CONFIG_GENERIC_PHY) && !hcd->phy) {
struct phy *phy = phy_get(hcd->self.controller, "usb");
if (IS_ERR(phy)) {
@@ -2670,6 +2670,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
goto err_phy;
}
hcd->phy = phy;
+ hcd->remove_phy = 1;
}
}
@@ -2816,7 +2817,7 @@ err_allocate_root_hub:
err_register_bus:
hcd_buffer_destroy(hcd);
err_create_buf:
- if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->phy) {
+ if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->remove_phy && hcd->phy) {
phy_power_off(hcd->phy);
phy_exit(hcd->phy);
phy_put(hcd->phy);
@@ -2900,7 +2901,7 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_deregister_bus(&hcd->self);
hcd_buffer_destroy(hcd);
- if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->phy) {
+ if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->remove_phy && hcd->phy) {
phy_power_off(hcd->phy);
phy_exit(hcd->phy);
phy_put(hcd->phy);
--
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
[PATCH v2 2/8] usb: rename phy to usb_phy in OTG
This patch prepares the introduction of the generic PHY support in the
USB OTG common functions. The USB PHY member of the OTG structure is
renamed to 'usb_phy' and modifications are done in all drivers accessing
it. Renaming this pointer will allow to keep the compatibility for USB
PHY drivers.
Signed-off-by: Antoine Ténart
---
drivers/phy/phy-omap-usb2.c | 6 ++--
drivers/usb/chipidea/otg_fsm.c | 2 +-
drivers/usb/phy/phy-ab8500-usb.c| 6 ++--
drivers/usb/phy/phy-fsl-usb.c | 13
drivers/usb/phy/phy-generic.c | 2 +-
drivers/usb/phy/phy-gpio-vbus-usb.c | 2 +-
drivers/usb/phy/phy-isp1301-omap.c | 10 +++---
drivers/usb/phy/phy-msm-usb.c | 61 +++--
drivers/usb/phy/phy-mv-usb.c| 4 +--
drivers/usb/phy/phy-samsung-usb2.c | 2 +-
drivers/usb/phy/phy-tahvo.c | 8 +++--
drivers/usb/phy/phy-ulpi.c | 6 ++--
include/linux/usb/otg.h | 2 +-
13 files changed, 65 insertions(+), 59 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 32a703ce7a85..0a78fbbdf764 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -60,7 +60,7 @@ EXPORT_SYMBOL_GPL(omap_usb2_set_comparator);
static int omap_usb_set_vbus(struct usb_otg *otg, bool enabled)
{
- struct omap_usb *phy = phy_to_omapusb(otg->phy);
+ struct omap_usb *phy = phy_to_omapusb(otg->usb_phy);
if (!phy->comparator)
return -ENODEV;
@@ -70,7 +70,7 @@ static int omap_usb_set_vbus(struct usb_otg *otg, bool
enabled)
static int omap_usb_start_srp(struct usb_otg *otg)
{
- struct omap_usb *phy = phy_to_omapusb(otg->phy);
+ struct omap_usb *phy = phy_to_omapusb(otg->usb_phy);
if (!phy->comparator)
return -ENODEV;
@@ -255,7 +255,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
otg->set_vbus = omap_usb_set_vbus;
if (phy_data->flags & OMAP_USB2_HAS_START_SRP)
otg->start_srp = omap_usb_start_srp;
- otg->phy= &phy->phy;
+ otg->usb_phy= &phy->phy;
platform_set_drvdata(pdev, phy);
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 8cb2508a6b71..d8490e758a74 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -788,7 +788,7 @@ int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
return -ENOMEM;
}
- otg->phy = ci->transceiver;
+ otg->usb_phy = ci->transceiver;
otg->gadget = &ci->gadget;
ci->fsm.otg = otg;
ci->transceiver->otg = ci->fsm.otg;
diff --git a/drivers/usb/phy/phy-ab8500-usb.c b/drivers/usb/phy/phy-ab8500-usb.c
index 2d5250143ce1..3a802fa7dae2 100644
--- a/drivers/usb/phy/phy-ab8500-usb.c
+++ b/drivers/usb/phy/phy-ab8500-usb.c
@@ -1056,7 +1056,7 @@ static int ab8500_usb_set_peripheral(struct usb_otg *otg,
if (!otg)
return -ENODEV;
- ab = phy_to_ab(otg->phy);
+ ab = phy_to_ab(otg->usb_phy);
ab->phy.otg->gadget = gadget;
@@ -1080,7 +1080,7 @@ static int ab8500_usb_set_host(struct usb_otg *otg,
struct usb_bus *host)
if (!otg)
return -ENODEV;
- ab = phy_to_ab(otg->phy);
+ ab = phy_to_ab(otg->usb_phy);
ab->phy.otg->host = host;
@@ -1382,7 +1382,7 @@ static int ab8500_usb_probe(struct platform_device *pdev)
ab->phy.set_power = ab8500_usb_set_power;
ab->phy.otg->state = OTG_STATE_UNDEFINED;
- otg->phy= &ab->phy;
+ otg->usb_phy= &ab->phy;
otg->set_host = ab8500_usb_set_host;
otg->set_peripheral = ab8500_usb_set_peripheral;
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index a22f88fb8176..b4cc341094ac 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -499,7 +499,8 @@ int fsl_otg_start_host(struct otg_fsm *fsm, int on)
{
struct usb_otg *otg = fsm->otg;
struct device *dev;
- struct fsl_otg *otg_dev = container_of(otg->phy, struct fsl_otg, phy);
+ struct fsl_otg *otg_dev =
+ container_of(otg->usb_phy, struct fsl_otg, phy);
u32 retval = 0;
if (!otg->host)
@@ -594,7 +595,7 @@ static int fsl_otg_set_host(struct usb_otg *otg, struct
usb_bus *host)
if (!otg)
return -ENODEV;
- otg_dev = container_of(otg->phy, struct fsl_otg, phy);
+ otg_dev = container_of(otg->usb_phy, struct fsl_otg, phy);
if (otg_dev != fsl_otg_dev)
return -ENODEV;
@@ -644,7 +645,7 @@ static int fsl_otg_set_peripheral(struct usb_otg *otg,
if (!otg)
return -ENODEV;
- otg_dev = container_of(otg->phy, struct fsl_otg, phy);
+ otg_dev = container_of(otg->usb_phy, struct fsl_otg, phy);
VDBG("otg_dev
[PATCH v2 5/8] usb: rename gen_phy to phy in HCD
The patch adding support to the generic PHY framework introduced a
'gen_phy' member in the HCD structure. Rename it to 'phy' to have a
consistent USB framework.
Signed-off-by: Antoine Ténart
---
drivers/usb/core/hcd.c | 22 +++---
include/linux/usb/hcd.h | 4 +++-
2 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index f0bfaad62280..228bad89f09b 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2669,7 +2669,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
phy_put(phy);
goto err_phy;
}
- hcd->gen_phy = phy;
+ hcd->phy = phy;
}
}
@@ -2816,11 +2816,11 @@ err_allocate_root_hub:
err_register_bus:
hcd_buffer_destroy(hcd);
err_create_buf:
- if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->gen_phy) {
- phy_power_off(hcd->gen_phy);
- phy_exit(hcd->gen_phy);
- phy_put(hcd->gen_phy);
- hcd->gen_phy = NULL;
+ if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->phy) {
+ phy_power_off(hcd->phy);
+ phy_exit(hcd->phy);
+ phy_put(hcd->phy);
+ hcd->phy = NULL;
}
err_phy:
if (hcd->remove_phy && hcd->usb_phy) {
@@ -2900,11 +2900,11 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_deregister_bus(&hcd->self);
hcd_buffer_destroy(hcd);
- if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->gen_phy) {
- phy_power_off(hcd->gen_phy);
- phy_exit(hcd->gen_phy);
- phy_put(hcd->gen_phy);
- hcd->gen_phy = NULL;
+ if (IS_ENABLED(CONFIG_GENERIC_PHY) && hcd->phy) {
+ phy_power_off(hcd->phy);
+ phy_exit(hcd->phy);
+ phy_put(hcd->phy);
+ hcd->phy = NULL;
}
if (hcd->remove_phy && hcd->usb_phy) {
usb_phy_shutdown(hcd->usb_phy);
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 604d2e6e0c1c..19b3fbd1f9e1 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -105,9 +105,11 @@ struct usb_hcd {
/*
* OTG and some Host controllers need software interaction with phys;
* other external phys should be software-transparent
+*
+* Keep the usb_phy for compatibility reasons, for now
*/
struct usb_phy *usb_phy;
- struct phy *gen_phy;
+ struct phy *phy;
/* Flags that need to be manipulated atomically because they can
* change while the host controller is running. Always use
--
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
[PATCH v2 8/8] usb: chipidea: add support to the generic PHY framework in ChipIdea
This patch adds support of the PHY framework for ChipIdea drivers.
Changes are done in both the ChipIdea common code and in the drivers
accessing the PHY. This is done by adding a new PHY member in
ChipIdea's structures and by taking care of it in the code.
Signed-off-by: Antoine Ténart
---
drivers/usb/chipidea/ci.h | 5 ++-
drivers/usb/chipidea/core.c| 71 ++
drivers/usb/chipidea/debug.c | 4 ++-
drivers/usb/chipidea/host.c| 18 +++
drivers/usb/chipidea/otg_fsm.c | 6 ++--
include/linux/usb/chipidea.h | 2 ++
6 files changed, 83 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index b2caa1772712..f219588f4ce6 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -161,7 +161,8 @@ struct hw_bank {
* @test_mode: the selected test mode
* @platdata: platform specific information supplied by parent device
* @vbus_active: is VBUS active
- * @usb_phy: pointer to USB PHY, if any
+ * @phy: pointer to PHY, if any
+ * @usb_phy: pointer to USB PHY, if any and if using the USB PHY framework
* @hcd: pointer to usb_hcd for ehci host driver
* @debugfs: root dentry for this controller in debugfs
* @id_event: indicates there is an id event, and handled at ci_otg_work
@@ -201,6 +202,8 @@ struct ci_hdrc {
struct ci_hdrc_platform_data*platdata;
int vbus_active;
+ struct phy *phy;
+ /* old usb_phy interface */
struct usb_phy *usb_phy;
struct usb_hcd *hcd;
struct dentry *debugfs;
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index a8cd35fd8175..28bcefcdbd9a 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -293,6 +294,46 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
}
/**
+ * _ci_usb_phy_init: initialize phy taking in account both phy and usb_phy
+ * interfaces
+ * @ci: the controller
+ *
+ * This function returns an error code if the phy failed to init
+ */
+static int _ci_usb_phy_init(struct ci_hdrc *ci)
+{
+ int ret;
+
+ if (ci->phy) {
+ ret = phy_init(ci->phy);
+ if (ret) {
+ phy_exit(ci->phy);
+ return ret;
+ }
+ ret = phy_power_on(ci->phy);
+ } else {
+ ret = usb_phy_init(ci->usb_phy);
+ }
+
+ return ret;
+}
+
+/**
+ * _ci_usb_phy_exit: deinitialize phy taking in account both phy and usb_phy
+ * interfaces
+ * @ci: the controller
+ */
+static void ci_usb_phy_exit(struct ci_hdrc *ci)
+{
+ if (ci->phy) {
+ phy_power_off(ci->phy);
+ phy_exit(ci->phy);
+ } else {
+ usb_phy_shutdown(ci->usb_phy);
+ }
+}
+
+/**
* ci_usb_phy_init: initialize phy according to different phy type
* @ci: the controller
*
@@ -306,7 +347,7 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
case USBPHY_INTERFACE_MODE_UTMI:
case USBPHY_INTERFACE_MODE_UTMIW:
case USBPHY_INTERFACE_MODE_HSIC:
- ret = usb_phy_init(ci->usb_phy);
+ ret = _ci_usb_phy_init(ci);
if (ret)
return ret;
hw_phymode_configure(ci);
@@ -314,12 +355,12 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
case USBPHY_INTERFACE_MODE_ULPI:
case USBPHY_INTERFACE_MODE_SERIAL:
hw_phymode_configure(ci);
- ret = usb_phy_init(ci->usb_phy);
+ ret = _ci_usb_phy_init(ci);
if (ret)
return ret;
break;
default:
- ret = usb_phy_init(ci->usb_phy);
+ ret = _ci_usb_phy_init(ci);
}
return ret;
@@ -595,23 +636,27 @@ static int ci_hdrc_probe(struct platform_device *pdev)
return -ENODEV;
}
- if (ci->platdata->usb_phy)
+ if (ci->platdata->phy)
+ ci->phy = ci->platdata->phy;
+ else if (ci->platdata->usb_phy)
ci->usb_phy = ci->platdata->usb_phy;
else
- ci->usb_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ ci->phy = of_phy_get(dev->of_node, 0);
- if (IS_ERR(ci->usb_phy)) {
- ret = PTR_ERR(ci->usb_phy);
+ if (IS_ERR(ci->phy)) {
/*
* if -ENXIO is returned, it means PHY layer wasn't
* enabled, so it makes no sense to return -EPROBE_DEFER
* in that case, since no PHY driver will ever probe.
*/
- if (ret == -ENXIO)
- return ret;
+ if (PTR_ERR(ci->phy) == -ENXIO)
+ return -ENXIO;
-
[PATCH v2 7/8] usb: rename transceiver and phy to usb_phy in ChipIdea
This patch prepares the introduction of the generic PHY support in the
USB ChipIdea common functions. The USB PHY member of the ChipIdea
structure ('transceiver') is renamed to 'usb_phy', the 'phy' member of
the ChipIdea pdata structure is renamed to 'usb_phy' and modifications
are done in all drivers accessing it. Renaming this pointer will allow
to keep the compatibility for USB PHY drivers.
Signed-off-by: Antoine Ténart
---
drivers/usb/chipidea/ci.h | 4 ++--
drivers/usb/chipidea/ci_hdrc_imx.c | 2 +-
drivers/usb/chipidea/ci_hdrc_msm.c | 8
drivers/usb/chipidea/core.c| 20 ++--
drivers/usb/chipidea/debug.c | 2 +-
drivers/usb/chipidea/host.c| 4 ++--
drivers/usb/chipidea/otg_fsm.c | 4 ++--
drivers/usb/chipidea/udc.c | 4 ++--
include/linux/usb/chipidea.h | 2 +-
9 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 9563cb56d564..b2caa1772712 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -161,7 +161,7 @@ struct hw_bank {
* @test_mode: the selected test mode
* @platdata: platform specific information supplied by parent device
* @vbus_active: is VBUS active
- * @transceiver: pointer to USB PHY, if any
+ * @usb_phy: pointer to USB PHY, if any
* @hcd: pointer to usb_hcd for ehci host driver
* @debugfs: root dentry for this controller in debugfs
* @id_event: indicates there is an id event, and handled at ci_otg_work
@@ -201,7 +201,7 @@ struct ci_hdrc {
struct ci_hdrc_platform_data*platdata;
int vbus_active;
- struct usb_phy *transceiver;
+ struct usb_phy *usb_phy;
struct usb_hcd *hcd;
struct dentry *debugfs;
boolid_event;
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 2e58f8dfd311..33b982dddac5 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -136,7 +136,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
goto err_clk;
}
- pdata.phy = data->phy;
+ pdata.usb_phy = data->phy;
if (imx_platform_flag->flags & CI_HDRC_IMX_IMX28_WRITE_FIX)
pdata.flags |= CI_HDRC_IMX28_WRITE_FIX;
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index d72b9d2de2c5..94cd7c3e12a3 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -31,13 +31,13 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci,
unsigned event)
case CI_HDRC_CONTROLLER_STOPPED_EVENT:
dev_dbg(dev, "CI_HDRC_CONTROLLER_STOPPED_EVENT received\n");
/*
-* Put the transceiver in non-driving mode. Otherwise host
+* Put the phy in non-driving mode. Otherwise host
* may not detect soft-disconnection.
*/
- val = usb_phy_io_read(ci->transceiver, ULPI_FUNC_CTRL);
+ val = usb_phy_io_read(ci->usb_phy, ULPI_FUNC_CTRL);
val &= ~ULPI_FUNC_CTRL_OPMODE_MASK;
val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
- usb_phy_io_write(ci->transceiver, val, ULPI_FUNC_CTRL);
+ usb_phy_io_write(ci->usb_phy, val, ULPI_FUNC_CTRL);
break;
default:
dev_dbg(dev, "unknown ci_hdrc event\n");
@@ -71,7 +71,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
if (IS_ERR(phy))
return PTR_ERR(phy);
- ci_hdrc_msm_platdata.phy = phy;
+ ci_hdrc_msm_platdata.usb_phy = phy;
plat_ci = ci_hdrc_add_device(&pdev->dev,
pdev->resource, pdev->num_resources,
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 619d13e29995..a8cd35fd8175 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -306,7 +306,7 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
case USBPHY_INTERFACE_MODE_UTMI:
case USBPHY_INTERFACE_MODE_UTMIW:
case USBPHY_INTERFACE_MODE_HSIC:
- ret = usb_phy_init(ci->transceiver);
+ ret = usb_phy_init(ci->usb_phy);
if (ret)
return ret;
hw_phymode_configure(ci);
@@ -314,12 +314,12 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
case USBPHY_INTERFACE_MODE_ULPI:
case USBPHY_INTERFACE_MODE_SERIAL:
hw_phymode_configure(ci);
- ret = usb_phy_init(ci->transceiver);
+ ret = usb_phy_init(ci->usb_phy);
if (ret)
return ret;
break;
default:
- ret = usb_phy_init(ci->transceiver);
+ ret = usb_phy_init(
[PATCH v2 3/8] usb: add support to the generic PHY framework in OTG
This patch adds support of the PHY framework in OTG and keeps the USB
PHY compatibility. Here the only modification is to add PHY member in
the OTG structure, along with the USB PHY one.
Signed-off-by: Antoine Ténart
---
include/linux/usb/otg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 978fbbb0e266..52661c5da690 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -9,11 +9,14 @@
#ifndef __LINUX_USB_OTG_H
#define __LINUX_USB_OTG_H
+#include
#include
struct usb_otg {
u8 default_a;
+ struct phy *phy;
+ /* old usb_phy interface */
struct usb_phy *usb_phy;
struct usb_bus *host;
struct usb_gadget *gadget;
--
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: disable VBUS?
On Mon, 14 Jul 2014, Grant wrote: > >> >> I should have been more specific then. I think I understand, but to > >> >> be sure, if I splice a USB cable, power VBUS with an external 5V power > >> >> supply, and connect a host and device, the device will work as if the > >> >> cable was connected to the host normally? > >> > > >> > Yes. But why do you want to do this? > >> > >> > >> My application calls for low noise so I'm hoping to feed a clean 5V > >> from a battery. > > > > Okay. Not much you can do about noise on the USB data lines, though. > > > Any ideas for minimizing that are most welcome. I suppose you could use a low-pass filter, with a cutoff frequency depending on the speed of the connection. How effective this would be is questionable, especially for high-speed (480 Mb/s) connections. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] usb: Check if port status is equal to RxDetect
On Fri, 11 Jul 2014, Gavin Guo wrote:
> When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller
> [1022:7814], the second hotplugging will experience the USB 3.0 pen
> drive is recognized as high-speed device. After bisecting the kernel,
> I found the commit number 41e7e056cdc662f704fa9262e5c6e213b4ab45dd
> (USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing
> some experiments, the bug can be fixed by avoiding executing the function
> hub_usb3_port_disable(). Because the port status with [AMD] FCH USB
> XHCI Controlleris [1022:7814] is already in RxDetect
> (I tried printing out the port status before setting to Disabled state),
> it's reasonable to check the port status before really executing
> hub_usb3_port_disable().
This seems like a race. Even if the port isn't in RxDetect when you
check it, it could switch to RxDetect before the kernel sets it to
Disabled.
But maybe this is the best we can do.
> Fixes: 41e7e056cdc6 (USB: Allow USB 3.0 ports to be disabled.)
> Signed-off-by: Gavin Guo
> ---
> drivers/usb/core/hub.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 21b99b4..e02ab62 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -889,6 +889,25 @@ static int hub_usb3_port_disable(struct usb_hub *hub,
> int port1)
> if (!hub_is_superspeed(hub->hdev))
> return -EINVAL;
>
> + ret = hub_port_status(hub, port1, &portstatus, &portchange);
> + if (ret < 0)
> + return ret;
> +
> + /*
> + * USB controller Advanced Micro Devices,
> + * Inc. [AMD] FCH USB XHCI Controller [1022:7814] will have spurious
> result
> + * making the following usb 3.0 device hotplugging route to the 2.0
> root hub
> + * and recognized as high-speed device if we set the usb 3.0 port link
> state
> + * to Disabled. Since it's already in USB_SS_PORT_LS_RX_DETECT state,
> we
> + * check the state here to avoid the bug.
> + */
Comments should not extend beyond column 80. And there should be only
one space, not two, after the '*' in the 6th and 7th lines.
> + if ((portstatus & USB_PORT_STAT_LINK_STATE) ==
> + USB_SS_PORT_LS_RX_DETECT) {
> + dev_dbg(&hub->ports[port1 - 1]->dev,
> + "The link state is already in
> USB_SS_PORT_LS_RX_DETECT\n");
This message does not explain what has happened. It should say
something like "Not disabling port; link state is RxDetect".
> + return ret;
> + }
> +
> ret = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_SS_DISABLED);
> if (ret)
> return ret;
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: gadget: composite: dequeue cdev->req before free it in composite_dev_cleanup
This patch try to dequeue the cdev->req to guarantee the request is not queued
before free it.
Signed-off-by: Li Jun
---
drivers/usb/gadget/composite.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index f801519..6935a82 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1956,6 +1956,7 @@ void composite_dev_cleanup(struct usb_composite_dev *cdev)
}
if (cdev->req) {
kfree(cdev->req->buf);
+ usb_ep_dequeue(cdev->gadget->ep0, cdev->req);
usb_ep_free_request(cdev->gadget->ep0, cdev->req);
}
cdev->next_string_id = 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: fix the sequence modules are built
If gadget g_*.ko modules are built-in their initialization happens before libcomposite is initialized. This results in e.g. g_ether not initializing if compiled-in. This patch fixes the order modules are built, so that they are initialized in proper order when built-in. Signed-off-by: Andrzej Pietrasiewicz --- @Felipe: I'm also sending a v4 series which corrects this problem from the beginning (unlike this patch which fixes things afterwards) so that you can choose which fits better. drivers/usb/gadget/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 319500f..4fdac2f 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -5,7 +5,8 @@ subdir-ccflags-$(CONFIG_USB_GADGET_DEBUG) := -DDEBUG subdir-ccflags-$(CONFIG_USB_GADGET_VERBOSE)+= -DVERBOSE_DEBUG ccflags-y += -I$(PWD)/drivers/usb/gadget/udc -obj-$(CONFIG_USB_GADGET) += legacy/ udc/ function/ obj-$(CONFIG_USB_LIBCOMPOSITE) += libcomposite.o libcomposite-y := usbstring.o config.o epautoconf.o libcomposite-y += composite.o functions.o configfs.o u_f.o + +obj-$(CONFIG_USB_GADGET) += udc/ function/ legacy/ -- 1.8.3.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
[PATCHv4 0/3] Gadget directory cleanup
This is a follow-up to this thread: http://www.spinics.net/lists/linux-usb/msg107611.html The cleanup rearranges the way source code files are located in the drivers/usb/gadget directory. New subdirectories are introduced: - "udc" for UDC chip drivers - "function" for actual usb functions' implementations - "legacy" for gadgets compiled as statically composed modules while at the gadget's root level there are files related to the composite framework. These are the reasons for doing such a change: - there are ~130 source code files already in a clean tree - when all gadgets and some udc drivers are built as modules then, including the by-products of the build (*.o, *.ko, *.mod.c, .*.cmd), the number easily grows to ~500 files - files serving different purpose (udc chip drivers, actual gadget functions' implementations, legacy gadgets) are located side-by-side which might cause confusion - gadget's Kconfig and Makefile tend to be lengthy. After the patches are applied the gadget subdirectory looks much cleaner. Rebased onto Felipe's testing/next. v3..v4: changed the sequence modules are built so that for example g_ether is not initialized before libcomposite and functions if compiled-in Andrzej Pietrasiewicz (3): usb: gadget: Gadget directory cleanup - group legacy gadgets usb: gadget: Gadget directory cleanup - group UDC drivers usb: gadget: Gadget directory cleanup - group usb functions drivers/usb/gadget/Kconfig | 832 +- drivers/usb/gadget/Makefile| 101 +- drivers/usb/gadget/acm_ms.c| 274 -- drivers/usb/gadget/amd5536udc.c| 3366 - drivers/usb/gadget/amd5536udc.h| 617 drivers/usb/gadget/at91_udc.c | 1985 drivers/usb/gadget/at91_udc.h | 169 -- drivers/usb/gadget/atmel_usba_udc.c| 2133 - drivers/usb/gadget/atmel_usba_udc.h| 354 --- drivers/usb/gadget/audio.c | 180 -- drivers/usb/gadget/bcm63xx_udc.c | 2436 --- drivers/usb/gadget/cdc2.c | 238 -- drivers/usb/gadget/dbgp.c | 434 --- drivers/usb/gadget/dummy_hcd.c | 2764 - drivers/usb/gadget/ether.c | 482 --- drivers/usb/gadget/f_acm.c | 848 -- drivers/usb/gadget/f_ecm.c | 973 -- drivers/usb/gadget/f_eem.c | 660 drivers/usb/gadget/f_fs.c | 3347 - drivers/usb/gadget/f_hid.c | 763 - drivers/usb/gadget/f_loopback.c| 571 drivers/usb/gadget/f_mass_storage.c| 3668 --- drivers/usb/gadget/f_mass_storage.h| 166 - drivers/usb/gadget/f_midi.c| 986 -- drivers/usb/gadget/f_ncm.c | 1622 -- drivers/usb/gadget/f_obex.c| 533 drivers/usb/gadget/f_phonet.c | 758 - drivers/usb/gadget/f_rndis.c | 1029 --- drivers/usb/gadget/f_serial.c | 385 --- drivers/usb/gadget/f_sourcesink.c | 1247 drivers/usb/gadget/f_subset.c | 519 drivers/usb/gadget/f_uac1.c| 768 - drivers/usb/gadget/f_uac2.c| 1354 - drivers/usb/gadget/f_uvc.c | 836 -- drivers/usb/gadget/f_uvc.h | 27 - drivers/usb/gadget/fotg210-udc.c | 1216 drivers/usb/gadget/fotg210.h | 253 -- drivers/usb/gadget/fsl_mxc_udc.c | 123 - drivers/usb/gadget/fsl_qe_udc.c| 2731 - drivers/usb/gadget/fsl_qe_udc.h| 421 --- drivers/usb/gadget/fsl_udc_core.c | 2682 - drivers/usb/gadget/fsl_usb2_udc.h | 611 drivers/usb/gadget/function/Makefile | 34 + drivers/usb/gadget/function/f_acm.c| 848 ++ drivers/usb/gadget/function/f_ecm.c| 973 ++ drivers/usb/gadget/function/f_eem.c| 660 drivers/usb/gadget/function/f_fs.c | 3347 + drivers/usb/gadget/function/f_hid.c| 763 + drivers/usb/gadget/function/f_loopback.c | 571 drivers/usb/gadget/function/f_mass_storage.c | 3668 +++ drivers/usb/gadget/function/f_mass_storage.h | 166 + drivers/usb/gadget/function/f_midi.c | 986 ++ drivers/usb/gadget/function/f_ncm.c| 1622 ++ drivers/usb/gadget/function/f_obex.c | 533 drivers/usb/gadget/function/f_phonet.c | 758 + drivers/usb/gadget/function/f_rndis.c | 1029 +++ drivers/usb/gadget/function/f_se
[RFC] USB: Fix persist resume of some SS USB devices
Problem Summary: Problem has been observed generally with PM states
where VBUS goes off during suspend. There are some SS USB devices which
takes slightly longer time for link training compared to many others.
Such devices fails to reconnect with same old address which was
associated with it before suspend.
When system resumes, at some point of time (dpm_run_callback->
usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device->
usb_port_resume) SW reads hub status. If device is present,
then it finishes port resume and re-enumerates device with same
address. If device is not present, then SW thinks that device was
removed during suspend and therefore does logical disconnection
and removes all the resource allocated for this device.
Now, if I put sufficient delay just before root hub status read in
usb_resume_device then, SW sees always that device is present. In normal
course(without any delay) SW sees that no device is present and then SW
removes all resource associated with the device at this port. In the
latter case, after sometime, device says that hey I am here, now host
enumerates it, but with new address.
Problem had been reproduced when I connect verbatim USB3.0 hard disc
with my STiH407 XHCI host running with 3.10 kernel.
I see that similar problem has been reported here.
https://bugzilla.kernel.org/show_bug.cgi?id=53211
Reading above it seems that bug was not in 3.6.6 and was present in 3.8
and again it was not present for some in 3.12.6, while it was present for
few others. I tested with 3.13-FC19 with i686 desktop, problem was still
there. However, I was failed to reproduce it with 3.16-RC4 running at
same i686 machine. I would say it is just a random observation. Problem for few
devices is always there, as I am unable to find a proper fix for the
issue.
So, now question is what should be the amount of delay as per USB
specification so that host is always able to recognize suspended device
after resume.
-- XHCI specs 4.19.4 says that when Link training is successful,
port sets CSC bit to 1 (root hub controller says that device is
present). So the delay should be the maximum amount of time from the
moment when host enables VBUS to the moment it is able to perform Link
Training. Unfortunately, I could not find any direct statement in USB
specification for such timeout. Since path from VBUS on to U0 will
follow, like this Rx.Detect.Quite->Rx.Detect.Active->Polling.LFPS->
Polling.ExEQ->Polling.Active->Polling.Configuration->Polling.Idle->U0,
therefore we can set maximum delay as tRxDetectQuietTimeout (12 ms) +
tPollingLFPSTimeout (360 ms) + tPollingActiveTimeout (12 ms) +
tPollingConfigurationTimeout (12 ms) + tPollingIdleTimeout (2 ms)
(398 =~ 400 ms).
This patch implements above delay, but only for SS device and when
persist is enabled. After every 10 ms SW reads port status and if it
is enabled, SW exits delay loop.
So, for the good device overhead is just the time to execute
hub_port_status, while for the bad device penalty could be as long as
400 mS.
Results:
Verbatim USB SS hard disk connected with STiH407 USB host running 3.10
Kernel resumes in 461 msecs without this patch, but hard disk is
assigned a new device address. Same system resumes in 790 msecs with
this patch, but with old device address.
Signed-off-by: Pratyush Anand
---
drivers/usb/core/hub.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 21b99b4..93495b7 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3245,6 +3245,39 @@ static int finish_port_resume(struct usb_device *udev)
}
/*
+ * There are some SS USB devices which takes 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
+ * training, then it will not find device to be present.
+ * Successful SS link training follows Rx.Detect.Quite->Rx.Detect.Active->
+ * Polling.LFPS->Polling.ExEQ->Polling.Active->Polling.Configuration->
+ * Polling.Idle->U0.
+ * Following routine waits for either till port is enable or a timeout
+ * of 400 ms whichever is earlier [tRxDetectQuietTimeout (12 ms) +
+ * tPollingLFPSTimeout (360 ms) + tPollingActiveTimeout (12 ms) +
+ * tPollingConfigurationTimeout (12 ms) + * tPollingIdleTimeout (2 ms)]
+ *
+ * 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,
+ struct usb_hub *hub,
+ int *port1,
+ u16 *portchange,
+ u16 *portstatus)
+{
+ int status, wait_count_20ms = 0;
+
+ while (wait_count_20ms++ < 20) {
+ status = hub_port_status(hub, *port1, portstatus, portchange);
+ if (status || *portstatus & USB_PO
Re: [PATCH 3/4] usb: add support to the PHY framework for HCD
Hi Vivek,
On Mon, Jul 14, 2014 at 02:38:03PM +0530, Vivek Gautam wrote:
> On Wed, Jul 9, 2014 at 3:47 PM, Antoine Ténart
> wrote:
> > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> > index bec31e2efb88..b985af5b167c 100644
> > --- a/drivers/usb/core/hcd.c
> > +++ b/drivers/usb/core/hcd.c
> > @@ -42,6 +42,7 @@
> > #include
> > #include
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -2631,21 +2632,35 @@ int usb_add_hcd(struct usb_hcd *hcd,
> > int retval;
> > struct usb_device *rhdev;
> >
> > - if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->phy) {
> > - struct usb_phy *phy = usb_get_phy_dev(hcd->self.controller,
> > 0);
> > + if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->phy && !hcd->usb_phy) {
> > + struct phy *phy = of_phy_get(hcd->self.controller->of_node,
> > 0);
> >
> > - if (IS_ERR(phy)) {
> > - retval = PTR_ERR(phy);
> > - if (retval == -EPROBE_DEFER)
> > - return retval;
> > - } else {
> > - retval = usb_phy_init(phy);
> > + if (!IS_ERR(phy)) {
> > + retval = phy_init(hcd->phy);
> > if (retval) {
> > - usb_put_phy(phy);
> > + phy_exit(hcd->phy);
> > return retval;
> > }
> > + retval = phy_power_on(hcd->phy);
> > hcd->phy = phy;
> > hcd->remove_phy = 1;
> > + } else {
> > + struct usb_phy *phy =
> > + usb_get_phy_dev(hcd->self.controller, 0);
> > +
> > + if (IS_ERR(phy)) {
> > + retval = PTR_ERR(phy);
> > + if (retval == -EPROBE_DEFER)
> > + return retval;
> > + } else {
> > + retval = usb_phy_init(phy);
> > + if (retval) {
> > + usb_put_phy(phy);
> > + return retval;
> > + }
> > + hcd->usb_phy = phy;
> > + hcd->remove_phy = 1;
> > + }
> > }
> > }
>
> Just a note here:
> There had already been a patch for adding the generic phy support in
> usb/core/hcd.c in 3.16 cycle by
> Sergei and Yoshihiro [1], though structurally a bit different, was not
> picked since there wasn't any user of the patch
> till then. Do you mind modifying on top of that patch
>
> [1] https://www.mail-archive.com/linux-usb@vger.kernel.org/msg43471.html
Sure, I'll rework my series taking in account this patch. I'll cook a v2
for later today.
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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: Iso trbs for xhci arrangement
hi Paul: > Please read section 3.2.11 in the xHCI spec, which is freely available on > the web. I found what you mean. I dump "ep context", "ep ring" and "event ring" for handling short package. Driver prepare ep ring like below xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx xhci.0: @2796e160 279d 06f8 0625 //normal xhci.0: @2796e170 279d06f8 0bf4 80021625 but event ring get below result xhci.0: @278d1710 2796e150 0d0004fc 01038001 xhci.0: @278d1720 2796e160 0100 01038001 //event for normal My questions are 1. The xhci controller seems not handle the normal TRB for short package. as you can see the length of event package for normal package is 0. am I correct? 2. if above #1 is correct, how xhci controller get the left 0x6f8 data in original normal package? the controller did fire iso in token to get 0x4fc bytes, above marked "", and if xhci controller didn't firing the left in tokens to get 0x6f8 bytes, that mean the data we get from iso-in pipe is not continuous, right? 3. is there any relationship between below patch https://lkml.org/lkml/2013/6/26/501 appreciate your help, Endpoint 02 Context: xhci.0: @e52e90c0 (virt) @27f660c0 (dma) 0x01 - ep_info xhci.0: @e52e90c4 (virt) @27f660c4 (dma) 0x3fc0228 - ep_info2 xhci.0: @e52e90c8 (virt) @27f660c8 (dma) 0x2796e001 - deq xhci.0: @e52e90d0 (virt) @27f660d0 (dma) 0xbf40bf4 - tx_info xhci.0: @e52e90d4 (virt) @27f660d4 (dma) 0x00 - rsvd[0] xhci.0: @e52e90d8 (virt) @27f660d8 (dma) 0x00 - rsvd[1] xhci.0: @e52e90dc (virt) @27f660dc (dma) 0x300 - rsvd[2] ep ring xhci.0: @2796e110 279ccb34 0bf4 80021625 xhci.0: @2796e120 279cd728 0bf4 80021625 xhci.0: @2796e130 279ce31c 0bf4 80021625 xhci.0: @2796e140 279cef10 0bf4 80021625 xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx xhci.0: @2796e160 279d 06f8 0625 //normal xhci.0: @2796e170 279d06f8 0bf4 80021625 event ring: xhci.0: @278d1700 2796e140 0d000bf4 01038001 xhci.0: @278d1710 2796e150 0d0004fc 01038001 xhci.0: @278d1720 2796e160 0100 01038001 //event for normal xhci.0: @278d1730 2796e170 0d000bf4 01038001 xhci.0: @278d1740 2796e180 0d000bf4 01038001 -- 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
