Re: USB gadget lockup on MX53 udc
On 01/21/2013 11:58 PM, Peter Chen wrote: On Mon, Jan 21, 2013 at 01:34:51PM +, Michael McTernan wrote: Hi, I think I've found a debug in fsl_udc_core.c and hope for some review of the fix. It's pretty complex so apologies in advance if my explanation misses anything. The background is that I started with the 3.0.59 stable branch (which shows the problem), then merged down the specific changes around fsl_usb2_udc from /balbi/usb.git. The problem can be demonstrated on the Freescale START-R board (iMX53 running at 1GHz) acting as a USB gadget with g_ether (EEM) loaded and connected to a Linux PC, though I normally work on a derivative board. The problem I see is that if I hammer data over the USB Ethernet towards the iMX53, the USB Ethernet 'jams' after a random amount of time between 10 seconds and a couple of minutes. I currently use iperf to generate lots of packets - a bit more than the link can really carry e.g. iperf -c 10.10.10.10 -u -b 150M -i 1 -t 6000. When 'jammed' endpoint 0 still runs but endpoint 1 no longer transfers data. /proc/interrupts show that no interrupts are being created for ep1 (ep0 will increase the count). I beefed up /proc/driver/fsl_usb2_udc a bit, and it appears the queue on ep1out has gone wrong: Endpoint Setup Status Reg: SETUP on ep 0x00 EP Ctrl Reg [0x00] =[0x00800080] EP Ctrl Reg [0x01] =[0x00880088] EP Ctrl Reg [0x02] =[0x00080008] EP Ctrl Reg [0x03] =[0x00080008] EP Ctrl Reg [0x04] =[0x00080008] EP Ctrl Reg [0x05] =[0x00080008] EP Ctrl Reg [0x06] =[0x00080008] EP Ctrl Reg [0x07] =[0x00080008] EP Prime Reg = [0x] EP Complete Reg = [0x] EP Status = [0x] For ep0 Maxpkt is 0x0040 index is 0x its req queue is empty Gadget endpoints For ep1out Maxpkt is 0x0200 index is 0x0001 curr_dtd_ptr 0x8f017080 next_dtd_ptr 0x1 size_ioc_int_sts 0x128000 req df9a9c80 actual 0x0600 length 0x0600 buf dfb47802 no_interrupt 0 status -115 td_dma=0x8f0170c0 size_ioc_sts=0x06008080 next_td_ptr=0x8f017100 req df9a9f80 actual 0x0600 length 0x0600 buf df05c802 no_interrupt 0 status -115 td_dma=0x8f017100 size_ioc_sts=0x06008080 next_td_ptr=0x8f017140 req df9a9600 actual 0x0600 length 0x0600 buf df05d802 no_interrupt 0 status -115 td_dma=0x8f017140 size_ioc_sts=0x06008080 next_td_ptr=0x8f017180 req df9a9980 actual 0x0600 length 0x0600 buf df05e802 no_interrupt 0 status -115 td_dma=0x8f017180 size_ioc_sts=0x06008080 next_td_ptr=0x8f0171c0 req df9a9e80 actual 0x0600 length 0x0600 buf df05f802 no_interrupt 0 status -115 td_dma=0x8f0171c0 size_ioc_sts=0x06008080 next_td_ptr=0x8f017200 req df9a9e00 actual 0x0600 length 0x0600 buf df0bc802 no_interrupt 0 status -115 td_dma=0x8f017200 size_ioc_sts=0x06008080 next_td_ptr=0x8f017240 req df9a9b80 actual 0x0600 length 0x0600 buf df0bd802 no_interrupt 0 status -115 td_dma=0x8f017240 size_ioc_sts=0x06008080 next_td_ptr=0x8f017000 req df9a9580 actual 0x0600 length 0x0600 buf df0be802 no_interrupt 0 status -115 td_dma=0x8f017000 size_ioc_sts=0x06008080 next_td_ptr=0x8f017040 req df9a9f00 actual 0x0600 length 0x0600 buf df0bf802 no_interrupt 0 status -115 td_dma=0x8f017040 size_ioc_sts=0x06008080 next_td_ptr=0x8f017080 req df9a9b00 actual 0x0600 length 0x0600 buf df0cc802 no_interrupt 0 status -115 td_dma=0x8f017080 size_ioc_sts=0x00128000 next_td_ptr=0x0001 For ep1in Maxpkt is 0x0200 index is 0x0001 curr_dtd_ptr 0x8f017300 next_dtd_ptr 0x1 size_ioc_int_sts 0x8000 its req queue is empty This output shows that hardware arrived on the last queue entry for ep1out but somehow skipped the other items in the list (size_ioc_sts 0x8 still shows 0x8=active for them). I believe this is due to an incorrect re-priming of the hardware, so I added some debug to fsl_queue_td(). I found that the error occurs when the request list is not empty, tmp_stat is not set after the ATDTW procedure, AND the queue head next_dtd_ptr != 1 (i.e. not terminate but a dTD pointer). This last condition is unchecked in the software (checking the next_dtd_prr is not mentioned in the iMX53 Reference Manual), but from observation the next_dtd_ptr is normally always 1 when we have to re-prime and conversely when next_dtd_ptr contains a dTD address we see the jamming. This observation is not however the primary cause, but explains how we end up with the broken queue and jam I see. Working back, I found that jamming problem appears after the following [abbreviated] call sequence occurs: fsl_udc_irq() - dtd_complete_irq() - done() - dma_pool_free(udc-td_pool, ...) - req-req.complete() - fsl_ep_queue() - fsl_req_to_dtd() - fsl_build_dtd() - dma_pool_alloc(udc-td_pool, ...) - fsl_queue_td() Specifically when there is a problem, the
Re: Linux USB file storage gadget with new UDC
Hi, On Tue, Jan 22, 2013 at 11:47:09AM +0800, victor yeo wrote: Some progress, now i am able to see the dump_msg from ep0_complete(). It looks like the enumeration is ok, but the SCSI Inquiry command is not received by the UDC driver. The do_scsi_command() in fsg_main_thread() is not called. Is this another bug in my UDC driver? I would believe so since so many other controllers work just fine. Is there any way to to further debug into why do_scsi_command() is not called? usbmon, printk(), trace_printk(), kernel function tracer, there are many ways choose one and spend some time debugging, I'm sure you'll find the bug. It sounds like the UDC driver now works okay for control transfers but not for bulk transfers. Some code in file_storage.c that i cannot understand. In ep0_complete(), the code snippet: if (req-status == 0 req-context) ((fsg_routine_t) (req-context))(fsg); Does the UDC driver provide the context pointer to file_storage.c? That belongs to the gadget driver. file_storage.c maintains that req-context. Another gadget question: get_next_command() is receiving command from host PC, UDC HW isr routine is also receiving data from host PC. What is the difference between these two? hmm... ISR receives data and bounces it back to gadget driver. What do you mean ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/2] usb: exynos: Fix compatible strings used for device
Hi,
On Tue, Jan 22, 2013 at 11:18:55AM +0530, Vivek Gautam wrote:
On Tue, Jan 22, 2013 at 11:05 AM, Kukjin Kim kgene@samsung.com wrote:
Sylwester Nawrocki wrote:
On 12/24/2012 09:13 AM, Vivek Gautam wrote:
These two changes look good to me. For both of them:
Reviewed-by: Doug Andersondiand...@chromium.org
Well, I have another idea. Yes, I know, specific chip name should be
used.
But
you know the specific chip name in compatible can cause another
confusion
on other SoC which has same IP. So I think, we need to consider to use
common name or any specific name not chip in compatible for IP/driver
like
following?
- { .compatible = samsung,exynos-dwc3 },
+ { .compatible = samsung,synopsis-dwc3 },
Or if any version or something, how about following?
+ { .compatible = samsung,dwc-v3 },
Well, yes the newer SoCs with same IP using the chip name can cause some
confusion, but won't it be fine that -
Newer parts using the same core can claim compatibility by
including the older string in the compatible list - as quoted by Grant
Likely
Or, can we try another option, using multiple compatible strings for
SoC specific
in of_match_table, so that we don't create any confusion by using same
compatible for newer SoCs also. Like,
- { .compatible = samsung,exynos-dwc3 },
+ { .compatible = samsung,exynos5250-dwc3 },
+ { .compatible =new SoC using same IP },
Yes, why not just use an SoC name where given IP first appeared ? I
believe
IP revision numbers are not always well documented. Also when an IP is
instantiated multiple times in specific SoC, its revision number might not
be sufficient to determine the system integration details for each
instance.
I think having version for some devices and SoC name for others just adds
to the confusion. Thus using specific chip name in the compatible property
seems more clear to me.
Well, I don't think so. Let's see the DMAC PL330. Its compatible is
arm,pl330 and arm,primecell not SoC/Chip name. I think DWC is a same
case or at least similar.
You know, the DWC is a IP from Synopsis and I _Believe_ it has a kind of
version and it can be used for identify.
Right, DWC has version number, but that being the kind of USB controller
(USB 2.0 and USB 3.0)
DWC2: USB High Speed controller (as also indicated in the patch from
Paul: [RFC PATCH 0/6] DWC2 DesignWare HS OTG driver)
DWC3: USB Super Speed controller
Is it fine if we use something like shown below, as suggested by you earlier ?
- { .compatible = samsung,exynos-dwc3 },
+ { .compatible = samsung,synopsis-dwc3 }
You're both missing a point here. The synopsys IP driver is called
dwc3.ko and that's compatible with synopsys,dwc3. Your glue layer driver
(dwc3-exynos.ko) is compatible with your platform, so
samsung,exynos-dwc3 sounds correct to me.
The glue layer is just to abstract away the integration details of the
IP core into a specific platform.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 0/2] usb: exynos: Fix compatible strings used for device
On 01/22/2013 06:35 AM, Kukjin Kim wrote:
- { .compatible = samsung,exynos-dwc3 },
+ { .compatible = samsung,synopsis-dwc3 },
Or if any version or something, how about following?
+ { .compatible = samsung,dwc-v3 },
Well, yes the newer SoCs with same IP using the chip name can cause some
confusion, but won't it be fine that -
Newer parts using the same core can claim compatibility by
including the older string in the compatible list - as quoted by Grant
Likely
Or, can we try another option, using multiple compatible strings for
SoC specific
in of_match_table, so that we don't create any confusion by using same
compatible for newer SoCs also. Like,
- { .compatible = samsung,exynos-dwc3 },
+ { .compatible = samsung,exynos5250-dwc3 },
+ { .compatible =new SoC using same IP },
Yes, why not just use an SoC name where given IP first appeared ? I
believe
IP revision numbers are not always well documented. Also when an IP is
instantiated multiple times in specific SoC, its revision number might not
be sufficient to determine the system integration details for each
instance.
I think having version for some devices and SoC name for others just adds
to the confusion. Thus using specific chip name in the compatible property
seems more clear to me.
Well, I don't think so. Let's see the DMAC PL330. Its compatible is
arm,pl330 and arm,primecell not SoC/Chip name. I think DWC is a same
case or at least similar.
You know, the DWC is a IP from Synopsis and I _Believe_ it has a kind of
version and it can be used for identify.
That's a good point, but isn't DesignWare just a name of a family of IP
cores from Synopsys [1] ? And what would DWC be supposed to signify ?
DesignWare Controller ? Wouldn't that be too generic ? Synopsys seems
to offer multiple different controllers and any of them could eventually
end up in a specific SoC [2].
Maybe the compatible property should be something like:
compatible = samsung,exynos5250-dwc-3, synopsys,dw-usb-3;
or
compatible = samsung,exynos5250-usb3, synopsys,dw-ss-usb3;
? Or anything more specific in the synopsys part to indicate which
exactly USB controller IP is used ?
[1] http://www.synopsys.com/IP/InterfaceIP/USB/Pages/default.aspx
[2] http://www.synopsys.com/IP/InterfaceIP/Pages/default.aspx
--
Regards,
Sylwester
--
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 v6 0/4] Adding usb2.0 host-phy support for exynos5250
HI, On Mon, Jan 21, 2013 at 09:23:28PM -0800, Kukjin Kim wrote: Vivek Gautam wrote: Changes from v5: - Rebased on top of latest patches: usb: phy: samsung: Introducing usb phy driver for hsotg (v9) usb: phy: samsung: Add support to set pmu isolation (v6) As a result adding hostphy enable mask and hostphy register offsets to driver data in order to access the HOSTPHY CONTROL register. - Adding member 'otg' to struct samsung-usbphy so that its consumers can call otg-set_host so as to make 'phy' aware of the consumer type: HOST/DEVICE - Adding 'otg' to 'struct s5p_ehci_hcd' and 'struct exynos_ohci_hcd' which keeps track of 'otg' of the controllers' phy. This then sets the host. - Moved samsung_usbphy_set_type() calls from ehci-s5p and ohci-exynos to phy driver itself where based on phy_type it is called. - Added separate macro definition for USB20PHY_CFG register to select between host/device type usb link. - Removing unnecessary argument 'phy_type' from samsung_usbphy_set_type() and samsung_usbphy_cfg_sel(). - Addressed few nits: -- added macro for 'KHZ' -- removing useless 'if' from samsung_usbphy_cfg_sel() -- keeping the place of clk_get intact and requesting driver data before that. Vivek Gautam (4): ARM: EXYNOS: Update move usb-phy types to generic include layer usb: phy: samsung: Add host phy support to samsung-phy driver USB: ehci-s5p: Add phy driver support USB: ohci-exynos: Add phy driver support .../devicetree/bindings/usb/samsung-usbphy.txt | 12 +- drivers/usb/host/ehci-s5p.c| 81 +++- drivers/usb/host/ohci-exynos.c | 85 +++- drivers/usb/phy/Kconfig|2 +- drivers/usb/phy/samsung-usbphy.c | 512 ++-- include/linux/usb/samsung_usb_phy.h| 16 + 6 files changed, 635 insertions(+), 73 deletions(-) create mode 100644 include/linux/usb/samsung_usb_phy.h -- 1.7.6.5 Looks good to me, Felipe and Greg, I don't know who should take this series anyway, feel free to add my ack: Acked-by: Kukjin Kim kgene@samsung.com I will take care of it. But I need Alan's Acked-by for EHCI and OHCI parts. -- balbi signature.asc Description: Digital signature
Re: [PATCH net] net: cdc_ncm: workaround for missing CDC Union
On Monday 21 January 2013 16:28:48 Bjørn Mork wrote:
Agreed. But I believe the condition should be
if (!(info-flags FLAG_SEND_ZLP) !(info-flags FLAG_MULTI_PACKET)) {
..
} else {
urb-transfer_flags |= URB_ZERO_PACKET;
}
to ensure that we send the ZLP in this case.
Why? If a driver wants ZLP, it can set FLAG_SEND_ZLP. Your proposed change
would take away an option from drivers without any gain.
Besides you may want the current behavior.
Why? Does it ever make sense to prevent both the short packet and the
ZLP?
Why not? It is possible and a driver may want it, so why forbid it?
Especially, as in theory it takes least bandwidth as a solution.
Regards
Oliver
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB subsystem stops working
Hi, On Tue, Jan 22, 2013 at 10:52:41AM +0900, Norbert Preining wrote: Hi Felipe, hi all, On Mo, 21 Jan 2013, Felipe Balbi wrote: Can you try rebuilding your kernel with CONFIG_USB_DEBUG=y and run your test again ? Maybe it gives us more information of what's going on. Ok, I can reliably reproduce the problem as follows: * connect the kindle, it goes into usb disk mode * !!! important !!! use the temporary gnome3 dbus window to Eject the device after that the device is not really ejected * use eject /dev/sdb after this the device is actually ejected * unplug and replug here the usb system does not recognize the device anymore, and does not react on any usb connections * call lsusb -v gets it back to normal * repeat the above I have collected the syslog output of one of the cycles starting from lsusb -v to get back to normal, plugging, ejecting with dbus window, eject with cmd line, plug/replug without effect, etc. The log can be found at http://www.preining.info/usb-syslog-prob.txt I have documented the steps *in* the log file by calling logger with the appropriate steps, so please seach for norbert: which will give you the comments I have written with logger and the sequence of actions. Hope that helps, and let me know if you want/need more details. I need to see what happens before the problem shows up. Your log starts after the problem has already triggered. -- balbi signature.asc Description: Digital signature
Re: [PATCH net 3/3] net: cdc_ncm: fix error path for single interface probing
On Monday 21 January 2013 16:50:40 Bjørn Mork wrote: commit bbc8d92 (net: cdc_ncm: add Huawei devices) implemented support for devices with a single combined control and data interface. Fix up the error path so that we do not double release such interfaces in case of probing failures. Hi Bjørn, this should go also into stable. Could you submit? Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB subsystem stops working
Hi I need to see what happens before the problem shows up. Your log starts after the problem has already triggered. It is a cycle, it repeats after the lsusb -v when it is back to normal. So reading from *after* the issuing the lsusb -v should show you what you need. If you want I sent tomorrow a full log from boot ... Norbert -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB subsystem stops working
HI, On Tue, Jan 22, 2013 at 06:04:53PM +0900, Norbert Preining wrote: Hi I need to see what happens before the problem shows up. Your log starts after the problem has already triggered. It is a cycle, it repeats after the lsusb -v when it is back to normal. So reading from *after* the issuing the lsusb -v should show you what you need. If you want I sent tomorrow a full log from boot ... That would be great, meanwhile I'll go over current log again. -- balbi signature.asc Description: Digital signature
Re: [PATCH net] net: cdc_ncm: workaround for missing CDC Union
On Monday 21 January 2013 18:59:05 Alexey ORISHKO wrote: Specification says: NCM/MBIM shall not send ZLP if buffer size is dwNtbOutMaxSize. The problem is: dwNtbOutMaxSize value is negotiated between host and device NCM/MBIM entities and usbnet has no knowledge about it. Adding one byte to make buffer looking like a short packet was most simple approach instead of inventing a way to communicate dwNtbOutMaxSize to usbnet. You could drop short packet approach if dwNtbOutMaxSize is provided to usbnet and decision is made accordingly to NCM/MBIM spec (with exception to faulty devices). We could do that. Feel free to send a patch. ;-) Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2]linux-usb:define new macro and add new match rules for Huawei USB storage devices
From: fangxiaozhi huana...@huawei.com
1. Define a new macro for USB storage match rules:
matching with Vendor ID and interface descriptors.
Signed-off-by: fangxiaozhi huana...@huawei.com
diff -uprN linux-3.8-rc4_orig/drivers/usb/storage/usb.c
linux-3.8-rc4/drivers/usb/storage/usb.c
--- linux-3.8-rc4_orig/drivers/usb/storage/usb.c2013-01-22
14:12:42.595238727 +0800
+++ linux-3.8-rc4/drivers/usb/storage/usb.c 2013-01-22 14:16:01.398250305
+0800
@@ -120,6 +120,17 @@ MODULE_PARM_DESC(quirks, supplemental l
.useTransport = use_transport, \
}
+#define UNUSUAL_VENDOR_INTF(idVendor, cl, sc, pr, \
+ vendor_name, product_name, use_protocol, use_transport, \
+ init_function, Flags) \
+{ \
+ .vendorName = vendor_name, \
+ .productName = product_name,\
+ .useProtocol = use_protocol,\
+ .useTransport = use_transport, \
+ .initFunction = init_function, \
+}
+
static struct us_unusual_dev us_unusual_dev_list[] = {
# include unusual_devs.h
{ } /* Terminating entry */
@@ -131,6 +142,7 @@ static struct us_unusual_dev for_dynamic
#undef UNUSUAL_DEV
#undef COMPLIANT_DEV
#undef USUAL_DEV
+#undef UNUSUAL_VENDOR_INTF
#ifdef CONFIG_LOCKDEP
diff -uprN linux-3.8-rc4_orig/drivers/usb/storage/usual-tables.c
linux-3.8-rc4/drivers/usb/storage/usual-tables.c
--- linux-3.8-rc4_orig/drivers/usb/storage/usual-tables.c 2013-01-22
14:12:42.594238726 +0800
+++ linux-3.8-rc4/drivers/usb/storage/usual-tables.c2013-01-22
14:16:01.426250199 +0800
@@ -41,6 +41,19 @@
#define USUAL_DEV(useProto, useTrans) \
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, useProto, useTrans) }
+/* Define the device is matched with Vendor ID and interface descriptors */
+#define UNUSUAL_VENDOR_INTF(id_vendor, cl, sc, pr, \
+ vendorName, productName, useProtocol, useTransport, \
+ initFunction, flags) \
+{ \
+ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \
+ | USB_DEVICE_ID_MATCH_VENDOR, \
+ .idVendor= (id_vendor), \
+ .bInterfaceClass = (cl), \
+ .bInterfaceSubClass = (sc), \
+ .bInterfaceProtocol = (pr), \
+ .driver_info = (flags) }
+
struct usb_device_id usb_storage_usb_ids[] = {
# include unusual_devs.h
{ } /* Terminating entry */
@@ -50,6 +63,7 @@ MODULE_DEVICE_TABLE(usb, usb_storage_usb
#undef UNUSUAL_DEV
#undef COMPLIANT_DEV
#undef USUAL_DEV
+#undef UNUSUAL_VENDOR_INTF
/*
* The table of devices to ignore
--
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: musb: fix context save over suspend.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It looks like Kevin has a new address: Kevin Hilman khil...@deeprootsystems.com On 01/21/13 23:38, NeilBrown wrote: On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/21/13 11:28, NeilBrown wrote: The standard suspend sequence involves runtime_resuming devices before suspending the system. So just saving context in runtime_suspend and restoring it in runtime resume isn't enough. We must also save in suspend and restore in resume. Without this patch, and OMAP3 system with off_mode enabled will find the musb port non-functional after suspend/resume. With the patch it works perfectly. Hmmm... Some time ago, this has been removed in 5d193ce8 (usb: musb: PM: fix context save/restore in suspend/resume path) Am I missing something? Or things changed and now this patch is correct? Hi Igor, thanks for alerting me to that patch does anyone else get the feeling that power management to too complex to be understood by a mere human? That commit (5d193ce8) suggests that the musb-hdrc device is an 'omap_device', or maybe has a PM domain set to something else. However it isn't/doesn't. dev-pm_domain is NULL. So no PM domain layer will ever call the musb_core musb_runtime_suspend/resume. The parent device - musb-omap2430 - is an omap device, does have pm_domain set, and does have its omap2430_runtime_suspend/resume called for system suspend and so the context for that device is saved and restored. However that doesn't help the context for musb-hdrc. Whether musb ever was an omap_device is beyond my archaeological skills to determine. Kevin: Was musb-hdrc ever a device with a pm_domain? or was it only ever the various possible parents that had domains? Are you able to defend your earlier patch in today's kernel? It certainly causes my device not to work properly. Thanks, NeilBrown Signed-off-by: NeilBrown ne...@suse.de diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index fd34867..b6ccc02 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2225,6 +2225,7 @@ static int musb_suspend(struct device *dev) } spin_unlock_irqrestore(musb-lock, flags); + musb_save_context(musb); return 0; } @@ -2234,6 +2235,8 @@ static int musb_resume_noirq(struct device *dev) * unless for some reason the whole soc powered down or the USB * module got reset through the PSC (vs just being disabled). */ + struct musb *musb = dev_to_musb(dev); + musb_restore_context(musb); return 0; } - -- Regards, Igor. - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQ/lgWAAoJEBDE8YO64EfacIAP/3nyXjs8QQpcD6RcNuRSLp3O veKU2grzsUOL/Eu/8TQMM7WDz5n8YlycQ6/THNGGYojjOlEimDC02wbsI4gc5j41 QC1/XGf62Nlxv6CzORzkGkUoKXtVWzgMYKddWKPEwsXMKPun/LH4ZGDp+7Rkfcmu U0k7LM1Pv487iG9pF3Bq5BPYeMxyxyFJC0PiQEK1ZE65RKWbCvInibc7p1bvZ+XX JQxf8Qx1p/kBhqWc6LLpcHT5Z3B/F+3rxEhvf8lSu5fdRPHFffcmuX7bIbC/GlTe e6mODA114mtn5YbaKCmnYExvJcpz4Nziy+8fGLJ56aAyeKI1wsOJzhWDpSKwQiIF CVtYulk5iIfaeUA4sAzvRqEu7dJuaVgm6mEeGHQjebPastYhK7vHjiEOJJ2+LQrs 698A9wMLckp4AQ75HiwXRgi5N0W528gD8piNoIA9Sh1LwyytIa5Wg7uYw14UjtLJ QIerm0v6Ay+8FbVfmpm9k0v3HkYfv0ZVTSdtIXVAE30+WKIBTn0yszxWYo6JZtvj p0NEFUNVuR3C9k/xyzkcqwJh8Q6DrleWJeHWL59xgWWKzfeDKjU/DMOuWmuVEkTO aRdAlW32VDtUeWlWz3Jz3IOWZRJQKCW2o97n/MDyxwMoRiMWcHxYw6jti6se9S7a IGZeEMCcf39fnH5o7i2q =nwGe -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2]linux-usb:define new macro and add new match rules for Huawei USB storage devices
From: fangxiaozhi huana...@huawei.com
1. Optimize the matching rules with new macro for Huawei USB storage devices,
to avoid to load USB storage driver for the modem interface
with Huawei devices.
2. Add to support new switch command for new Huawei USB dongles.
Signed-off-by: fangxiaozhi huana...@huawei.com
diff -uprN linux-3.8-rc4_orig/drivers/usb/storage/initializers.c
linux-3.8-rc4/drivers/usb/storage/initializers.c
--- linux-3.8-rc4_orig/drivers/usb/storage/initializers.c 2013-01-22
14:12:42.594238726 +0800
+++ linux-3.8-rc4/drivers/usb/storage/initializers.c2013-01-22
14:28:21.512294889 +0800
@@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_dat
return 0;
}
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us)
+/* This places the HUAWEI usb dongles in multi-port mode */
+static int usb_stor_huawei_feature_init(struct us_data *us)
{
int result;
@@ -104,3 +104,75 @@ int usb_stor_huawei_e220_init(struct us_
US_DEBUGP(Huawei mode set result is %d\n, result);
return 0;
}
+
+/*
+ * It will send a scsi switch command called rewind' to huawei dongle.
+ * When the dongle receives this command at the first time,
+ * it will reboot immediately. After rebooted, it will ignore this command.
+ * So it is unnecessary to read its response.
+ */
+static int usb_stor_huawei_scsi_init(struct us_data *us)
+{
+ int result = 0;
+ int act_len = 0;
+ struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us-iobuf;
+ char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
+ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+
+ bcbw-Signature = cpu_to_le32(US_BULK_CB_SIGN);
+ bcbw-Tag = 0;
+ bcbw-DataTransferLength = 0;
+ bcbw-Flags = bcbw-Lun = 0;
+ bcbw-Length = sizeof(rewind_cmd);
+ memset(bcbw-CDB, 0, sizeof(bcbw-CDB));
+ memcpy(bcbw-CDB, rewind_cmd, sizeof(rewind_cmd));
+
+ result = usb_stor_bulk_transfer_buf(us, us-send_bulk_pipe, bcbw,
+ US_BULK_CB_WRAP_LEN, act_len);
+ US_DEBUGP(transfer actual length=%d, result=%d\n, act_len, result);
+ return result;
+}
+
+/*
+ * It tries to find the supported Huawei USB dongles.
+ * In Huawei, they assign the following product IDs
+ * for all of their mobile broadband dongles,
+ * including the new dongles in the future.
+ * So if the product ID is not included in this list,
+ * it means it is not Huawei's mobile broadband dongles.
+ */
+static int usb_stor_huawei_dongles_pid(struct us_data *us)
+{
+ struct usb_interface_descriptor *idesc;
+ int idProduct;
+
+ idesc = us-pusb_intf-cur_altsetting-desc;
+ idProduct = us-pusb_dev-descriptor.idProduct;
+ /* The first port is CDROM,
+* means the dongle in the single port mode,
+* and a switch command is required to be sent. */
+ if (idesc idesc-bInterfaceNumber == 0) {
+ if ((idProduct == 0x1001)
+ || (idProduct == 0x1003)
+ || (idProduct == 0x1004)
+ || (idProduct = 0x1401 idProduct = 0x1500)
+ || (idProduct = 0x1505 idProduct = 0x1600)
+ || (idProduct = 0x1c02 idProduct = 0x2202)) {
+ return 1;
+ }
+ }
+ return 0;
+}
+
+int usb_stor_huawei_init(struct us_data *us)
+{
+ int result = 0;
+
+ if (usb_stor_huawei_dongles_pid(us)) {
+ if (us-pusb_dev-descriptor.idProduct = 0x1446)
+ result = usb_stor_huawei_scsi_init(us);
+ else
+ result = usb_stor_huawei_feature_init(us);
+ }
+ return result;
+}
diff -uprN linux-3.8-rc4_orig/drivers/usb/storage/initializers.h
linux-3.8-rc4/drivers/usb/storage/initializers.h
--- linux-3.8-rc4_orig/drivers/usb/storage/initializers.h 2013-01-22
14:12:42.595238727 +0800
+++ linux-3.8-rc4/drivers/usb/storage/initializers.h2013-01-22
14:19:53.208263547 +0800
@@ -46,5 +46,5 @@ int usb_stor_euscsi_init(struct us_data
* flash reader */
int usb_stor_ucr61s2b_init(struct us_data *us);
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us);
+/* This places the HUAWEI usb dongles in multi-port mode */
+int usb_stor_huawei_init(struct us_data *us);
diff -uprN linux-3.8-rc4_orig/drivers/usb/storage/unusual_devs.h
linux-3.8-rc4/drivers/usb/storage/unusual_devs.h
--- linux-3.8-rc4_orig/drivers/usb/storage/unusual_devs.h 2013-01-22
14:12:42.594238726 +0800
+++ linux-3.8-rc4/drivers/usb/storage/unusual_devs.h2013-01-22
14:19:53.208263547 +0800
@@ -1527,335 +1527,10 @@ UNUSUAL_DEV( 0x1210, 0x0003, 0x0100, 0x
/* Reported by fangxiaozhi huana...@huawei.com
* This brings the
Re: [PATCH v6 0/4] Adding usb2.0 host-phy support for exynos5250
Hi Felipe, On Tue, Jan 22, 2013 at 2:20 PM, Felipe Balbi ba...@ti.com wrote: HI, On Mon, Jan 21, 2013 at 09:23:28PM -0800, Kukjin Kim wrote: Vivek Gautam wrote: Changes from v5: - Rebased on top of latest patches: usb: phy: samsung: Introducing usb phy driver for hsotg (v9) usb: phy: samsung: Add support to set pmu isolation (v6) As a result adding hostphy enable mask and hostphy register offsets to driver data in order to access the HOSTPHY CONTROL register. - Adding member 'otg' to struct samsung-usbphy so that its consumers can call otg-set_host so as to make 'phy' aware of the consumer type: HOST/DEVICE - Adding 'otg' to 'struct s5p_ehci_hcd' and 'struct exynos_ohci_hcd' which keeps track of 'otg' of the controllers' phy. This then sets the host. - Moved samsung_usbphy_set_type() calls from ehci-s5p and ohci-exynos to phy driver itself where based on phy_type it is called. - Added separate macro definition for USB20PHY_CFG register to select between host/device type usb link. - Removing unnecessary argument 'phy_type' from samsung_usbphy_set_type() and samsung_usbphy_cfg_sel(). - Addressed few nits: -- added macro for 'KHZ' -- removing useless 'if' from samsung_usbphy_cfg_sel() -- keeping the place of clk_get intact and requesting driver data before that. Vivek Gautam (4): ARM: EXYNOS: Update move usb-phy types to generic include layer usb: phy: samsung: Add host phy support to samsung-phy driver USB: ehci-s5p: Add phy driver support USB: ohci-exynos: Add phy driver support .../devicetree/bindings/usb/samsung-usbphy.txt | 12 +- drivers/usb/host/ehci-s5p.c| 81 +++- drivers/usb/host/ohci-exynos.c | 85 +++- drivers/usb/phy/Kconfig|2 +- drivers/usb/phy/samsung-usbphy.c | 512 ++-- include/linux/usb/samsung_usb_phy.h| 16 + 6 files changed, 635 insertions(+), 73 deletions(-) create mode 100644 include/linux/usb/samsung_usb_phy.h -- 1.7.6.5 Looks good to me, Felipe and Greg, I don't know who should take this series anyway, feel free to add my ack: Acked-by: Kukjin Kim kgene@samsung.com I will take care of it. But I need Alan's Acked-by for EHCI and OHCI parts. We got Alan's ACK for: USB: ehci-s5p: Add phy driver support USB: ohci-exynos: Add phy driver support -- Thanks Regards Vivek -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB: storage: optimize the matching rules and support new switch command for Huawei USB storage devices
Dear Greg: OK, I have fixed up and resend the patches based on linux-3.8-rc4 today. Email subjects: 1. [PATCH 1/2]linux-usb:define new macro and add new match rules for Huawei USB storage devices 2. [PATCH 2/2]linux-usb:define new macro and add new match rules for Huawei USB storage devices Please apply them, thank you very much. Best Regards, Franko Fang -Original Message- From: Greg KH [mailto:g...@kroah.com] Sent: Tuesday, January 22, 2013 1:12 AM To: Fangxiaozhi (Franko) Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Xueguiying (Zihan); Linlei (Lei Lin); Yili (Neil); Wangyuhua (Roger, Credit); Huqiao (C); ba...@ti.com; mdharm-...@one-eyed-alien.net; sebast...@breakpoint.cc Subject: Re: USB: storage: optimize the matching rules and support new switch command for Huawei USB storage devices On Mon, Jan 21, 2013 at 03:37:15AM +, Fangxiaozhi (Franko) wrote: Dear Greg: I get the following errors: drivers/usb/storage/unusual_devs.h:1530:1: error: implicit declaration of function ‘UNUSUAL_VENDOR_INTF’ [-Werror=implicit-function-declaration] drivers/usb/storage/unusual_devs.h:1534:3: warning: missing braces around initializer [-Wmissing-braces] drivers/usb/storage/unusual_devs.h:1534:3: warning: (near initialization for ‘us_unusual_dev_list[186]’) [-Wmissing-braces] drivers/usb/storage/unusual_devs.h:1534:3: error: initializer element is not constant drivers/usb/storage/unusual_devs.h:1534:3: error: (near initialization for ‘us_unusual_dev_list[186].vendorName’) drivers/usb/storage/unusual_devs.h:1537:1: warning: braces around scalar initializer [enabled by default] And it goes on and on... --The macro define, please see another patch: [PATCH 1/1]linux-usb:Define a new macro for USB storage match rules http://www.spinics.net/lists/linux-usb/msg76629.html Please resend it, I do not have this patch anymore in my queue. Remember, I asked you to resend everything that was needed, with the proper ordering. Please resend all patches, properly fixed up, that you wish to see applied. thanks, greg k-h
Re: Linux USB file storage gadget with new UDC
Hi,
Is there any way to to further debug into why do_scsi_command() is not
called?
usbmon, printk(), trace_printk(), kernel function tracer, there are many
ways choose one and spend some time debugging, I'm sure you'll find the
bug.
It sounds like the UDC driver now works okay for control transfers but
not for bulk transfers.
Some code in file_storage.c that i cannot understand. In
ep0_complete(), the code snippet:
if (req-status == 0 req-context)
((fsg_routine_t) (req-context))(fsg);
Does the UDC driver provide the context pointer to file_storage.c?
That belongs to the gadget driver. file_storage.c maintains that
req-context.
Another gadget question: get_next_command() is receiving command from
host PC, UDC HW isr routine is also receiving data from host PC. What
is the difference between these two?
hmm... ISR receives data and bounces it back to gadget driver. What do
you mean ?
Ok, rephrase the question, is this the flow for bulk transfer?
1) data is received by Usb mass storage HW, the UDC driver ISR is
called to read the data to usb_request buffer
2) bulk_out_complete() in gadget driver, is called to set buffer state to full
3) get_next_command() in gadget driver, is called to read the CBW.
4) do_scsi_command() to process SCSI command encoded in CBW
5) send_status() sends the CSW to host
i see this code snippet in fsg_main_thread(), i cannot understand it,
please tell me what the purpose of this code is. is handle_exception()
tries to process error condition?
if (exception_in_progress(fsg) || signal_pending(current)) {
handle_exception(fsg);
}
thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
Hi,
On Tue, Jan 22, 2013 at 05:22:58PM +0800, victor yeo wrote:
Is there any way to to further debug into why do_scsi_command() is
not called?
usbmon, printk(), trace_printk(), kernel function tracer, there are many
ways choose one and spend some time debugging, I'm sure you'll find the
bug.
It sounds like the UDC driver now works okay for control transfers but
not for bulk transfers.
Some code in file_storage.c that i cannot understand. In
ep0_complete(), the code snippet:
if (req-status == 0 req-context)
((fsg_routine_t) (req-context))(fsg);
Does the UDC driver provide the context pointer to file_storage.c?
That belongs to the gadget driver. file_storage.c maintains that
req-context.
Another gadget question: get_next_command() is receiving command from
host PC, UDC HW isr routine is also receiving data from host PC. What
is the difference between these two?
hmm... ISR receives data and bounces it back to gadget driver. What do
you mean ?
Ok, rephrase the question, is this the flow for bulk transfer?
1) data is received by Usb mass storage HW, the UDC driver ISR is
called to read the data to usb_request buffer
2) bulk_out_complete() in gadget driver, is called to set buffer state to full
3) get_next_command() in gadget driver, is called to read the CBW.
4) do_scsi_command() to process SCSI command encoded in CBW
5) send_status() sends the CSW to host
Something like below:
OUT Token - ISR - giveback() - bulk_out_complete() -
get_next_command() - do_scsi_command() - usb_ep_queue() - OUT/IN
Token - ISR - bulk_out_complete() - send_status()
i see this code snippet in fsg_main_thread(), i cannot understand it,
please tell me what the purpose of this code is. is handle_exception()
tries to process error condition?
if (exception_in_progress(fsg) || signal_pending(current)) {
handle_exception(fsg);
}
Mass storage is processed in thread context. This is just the main loop.
It tells us to continue running while we have a signal_pending() (like
SIGHUP and the like) or an exception which is raised with
raise_exception().
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v8 19/22] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
On 01/21/2013 05:03 PM, Paul Walmsley wrote: Hi On Mon, 21 Jan 2013, Roger Quadros wrote: On 01/18/2013 10:27 PM, Paul Walmsley wrote: On Fri, 18 Jan 2013, Roger Quadros wrote: We don't need multiple aliases for the OMAP USB host clocks and neither the dummy clocks so remove them. CC: Paul Walmsley p...@pwsan.com CC: Rajendra Nayak rna...@ti.com CC: Benoit Cousson b-cous...@ti.com CC: Mike Turquette mturque...@linaro.com Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Per Tony's earlier request, you can drop this patch and patch 20 from your series now. I've got them queued for 3.10 or late 3.9 merge window. Should have mentioned it earlier, but just this patch without the rest of the cleanup patches will break USB Host on OMAP3, as the old driver bails out if optional clock nodes are missing. Including patch 20 doesn't seem to cause a problem with OMAP4 though. I've got these two patches queued for merging after your other patches go upstream -- e.g., probably 3.10. Do you foresee any problems with that? That should be fine. Thanks :). -- cheers, -roger -- 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 v6 0/4] Adding usb2.0 host-phy support for exynos5250
On Tue, Jan 22, 2013 at 02:45:26PM +0530, Vivek Gautam wrote: Hi Felipe, On Tue, Jan 22, 2013 at 2:20 PM, Felipe Balbi ba...@ti.com wrote: HI, On Mon, Jan 21, 2013 at 09:23:28PM -0800, Kukjin Kim wrote: Vivek Gautam wrote: Changes from v5: - Rebased on top of latest patches: usb: phy: samsung: Introducing usb phy driver for hsotg (v9) usb: phy: samsung: Add support to set pmu isolation (v6) As a result adding hostphy enable mask and hostphy register offsets to driver data in order to access the HOSTPHY CONTROL register. - Adding member 'otg' to struct samsung-usbphy so that its consumers can call otg-set_host so as to make 'phy' aware of the consumer type: HOST/DEVICE - Adding 'otg' to 'struct s5p_ehci_hcd' and 'struct exynos_ohci_hcd' which keeps track of 'otg' of the controllers' phy. This then sets the host. - Moved samsung_usbphy_set_type() calls from ehci-s5p and ohci-exynos to phy driver itself where based on phy_type it is called. - Added separate macro definition for USB20PHY_CFG register to select between host/device type usb link. - Removing unnecessary argument 'phy_type' from samsung_usbphy_set_type() and samsung_usbphy_cfg_sel(). - Addressed few nits: -- added macro for 'KHZ' -- removing useless 'if' from samsung_usbphy_cfg_sel() -- keeping the place of clk_get intact and requesting driver data before that. Vivek Gautam (4): ARM: EXYNOS: Update move usb-phy types to generic include layer usb: phy: samsung: Add host phy support to samsung-phy driver USB: ehci-s5p: Add phy driver support USB: ohci-exynos: Add phy driver support .../devicetree/bindings/usb/samsung-usbphy.txt | 12 +- drivers/usb/host/ehci-s5p.c| 81 +++- drivers/usb/host/ohci-exynos.c | 85 +++- drivers/usb/phy/Kconfig|2 +- drivers/usb/phy/samsung-usbphy.c | 512 ++-- include/linux/usb/samsung_usb_phy.h| 16 + 6 files changed, 635 insertions(+), 73 deletions(-) create mode 100644 include/linux/usb/samsung_usb_phy.h -- 1.7.6.5 Looks good to me, Felipe and Greg, I don't know who should take this series anyway, feel free to add my ack: Acked-by: Kukjin Kim kgene@samsung.com I will take care of it. But I need Alan's Acked-by for EHCI and OHCI parts. We got Alan's ACK for: USB: ehci-s5p: Add phy driver support USB: ohci-exynos: Add phy driver support Ok, then as soon as I get back to the office (in a few hours), I'll start queueing those. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH net] net: cdc_ncm: workaround for missing CDC Union
On Monday 21 January 2013 18:59:05 Alexey ORISHKO wrote: Either the FLAG_MULTI_PACKET minidriver will have already padded the buffer so that we do not hit (length % dev-maxpacket == 0), or we should choose one of the alternatives: ZLP or padding. But we cannot simply call __skb_put for a complicated data frame. Besides you may want the current behavior. Specification says: NCM/MBIM shall not send ZLP if buffer size is dwNtbOutMaxSize. Hi, one thing on a generic level, which I hope you don't take wrong, but I need to make it clear. Usbnet is for every driver. What a spec says or what the reality of implementations of that spec looks like, determine what usbnet needs to support. But what is not needed to implement that spec doesn't matter in deciding what usbnet needs not support. Drivers may or may not need ZLPs. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/4] Adding usb2.0 host-phy support for exynos5250
HI, On Tue, Jan 22, 2013 at 11:29:47AM +0200, Felipe Balbi wrote: On Tue, Jan 22, 2013 at 02:45:26PM +0530, Vivek Gautam wrote: Hi Felipe, On Tue, Jan 22, 2013 at 2:20 PM, Felipe Balbi ba...@ti.com wrote: HI, On Mon, Jan 21, 2013 at 09:23:28PM -0800, Kukjin Kim wrote: Vivek Gautam wrote: Changes from v5: - Rebased on top of latest patches: usb: phy: samsung: Introducing usb phy driver for hsotg (v9) usb: phy: samsung: Add support to set pmu isolation (v6) As a result adding hostphy enable mask and hostphy register offsets to driver data in order to access the HOSTPHY CONTROL register. - Adding member 'otg' to struct samsung-usbphy so that its consumers can call otg-set_host so as to make 'phy' aware of the consumer type: HOST/DEVICE - Adding 'otg' to 'struct s5p_ehci_hcd' and 'struct exynos_ohci_hcd' which keeps track of 'otg' of the controllers' phy. This then sets the host. - Moved samsung_usbphy_set_type() calls from ehci-s5p and ohci-exynos to phy driver itself where based on phy_type it is called. - Added separate macro definition for USB20PHY_CFG register to select between host/device type usb link. - Removing unnecessary argument 'phy_type' from samsung_usbphy_set_type() and samsung_usbphy_cfg_sel(). - Addressed few nits: -- added macro for 'KHZ' -- removing useless 'if' from samsung_usbphy_cfg_sel() -- keeping the place of clk_get intact and requesting driver data before that. Vivek Gautam (4): ARM: EXYNOS: Update move usb-phy types to generic include layer usb: phy: samsung: Add host phy support to samsung-phy driver USB: ehci-s5p: Add phy driver support USB: ohci-exynos: Add phy driver support .../devicetree/bindings/usb/samsung-usbphy.txt | 12 +- drivers/usb/host/ehci-s5p.c| 81 +++- drivers/usb/host/ohci-exynos.c | 85 +++- drivers/usb/phy/Kconfig|2 +- drivers/usb/phy/samsung-usbphy.c | 512 ++-- include/linux/usb/samsung_usb_phy.h| 16 + 6 files changed, 635 insertions(+), 73 deletions(-) create mode 100644 include/linux/usb/samsung_usb_phy.h -- 1.7.6.5 Looks good to me, Felipe and Greg, I don't know who should take this series anyway, feel free to add my ack: Acked-by: Kukjin Kim kgene@samsung.com I will take care of it. But I need Alan's Acked-by for EHCI and OHCI parts. We got Alan's ACK for: USB: ehci-s5p: Add phy driver support USB: ohci-exynos: Add phy driver support Ok, then as soon as I get back to the office (in a few hours), I'll start queueing those. Actually, if you want to make my life a little easier today, you could resend the series with all Acks in place ;-) ps: hehe, I'm about to go a little nuts today, too many things happening at once ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 0/4] Adding usb2.0 host-phy support for exynos5250
Hi Felipe, On Tue, Jan 22, 2013 at 3:02 PM, Felipe Balbi ba...@ti.com wrote: HI, On Tue, Jan 22, 2013 at 11:29:47AM +0200, Felipe Balbi wrote: On Tue, Jan 22, 2013 at 02:45:26PM +0530, Vivek Gautam wrote: Hi Felipe, On Tue, Jan 22, 2013 at 2:20 PM, Felipe Balbi ba...@ti.com wrote: HI, On Mon, Jan 21, 2013 at 09:23:28PM -0800, Kukjin Kim wrote: Vivek Gautam wrote: Changes from v5: - Rebased on top of latest patches: usb: phy: samsung: Introducing usb phy driver for hsotg (v9) usb: phy: samsung: Add support to set pmu isolation (v6) As a result adding hostphy enable mask and hostphy register offsets to driver data in order to access the HOSTPHY CONTROL register. - Adding member 'otg' to struct samsung-usbphy so that its consumers can call otg-set_host so as to make 'phy' aware of the consumer type: HOST/DEVICE - Adding 'otg' to 'struct s5p_ehci_hcd' and 'struct exynos_ohci_hcd' which keeps track of 'otg' of the controllers' phy. This then sets the host. - Moved samsung_usbphy_set_type() calls from ehci-s5p and ohci-exynos to phy driver itself where based on phy_type it is called. - Added separate macro definition for USB20PHY_CFG register to select between host/device type usb link. - Removing unnecessary argument 'phy_type' from samsung_usbphy_set_type() and samsung_usbphy_cfg_sel(). - Addressed few nits: -- added macro for 'KHZ' -- removing useless 'if' from samsung_usbphy_cfg_sel() -- keeping the place of clk_get intact and requesting driver data before that. Vivek Gautam (4): ARM: EXYNOS: Update move usb-phy types to generic include layer usb: phy: samsung: Add host phy support to samsung-phy driver USB: ehci-s5p: Add phy driver support USB: ohci-exynos: Add phy driver support .../devicetree/bindings/usb/samsung-usbphy.txt | 12 +- drivers/usb/host/ehci-s5p.c| 81 +++- drivers/usb/host/ohci-exynos.c | 85 +++- drivers/usb/phy/Kconfig|2 +- drivers/usb/phy/samsung-usbphy.c | 512 ++-- include/linux/usb/samsung_usb_phy.h| 16 + 6 files changed, 635 insertions(+), 73 deletions(-) create mode 100644 include/linux/usb/samsung_usb_phy.h -- 1.7.6.5 Looks good to me, Felipe and Greg, I don't know who should take this series anyway, feel free to add my ack: Acked-by: Kukjin Kim kgene@samsung.com I will take care of it. But I need Alan's Acked-by for EHCI and OHCI parts. We got Alan's ACK for: USB: ehci-s5p: Add phy driver support USB: ohci-exynos: Add phy driver support Ok, then as soon as I get back to the office (in a few hours), I'll start queueing those. Actually, if you want to make my life a little easier today, you could resend the series with all Acks in place ;-) Sure, will resend the patches with proper Acks and version :-) ps: hehe, I'm about to go a little nuts today, too many things happening at once ;-) :-) -- Thanks Regards Vivek -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net 2/3] net: cdc_mbim: send ZLP after max sized NTBs
Alexey ORISHKO alexey.oris...@stericsson.com writes: If you add ZLP for NTBs of dwNtbOutMaxSize, you are heavily affecting CPU load, increasing interrupt load by factor of 2 in high load traffic scenario and possibly decreasing throughput for all other devices which behaves correctly. Hello Alexey, Still trying to understand the mechanisms involved here. I must apologize for my lack of knowledge of the hardware restrictions involved. The current cdc_ncm/cdc_mbim drivers will pad a NTB to the full dwNtbOutMaxSize whenever it reaches at least 512 bytes. The reason is that this allows more efficient device DMA operation. This is something we do to adapt to device hardware restrictions even though there is no such recommendations in the NCM/MBIM specs. The penalty on the host and bus should be obvious: Even with a quite small dwNtbOutMaxSize of 4096, we end up sending 8 x 512-byte data packets instead of the 2 we could have managed with. Now you claim that sending 9 packets, where the last one is a zero length packet, increaes the interrupt load by factor of 2? How is that? This is where my lack of hardware knowledge shows up, but I assumed based on the device DMA argument that the device USB engine would do the actual packet reception and assembly and DMA the complete 4096-byte data transfer to the device memory. Won't the device USB engine also handle the ZLP? Won't it just collect 9 packets instead of 8 and assemble them to the 4096-byte data transfer which is DMAed away the same way it would if there were just 8 packets in the transfer? The only differences being that the ZLP variant works even if the device stack for some reason requests more than dwNtbOutMaxSize bytes (which of course could be claimed to be stupid, but the spec allows it), and of course that we waste even more USB bus bandwidth. But if USB bandwidth is a factor we consider here then I am going to question the padding to dwNtbOutMaxSize based on some devices having DMA restrictions making that more efficient. Why is the device DMA restrictions not a fault, while the device ZLP requirement is? Both seem like reasonable device hardware/firmware implementation imposed restrictions to me. Something we'll just have to accept. Note that the problem with the ZLP on the Sierra devices is made much worse than necessary by the padding. Without this we would rarely have hit the dwNtbOutMaxSize limit, and would have been able to work around it by simply using tx_max = dwNtbOutMaxSize - 1 if (dwNtbOutMaxSize % wMaxPacketSize == 0). Maybe that is what Windows does? But we cannot do that due to other devices having issues with transfers less than dwNtbOutMaxSize.. 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
[PATCH v1 0/6] USB: Add support for multiple PHYs of same type
This patch series adds support for adding multiple PHY's (of same type). The binding information has to be present in the PHY library (otg.c) in order for it to return the appropriate PHY whenever the USB controller request for the PHY. So added a new API usb_bind_phy() to pass the binding information. This API should be called by platform specific initialization code. So the binding should be done something like usb_bind_phy(musb-hdrc.0.auto, 0, omap-usb2.1.auto); specifying the USB controller device name, index, and the PHY device name. I have done this binding for OMAP platforms, but it should be done for all the platforms. After this design, the phy can be got by passing the USB controller device pointer and the index. Developed this patch series on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv after applying usb: musb: add driver for control module patch series and ARM: dts: omap: add dt data for MUSB Did basic enumeration testing in omap4 panda and omap3 beagle. Kishon Vijay Abraham I (6): usb: otg: Add an API to bind the USB controller and PHY usb: otg: utils: add facilities in phy lib to support multiple PHYs of same type ARM: OMAP: USB: Add phy binding information drivers: usb: musb: omap: make use of the new PHY lib APIs usb: otg: add device tree support to otg library USB: MUSB: OMAP: get PHY by phandle for dt boot arch/arm/mach-omap2/board-2430sdp.c |2 + arch/arm/mach-omap2/board-3430sdp.c |2 + arch/arm/mach-omap2/board-4430sdp.c |2 + arch/arm/mach-omap2/board-cm-t35.c |2 + arch/arm/mach-omap2/board-devkit8000.c |2 + arch/arm/mach-omap2/board-igep0020.c |2 + arch/arm/mach-omap2/board-ldp.c |2 + arch/arm/mach-omap2/board-omap3beagle.c |2 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3logic.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |2 + arch/arm/mach-omap2/board-omap3stalker.c |2 + arch/arm/mach-omap2/board-omap3touchbook.c |2 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-overo.c|2 + arch/arm/mach-omap2/board-rm680.c|2 + arch/arm/mach-omap2/board-zoom-peripherals.c |2 + drivers/usb/musb/omap2430.c |7 +- drivers/usb/otg/otg.c| 228 +- drivers/usb/otg/twl4030-usb.c|3 +- drivers/usb/phy/omap-usb2.c |3 +- include/linux/usb/phy.h | 43 + 22 files changed, 314 insertions(+), 4 deletions(-) -- 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 v1 5/6] usb: otg: add device tree support to otg library
Added an API devm_usb_get_phy_by_phandle(), to get usb phy by passing a
device node phandle value. This function will return a pointer to
the phy on success, -EPROBE_DEFER if there is a device_node for the phandle,
but the phy has not been added, or a ERR_PTR() otherwise.
Cc: Marc Kleine-Budde m...@pengutronix.de
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/otg.c | 77 +++
include/linux/usb/phy.h |8 +
2 files changed, 85 insertions(+)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index 1f30b22..67daf8c 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -13,7 +13,9 @@
#include linux/export.h
#include linux/err.h
#include linux/device.h
+#include linux/module.h
#include linux/slab.h
+#include linux/of.h
#include linux/usb/otg.h
@@ -50,6 +52,20 @@ static struct usb_phy *__usb_find_phy_dev(struct device *dev,
return ERR_PTR(-ENODEV);
}
+static struct usb_phy *__of_usb_find_phy(struct device_node *node)
+{
+ struct usb_phy *phy;
+
+ list_for_each_entry(phy, phy_list, head) {
+ if (node != phy-dev-of_node)
+ continue;
+
+ return phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
static void devm_usb_phy_release(struct device *dev, void *res)
{
struct usb_phy *phy = *(struct usb_phy **)res;
@@ -125,6 +141,67 @@ err0:
}
EXPORT_SYMBOL(usb_get_phy);
+ /**
+ * devm_usb_get_phy_by_phandle - find the USB PHY by phandle
+ * @dev - device that requests this phy
+ * @phandle - name of the property holding the phy phandle value
+ * @index - the index of the phy
+ *
+ * Returns the phy driver associated with the given phandle value,
+ * after getting a refcount to it, -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded. While at that, it also associates the device with
+ * the phy using devres. On driver detach, release function is invoked
+ * on the devres data, then, devres data is freed.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
+ const char *phandle, u8 index)
+{
+ struct usb_phy *phy = NULL, **ptr;
+ unsigned long flags;
+ struct device_node *node;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, phandle, index);
+ if (!node) {
+ dev_dbg(dev, failed to get %s phandle in %s node\n, phandle,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr) {
+ dev_dbg(dev, failed to allocate memory for devres\n);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ spin_lock_irqsave(phy_lock, flags);
+
+ phy = __of_usb_find_phy(node);
+ if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
+ phy = ERR_PTR(-EPROBE_DEFER);
+ devres_free(ptr);
+ goto err0;
+ }
+
+ *ptr = phy;
+ devres_add(dev, ptr);
+
+ get_device(phy-dev);
+
+err0:
+ spin_unlock_irqrestore(phy_lock, flags);
+
+ return phy;
+}
+EXPORT_SYMBOL(devm_usb_get_phy_by_phandle);
+
/**
* usb_get_phy_dev - find the USB PHY
* @dev - device that requests this phy
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 3a9ae3e..c7f5a98 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -167,6 +167,8 @@ extern struct usb_phy *devm_usb_get_phy(struct device *dev,
enum usb_phy_type type);
extern struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index);
extern struct usb_phy *devm_usb_get_phy_dev(struct device *dev, u8 index);
+extern struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
+ const char *phandle, u8 index);
extern void usb_put_phy(struct usb_phy *);
extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
extern struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8 index,
@@ -193,6 +195,12 @@ static inline struct usb_phy *devm_usb_get_phy_dev(struct
device *dev, u8 index)
return NULL;
}
+static inline struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
+ const char *phandle, u8 index)
+{
+ return NULL;
+}
+
static inline void usb_put_phy(struct usb_phy *x)
{
}
--
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 v1 1/6] usb: otg: Add an API to bind the USB controller and PHY
In order to support platforms which has multiple PHY's (of same type) and
which has multiple USB controllers, a new design is adopted wherin the binding
information (between the PHY and the USB controller) should be passed to the
PHY library from platform specific file (board file).
So added a new API to pass the binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/otg.c | 37 +
include/linux/usb/phy.h | 22 ++
2 files changed, 59 insertions(+)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index a30c041..492ba2f 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -18,6 +18,7 @@
#include linux/usb/otg.h
static LIST_HEAD(phy_list);
+static LIST_HEAD(phy_bind_list);
static DEFINE_SPINLOCK(phy_lock);
static struct usb_phy *__usb_find_phy(struct list_head *list,
@@ -201,6 +202,42 @@ void usb_remove_phy(struct usb_phy *x)
}
EXPORT_SYMBOL(usb_remove_phy);
+/**
+ * usb_bind_phy - bind the phy and the controller that uses the phy
+ * @dev_name: the device name of the device that will bind to the phy
+ * @index: index to specify the port number
+ * @phy_dev_name: the device name of the phy
+ *
+ * Fills the phy_bind structure with the dev_name and phy_dev_name. This will
+ * be used when the phy driver registers the phy and when the controller
+ * requests this phy.
+ *
+ * To be used by platform specific initialization code.
+ */
+struct usb_phy_bind __init *usb_bind_phy(const char *dev_name, u8 index,
+ const char *phy_dev_name)
+{
+ struct usb_phy_bind *phy_bind;
+ unsigned long flags;
+
+ phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
+ if (!phy_bind) {
+ pr_err(phy_bind(): No memory for phy_bind);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ phy_bind-dev_name = dev_name;
+ phy_bind-phy_dev_name = phy_dev_name;
+ phy_bind-index = index;
+
+ spin_lock_irqsave(phy_lock, flags);
+ list_add_tail(phy_bind-list, phy_bind_list);
+ spin_unlock_irqrestore(phy_lock, flags);
+
+ return phy_bind;
+}
+EXPORT_SYMBOL_GPL(usb_bind_phy);
+
const char *otg_state_string(enum usb_otg_state state)
{
switch (state) {
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index a29ae1e..fbeab1a 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -106,6 +106,21 @@ struct usb_phy {
enum usb_device_speed speed);
};
+/**
+ * struct usb_phy_bind - represent the binding for the phy
+ * @dev_name: the device name of the device that will bind to the phy
+ * @phy_dev_name: the device name of the phy
+ * @index: used if a single controller uses multiple phys
+ * @phy: reference to the phy
+ * @list: to maintain a linked list of the binding information
+ */
+struct usb_phy_bind {
+ const char *dev_name;
+ const char *phy_dev_name;
+ u8 index;
+ struct usb_phy *phy;
+ struct list_head list;
+};
/* for board-specific init logic */
extern int usb_add_phy(struct usb_phy *, enum usb_phy_type type);
@@ -151,6 +166,8 @@ extern struct usb_phy *devm_usb_get_phy(struct device *dev,
enum usb_phy_type type);
extern void usb_put_phy(struct usb_phy *);
extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
+extern struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8 index,
+ const char *phy_dev_name);
#else
static inline struct usb_phy *usb_get_phy(enum usb_phy_type type)
{
@@ -171,6 +188,11 @@ static inline void devm_usb_put_phy(struct device *dev,
struct usb_phy *x)
{
}
+static inline struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8 index,
+ const char *phy_dev_name)
+{
+ return NULL;
+}
#endif
static inline int
--
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 v1 2/6] usb: otg: utils: add facilities in phy lib to support multiple PHYs of same type
In order to add support for multipe PHY's of the same type, new API's
for adding PHY and getting PHY has been added. Now the binding
information for the PHY and controller should be done in platform file
using usb_bind_phy API. And for getting a PHY, the device pointer of the
USB controller and an index should be passed. Based on the binding
information that is added in the platform file, usb_get_phy_dev will return the
appropriate PHY.
Already existing API's to add and get phy by type is not removed. These
API's are deprecated and will be removed once all the platforms start to
use the new API.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/otg.c | 114 ++-
include/linux/usb/phy.h | 13 ++
2 files changed, 126 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index 492ba2f..1f30b22 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -36,6 +36,20 @@ static struct usb_phy *__usb_find_phy(struct list_head *list,
return ERR_PTR(-ENODEV);
}
+static struct usb_phy *__usb_find_phy_dev(struct device *dev,
+ struct list_head *list, u8 index)
+{
+ struct usb_phy_bind *phy_bind = NULL;
+
+ list_for_each_entry(phy_bind, list, list) {
+ if (!(strcmp(phy_bind-dev_name, dev_name(dev)))
+ phy_bind-index == index)
+ return phy_bind-phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
static void devm_usb_phy_release(struct device *dev, void *res)
{
struct usb_phy *phy = *(struct usb_phy **)res;
@@ -112,6 +126,69 @@ err0:
EXPORT_SYMBOL(usb_get_phy);
/**
+ * usb_get_phy_dev - find the USB PHY
+ * @dev - device that requests this phy
+ * @index - the index of the phy
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy. The caller is responsible for
+ * calling usb_put_phy() to release that count.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index)
+{
+ struct usb_phy *phy = NULL;
+ unsigned long flags;
+
+ spin_lock_irqsave(phy_lock, flags);
+
+ phy = __usb_find_phy_dev(dev, phy_bind_list, index);
+ if (IS_ERR(phy)) {
+ pr_err(unable to find transceiver\n);
+ goto err0;
+ }
+
+ get_device(phy-dev);
+
+err0:
+ spin_unlock_irqrestore(phy_lock, flags);
+
+ return phy;
+}
+EXPORT_SYMBOL(usb_get_phy_dev);
+
+/**
+ * devm_usb_get_phy_dev - find the USB PHY using device ptr and index
+ * @dev - device that requests this phy
+ * @index - the index of the phy
+ *
+ * Gets the phy using usb_get_phy_dev(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *devm_usb_get_phy_dev(struct device *dev, u8 index)
+{
+ struct usb_phy **ptr, *phy;
+
+ ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ phy = usb_get_phy_dev(dev, index);
+ if (!IS_ERR(phy)) {
+ *ptr = phy;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return phy;
+}
+EXPORT_SYMBOL(devm_usb_get_phy_dev);
+
+/**
* devm_usb_put_phy - release the USB PHY
* @dev - device that wants to release this phy
* @phy - the phy returned by devm_usb_get_phy()
@@ -186,6 +263,36 @@ out:
EXPORT_SYMBOL(usb_add_phy);
/**
+ * usb_add_phy_dev - declare the USB PHY
+ * @x: the USB phy to be used; or NULL
+ *
+ * This call is exclusively for use by phy drivers, which
+ * coordinate the activities of drivers for host and peripheral
+ * controllers, and in some cases for VBUS current regulation.
+ */
+int usb_add_phy_dev(struct usb_phy *x)
+{
+ struct usb_phy_bind *phy_bind;
+ unsigned long flags;
+
+ if (!x-dev) {
+ dev_err(x-dev, no device provided for PHY\n);
+ return -EINVAL;
+ }
+
+ spin_lock_irqsave(phy_lock, flags);
+ list_for_each_entry(phy_bind, phy_bind_list, list)
+ if (!(strcmp(phy_bind-phy_dev_name, dev_name(x-dev
+ phy_bind-phy = x;
+
+ list_add_tail(x-head, phy_list);
+
+ spin_unlock_irqrestore(phy_lock, flags);
+ return 0;
+}
+EXPORT_SYMBOL(usb_add_phy_dev);
+
+/**
* usb_remove_phy - remove the OTG PHY
* @x: the USB OTG PHY to be removed;
*
@@ -194,10 +301,15 @@ EXPORT_SYMBOL(usb_add_phy);
void usb_remove_phy(struct usb_phy *x)
{
unsigned long flags;
+ struct usb_phy_bind *phy_bind;
spin_lock_irqsave(phy_lock, flags);
- if (x)
+ if (x) {
+ list_for_each_entry(phy_bind, phy_bind_list, list)
+ if (phy_bind-phy == x)
+
[PATCH v1 4/6] drivers: usb: musb: omap: make use of the new PHY lib APIs
New PHY lib APIs like usb_add_phy_dev() and devm_usb_get_phy_dev() are
used in MUSB (OMAP), in order to make use of the binding information
provided in the board file (of OMAP platforms).
All the platforms should be modified similar to this to add and get the
PHY.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c |2 +-
drivers/usb/otg/twl4030-usb.c |3 ++-
drivers/usb/phy/omap-usb2.c |3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index bf6cfe0..1a8cf6d 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -345,7 +345,7 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
- musb-xceiv = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ musb-xceiv = devm_usb_get_phy_dev(dev, 0);
if (IS_ERR_OR_NULL(musb-xceiv)) {
pr_err(HS USB OTG: no transceiver configured\n);
return -ENODEV;
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 0a70193..a994715 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -610,6 +610,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl-phy.dev= twl-dev;
twl-phy.label = twl4030;
twl-phy.otg= otg;
+ twl-phy.type = USB_PHY_TYPE_USB2;
twl-phy.set_suspend= twl4030_set_suspend;
otg-phy= twl-phy;
@@ -624,7 +625,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
dev_err(pdev-dev, ldo init failed\n);
return err;
}
- usb_add_phy(twl-phy, USB_PHY_TYPE_USB2);
+ usb_add_phy_dev(twl-phy);
platform_set_drvdata(pdev, twl);
if (device_create_file(pdev-dev, dev_attr_vbus))
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 4b59b39..b5c759c 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -143,6 +143,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-phy.label = omap-usb2;
phy-phy.set_suspend= omap_usb2_suspend;
phy-phy.otg= otg;
+ phy-phy.type = USB_PHY_TYPE_USB2;
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -168,7 +169,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
clk_prepare(phy-wkupclk);
- usb_add_phy(phy-phy, USB_PHY_TYPE_USB2);
+ usb_add_phy_dev(phy-phy);
platform_set_drvdata(pdev, phy);
--
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 v1 3/6] ARM: OMAP: USB: Add phy binding information
This is w.r.t the changes in PHY library to support adding and getting multiple PHYs of the same type. In the new design, the binding information between the PHY and the USB controller should be specified in the platform specific initialization code. So it's been done here for OMAP platforms. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/mach-omap2/board-2430sdp.c |2 ++ arch/arm/mach-omap2/board-3430sdp.c |2 ++ arch/arm/mach-omap2/board-4430sdp.c |2 ++ arch/arm/mach-omap2/board-cm-t35.c |2 ++ arch/arm/mach-omap2/board-devkit8000.c |2 ++ arch/arm/mach-omap2/board-igep0020.c |2 ++ arch/arm/mach-omap2/board-ldp.c |2 ++ arch/arm/mach-omap2/board-omap3beagle.c |2 ++ arch/arm/mach-omap2/board-omap3evm.c |2 ++ arch/arm/mach-omap2/board-omap3logic.c |2 ++ arch/arm/mach-omap2/board-omap3pandora.c |2 ++ arch/arm/mach-omap2/board-omap3stalker.c |2 ++ arch/arm/mach-omap2/board-omap3touchbook.c |2 ++ arch/arm/mach-omap2/board-omap4panda.c |2 ++ arch/arm/mach-omap2/board-overo.c|2 ++ arch/arm/mach-omap2/board-rm680.c|2 ++ arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++ 17 files changed, 34 insertions(+) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index 4815ea6..1337f2c 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -27,6 +27,7 @@ #include linux/clk.h #include linux/io.h #include linux/gpio.h +#include linux/usb/phy.h #include asm/mach-types.h #include asm/mach/arch.h @@ -263,6 +264,7 @@ static void __init omap_2430sdp_init(void) omap_hsmmc_init(mmc); omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA | OMAP_PULL_UP); + usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); board_smc91x_init(); diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index bb73afc..8a2e242 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -25,6 +25,7 @@ #include linux/gpio.h #include linux/mmc/host.h #include linux/platform_data/spi-omap2-mcspi.h +#include linux/usb/phy.h #include asm/mach-types.h #include asm/mach/arch.h @@ -579,6 +580,7 @@ static void __init omap_3430sdp_init(void) omap_ads7846_init(1, gpio_pendown, 310, NULL); omap_serial_init(); omap_sdrc_init(hyb18m512160af6_sdrc_params, NULL); + usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); board_smc91x_init(); board_flash_init(sdp_flash_partitions, chip_sel_3430, 0); diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 1cc6696..8e8efcc 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -28,6 +28,7 @@ #include linux/leds_pwm.h #include linux/platform_data/omap4-keypad.h #include linux/usb/musb.h +#include linux/usb/phy.h #include asm/hardware/gic.h #include asm/mach-types.h @@ -696,6 +697,7 @@ static void __init omap_4430sdp_init(void) omap4_sdp4430_wifi_init(); omap4_twl6030_hsmmc_init(mmc); + usb_bind_phy(musb-hdrc.0.auto, 0, omap-usb2.1.auto); usb_musb_init(musb_board_data); status = omap_ethernet_init(); diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index b3102c2..f1172f2 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -30,6 +30,7 @@ #include linux/regulator/fixed.h #include linux/regulator/machine.h #include linux/mmc/host.h +#include linux/usb/phy.h #include linux/spi/spi.h #include linux/spi/tdo24m.h @@ -724,6 +725,7 @@ static void __init cm_t3x_common_init(void) cm_t35_init_display(); omap_twl4030_audio_init(cm-t3x); + usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); cm_t35_init_usbh(); cm_t35_init_camera(); diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c index 12865af..77cade52 100644 --- a/arch/arm/mach-omap2/board-devkit8000.c +++ b/arch/arm/mach-omap2/board-devkit8000.c @@ -29,6 +29,7 @@ #include linux/mtd/partitions.h #include linux/mtd/nand.h #include linux/mmc/host.h +#include linux/usb/phy.h #include linux/regulator/machine.h #include linux/i2c/twl.h @@ -622,6 +623,7 @@ static void __init devkit8000_init(void) omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL); + usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); usbhs_init(usbhs_bdata); board_nand_init(devkit8000_nand_partitions, diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c index 0f24cb8..15e5881 100644 ---
[PATCH v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
The OMAP glue has been modified to get PHY by phandle for dt boot.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1a8cf6d..e43faeb 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -345,7 +345,12 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
- musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+ if (dev-parent-of_node)
+ musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
+ usb_phy, 0);
+ else
+ musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+
if (IS_ERR_OR_NULL(musb-xceiv)) {
pr_err(HS USB OTG: no transceiver configured\n);
return -ENODEV;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] HID: add support for Sony RF receiver with USB product id 0x0374
On Tue, 22 Jan 2013, Fernando Luis Vazquez Cao wrote: If possible, I would like to get it backported to 3.7-stable (and possibly 3.2 stable), since without it a whole family of Sony desktop computers is unusable under Linux out of the box. Should I do it myself or do you have a process in place for HID stable patches? If the patch had Cc: sta...@vger.kernel.org in it, it'd be picked for -stable queue automatically. I considered doing that but I thought and upstream commit ID was needed. Yes, that's necessary in case you are cherry-picking a commit already present in Linus' tree that doesn't have explicit Cc: sta...@vger.kernel.org. Otherwise, -stable tree maintainer is automatically picking up commits that appear in Linus tree with this tag. Otherwise, anyone is free to take it once it's in Linus' tree and sent to to sta...@vger.kernel.org for inclusion. So it is the standard procedure. I just wanted to make sure whether you wanted to have all the -stable patches funnelled through you. It's not strictly necessary. I get copied on them when they are queued in -stable queue anyway. By the way, I will be replying to this email with a follow-up patch that I forgot to send the last time around. It is just documentation for the quirk. Ok, thanks. -- Jiri Kosina SUSE Labs -- 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: HID: clean up quirk for Sony RF receivers
On Tue, 22 Jan 2013, Fernando Luis Vázquez Cao wrote: Document what the fix-up is does and make it more robust by ensuring that it is only applied to the USB interface that corresponds to the mouse (sony_report_fixup() is called once per interface during probing). Applied. -- Jiri Kosina SUSE Labs -- 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 net 3/3] net: cdc_ncm: fix error path for single interface probing
Oliver Neukum oneu...@suse.de writes: On Monday 21 January 2013 16:50:40 Bjørn Mork wrote: commit bbc8d92 (net: cdc_ncm: add Huawei devices) implemented support for devices with a single combined control and data interface. Fix up the error path so that we do not double release such interfaces in case of probing failures. Hi Bjørn, this should go also into stable. Could you submit? Yes, it should. But AFAIK David prefers to do the stable submissions for net, including drivers/net/usb. 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: [PATCH net] net: cdc_ncm: workaround for missing CDC Union
Oliver Neukum oneu...@suse.de writes:
On Monday 21 January 2013 16:28:48 Bjørn Mork wrote:
Agreed. But I believe the condition should be
if (!(info-flags FLAG_SEND_ZLP) !(info-flags FLAG_MULTI_PACKET)) {
..
} else {
urb-transfer_flags |= URB_ZERO_PACKET;
}
to ensure that we send the ZLP in this case.
Why? If a driver wants ZLP, it can set FLAG_SEND_ZLP. Your proposed change
would take away an option from drivers without any gain.
OK.
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: [PATCH v1 5/6] usb: otg: add device tree support to otg library
+struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
+ const char *phandle, u8 index)
+{
+ struct usb_phy *phy = NULL, **ptr;
+ unsigned long flags;
+ struct device_node *node;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, phandle, index);
+ if (!node) {
+ dev_dbg(dev, failed to get %s phandle in %s node\n, phandle,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
At any point past this, node's refcount is incremented (done automatically by
of_parse_phandle = of_find_node_by_phandle).
+
+ ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr) {
+ dev_dbg(dev, failed to allocate memory for devres\n);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ spin_lock_irqsave(phy_lock, flags);
+
+ phy = __of_usb_find_phy(node);
+ if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
+ phy = ERR_PTR(-EPROBE_DEFER);
+ devres_free(ptr);
+ goto err0;
+ }
+
+ *ptr = phy;
+ devres_add(dev, ptr);
+
+ get_device(phy-dev);
+
+err0:
+ spin_unlock_irqrestore(phy_lock, flags);
+
+ return phy;
+}
This means that on all of the exit paths, node's refcount is left incremented
incorrectly. You'll need an of_node_put(node) on each exit path.
Thanks,
Mark.
--
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: phy: moving all PHY API definitions to usb/phy directory
As drivers/usb/otg/otg.c contains most of the PHY related APIs
which are not OTG specific, moving them to more logical place
under driver/usb/phy.
Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com
---
drivers/usb/otg/otg.c| 184 --
drivers/usb/phy/Makefile |1 +
2 files changed, 1 insertions(+), 184 deletions(-)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index a30c041..95561b9 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -17,190 +17,6 @@
#include linux/usb/otg.h
-static LIST_HEAD(phy_list);
-static DEFINE_SPINLOCK(phy_lock);
-
-static struct usb_phy *__usb_find_phy(struct list_head *list,
- enum usb_phy_type type)
-{
- struct usb_phy *phy = NULL;
-
- list_for_each_entry(phy, list, head) {
- if (phy-type != type)
- continue;
-
- return phy;
- }
-
- return ERR_PTR(-ENODEV);
-}
-
-static void devm_usb_phy_release(struct device *dev, void *res)
-{
- struct usb_phy *phy = *(struct usb_phy **)res;
-
- usb_put_phy(phy);
-}
-
-static int devm_usb_phy_match(struct device *dev, void *res, void *match_data)
-{
- return res == match_data;
-}
-
-/**
- * devm_usb_get_phy - find the USB PHY
- * @dev - device that requests this phy
- * @type - the type of the phy the controller requires
- *
- * Gets the phy using usb_get_phy(), and associates a device with it using
- * devres. On driver detach, release function is invoked on the devres data,
- * then, devres data is freed.
- *
- * For use by USB host and peripheral drivers.
- */
-struct usb_phy *devm_usb_get_phy(struct device *dev, enum usb_phy_type type)
-{
- struct usb_phy **ptr, *phy;
-
- ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
- if (!ptr)
- return NULL;
-
- phy = usb_get_phy(type);
- if (!IS_ERR(phy)) {
- *ptr = phy;
- devres_add(dev, ptr);
- } else
- devres_free(ptr);
-
- return phy;
-}
-EXPORT_SYMBOL(devm_usb_get_phy);
-
-/**
- * usb_get_phy - find the USB PHY
- * @type - the type of the phy the controller requires
- *
- * Returns the phy driver, after getting a refcount to it; or
- * -ENODEV if there is no such phy. The caller is responsible for
- * calling usb_put_phy() to release that count.
- *
- * For use by USB host and peripheral drivers.
- */
-struct usb_phy *usb_get_phy(enum usb_phy_type type)
-{
- struct usb_phy *phy = NULL;
- unsigned long flags;
-
- spin_lock_irqsave(phy_lock, flags);
-
- phy = __usb_find_phy(phy_list, type);
- if (IS_ERR(phy)) {
- pr_err(unable to find transceiver of type %s\n,
- usb_phy_type_string(type));
- goto err0;
- }
-
- get_device(phy-dev);
-
-err0:
- spin_unlock_irqrestore(phy_lock, flags);
-
- return phy;
-}
-EXPORT_SYMBOL(usb_get_phy);
-
-/**
- * devm_usb_put_phy - release the USB PHY
- * @dev - device that wants to release this phy
- * @phy - the phy returned by devm_usb_get_phy()
- *
- * destroys the devres associated with this phy and invokes usb_put_phy
- * to release the phy.
- *
- * For use by USB host and peripheral drivers.
- */
-void devm_usb_put_phy(struct device *dev, struct usb_phy *phy)
-{
- int r;
-
- r = devres_destroy(dev, devm_usb_phy_release, devm_usb_phy_match, phy);
- dev_WARN_ONCE(dev, r, couldn't find PHY resource\n);
-}
-EXPORT_SYMBOL(devm_usb_put_phy);
-
-/**
- * usb_put_phy - release the USB PHY
- * @x: the phy returned by usb_get_phy()
- *
- * Releases a refcount the caller received from usb_get_phy().
- *
- * For use by USB host and peripheral drivers.
- */
-void usb_put_phy(struct usb_phy *x)
-{
- if (x)
- put_device(x-dev);
-}
-EXPORT_SYMBOL(usb_put_phy);
-
-/**
- * usb_add_phy - declare the USB PHY
- * @x: the USB phy to be used; or NULL
- * @type - the type of this PHY
- *
- * This call is exclusively for use by phy drivers, which
- * coordinate the activities of drivers for host and peripheral
- * controllers, and in some cases for VBUS current regulation.
- */
-int usb_add_phy(struct usb_phy *x, enum usb_phy_type type)
-{
- int ret = 0;
- unsigned long flags;
- struct usb_phy *phy;
-
- if (x-type != USB_PHY_TYPE_UNDEFINED) {
- dev_err(x-dev, not accepting initialized PHY %s\n, x-label);
- return -EINVAL;
- }
-
- spin_lock_irqsave(phy_lock, flags);
-
- list_for_each_entry(phy, phy_list, head) {
- if (phy-type == type) {
- ret = -EBUSY;
- dev_err(x-dev, transceiver type %s already exists\n,
- usb_phy_type_string(type));
- goto out;
- }
- }
-
- x-type = type;
- list_add_tail(x-head, phy_list);
Re: [PATCH] usb: phy: moving all PHY API definitions to usb/phy directory
HI, On Tue, Jan 22, 2013 at 04:26:50PM +0530, Venu Byravarasu wrote: As drivers/usb/otg/otg.c contains most of the PHY related APIs which are not OTG specific, moving them to more logical place under driver/usb/phy. Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com --- drivers/usb/otg/otg.c| 184 -- drivers/usb/phy/Makefile |1 + missed git add of the new file, but hey, let's call it phy.c and place it on drivers/usb/phy/phy.c Also, you will have to rebase on top of Kishon's latest work which I'll apply first. -- balbi signature.asc Description: Digital signature
[PATCH v2] usb: phy: moving all PHY API definitions to usb/phy directory
As drivers/usb/otg/otg.c contains most of the PHY related APIs
which are not OTG specific, moving them to more logical place
under driver/usb/phy.
Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com
---
delta from v1:
Missed adding newly created file usb_phy.c with previous patch.
hence sending v2, after adding that.
drivers/usb/otg/otg.c| 184 --
drivers/usb/phy/Makefile |1 +
drivers/usb/{otg/otg.c = phy/usb_phy.c} | 45 +---
3 files changed, 6 insertions(+), 224 deletions(-)
copy drivers/usb/{otg/otg.c = phy/usb_phy.c} (82%)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index a30c041..95561b9 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -17,190 +17,6 @@
#include linux/usb/otg.h
-static LIST_HEAD(phy_list);
-static DEFINE_SPINLOCK(phy_lock);
-
-static struct usb_phy *__usb_find_phy(struct list_head *list,
- enum usb_phy_type type)
-{
- struct usb_phy *phy = NULL;
-
- list_for_each_entry(phy, list, head) {
- if (phy-type != type)
- continue;
-
- return phy;
- }
-
- return ERR_PTR(-ENODEV);
-}
-
-static void devm_usb_phy_release(struct device *dev, void *res)
-{
- struct usb_phy *phy = *(struct usb_phy **)res;
-
- usb_put_phy(phy);
-}
-
-static int devm_usb_phy_match(struct device *dev, void *res, void *match_data)
-{
- return res == match_data;
-}
-
-/**
- * devm_usb_get_phy - find the USB PHY
- * @dev - device that requests this phy
- * @type - the type of the phy the controller requires
- *
- * Gets the phy using usb_get_phy(), and associates a device with it using
- * devres. On driver detach, release function is invoked on the devres data,
- * then, devres data is freed.
- *
- * For use by USB host and peripheral drivers.
- */
-struct usb_phy *devm_usb_get_phy(struct device *dev, enum usb_phy_type type)
-{
- struct usb_phy **ptr, *phy;
-
- ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
- if (!ptr)
- return NULL;
-
- phy = usb_get_phy(type);
- if (!IS_ERR(phy)) {
- *ptr = phy;
- devres_add(dev, ptr);
- } else
- devres_free(ptr);
-
- return phy;
-}
-EXPORT_SYMBOL(devm_usb_get_phy);
-
-/**
- * usb_get_phy - find the USB PHY
- * @type - the type of the phy the controller requires
- *
- * Returns the phy driver, after getting a refcount to it; or
- * -ENODEV if there is no such phy. The caller is responsible for
- * calling usb_put_phy() to release that count.
- *
- * For use by USB host and peripheral drivers.
- */
-struct usb_phy *usb_get_phy(enum usb_phy_type type)
-{
- struct usb_phy *phy = NULL;
- unsigned long flags;
-
- spin_lock_irqsave(phy_lock, flags);
-
- phy = __usb_find_phy(phy_list, type);
- if (IS_ERR(phy)) {
- pr_err(unable to find transceiver of type %s\n,
- usb_phy_type_string(type));
- goto err0;
- }
-
- get_device(phy-dev);
-
-err0:
- spin_unlock_irqrestore(phy_lock, flags);
-
- return phy;
-}
-EXPORT_SYMBOL(usb_get_phy);
-
-/**
- * devm_usb_put_phy - release the USB PHY
- * @dev - device that wants to release this phy
- * @phy - the phy returned by devm_usb_get_phy()
- *
- * destroys the devres associated with this phy and invokes usb_put_phy
- * to release the phy.
- *
- * For use by USB host and peripheral drivers.
- */
-void devm_usb_put_phy(struct device *dev, struct usb_phy *phy)
-{
- int r;
-
- r = devres_destroy(dev, devm_usb_phy_release, devm_usb_phy_match, phy);
- dev_WARN_ONCE(dev, r, couldn't find PHY resource\n);
-}
-EXPORT_SYMBOL(devm_usb_put_phy);
-
-/**
- * usb_put_phy - release the USB PHY
- * @x: the phy returned by usb_get_phy()
- *
- * Releases a refcount the caller received from usb_get_phy().
- *
- * For use by USB host and peripheral drivers.
- */
-void usb_put_phy(struct usb_phy *x)
-{
- if (x)
- put_device(x-dev);
-}
-EXPORT_SYMBOL(usb_put_phy);
-
-/**
- * usb_add_phy - declare the USB PHY
- * @x: the USB phy to be used; or NULL
- * @type - the type of this PHY
- *
- * This call is exclusively for use by phy drivers, which
- * coordinate the activities of drivers for host and peripheral
- * controllers, and in some cases for VBUS current regulation.
- */
-int usb_add_phy(struct usb_phy *x, enum usb_phy_type type)
-{
- int ret = 0;
- unsigned long flags;
- struct usb_phy *phy;
-
- if (x-type != USB_PHY_TYPE_UNDEFINED) {
- dev_err(x-dev, not accepting initialized PHY %s\n, x-label);
- return -EINVAL;
- }
-
- spin_lock_irqsave(phy_lock, flags);
-
- list_for_each_entry(phy, phy_list, head) {
- if (phy-type == type) {
- ret = -EBUSY;
- dev_err(x-dev,
Re: [PATCH] usb: gadget: nokia: Add mass storage driver to g_nokia
On Monday 21 January 2013 09:05:06 Felipe Balbi wrote:
Hi,
On Sun, Jan 20, 2013 at 11:17:31AM +0100, Pali Rohár wrote:
On Sunday 20 January 2013 10:25:37 Felipe Balbi wrote:
On Sun, Jan 20, 2013 at 03:58:13AM +0100, Pali Rohár wrote:
Signed-off-by: Pali Rohár pali.ro...@gmail.com
NAK for two reasons:
a) the original Nokia kernel used a separate
g_file_storage gadget to use Mass Storage mode, use that
b) there is no commit log
Reason why add mass storage mode to g_nokia is to avoid
switching between g_{file,mass}_storage and g_nokia and to
have one gadget driver for Nokia N900. It is better to have
usb network and mass storage mode in one driver (and not to
unload load another).
I tested this patch with 3.8-rc3 kernel on Nokia N900 and
usb network with mass storage mode working without
problems.
Doesn't matter, in this case this is something which nokia
wrote to carry on their Maemo/MeeGo devices so unless someone
from Nokia says this is how they want to use nokia.c from now
on, I can't simply risk breaking all other users for your own
convenience.
Hello,
you may know that Nokia not working on any linux Maemo/MeeGo
systems anymore. And also that Nokia devices needs own patched
kernel. Also g_nokia gadget is for Nokia N900 and this device
with original Maemo 5 system which was supported by Nokia is
locked for patched 2.6.28 kernel. More drivers in 2.6.28 was not
upstreamed, so running other kernels will not work without
problems. And waiting what Nokia say is now irrelevant, because
N900 is at end-of-live cycle and Nokia not doing with linux
devices anymore. So I do not understand why current code cannot
be extended for more functionality. Because patch is not signed
by Nokia?
There are more developers which playing with upstream kernel on
Nokia N900 and trying to use some modern linux distribution on
it. And who using upstream kernels on N900 also want some
additional functionality which was not in 2.6.28. And having mass
storage in g_nokia is usefull.
Also you can see that this patch simply adding new composite
gadget to exisitng driver. Nothing is removed, so original code
is compatible with these changes. If somebody still want (for
some reason) to switching between g_nokia and g_file_storage (ops,
it was renamed to g_mass_storage, so now it is broken on old
Nokia systems...) it is still possible.
And when I looked into nokia 2.6.28 kernel, they also patched
g_file_storage, so I think it is incompatible with upstream too.
So why to care about current API implementation in upstream
kernel (do not allow to add new functionality) which is
incompatible with Nokia patched kernel?
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
RE: [PATCH] usb: phy: moving all PHY API definitions to usb/phy directory
-Original Message- From: Felipe Balbi [mailto:ba...@ti.com] Sent: Tuesday, January 22, 2013 4:31 PM To: Venu Byravarasu Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH] usb: phy: moving all PHY API definitions to usb/phy directory * PGP Signed by an unknown key HI, On Tue, Jan 22, 2013 at 04:26:50PM +0530, Venu Byravarasu wrote: As drivers/usb/otg/otg.c contains most of the PHY related APIs which are not OTG specific, moving them to more logical place under driver/usb/phy. Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com --- drivers/usb/otg/otg.c| 184 -- drivers/usb/phy/Makefile |1 + missed git add of the new file, but hey, let's call it phy.c and place it on drivers/usb/phy/phy.c Yeah, I used git commit -a missed adding new file. Just few min back, sent a patch update. Also, you will have to rebase on top of Kishon's latest work which I'll apply first. That's fine. I'll rebase on top of Kishon's latest work and send v3. In that v3 patch, will rename the file as phy.c, as you suggested above. -- balbi * Unknown Key * 0x35CAA444 -- 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: phy: moving all PHY API definitions to usb/phy directory
Hi,
On Tue, Jan 22, 2013 at 04:31:11PM +0530, Venu Byravarasu wrote:
As drivers/usb/otg/otg.c contains most of the PHY related APIs
which are not OTG specific, moving them to more logical place
under driver/usb/phy.
Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com
---
delta from v1:
Missed adding newly created file usb_phy.c with previous patch.
hence sending v2, after adding that.
drivers/usb/otg/otg.c| 184
--
drivers/usb/phy/Makefile |1 +
drivers/usb/{otg/otg.c = phy/usb_phy.c} | 45 +---
let's call this file phy.c or phy-core.c.
--
balbi
signature.asc
Description: Digital signature
[PATCH v8 0/4] Adding usb2.0 host-phy support for exynos5250
Changes from v7: - Rebased on 'xceive' of Balbi's usb tree. - Placing proper Acked By's received for each patch. Changes from v6: - Changing macro names from 'HOST_CTRL0_FSEL_CLKSEL_XX' to 'FSEL_CLKSEL_XX' since it's being used by HOST and OTG block to prepare reference clock. - Directly Assigning 'FSEL_CLKSEL_XX' to refclk_freq in samsung_usbphy_get_refclk_freq() instead of ORing them since we are anyways using macros: HOST_CTRL0_FSEL(_x)((_x) 16) OTG_SYS_FSEL(_x) ((_x) 4) Changes from v5: - Adding hostphy enable mask and hostphy register offsets to driver data in order to access the HOSTPHY CONTROL register. - Adding member 'otg' to struct samsung-usbphy so that its consumers can call otg-set_host so as to make 'phy' aware of the consumer type: HOST/DEVICE - Adding 'otg' to 'struct s5p_ehci_hcd' and 'struct exynos_ohci_hcd' which keeps track of 'otg' of the controllers' phy. This then sets the host. - Moved samsung_usbphy_set_type() calls from ehci-s5p and ohci-exynos to phy driver itself where based on phy_type it is called. - Added separate macro definition for USB20PHY_CFG register to select between host/device type usb link. - Removing unnecessary argument 'phy_type' from samsung_usbphy_set_type() and samsung_usbphy_cfg_sel(). - Addressed few nits: -- added macro for 'KHZ' -- removing useless 'if' from samsung_usbphy_cfg_sel() -- keeping the place of clk_get intact and requesting driver data before that. Vivek Gautam (4): ARM: EXYNOS: Update move usb-phy types to generic include layer usb: phy: samsung: Add host phy support to samsung-phy driver USB: ehci-s5p: Add phy driver support USB: ohci-exynos: Add phy driver support .../devicetree/bindings/usb/samsung-usbphy.txt | 12 +- drivers/usb/host/ehci-s5p.c| 81 +++- drivers/usb/host/ohci-exynos.c | 85 +++- drivers/usb/phy/Kconfig|2 +- drivers/usb/phy/samsung-usbphy.c | 513 ++-- include/linux/usb/samsung_usb_phy.h| 16 + 6 files changed, 636 insertions(+), 73 deletions(-) create mode 100644 include/linux/usb/samsung_usb_phy.h -- 1.7.6.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 v8 1/4] ARM: EXYNOS: Update move usb-phy types to generic include layer
Updating the names of usb-phy types to more generic names:
USB_PHY_TYPE_DEIVCE USB_PHY_TYPE_HOST; and further update
its dependencies.
Signed-off-by: Praveen Paneri p.pan...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
---
drivers/usb/host/ehci-s5p.c |9 +
drivers/usb/host/ohci-exynos.c |9 +
include/linux/usb/samsung_usb_phy.h | 16
3 files changed, 26 insertions(+), 8 deletions(-)
create mode 100644 include/linux/usb/samsung_usb_phy.h
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 319dcfa..46ca5ef 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -17,6 +17,7 @@
#include linux/platform_device.h
#include linux/of_gpio.h
#include linux/platform_data/usb-ehci-s5p.h
+#include linux/usb/samsung_usb_phy.h
#include plat/usb-phy.h
#define EHCI_INSNREG00(base) (base + 0x90)
@@ -164,7 +165,7 @@ static int s5p_ehci_probe(struct platform_device *pdev)
}
if (pdata-phy_init)
- pdata-phy_init(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
ehci = hcd_to_ehci(hcd);
ehci-caps = hcd-regs;
@@ -198,7 +199,7 @@ static int s5p_ehci_remove(struct platform_device *pdev)
usb_remove_hcd(hcd);
if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
clk_disable_unprepare(s5p_ehci-clk);
@@ -229,7 +230,7 @@ static int s5p_ehci_suspend(struct device *dev)
rc = ehci_suspend(hcd, do_wakeup);
if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
clk_disable_unprepare(s5p_ehci-clk);
@@ -246,7 +247,7 @@ static int s5p_ehci_resume(struct device *dev)
clk_prepare_enable(s5p_ehci-clk);
if (pdata pdata-phy_init)
- pdata-phy_init(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
/* DMA burst Enable */
writel(EHCI_INSNREG00_ENABLE_DMA_BURST, EHCI_INSNREG00(hcd-regs));
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index aa3b884..804fb62 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -15,6 +15,7 @@
#include linux/of.h
#include linux/platform_device.h
#include linux/platform_data/usb-exynos.h
+#include linux/usb/samsung_usb_phy.h
#include plat/usb-phy.h
struct exynos_ohci_hcd {
@@ -153,7 +154,7 @@ static int exynos_ohci_probe(struct platform_device *pdev)
}
if (pdata-phy_init)
- pdata-phy_init(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
ohci = hcd_to_ohci(hcd);
ohci_hcd_init(ohci);
@@ -184,7 +185,7 @@ static int exynos_ohci_remove(struct platform_device *pdev)
usb_remove_hcd(hcd);
if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
clk_disable_unprepare(exynos_ohci-clk);
@@ -229,7 +230,7 @@ static int exynos_ohci_suspend(struct device *dev)
clear_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
clk_disable_unprepare(exynos_ohci-clk);
@@ -249,7 +250,7 @@ static int exynos_ohci_resume(struct device *dev)
clk_prepare_enable(exynos_ohci-clk);
if (pdata pdata-phy_init)
- pdata-phy_init(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
ohci_resume(hcd, false);
diff --git a/include/linux/usb/samsung_usb_phy.h
b/include/linux/usb/samsung_usb_phy.h
new file mode 100644
index 000..9167826
--- /dev/null
+++ b/include/linux/usb/samsung_usb_phy.h
@@ -0,0 +1,16 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * http://www.samsung.com/
+ *
+ * Defines phy types for samsung usb phy controllers - HOST or DEIVCE.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+enum samsung_usb_phy_type {
+ USB_PHY_TYPE_DEVICE,
+ USB_PHY_TYPE_HOST,
+};
--
1.7.6.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 v8 2/4] usb: phy: samsung: Add host phy support to samsung-phy driver
This patch adds host phy support to samsung-usbphy driver and further adds support for samsung's exynos5250 usb-phy. Signed-off-by: Praveen Paneri p.pan...@samsung.com Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Acked-by: Kukjin Kim kgene@samsung.com --- .../devicetree/bindings/usb/samsung-usbphy.txt | 12 +- drivers/usb/phy/Kconfig|2 +- drivers/usb/phy/samsung-usbphy.c | 513 ++-- 3 files changed, 496 insertions(+), 31 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt index 22d06cf..0331949 100644 --- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -1,15 +1,23 @@ * Samsung's usb phy transceiver -The Samsung's phy transceiver is used for controlling usb otg phy for -s3c-hsotg usb device controller. +The Samsung's phy transceiver is used for controlling usb phy for +s3c-hsotg as well as ehci-s5p and ohci-exynos usb controllers +across Samsung SOCs. TODO: Adding the PHY binding with controller(s) according to the under developement generic PHY driver. Required properties: + +Exynos4210: - compatible : should be samsung,exynos4210-usbphy - reg : base physical address of the phy registers and length of memory mapped region. +Exynos5250: +- compatible : should be samsung,exynos5250-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. + Optional properties: - #address-cells: should be '1' when usbphy node has a child node with 'reg' property. diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 36a85b6..fae4d08 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -48,7 +48,7 @@ config USB_RCAR_PHY config SAMSUNG_USBPHY bool Samsung USB PHY controller Driver - depends on USB_S3C_HSOTG + depends on USB_S3C_HSOTG || USB_EHCI_S5P || USB_OHCI_EXYNOS select USB_OTG_UTILS help Enable this to support Samsung USB phy controller for samsung diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c index 30aebb5..9e9861c 100644 --- a/drivers/usb/phy/samsung-usbphy.c +++ b/drivers/usb/phy/samsung-usbphy.c @@ -5,7 +5,8 @@ * * Author: Praveen Paneri p.pan...@samsung.com * - * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * Samsung USB2.0 PHY transceiver; talks to S3C HS OTG controller, EHCI-S5P and + * OHCI-EXYNOS controllers. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -21,11 +22,13 @@ #include linux/platform_device.h #include linux/clk.h #include linux/delay.h +#include linux/device.h #include linux/err.h #include linux/io.h #include linux/of.h #include linux/of_address.h #include linux/usb/otg.h +#include linux/usb/samsung_usb_phy.h #include linux/platform_data/samsung-usbphy.h /* Register definitions */ @@ -57,24 +60,132 @@ #define RSTCON_HLINK_SWRST (0x1 1) #define RSTCON_SWRST (0x1 0) +/* EXYNOS5 */ +#define EXYNOS5_PHY_HOST_CTRL0 (0x00) + +#define HOST_CTRL0_PHYSWRSTALL (0x1 31) + +#define HOST_CTRL0_REFCLKSEL_MASK (0x3 19) +#define HOST_CTRL0_REFCLKSEL_XTAL (0x0 19) +#define HOST_CTRL0_REFCLKSEL_EXTL (0x1 19) +#define HOST_CTRL0_REFCLKSEL_CLKCORE (0x2 19) + +#define HOST_CTRL0_FSEL_MASK (0x7 16) +#define HOST_CTRL0_FSEL(_x)((_x) 16) + +#define FSEL_CLKSEL_50M(0x7) +#define FSEL_CLKSEL_24M(0x5) +#define FSEL_CLKSEL_20M(0x4) +#define FSEL_CLKSEL_19200K (0x3) +#define FSEL_CLKSEL_12M(0x2) +#define FSEL_CLKSEL_10M(0x1) +#define FSEL_CLKSEL_9600K (0x0) + +#define HOST_CTRL0_TESTBURNIN (0x1 11) +#define HOST_CTRL0_RETENABLE (0x1 10) +#define HOST_CTRL0_COMMONON_N (0x1 9) +#define HOST_CTRL0_SIDDQ (0x1 6) +#define HOST_CTRL0_FORCESLEEP (0x1 5) +#define HOST_CTRL0_FORCESUSPEND(0x1 4) +#define HOST_CTRL0_WORDINTERFACE (0x1 3) +#define HOST_CTRL0_UTMISWRST (0x1 2) +#define HOST_CTRL0_LINKSWRST (0x1 1) +#define HOST_CTRL0_PHYSWRST(0x1 0) + +#define EXYNOS5_PHY_HOST_TUNE0 (0x04) + +#define EXYNOS5_PHY_HSIC_CTRL1 (0x10) + +#define EXYNOS5_PHY_HSIC_TUNE1 (0x14) + +#define EXYNOS5_PHY_HSIC_CTRL2 (0x20) +
[PATCH v8 4/4] USB: ohci-exynos: Add phy driver support
Adding the phy-driver to ohci-exynos. Keeping the platform data
for continuing the smooth operation for boards which still uses it
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Acked-by: Alan Stern st...@rowland.harvard.edu
Acked-by: Kukjin Kim kgene@samsung.com
---
drivers/usb/host/ohci-exynos.c | 84 ++--
1 files changed, 63 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 804fb62..1b38409 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -15,6 +15,7 @@
#include linux/of.h
#include linux/platform_device.h
#include linux/platform_data/usb-exynos.h
+#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include plat/usb-phy.h
@@ -22,8 +23,31 @@ struct exynos_ohci_hcd {
struct device *dev;
struct usb_hcd *hcd;
struct clk *clk;
+ struct usb_phy *phy;
+ struct usb_otg *otg;
+ struct exynos4_ohci_platdata *pdata;
};
+static void exynos_ohci_phy_enable(struct exynos_ohci_hcd *exynos_ohci)
+{
+ struct platform_device *pdev = to_platform_device(exynos_ohci-dev);
+
+ if (exynos_ohci-phy)
+ usb_phy_init(exynos_ohci-phy);
+ else if (exynos_ohci-pdata-phy_init)
+ exynos_ohci-pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
+}
+
+static void exynos_ohci_phy_disable(struct exynos_ohci_hcd *exynos_ohci)
+{
+ struct platform_device *pdev = to_platform_device(exynos_ohci-dev);
+
+ if (exynos_ohci-phy)
+ usb_phy_shutdown(exynos_ohci-phy);
+ else if (exynos_ohci-pdata-phy_exit)
+ exynos_ohci-pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
+}
+
static int ohci_exynos_reset(struct usb_hcd *hcd)
{
return ohci_init(hcd_to_ohci(hcd));
@@ -79,20 +103,15 @@ static u64 ohci_exynos_dma_mask = DMA_BIT_MASK(32);
static int exynos_ohci_probe(struct platform_device *pdev)
{
- struct exynos4_ohci_platdata *pdata;
+ struct exynos4_ohci_platdata *pdata = pdev-dev.platform_data;
struct exynos_ohci_hcd *exynos_ohci;
struct usb_hcd *hcd;
struct ohci_hcd *ohci;
struct resource *res;
+ struct usb_phy *phy;
int irq;
int err;
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(pdev-dev, No platform data defined\n);
- return -EINVAL;
- }
-
/*
* Right now device-tree probed devices don't get dma_mask set.
* Since shared usb code relies on it, set it here for now.
@@ -108,6 +127,20 @@ static int exynos_ohci_probe(struct platform_device *pdev)
if (!exynos_ohci)
return -ENOMEM;
+ phy = devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR_OR_NULL(phy)) {
+ /* Fallback to pdata */
+ if (!pdata) {
+ dev_warn(pdev-dev, no platform data or transceiver
defined\n);
+ return -EPROBE_DEFER;
+ } else {
+ exynos_ohci-pdata = pdata;
+ }
+ } else {
+ exynos_ohci-phy = phy;
+ exynos_ohci-otg = phy-otg;
+ }
+
exynos_ohci-dev = pdev-dev;
hcd = usb_create_hcd(exynos_ohci_hc_driver, pdev-dev,
@@ -153,8 +186,11 @@ static int exynos_ohci_probe(struct platform_device *pdev)
goto fail_io;
}
- if (pdata-phy_init)
- pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
+ if (exynos_ohci-otg)
+ exynos_ohci-otg-set_host(exynos_ohci-otg,
+ exynos_ohci-hcd-self);
+
+ exynos_ohci_phy_enable(exynos_ohci);
ohci = hcd_to_ohci(hcd);
ohci_hcd_init(ohci);
@@ -162,13 +198,15 @@ static int exynos_ohci_probe(struct platform_device *pdev)
err = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (err) {
dev_err(pdev-dev, Failed to add USB HCD\n);
- goto fail_io;
+ goto fail_add_hcd;
}
platform_set_drvdata(pdev, exynos_ohci);
return 0;
+fail_add_hcd:
+ exynos_ohci_phy_disable(exynos_ohci);
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
@@ -178,14 +216,16 @@ fail_clk:
static int exynos_ohci_remove(struct platform_device *pdev)
{
- struct exynos4_ohci_platdata *pdata = pdev-dev.platform_data;
struct exynos_ohci_hcd *exynos_ohci = platform_get_drvdata(pdev);
struct usb_hcd *hcd = exynos_ohci-hcd;
usb_remove_hcd(hcd);
- if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
+ if (exynos_ohci-otg)
+ exynos_ohci-otg-set_host(exynos_ohci-otg,
+ exynos_ohci-hcd-self);
+
+ exynos_ohci_phy_disable(exynos_ohci);
Re: ehci-hcd compile error
On 01/18/2013 08:35 PM, Alan Stern wrote:
On Fri, 18 Jan 2013, Roger Quadros wrote:
Thanks. I used the below code (also attached) and could reproduce
corruption on the first byte at ehci-priv. This is from the the kernel log.
[ 30.381774] ehci-omap ehci-omap.0: ehci_hcd_omap_probe a 0x1234abcd, b
0x5679efba
[ 122.523468] ehci-omap ehci-omap.0: ehci_hcd_omap_remove a 0x1234abe0, b
0x5679efba
NOTE: EHCI needs to be running and you need to enumerate some device for
the corruption to happen.
If I disable CONFIG_USB_DEBUG, then there is no corruption.
I tried doing something similar with (using ehci-pci rather than
ehci-omap) and didn't get any corruption. My test patch is below.
Unforunately you won't be able to utilize the hw_breakpoint mechanism
in your testing because it hasn't been set up for OMAP. Here's the log
for a test with two EHCI controllers and one device plugged in. (Note:
I did have CONFIG_USB_DEBUG enabled, but this log doesn't include any
of the debug-level messages.)
Alan,
It seems that EHCI_STATS is locally defined in ehci_hcd.c thus causing
different versions of struct ehci_hcd to be visible to other users
like ehci-omap.c
The attached patch solves the problem for me and must go in with your
other patches.
From 70a3621d583c0c76d0bf8239b27eb65d01d918b2 Mon Sep 17 00:00:00 2001
From: Roger Quadros rog...@ti.com
Date: Tue, 22 Jan 2013 14:37:57 +0200
Subject: [PATCH] USB: EHCI: Move defination of EHCI_STATS to ehci.h
Without this, platform drivers e.g. ehci-omap.c will see a
different version of struct ehci_hcd than ehci-hcd.c and
break reference to 'debug_dir' and 'priv' members when
CONFIG_USB_DEBUG is enabled.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-hcd.c |4
drivers/usb/host/ehci.h |4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 97b829e..5a35246 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -74,10 +74,6 @@ static const charhcd_name [] = ehci_hcd;
#undef VERBOSE_DEBUG
#undef EHCI_URB_TRACE
-#ifdef DEBUG
-#define EHCI_STATS
-#endif
-
/* magic numbers that can affect system performance */
#defineEHCI_TUNE_CERR 3 /* 0-3 qtd retries; 0 == don't
stop */
#defineEHCI_TUNE_RL_HS 4 /* nak throttle; see 4.9 */
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index e9f8c0e..31a935d 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -38,6 +38,10 @@ typedef __u16 __bitwise __hc16;
#endif
/* statistics can be kept for tuning/monitoring */
+#ifdef DEBUG
+#define EHCI_STATS
+#endif
+
struct ehci_stats {
/* irq usage */
unsigned long normal;
-- 1.7.4.1
From 70a3621d583c0c76d0bf8239b27eb65d01d918b2 Mon Sep 17 00:00:00 2001
From: Roger Quadros rog...@ti.com
Date: Tue, 22 Jan 2013 14:37:57 +0200
Subject: [PATCH] USB: EHCI: Move defination of EHCI_STATS to ehci.h
Without this, platform drivers e.g. ehci-omap.c will see a
different version of struct ehci_hcd than ehci-hcd.c and
break reference to 'debug_dir' and 'priv' members when
CONFIG_USB_DEBUG is enabled.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-hcd.c |4
drivers/usb/host/ehci.h |4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 97b829e..5a35246 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -74,10 +74,6 @@ static const char hcd_name [] = ehci_hcd;
#undef VERBOSE_DEBUG
#undef EHCI_URB_TRACE
-#ifdef DEBUG
-#define EHCI_STATS
-#endif
-
/* magic numbers that can affect system performance */
#define EHCI_TUNE_CERR 3 /* 0-3 qtd retries; 0 == don't stop */
#define EHCI_TUNE_RL_HS 4 /* nak throttle; see 4.9 */
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index e9f8c0e..31a935d 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -38,6 +38,10 @@ typedef __u16 __bitwise __hc16;
#endif
/* statistics can be kept for tuning/monitoring */
+#ifdef DEBUG
+#define EHCI_STATS
+#endif
+
struct ehci_stats {
/* irq usage */
unsigned long normal;
--
1.7.4.1
Re: [PATCH v6 6/8] usb: expose usb port's pm qos flags to user space
On 2013/1/22 5:31, Greg KH wrote: On Mon, Jan 21, 2013 at 10:18:05PM +0800, Lan Tianyu wrote: This patch is to expose usb port's pm qos flags(pm_qos_no_power_off, pm_qos_remote_wakeup) to user space. User can set pm_qos_no_power_off flag to prohibit the port from being powered off. How are they now seen by userspace? Should a new Documentation/ABI entry be created somewhere describing this? There are already some descriptors in the Documentation/ABI/testing/sysfs-devices-power(line 208, lin223). thanks, greg k-h -- Best Regards Tianyu Lan linux kernel enabling team -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: 3.8.0-rc4 keyboard failure at boot
On Tue, 22 Jan 2013, Brad Tilley wrote: Could you please provide dmesg output from both working and non-working case? See attached. Two dmesgs from the same machine. One from 3.7.3, the other from 3.8-rc4 (with a ps2 keyboard). USB keyboards on this machine never work with 3.8, but always works with 3.7. I used an old ps2 keyboard to enter the dm-crypt password. After that, the boot process continues and the USB keyboard and mouse become active and begin to work. However, USB keyboards do not work when the user is prompted to enter the dm-crypt decryption password early in the boot process. That's the primary issue. Ah, I see, that's a very important piece of information. This might be related to USB BIOS handoff then. Do you happen to have Legacy USB option (or similar, such as USB emulation the name is not consistent between different BIOS vendors and versions) in your BIOS? Does toggling it change the behavior? Adding linux-usb@ to CC. Also /proc/bus/input/devices content would be interesting (in case you are able to log remotely into the machine). See attached. One from 3.7.3 the other from 3.8-rc4 (again, the 3.8 kernel is using a ps2 keyboard and a USB keyboard). Does replugging the keyboard fix the problem with 50% probability? Replugging the keyboard does not fix the problem, nor does plugging it into different USB ports or swapping USB keyboards. Are other USB devices (such as mice) affected by this as well? Users are attempting to enter the dm-crypt decryption password during boot so they have not noticed nor complained about mouse failure, only keyboard failure. -- Jiri Kosina SUSE Labs -- 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 v6 7/8] usb: add usb_device_allow_power_off() and usb_device_prevent_power_off() function.
On 2013/1/22 5:33, Greg KH wrote: On Mon, Jan 21, 2013 at 10:18:06PM +0800, Lan Tianyu wrote: Some usb devices can't be resumed correctly after power off. This patch is to add usb_device_allow_power_off() and usb_device_prevent_power_off() for device's driver. Call pm_runtime_get_sync(portdev) to increase port's usage count and then port will not be suspended. The device will not be powered off. Please linewrap comments at the proper level (git likes 72). Acked-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Lan Tianyu tianyu@intel.com --- drivers/usb/core/port.c | 28 1 file changed, 28 insertions(+) diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c index 0c51d24..0334d91 100644 --- a/drivers/usb/core/port.c +++ b/drivers/usb/core/port.c @@ -18,11 +18,39 @@ #include linux/slab.h #include linux/pm_qos.h +#include linux/module.h #include hub.h static const struct attribute_group *port_dev_group[]; +/** + * usb_device_control_power_off - Allow or prohibit power off device. + * @udev: target usb device + * @allow: choice of allow or prohibit + * + * Call pm_runtime_get/put_sync(portdev) to allow or prohibit target + * usb device to be powered off in the kernel. The operations of setting + * true and false should be couple. The default status is allowed. + */ +int usb_device_control_power_off(struct usb_device *udev, bool allow) Ick, again with the boolean variables. Please don't do this, just make two different functions: usb_device_allow_power_off() usb_device_forbid_power_off() that makes it much easier to understand when you see the function being called, right? Ok. I will do it. thanks, greg k-h -- Best Regards Tianyu Lan linux kernel enabling team -- 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 v1 2/6] usb: otg: utils: add facilities in phy lib to support multiple PHYs of same type
On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
In order to add support for multipe PHY's of the same type, new API's
for adding PHY and getting PHY has been added. Now the binding
information for the PHY and controller should be done in platform file
using usb_bind_phy API. And for getting a PHY, the device pointer of the
USB controller and an index should be passed. Based on the binding
information that is added in the platform file, usb_get_phy_dev will return
the
appropriate PHY.
Already existing API's to add and get phy by type is not removed. These
API's are deprecated and will be removed once all the platforms start to
use the new API.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/otg.c | 114
++-
include/linux/usb/phy.h | 13 ++
2 files changed, 126 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index 492ba2f..1f30b22 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -36,6 +36,20 @@ static struct usb_phy *__usb_find_phy(struct list_head
*list,
return ERR_PTR(-ENODEV);
}
+static struct usb_phy *__usb_find_phy_dev(struct device *dev,
+ struct list_head *list, u8 index)
+{
+ struct usb_phy_bind *phy_bind = NULL;
+
+ list_for_each_entry(phy_bind, list, list) {
+ if (!(strcmp(phy_bind-dev_name, dev_name(dev)))
+ phy_bind-index == index)
+ return phy_bind-phy;
If the PHY driver has not yet called usb_add_phy_dev() (e.g. driver not yet
loaeded)
then this will return NULL.
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
static void devm_usb_phy_release(struct device *dev, void *res)
{
struct usb_phy *phy = *(struct usb_phy **)res;
@@ -112,6 +126,69 @@ err0:
EXPORT_SYMBOL(usb_get_phy);
/**
+ * usb_get_phy_dev - find the USB PHY
+ * @dev - device that requests this phy
+ * @index - the index of the phy
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy. The caller is responsible for
+ * calling usb_put_phy() to release that count.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index)
+{
+ struct usb_phy *phy = NULL;
+ unsigned long flags;
+
+ spin_lock_irqsave(phy_lock, flags);
+
+ phy = __usb_find_phy_dev(dev, phy_bind_list, index);
+ if (IS_ERR(phy)) {
+ pr_err(unable to find transceiver\n);
+ goto err0;
+ }
Since NULL is not IS_ERR(), you will do a NULL pointer reference below.
In such cases we would want to use the deferred probe mechanism. So should we
return
-EPROBE_DEFER?
+
+ get_device(phy-dev);
+
+err0:
+ spin_unlock_irqrestore(phy_lock, flags);
+
+ return phy;
+}
+EXPORT_SYMBOL(usb_get_phy_dev);
+
--
cheers,
-roger
--
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 v1 4/6] drivers: usb: musb: omap: make use of the new PHY lib APIs
On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
New PHY lib APIs like usb_add_phy_dev() and devm_usb_get_phy_dev() are
used in MUSB (OMAP), in order to make use of the binding information
provided in the board file (of OMAP platforms).
All the platforms should be modified similar to this to add and get the
PHY.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c |2 +-
drivers/usb/otg/twl4030-usb.c |3 ++-
drivers/usb/phy/omap-usb2.c |3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index bf6cfe0..1a8cf6d 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -345,7 +345,7 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
- musb-xceiv = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ musb-xceiv = devm_usb_get_phy_dev(dev, 0);
if (IS_ERR_OR_NULL(musb-xceiv)) {
pr_err(HS USB OTG: no transceiver configured\n);
return -ENODEV;
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 0a70193..a994715 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -610,6 +610,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl-phy.dev= twl-dev;
twl-phy.label = twl4030;
twl-phy.otg= otg;
+ twl-phy.type = USB_PHY_TYPE_USB2;
What is the need to set phy.type? I think this should be deprecated along with
the old API.
twl-phy.set_suspend= twl4030_set_suspend;
otg-phy= twl-phy;
@@ -624,7 +625,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
dev_err(pdev-dev, ldo init failed\n);
return err;
}
- usb_add_phy(twl-phy, USB_PHY_TYPE_USB2);
+ usb_add_phy_dev(twl-phy);
platform_set_drvdata(pdev, twl);
if (device_create_file(pdev-dev, dev_attr_vbus))
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 4b59b39..b5c759c 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -143,6 +143,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-phy.label = omap-usb2;
phy-phy.set_suspend= omap_usb2_suspend;
phy-phy.otg= otg;
+ phy-phy.type = USB_PHY_TYPE_USB2;
same here.
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -168,7 +169,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
clk_prepare(phy-wkupclk);
- usb_add_phy(phy-phy, USB_PHY_TYPE_USB2);
+ usb_add_phy_dev(phy-phy);
platform_set_drvdata(pdev, phy);
--
cheers,
-roger
--
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 v1 2/6] usb: otg: utils: add facilities in phy lib to support multiple PHYs of same type
Hi,
On Tuesday 22 January 2013 07:37 PM, Roger Quadros wrote:
On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
In order to add support for multipe PHY's of the same type, new API's
for adding PHY and getting PHY has been added. Now the binding
information for the PHY and controller should be done in platform file
using usb_bind_phy API. And for getting a PHY, the device pointer of the
USB controller and an index should be passed. Based on the binding
information that is added in the platform file, usb_get_phy_dev will return the
appropriate PHY.
Already existing API's to add and get phy by type is not removed. These
API's are deprecated and will be removed once all the platforms start to
use the new API.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/otg.c | 114 ++-
include/linux/usb/phy.h | 13 ++
2 files changed, 126 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index 492ba2f..1f30b22 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -36,6 +36,20 @@ static struct usb_phy *__usb_find_phy(struct list_head *list,
return ERR_PTR(-ENODEV);
}
+static struct usb_phy *__usb_find_phy_dev(struct device *dev,
+ struct list_head *list, u8 index)
+{
+ struct usb_phy_bind *phy_bind = NULL;
+
+ list_for_each_entry(phy_bind, list, list) {
+ if (!(strcmp(phy_bind-dev_name, dev_name(dev)))
+ phy_bind-index == index)
+ return phy_bind-phy;
If the PHY driver has not yet called usb_add_phy_dev() (e.g. driver not yet
loaeded)
then this will return NULL.
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
static void devm_usb_phy_release(struct device *dev, void *res)
{
struct usb_phy *phy = *(struct usb_phy **)res;
@@ -112,6 +126,69 @@ err0:
EXPORT_SYMBOL(usb_get_phy);
/**
+ * usb_get_phy_dev - find the USB PHY
+ * @dev - device that requests this phy
+ * @index - the index of the phy
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy. The caller is responsible for
+ * calling usb_put_phy() to release that count.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index)
+{
+ struct usb_phy *phy = NULL;
+ unsigned long flags;
+
+ spin_lock_irqsave(phy_lock, flags);
+
+ phy = __usb_find_phy_dev(dev, phy_bind_list, index);
+ if (IS_ERR(phy)) {
+ pr_err(unable to find transceiver\n);
+ goto err0;
+ }
Since NULL is not IS_ERR(), you will do a NULL pointer reference below.
In such cases we would want to use the deferred probe mechanism. So should we
return
-EPROBE_DEFER?
Good catch. I'll update the patch.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: 3.8.0-rc4 keyboard failure at boot
On Tue, Jan 22, 2013 at 02:51:08PM +0100, Jiri Kosina wrote: On Tue, 22 Jan 2013, Brad Tilley wrote: Could you please provide dmesg output from both working and non-working case? See attached. Two dmesgs from the same machine. One from 3.7.3, the other from 3.8-rc4 (with a ps2 keyboard). USB keyboards on this machine never work with 3.8, but always works with 3.7. I used an old ps2 keyboard to enter the dm-crypt password. After that, the boot process continues and the USB keyboard and mouse become active and begin to work. However, USB keyboards do not work when the user is prompted to enter the dm-crypt decryption password early in the boot process. That's the primary issue. Ah, I see, that's a very important piece of information. This might be related to USB BIOS handoff then. Do you happen to have Legacy USB option (or similar, such as USB emulation the name is not consistent between different BIOS vendors and versions) in your BIOS? Does toggling it change the behavior? 3.6 and 3.7 kernels on the same machine work with the standard BIOS settings. We did flash the BIOS to the latest revision when the issue was first noticed with 3.8 kernels. I do not see such a setting in the BIOS, and as I said, earlier kernels work just fine with the existing BIOS settings. To me, this seems like a race condition. Sometimes USB keyboards work when the user is prompted to enter the dm-crypt password, other times they do not. The problem never occurs on single-core machines (that we have noticed), only occurs about 50% of the time on AMD multi-core machines and 100% of the time on Intel multi-core machines. And none of the machine have encountered the issue with 3.6 or 3.7 kernels. The possibility of a race condition is just a guess on my part and may be incorrect. I did not mention it earlier as I did not want to misguide you. Brad -- 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 v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
The OMAP glue has been modified to get PHY by phandle for dt boot.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1a8cf6d..e43faeb 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -345,7 +345,12 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
- musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+ if (dev-parent-of_node)
+ musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
+ usb_phy, 0);
+ else
+ musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+
if (IS_ERR_OR_NULL(musb-xceiv)) {
pr_err(HS USB OTG: no transceiver configured\n);
return -ENODEV;
This will not work with PHY driver as a module. You need to use deferred
probing mechanism here
after you have addressed my comment in patch 2 and also
devm_usb_get_phy_by_phandle()
e.g.
if (IS_ERR(musb-xceiv)) {
int ret = PTR_ERR(musb-xveiv);
if (ret == -ENODEV)
pr_err(HS USB OTG: no transceiver configured\n);
return ret;
}
--
cheers,
-roger
--
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: phy: moving all PHY API definitions to usb/phy directory
On 01/22/2013 01:01 PM, Venu Byravarasu wrote:
As drivers/usb/otg/otg.c contains most of the PHY related APIs
which are not OTG specific, moving them to more logical place
under driver/usb/phy.
Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com
---
delta from v1:
Missed adding newly created file usb_phy.c with previous patch.
hence sending v2, after adding that.
drivers/usb/otg/otg.c| 184
--
drivers/usb/phy/Makefile |1 +
drivers/usb/{otg/otg.c = phy/usb_phy.c} | 45 +---
3 files changed, 6 insertions(+), 224 deletions(-)
copy drivers/usb/{otg/otg.c = phy/usb_phy.c} (82%)
what about updating
drivers/usb/otg/Makefile and Kconfig?
i.e. remove CONFIG_USB_OTG_UTILS and otg.o there?
--
cheers,
-roger
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index a30c041..95561b9 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -17,190 +17,6 @@
#include linux/usb/otg.h
-static LIST_HEAD(phy_list);
-static DEFINE_SPINLOCK(phy_lock);
-
-static struct usb_phy *__usb_find_phy(struct list_head *list,
- enum usb_phy_type type)
-{
- struct usb_phy *phy = NULL;
-
- list_for_each_entry(phy, list, head) {
- if (phy-type != type)
- continue;
-
- return phy;
- }
-
- return ERR_PTR(-ENODEV);
-}
-
-static void devm_usb_phy_release(struct device *dev, void *res)
-{
- struct usb_phy *phy = *(struct usb_phy **)res;
-
- usb_put_phy(phy);
-}
-
-static int devm_usb_phy_match(struct device *dev, void *res, void
*match_data)
-{
- return res == match_data;
-}
-
-/**
- * devm_usb_get_phy - find the USB PHY
- * @dev - device that requests this phy
- * @type - the type of the phy the controller requires
- *
- * Gets the phy using usb_get_phy(), and associates a device with it using
- * devres. On driver detach, release function is invoked on the devres data,
- * then, devres data is freed.
- *
- * For use by USB host and peripheral drivers.
- */
-struct usb_phy *devm_usb_get_phy(struct device *dev, enum usb_phy_type type)
-{
- struct usb_phy **ptr, *phy;
-
- ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
- if (!ptr)
- return NULL;
-
- phy = usb_get_phy(type);
- if (!IS_ERR(phy)) {
- *ptr = phy;
- devres_add(dev, ptr);
- } else
- devres_free(ptr);
-
- return phy;
-}
-EXPORT_SYMBOL(devm_usb_get_phy);
-
-/**
- * usb_get_phy - find the USB PHY
- * @type - the type of the phy the controller requires
- *
- * Returns the phy driver, after getting a refcount to it; or
- * -ENODEV if there is no such phy. The caller is responsible for
- * calling usb_put_phy() to release that count.
- *
- * For use by USB host and peripheral drivers.
- */
-struct usb_phy *usb_get_phy(enum usb_phy_type type)
-{
- struct usb_phy *phy = NULL;
- unsigned long flags;
-
- spin_lock_irqsave(phy_lock, flags);
-
- phy = __usb_find_phy(phy_list, type);
- if (IS_ERR(phy)) {
- pr_err(unable to find transceiver of type %s\n,
- usb_phy_type_string(type));
- goto err0;
- }
-
- get_device(phy-dev);
-
-err0:
- spin_unlock_irqrestore(phy_lock, flags);
-
- return phy;
-}
-EXPORT_SYMBOL(usb_get_phy);
-
-/**
- * devm_usb_put_phy - release the USB PHY
- * @dev - device that wants to release this phy
- * @phy - the phy returned by devm_usb_get_phy()
- *
- * destroys the devres associated with this phy and invokes usb_put_phy
- * to release the phy.
- *
- * For use by USB host and peripheral drivers.
- */
-void devm_usb_put_phy(struct device *dev, struct usb_phy *phy)
-{
- int r;
-
- r = devres_destroy(dev, devm_usb_phy_release, devm_usb_phy_match, phy);
- dev_WARN_ONCE(dev, r, couldn't find PHY resource\n);
-}
-EXPORT_SYMBOL(devm_usb_put_phy);
-
-/**
- * usb_put_phy - release the USB PHY
- * @x: the phy returned by usb_get_phy()
- *
- * Releases a refcount the caller received from usb_get_phy().
- *
- * For use by USB host and peripheral drivers.
- */
-void usb_put_phy(struct usb_phy *x)
-{
- if (x)
- put_device(x-dev);
-}
-EXPORT_SYMBOL(usb_put_phy);
-
-/**
- * usb_add_phy - declare the USB PHY
- * @x: the USB phy to be used; or NULL
- * @type - the type of this PHY
- *
- * This call is exclusively for use by phy drivers, which
- * coordinate the activities of drivers for host and peripheral
- * controllers, and in some cases for VBUS current regulation.
- */
-int usb_add_phy(struct usb_phy *x, enum usb_phy_type type)
-{
- int ret = 0;
- unsigned long flags;
- struct usb_phy *phy;
-
- if (x-type != USB_PHY_TYPE_UNDEFINED) {
- dev_err(x-dev, not accepting initialized PHY %s\n,
Re: [PATCH v6 7/8] usb: add usb_device_allow_power_off() and usb_device_prevent_power_off() function.
On 2013/1/22 5:33, Greg KH wrote:
On Mon, Jan 21, 2013 at 10:18:06PM +0800, Lan Tianyu wrote:
Some usb devices can't be resumed correctly after power off. This
patch is to add usb_device_allow_power_off() and usb_device_prevent_power_off()
for device's driver. Call pm_runtime_get_sync(portdev) to increase port's usage
count and then port will not be suspended. The device will not be powered off.
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Lan Tianyu tianyu@intel.com
---
drivers/usb/core/port.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 0c51d24..0334d91 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -18,11 +18,39 @@
#include linux/slab.h
#include linux/pm_qos.h
+#include linux/module.h
#include hub.h
static const struct attribute_group *port_dev_group[];
+/**
+ * usb_device_control_power_off - Allow or prohibit power off device.
+ * @udev: target usb device
+ * @allow: choice of allow or prohibit
+ *
+ * Call pm_runtime_get/put_sync(portdev) to allow or prohibit target
+ * usb device to be powered off in the kernel. The operations of setting
+ * true and false should be couple. The default status is allowed.
+ */
+int usb_device_control_power_off(struct usb_device *udev, bool allow)
+{
+ struct usb_port *port_dev;
+
+ if (!udev-parent)
+ return -EINVAL;
+
+ port_dev = hdev_to_hub(udev-parent)-ports[udev-portnum - 1];
+
+ if (allow)
+ pm_runtime_put_sync(port_dev-dev);
+ else
+ pm_runtime_get_sync(port_dev-dev);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_device_control_power_off);
Oh, I don't see any code calling this function, so why did you add it?
Who needs it? Where is that code?
This is provided for device driver. Some device may not be compatible
with the power off mechanism and driver can use these function to
forbid/allow it. But currently, we are not sure which kinds of device
they are. So just provide new interfaces.
thanks,
greg k-h
--
Best Regards
Tianyu Lan
linux kernel enabling team
--
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 v6 8/8] usb: enable usb port device's async suspend.
On 2013/1/22 5:34, Greg KH wrote: On Mon, Jan 21, 2013 at 10:18:07PM +0800, Lan Tianyu wrote: Signed-off-by: Lan Tianyu tianyu@intel.com Why are you doing this? Why is it now ok? We need a much better changelog entry here. Ok. I will add later. thanks, greg k-h -- Best Regards Tianyu Lan linux kernel enabling team -- 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 v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
On Tuesday 22 January 2013 07:47 PM, Roger Quadros wrote:
On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
The OMAP glue has been modified to get PHY by phandle for dt boot.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1a8cf6d..e43faeb 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -345,7 +345,12 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
- musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+ if (dev-parent-of_node)
+ musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
+ usb_phy, 0);
+ else
+ musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+
if (IS_ERR_OR_NULL(musb-xceiv)) {
pr_err(HS USB OTG: no transceiver configured\n);
return -ENODEV;
This will not work with PHY driver as a module. You need to use deferred
probing mechanism here
after you have addressed my comment in patch 2 and also
devm_usb_get_phy_by_phandle()
IIUC, even using -EPROBE_DEFER might not help if we are making the PHY
driver as module, since the kernel will try to probe only till the
prompt comes.
And having -EPROBE_DEFER instead of -ENODEV might also not help since,
the gadget driver wont be able to bind to UDC (usb_gadget_probe_driver
will fail).
A lot of things need to be changed before we change to -EPROBE_DEFER IMO.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uhci irq race before term_td is allocated
On Tue, Jan 22, 2013 at 06:17:00AM +, Huang, Adrian (ISS Linux TW) wrote: Hi Alan, Recently, I'm debugging this issue (the same symptom described by Don) on my server. Fortunately, the issue was fixed by applying your patch posted in this email thread. Just checked the latest kernel (3.7.4) and the mainline (3.8-rc4), the patch was not included in those kernels. Do you have any schedule to submit the patch to the upstream? Thanks in advance. I don't think Alan ever committed that patch because I never gave him feedback on it. Of course, the reason I never gave feedback was the customer I was working with (HP??) updated their firmware and couldn't reproduce the problem anymore. Therefore the patch couldn't be verified to work or not. But if you are able to show the patch working, I'll leave it up to Alan to decide what to do. Cheers, Don The list of the allocated IRQ (uhci_hcd used the shared interrupt) on my server: CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0:120 0 0 0 0 0 0 0 IR-IO-APIC-edge timer 1: 2 0 0 0 0 0 0 0 IR-IO-APIC-edge i8042 3: 2 0 0 0 0 0 0 0 IR-IO-APIC-edge 4: 1 0 0 0 0 0 0 0 IR-IO-APIC-edge 8: 1 0 0 0 0 0 0 0 IR-IO-APIC-edge rtc0 9: 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi acpi 12: 4 0 0 0 0 0 0 0 IR-IO-APIC-edge i8042 16: 1187 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi uhci_hcd:usb3, hpilo 20: 1385 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi ehci_hcd:usb2 21:167 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi ehci_hcd:usb1 -- Adrian -- 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 v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
On 01/22/2013 04:37 PM, kishon wrote:
On Tuesday 22 January 2013 07:47 PM, Roger Quadros wrote:
On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
The OMAP glue has been modified to get PHY by phandle for dt boot.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1a8cf6d..e43faeb 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -345,7 +345,12 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
-musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+if (dev-parent-of_node)
+musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
+usb_phy, 0);
+else
+musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+
if (IS_ERR_OR_NULL(musb-xceiv)) {
pr_err(HS USB OTG: no transceiver configured\n);
return -ENODEV;
This will not work with PHY driver as a module. You need to use deferred
probing mechanism here
after you have addressed my comment in patch 2 and also
devm_usb_get_phy_by_phandle()
IIUC, even using -EPROBE_DEFER might not help if we are making the PHY driver
as module, since the kernel will try to probe only till the prompt comes.
Oh really? I thought deferred probing takes place whenever a new driver is
bound to a device. What does prompt comes have to do with it?
And having -EPROBE_DEFER instead of -ENODEV might also not help since, the
gadget driver wont be able to bind to UDC (usb_gadget_probe_driver will fail).
A lot of things need to be changed before we change to -EPROBE_DEFER IMO.
OK.
--
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
Hi, It sounds like the UDC driver now works okay for control transfers but not for bulk transfers. Some code in file_storage.c that i cannot understand. In ep0_complete(), the code snippet: if (req-status == 0 req-context) ((fsg_routine_t) (req-context))(fsg); Does the UDC driver provide the context pointer to file_storage.c? That belongs to the gadget driver. file_storage.c maintains that req-context. Another gadget question: get_next_command() is receiving command from host PC, UDC HW isr routine is also receiving data from host PC. What is the difference between these two? hmm... ISR receives data and bounces it back to gadget driver. What do you mean ? Ok, rephrase the question, is this the flow for bulk transfer? 1) data is received by Usb mass storage HW, the UDC driver ISR is called to read the data to usb_request buffer 2) bulk_out_complete() in gadget driver, is called to set buffer state to full 3) get_next_command() in gadget driver, is called to read the CBW. 4) do_scsi_command() to process SCSI command encoded in CBW 5) send_status() sends the CSW to host Something like below: OUT Token - ISR - giveback() - bulk_out_complete() - get_next_command() - do_scsi_command() - usb_ep_queue() - OUT/IN Token - ISR - bulk_out_complete() - send_status() For the IN Token, i will just write the data to the HW buffer, and the flow will go to send_status(). I use a different USB cable, now the USB gadget is able to receive bulk transfer data from host PC. I am working on the bulk transfer code. Thank you for the very useful answers. victor -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB: storage: optimize the matching rules and support new switch command for Huawei USB storage devices
On Tue, Jan 22, 2013 at 09:16:08AM +, Fangxiaozhi (Franko) wrote: Dear Greg: OK, I have fixed up and resend the patches based on linux-3.8-rc4 today. Email subjects: 1. [PATCH 1/2]linux-usb:define new macro and add new match rules for Huawei USB storage devices 2. [PATCH 2/2]linux-usb:define new macro and add new match rules for Huawei USB storage devices You sent me two patches, both with the same exact Subject: line. That's not ok, please be descriptive in the subject lines as to what each individual patch does, as obviously they both don't do the same thing, right? Please fix that up and resend the two patches. 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 v6 7/8] usb: add usb_device_allow_power_off() and usb_device_prevent_power_off() function.
On Tue, Jan 22, 2013 at 10:23:12PM +0800, Lan Tianyu wrote:
On 2013/1/22 5:33, Greg KH wrote:
On Mon, Jan 21, 2013 at 10:18:06PM +0800, Lan Tianyu wrote:
Some usb devices can't be resumed correctly after power off. This
patch is to add usb_device_allow_power_off() and
usb_device_prevent_power_off()
for device's driver. Call pm_runtime_get_sync(portdev) to increase port's
usage
count and then port will not be suspended. The device will not be powered
off.
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Lan Tianyu tianyu@intel.com
---
drivers/usb/core/port.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 0c51d24..0334d91 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -18,11 +18,39 @@
#include linux/slab.h
#include linux/pm_qos.h
+#include linux/module.h
#include hub.h
static const struct attribute_group *port_dev_group[];
+/**
+ * usb_device_control_power_off - Allow or prohibit power off device.
+ * @udev: target usb device
+ * @allow: choice of allow or prohibit
+ *
+ * Call pm_runtime_get/put_sync(portdev) to allow or prohibit target
+ * usb device to be powered off in the kernel. The operations of setting
+ * true and false should be couple. The default status is allowed.
+ */
+int usb_device_control_power_off(struct usb_device *udev, bool allow)
+{
+ struct usb_port *port_dev;
+
+ if (!udev-parent)
+ return -EINVAL;
+
+ port_dev = hdev_to_hub(udev-parent)-ports[udev-portnum - 1];
+
+ if (allow)
+ pm_runtime_put_sync(port_dev-dev);
+ else
+ pm_runtime_get_sync(port_dev-dev);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_device_control_power_off);
Oh, I don't see any code calling this function, so why did you add it?
Who needs it? Where is that code?
This is provided for device driver. Some device may not be
compatible with the power off mechanism and driver can use these
function to forbid/allow it. But currently, we are not sure which
kinds of device
they are. So just provide new interfaces.
We don't add new interfaces to the kernel unless they have a user. If I
were to see this in the tree, I would expect it to be removed because of
that. So don't add it at all, only add it when it is needed.
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 v6 7/8] usb: add usb_device_allow_power_off() and usb_device_prevent_power_off() function.
On Tue, 22 Jan 2013, Lan Tianyu wrote: +/** + * usb_device_control_power_off - Allow or prohibit power off device. + * @udev: target usb device + * @allow: choice of allow or prohibit + * + * Call pm_runtime_get/put_sync(portdev) to allow or prohibit target + * usb device to be powered off in the kernel. The operations of setting + * true and false should be couple. The default status is allowed. + */ +int usb_device_control_power_off(struct usb_device *udev, bool allow) Ick, again with the boolean variables. Please don't do this, just make two different functions: usb_device_allow_power_off() usb_device_forbid_power_off() that makes it much easier to understand when you see the function being called, right? Ok. I will do it. Greg and Tianyu: You both missed the fact that Tianyu already did this. It is in the submitted patch. The two functions Greg asked for are defined as inline routines. 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 13/15] USB: ehci: make orion and mxc bus glues coexist
On Tue, 22 Jan 2013, Manjunath Goudar wrote: I think we can actually get the same results by turning the Kconfig logic around and making the platform glue drivers 'select USB_EHCI_HCD' than depending on it. That's a good idea. The Kconfig changes would have to be done carefully to make sure that the dependency on USB_ARCH_HAS_EHCI still applies to all the platform drivers. Manjunath, would you like to send a patch to do this? Alan Stern Ya sure,could you explain little bit briefly about the Kconfig changes. Suppose you do exactly what Arnd proposed: add select USB_EHCI_HCD to the Kconfig entries for each of the platform glue drivers. Then consider what would happen in a build where USB_ARCH_HAS_EHCI is n but one of those glue drivers is enabled. There would be conflicting requirements on USB_EHCI_HCD: The new select would force it to be on, but the existing depends on USB USB_ARCH_HAS_EHCI would force it to be off. The build would fail. In order to prevent this, you have to make sure that each glue driver depends on USB_ARCH_HAS_EHCI. A simple way to do this is to surround the Kconfig entries for those drivers with if USB USB_ARCH_HAS_EHCI ... endif. Come to think of it, the if USB part really should protect the entire file. 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 v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
On Tuesday 22 January 2013 08:17 PM, Roger Quadros wrote:
On 01/22/2013 04:37 PM, kishon wrote:
On Tuesday 22 January 2013 07:47 PM, Roger Quadros wrote:
On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
The OMAP glue has been modified to get PHY by phandle for dt boot.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1a8cf6d..e43faeb 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -345,7 +345,12 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
-musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+if (dev-parent-of_node)
+musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
+usb_phy, 0);
+else
+musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+
if (IS_ERR_OR_NULL(musb-xceiv)) {
pr_err(HS USB OTG: no transceiver configured\n);
return -ENODEV;
This will not work with PHY driver as a module. You need to use deferred
probing mechanism here
after you have addressed my comment in patch 2 and also
devm_usb_get_phy_by_phandle()
IIUC, even using -EPROBE_DEFER might not help if we are making the PHY driver
as module, since the kernel will try to probe only till the prompt comes.
Oh really? I thought deferred probing takes place whenever a new driver is
bound to a device.
You might also be right. I'm not so sure.
What does prompt comes have to do with it?
I just meant end of boot process. But it's better to check if deferred
probing takes place whenever a new driver is bound to a device as you
just mentioned.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ehci-hcd compile error
On Tue, 22 Jan 2013, Roger Quadros wrote: Alan, It seems that EHCI_STATS is locally defined in ehci_hcd.c thus causing different versions of struct ehci_hcd to be visible to other users like ehci-omap.c The attached patch solves the problem for me and must go in with your other patches. Great find! Thanks, I'll submit this today. 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 1/2] ARM: Exynos5250: Enabling samsung-usbphy driver
Adding usbphy node for Exynos5250 along with the
necessary device data to be parsed.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 30485de..610e338 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -275,6 +275,21 @@
#size-cells = 0;
};
+ usbphy@1213 {
+ compatible = samsung,exynos5250-usbphy;
+ reg = 0x1213 0x100;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbphy-sys {
+ /* USB device and host PHY_CONTROL registers */
+ reg = 0x10040704 0x8,
+ /* USB2.0 PHY configuration register */
+ 0x10050230 0x4;
+ };
+ };
+
amba {
#address-cells = 1;
#size-cells = 1;
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ARM: Exynos5250: Enabling samsung-usb3-phy driver
Adding usb3.0 phy node for Exynos5250 along with the
necessary device data to be parsed.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 610e338..018a70d 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -275,6 +275,19 @@
#size-cells = 0;
};
+ usbphy@1210 {
+ compatible = samsung,exynos5250-usb3-phy;
+ reg = 0x1210 0x100;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbphy-sys {
+ /* USB device and host PHY_CONTROL registers */
+ reg = 0x10040704 0x8;
+ };
+ };
+
usbphy@1213 {
compatible = samsung,exynos5250-usbphy;
reg = 0x1213 0x100;
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] ARM: Exynos5250: Enabling samsung usb phy
Changes from v1: - Putting separate device nodes for usb 2.0 phy and usb 3.0 phy based on separate driver for samsung usb 3.0 phy and samsung usb 2.0 phy: [PATCH v3 0/2] Adding USB 3.0 DRD-phy support for exynos5250 [PATCH v8 0/4] Adding usb2.0 host-phy support for exynos5250 - Aligning as per the patch: usb: phy: samsung: Add support to set pmu isolation - Replaced phy-handle approach for PHY CONTROL registers to child nodes. - Removing AUX data entry from exynos5250 dt file. Vivek Gautam (2): ARM: Exynos5250: Enabling samsung-usbphy driver ARM: Exynos5250: Enabling samsung-usb3-phy driver arch/arm/boot/dts/exynos5250.dtsi | 28 1 files changed, 28 insertions(+), 0 deletions(-) -- 1.7.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
On Tue, 22 Jan 2013, Shawn Guo wrote: On Mon, Jan 21, 2013 at 09:37:42PM +, Arnd Bergmann wrote: Arnd, please take a look at http://marc.info/?l=linux-usbamp;m=135843716515529amp;w=2 I can't test it easily, not being set up for cross compilation. I'm waiting to hear from anybody whether it works before submitting it. (There's also a report of memory corruption involving a similar patch for ehci-omap; it hasn't been tracked down yet.) Your patch looks good to me, but it also seems to do some other changes that are not required to fix the problem but could wait for 3.9 instead. You definitely have my Ack if you are willing to take it for 3.8 though. I think it's not too late to submit this for 3.8. Thanks for the Ack. Shawn or Sascha should be able to test it. Alan, Thanks for the patch. I just gave it try. The USB Host port still works for me with a couple of fixes on your changes integrated (one for compiling and the other for probing). So you have my ACK with the changes below rolled into your patch. Right, I have merged your changes into the patch. Will submit shortly. 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 v6 5/8] usb: add usb port auto power off mechanism
On 2013/1/22 5:30, Greg KH wrote:
On Mon, Jan 21, 2013 at 10:18:04PM +0800, Lan Tianyu wrote:
This patch is to add usb port auto power off mechanism.
When usb device is suspending, usb core will suspend usb port and
usb port runtime pm callback will clear PORT_POWER feature to
power off port if all conditions were met. These conditions are
remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist
enable. When it resumes, power on port again. Add did_runtime_put
in the struct usb_port in order to call pm_runtime_get/put(portdev)
paired during suspending and resuming.
I don't understand what did_runtime_put is supposed to mean. Care to
explain this better?
Ok.
Acked-by: Alan Stern st...@rowland.harvard.edu
Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
Signed-off-by: Lan Tianyu tianyu@intel.com
---
drivers/usb/core/hub.c | 67 ---
drivers/usb/core/hub.h |9 +++
drivers/usb/core/port.c | 40 ++--
3 files changed, 105 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 8c1f9a5..786db99 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -26,6 +26,7 @@
#include linux/mutex.h
#include linux/freezer.h
#include linux/random.h
+#include linux/pm_qos.h
#include asm/uaccess.h
#include asm/byteorder.h
@@ -108,7 +109,7 @@ MODULE_PARM_DESC(use_both_schemes,
DECLARE_RWSEM(ehci_cf_port_reset_rwsem);
EXPORT_SYMBOL_GPL(ehci_cf_port_reset_rwsem);
-#define HUB_DEBOUNCE_TIMEOUT 1500
+#define HUB_DEBOUNCE_TIMEOUT 2000
Why did you increase this timeout? You don't mention that above in the
changelog entry.
I will add this into change log.
#define HUB_DEBOUNCE_STEP 25
#define HUB_DEBOUNCE_STABLE100
@@ -127,7 +128,7 @@ static inline char *portspeed(struct usb_hub *hub, int
portstatus)
}
/* Note that hdev or one of its children must be locked! */
-static struct usb_hub *hdev_to_hub(struct usb_device *hdev)
+struct usb_hub *hdev_to_hub(struct usb_device *hdev)
This needs a better name now that this is a global function. No one
knows what a hdev is.
Actually the routine will only be used in the driver/usb/core/(hub.c,
port.c). Port also should be the part of hub, right? Moving port related
code to port.c is to make code more clear. I am not sure whether we
should rename it.
If we renamed it, how about usb_hub_to_struct_hub? \
Should we do rename operation in a separate patch since hdev_to_hub() is
called many places in the hub.c?
{
if (!hdev || !hdev-actconfig || !hdev-maxchild)
return NULL;
@@ -393,7 +394,7 @@ static int clear_hub_feature(struct usb_device *hdev, int
feature)
/*
* USB 2.0 spec Section 11.24.2.2
*/
-static int clear_port_feature(struct usb_device *hdev, int port1, int feature)
+int clear_port_feature(struct usb_device *hdev, int port1, int feature)
This is now a global function, please put usb_ infront of it.
Same above?
{
return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
USB_REQ_CLEAR_FEATURE, USB_RT_PORT, feature, port1,
@@ -718,11 +719,16 @@ int usb_hub_set_port_power(struct usb_device *hdev, int
port1,
bool set)
{
int ret;
+ struct usb_hub *hub = hdev_to_hub(hdev);
+ struct usb_port *port_dev = hub-ports[port1 - 1];
if (set)
ret = set_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
else
ret = clear_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
+
+ if (!ret)
+ port_dev-power_is_on = set;
return ret;
}
@@ -802,7 +808,11 @@ static unsigned hub_power_on(struct usb_hub *hub, bool
do_delay)
dev_dbg(hub-intfdev, trying to enable port power on
non-switchable hub\n);
for (port1 = 1; port1 = hub-descriptor-bNbrPorts; port1++)
- set_port_feature(hub-hdev, port1, USB_PORT_FEAT_POWER);
+ if (hub-ports[port1 - 1]-power_is_on)
+ set_port_feature(hub-hdev, port1, USB_PORT_FEAT_POWER);
+ else
+ clear_port_feature(hub-hdev, port1,
+ USB_PORT_FEAT_POWER);
/* Wait at least 100 msec for power to become stable */
delay = max(pgood_delay, (unsigned) 100);
@@ -1134,10 +1144,16 @@ static void hub_activate(struct usb_hub *hub, enum
hub_activation_type type)
set_bit(port1, hub-change_bits);
} else if (udev-persist_enabled) {
+ struct usb_port *port_dev = hub-ports[port1 - 1];
+
#ifdef CONFIG_PM
udev-reset_resume = 1;
#endif
- set_bit(port1, hub-change_bits);
+ /* Don't set the change_bits when the device
+* was powered off.
+
Re: [PATCH v6 7/8] usb: add usb_device_allow_power_off() and usb_device_prevent_power_off() function.
On 2013/1/22 23:05, Greg KH wrote:
On Tue, Jan 22, 2013 at 10:23:12PM +0800, Lan Tianyu wrote:
On 2013/1/22 5:33, Greg KH wrote:
On Mon, Jan 21, 2013 at 10:18:06PM +0800, Lan Tianyu wrote:
Some usb devices can't be resumed correctly after power off. This
patch is to add usb_device_allow_power_off() and usb_device_prevent_power_off()
for device's driver. Call pm_runtime_get_sync(portdev) to increase port's usage
count and then port will not be suspended. The device will not be powered off.
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Lan Tianyu tianyu@intel.com
---
drivers/usb/core/port.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 0c51d24..0334d91 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -18,11 +18,39 @@
#include linux/slab.h
#include linux/pm_qos.h
+#include linux/module.h
#include hub.h
static const struct attribute_group *port_dev_group[];
+/**
+ * usb_device_control_power_off - Allow or prohibit power off device.
+ * @udev: target usb device
+ * @allow: choice of allow or prohibit
+ *
+ * Call pm_runtime_get/put_sync(portdev) to allow or prohibit target
+ * usb device to be powered off in the kernel. The operations of setting
+ * true and false should be couple. The default status is allowed.
+ */
+int usb_device_control_power_off(struct usb_device *udev, bool allow)
+{
+ struct usb_port *port_dev;
+
+ if (!udev-parent)
+ return -EINVAL;
+
+ port_dev = hdev_to_hub(udev-parent)-ports[udev-portnum - 1];
+
+ if (allow)
+ pm_runtime_put_sync(port_dev-dev);
+ else
+ pm_runtime_get_sync(port_dev-dev);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_device_control_power_off);
Oh, I don't see any code calling this function, so why did you add it?
Who needs it? Where is that code?
This is provided for device driver. Some device may not be
compatible with the power off mechanism and driver can use these
function to forbid/allow it. But currently, we are not sure which
kinds of device
they are. So just provide new interfaces.
We don't add new interfaces to the kernel unless they have a user. If I
were to see this in the tree, I would expect it to be removed because of
that. So don't add it at all, only add it when it is needed.
Ok. I will add it later when I find such device.
thanks,
greg k-h
--
Best Regards
Tianyu Lan
linux kernel enabling team
--
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 v1 5/6] usb: otg: add device tree support to otg library
Hi,
On Tuesday 22 January 2013 04:06 PM, Mark Rutland wrote:
+struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
+ const char *phandle, u8 index)
+{
+ struct usb_phy *phy = NULL, **ptr;
+ unsigned long flags;
+ struct device_node *node;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, phandle, index);
+ if (!node) {
+ dev_dbg(dev, failed to get %s phandle in %s node\n, phandle,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
At any point past this, node's refcount is incremented (done automatically by
of_parse_phandle = of_find_node_by_phandle).
+
+ ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr) {
+ dev_dbg(dev, failed to allocate memory for devres\n);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ spin_lock_irqsave(phy_lock, flags);
+
+ phy = __of_usb_find_phy(node);
+ if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
+ phy = ERR_PTR(-EPROBE_DEFER);
+ devres_free(ptr);
+ goto err0;
+ }
+
+ *ptr = phy;
+ devres_add(dev, ptr);
+
+ get_device(phy-dev);
+
+err0:
+ spin_unlock_irqrestore(phy_lock, flags);
+
+ return phy;
+}
This means that on all of the exit paths, node's refcount is left incremented
incorrectly. You'll need an of_node_put(node) on each exit path.
Ok. Will fix it.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
On 01/22/2013 04:21 PM, kishon wrote: But it's better to check if deferred probing takes place whenever a new driver is bound to a device as you just mentioned. Whenever you load (might be also when you unload) a driver the deferred modules will try to probe again. This is to check back if the dependency of the deferred modules has been fulfilled by the new driver or not. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
On Tuesday 22 January 2013, Alan Stern wrote: In order to prevent this, you have to make sure that each glue driver depends on USB_ARCH_HAS_EHCI. A simple way to do this is to surround the Kconfig entries for those drivers with if USB USB_ARCH_HAS_EHCI ... endif. I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI as well once we have inverted the logic for selecting USB_EHCI_HCD, but there is another problem with that, because then we still need something to select USB_ARCH_HAS_HCD, or kill that symbol as well. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
Hi, On Tuesday 22 January 2013 09:08 PM, Peter Ujfalusi wrote: On 01/22/2013 04:21 PM, kishon wrote: But it's better to check if deferred probing takes place whenever a new driver is bound to a device as you just mentioned. Whenever you load (might be also when you unload) a driver the deferred modules will try to probe again. This is to check back if the dependency of the deferred modules has been fulfilled by the new driver or not. Thanks Peter. -Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 0/6] USB: Add support for multiple PHYs of same type
Op 22 jan. 2013, om 10:58 heeft Kishon Vijay Abraham I kis...@ti.com het volgende geschreven: This patch series adds support for adding multiple PHY's (of same type). The binding information has to be present in the PHY library (otg.c) in order for it to return the appropriate PHY whenever the USB controller request for the PHY. So added a new API usb_bind_phy() to pass the binding information. This API should be called by platform specific initialization code. So the binding should be done something like usb_bind_phy(musb-hdrc.0.auto, 0, omap-usb2.1.auto); specifying the USB controller device name, index, and the PHY device name. I have done this binding for OMAP platforms, but it should be done for all the platforms. After this design, the phy can be got by passing the USB controller device pointer and the index. Developed this patch series on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv after applying usb: musb: add driver for control module patch series and ARM: dts: omap: add dt data for MUSB Did basic enumeration testing in omap4 panda and omap3 beagle. With this patchset USB completely breaks on am33xx beaglebone, is that intended? -- 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 v1 0/6] USB: Add support for multiple PHYs of same type
On Tuesday 22 January 2013 09:11 PM, Koen Kooi wrote: Op 22 jan. 2013, om 10:58 heeft Kishon Vijay Abraham I kis...@ti.com het volgende geschreven: This patch series adds support for adding multiple PHY's (of same type). The binding information has to be present in the PHY library (otg.c) in order for it to return the appropriate PHY whenever the USB controller request for the PHY. So added a new API usb_bind_phy() to pass the binding information. This API should be called by platform specific initialization code. So the binding should be done something like usb_bind_phy(musb-hdrc.0.auto, 0, omap-usb2.1.auto); specifying the USB controller device name, index, and the PHY device name. I have done this binding for OMAP platforms, but it should be done for all the platforms. After this design, the phy can be got by passing the USB controller device pointer and the index. Developed this patch series on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv after applying usb: musb: add driver for control module patch series and ARM: dts: omap: add dt data for MUSB Did basic enumeration testing in omap4 panda and omap3 beagle. With this patchset USB completely breaks on am33xx beaglebone, is that intended? Not really. Does am33xx makes use of omap2430.c? Which PHY does am33xx uses? Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH net 2/3] net: cdc_mbim: send ZLP after max sized NTBs
H Bjørn, -Original Message- From: Bjørn Mork [mailto:bj...@mork.no] Sent: Tuesday, January 22, 2013 10:54 AM If you add ZLP for NTBs of dwNtbOutMaxSize, you are heavily affecting CPU load, increasing interrupt load by factor of 2 in high load traffic scenario and possibly decreasing throughput for all other devices which behaves correctly. The current cdc_ncm/cdc_mbim drivers will pad a NTB to the full dwNtbOutMaxSize whenever it reaches at least 512 bytes. The reason is that this allows more efficient device DMA operation. This is something we do to adapt to device hardware restrictions even though there is no such recommendations in the NCM/MBIM specs. There are a lot of things which were discussed during development of specifications, but not ended up in the final version of the spec due to various reasons. Companies attending USB-IF F2F meetings can benefit from discussions between member companies and get access to additional information not visible outside of USB-IF. The penalty on the host and bus should be obvious: Even with a quite small dwNtbOutMaxSize of 4096, we end up sending 8 x 512-byte data packets instead of the 2 we could have managed with. It was intentional and it's developer choice (see also the last comment). It's a straightforward approach, but this limit could be a dynamic value based on statistic and current load. Now you claim that sending 9 packets, where the last one is a zero length packet, increase the interrupt load by factor of 2? How is that? You set up DMA job to receive full NTB and get a single interrupt when job is done. It means while DMA is collecting data, CPU can do something else (send data to NW stack). In other protocols you need to indicate the end of data, but in NCM/MBIM we know for sure that host is not allowed to send more than dwNtbOutMaxSize bytes, so ZLP is not needed. If host decides to send ZLP after full NTB, CPU must handle additional INT per every full NTB instead of doing useful work. For FTP transfer with constantly full NTBs you get twice amount of Interrupts. Why is the device DMA restrictions not a fault, while the device ZLP requirement is? Both seem like reasonable device hardware/firmware implementation imposed restrictions to me. Something we'll just have to accept. Both specifications (NCM/MBIM) were written from the point of host (most likely PC with 2/4 core CPU) being more powerful than device and with requirement for host to honor device limitations. Regards, Alexey
Re: [PATCH v6 5/8] usb: add usb port auto power off mechanism
On Tue, Jan 22, 2013 at 11:32:13PM +0800, Lan Tianyu wrote:
On 2013/1/22 5:30, Greg KH wrote:
On Mon, Jan 21, 2013 at 10:18:04PM +0800, Lan Tianyu wrote:
@@ -127,7 +128,7 @@ static inline char *portspeed(struct usb_hub *hub, int
portstatus)
}
/* Note that hdev or one of its children must be locked! */
-static struct usb_hub *hdev_to_hub(struct usb_device *hdev)
+struct usb_hub *hdev_to_hub(struct usb_device *hdev)
This needs a better name now that this is a global function. No one
knows what a hdev is.
Actually the routine will only be used in the
driver/usb/core/(hub.c, port.c). Port also should be the part of
hub, right? Moving port related code to port.c is to make code more
clear. I am not sure whether we should rename it.
It is now a global symbol in the kernel name space, so yes, it should be
renamed.
If we renamed it, how about usb_hub_to_struct_hub? \
Should we do rename operation in a separate patch since
hdev_to_hub() is called many places in the hub.c?
That's fine with me.
{
if (!hdev || !hdev-actconfig || !hdev-maxchild)
return NULL;
@@ -393,7 +394,7 @@ static int clear_hub_feature(struct usb_device *hdev,
int feature)
/*
* USB 2.0 spec Section 11.24.2.2
*/
-static int clear_port_feature(struct usb_device *hdev, int port1, int
feature)
+int clear_port_feature(struct usb_device *hdev, int port1, int feature)
This is now a global function, please put usb_ infront of it.
Same above?
Yes.
-static int hub_port_debounce(struct usb_hub *hub, int port1)
+int hub_port_debounce(struct usb_hub *hub, int port1, bool
must_be_connected)
I hate boolean flags in functions that do different things depending on
the value. Can you just make two different functions here, and have
them call this private one with the proper flag set?
Sorry. I am not very sure I understand correctly.
Do you mean to create two wraps which call hub_port_debounce()?
Just like
hub_port_debounce_be_counted()
{
hub_port_debounce(...,..., true);
}
hub_port_debounce_be_counted()
{
hub_port_debounce(...,..., false);
}
If you name the functions differently, yes :)
@@ -3758,7 +3805,9 @@ static int hub_port_debounce(struct usb_hub *hub, int
port1)
if (!(portchange USB_PORT_STAT_C_CONNECTION)
(portstatus USB_PORT_STAT_CONNECTION) == connection) {
- stable_time += HUB_DEBOUNCE_STEP;
+ if (!must_be_connected || (connection
+ == USB_PORT_STAT_CONNECTION))
Please do:
if (!must_be_connected ||
(connection == USB_PORT_STAT_CONNECTION))
instead, that makes it much more readable.
Oh. I originally do the same thing. But there is following code
which requires this line to be more indention. This will cause this
line over 80 characters. So I had to break this line.
The above line, as written is under 80 characters, so I don't understand
the issue.
I finally find that if I just do following, it also can work.
if (!must_be_connected || connection)
stable_time += HUB_DEBOUNCE_STEP;
Does this make sense? Since connection only will be assigned to the
result of portstatus USB_PORT_STAT_CONNECTION.
Connection is an enumerated type, please be explicit when testing it.
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: USB issue with kernel 3.6
On Fri, 18 Jan 2013, Alan Stern wrote:
Well, I guess there's no choice but to go back to the one-at-a-time
approach. I'll write a proper patch for that.
And here it is at last. This completely replaces the earlier patch.
Alan Stern
Index: 3.7/drivers/usb/host/ehci-timer.c
===
--- 3.7.orig/drivers/usb/host/ehci-timer.c
+++ 3.7/drivers/usb/host/ehci-timer.c
@@ -113,21 +113,22 @@ static void ehci_poll_ASS(struct ehci_hc
if (want != actual) {
- /* Poll again later, but give up after about 20 ms */
- if (ehci-ASS_poll_count++ 20) {
- ehci_enable_event(ehci, EHCI_HRTIMER_POLL_ASS, true);
- return;
- }
- ehci_dbg(ehci, Waited too long for the async schedule status
(%x/%x), giving up\n,
- want, actual);
+ /* Poll again later */
+ ehci_enable_event(ehci, EHCI_HRTIMER_POLL_ASS, true);
+ ++ehci-ASS_poll_count;
+ return;
}
+
+ if (ehci-ASS_poll_count 20)
+ ehci_dbg(ehci, ASS poll count reached %d\n,
+ ehci-ASS_poll_count);
ehci-ASS_poll_count = 0;
/* The status is up-to-date; restart or stop the schedule as needed */
if (want == 0) {/* Stopped */
- if (ehci-async_count 0)
+ if (ehci-async_count 0) {
ehci_set_command_bit(ehci, CMD_ASE);
-
+ }
} else {/* Running */
if (ehci-async_count == 0) {
@@ -159,14 +160,14 @@ static void ehci_poll_PSS(struct ehci_hc
if (want != actual) {
- /* Poll again later, but give up after about 20 ms */
- if (ehci-PSS_poll_count++ 20) {
- ehci_enable_event(ehci, EHCI_HRTIMER_POLL_PSS, true);
- return;
- }
- ehci_dbg(ehci, Waited too long for the periodic schedule
status (%x/%x), giving up\n,
- want, actual);
+ /* Poll again later */
+ ehci_enable_event(ehci, EHCI_HRTIMER_POLL_PSS, true);
+ return;
}
+
+ if (ehci-PSS_poll_count 20)
+ ehci_dbg(ehci, PSS poll count reached %d\n,
+ ehci-PSS_poll_count);
ehci-PSS_poll_count = 0;
/* The status is up-to-date; restart or stop the schedule as needed */
Index: 3.7/drivers/usb/host/ehci-q.c
===
--- 3.7.orig/drivers/usb/host/ehci-q.c
+++ 3.7/drivers/usb/host/ehci-q.c
@@ -1203,17 +1203,26 @@ static void start_iaa_cycle(struct ehci_
if (ehci-async_iaa || ehci-async_unlinking)
return;
- /* Do all the waiting QHs at once */
- ehci-async_iaa = ehci-async_unlink;
- ehci-async_unlink = NULL;
-
/* If the controller isn't running, we don't have to wait for it */
if (unlikely(ehci-rh_state EHCI_RH_RUNNING)) {
+
+ /* Do all the waiting QHs */
+ ehci-async_iaa = ehci-async_unlink;
+ ehci-async_unlink = NULL;
+
if (!nested)/* Avoid recursion */
end_unlink_async(ehci);
/* Otherwise start a new IAA cycle */
} else if (likely(ehci-rh_state == EHCI_RH_RUNNING)) {
+ struct ehci_qh *qh;
+
+ /* Do only the first waiting QH (nVidia bug?) */
+ qh = ehci-async_unlink;
+ ehci-async_iaa = qh;
+ ehci-async_unlink = qh-unlink_next;
+ qh-unlink_next = NULL;
+
/* Make sure the unlinks are all visible to the hardware */
wmb();
@@ -1261,34 +1270,35 @@ static void end_unlink_async(struct ehci
}
}
+static void start_unlink_async(struct ehci_hcd *ehci, struct ehci_qh *qh);
+
static void unlink_empty_async(struct ehci_hcd *ehci)
{
- struct ehci_qh *qh, *next;
- boolstopped = (ehci-rh_state EHCI_RH_RUNNING);
+ struct ehci_qh *qh;
+ struct ehci_qh *qh_to_unlink = NULL;
boolcheck_unlinks_later = false;
+ int count = 0;
- /* Unlink all the async QHs that have been empty for a timer cycle */
- next = ehci-async-qh_next.qh;
- while (next) {
- qh = next;
- next = qh-qh_next.qh;
-
+ /* Find the last async QH which has been empty for a timer cycle */
+ for (qh = ehci-async-qh_next.qh; qh; qh = qh-qh_next.qh) {
if (list_empty(qh-qtd_list)
qh-qh_state == QH_STATE_LINKED) {
- if (!stopped qh-unlink_cycle ==
-
Re: Linux USB file storage gadget with new UDC
On Tue, Jan 22, 2013 at 10:49:50PM +0800, victor yeo wrote: Hi, It sounds like the UDC driver now works okay for control transfers but not for bulk transfers. Some code in file_storage.c that i cannot understand. In ep0_complete(), the code snippet: if (req-status == 0 req-context) ((fsg_routine_t) (req-context))(fsg); Does the UDC driver provide the context pointer to file_storage.c? That belongs to the gadget driver. file_storage.c maintains that req-context. Another gadget question: get_next_command() is receiving command from host PC, UDC HW isr routine is also receiving data from host PC. What is the difference between these two? hmm... ISR receives data and bounces it back to gadget driver. What do you mean ? Ok, rephrase the question, is this the flow for bulk transfer? 1) data is received by Usb mass storage HW, the UDC driver ISR is called to read the data to usb_request buffer 2) bulk_out_complete() in gadget driver, is called to set buffer state to full 3) get_next_command() in gadget driver, is called to read the CBW. 4) do_scsi_command() to process SCSI command encoded in CBW 5) send_status() sends the CSW to host Something like below: OUT Token - ISR - giveback() - bulk_out_complete() - get_next_command() - do_scsi_command() - usb_ep_queue() - OUT/IN Token - ISR - bulk_out_complete() - send_status() For the IN Token, i will just write the data to the HW buffer, and the flow will go to send_status(). I use a different USB cable, now the USB gadget is able to receive bulk transfer data from host PC. I am working on the bulk transfer code. Thank you for the very useful answers. np -- balbi signature.asc Description: Digital signature
Re: [PATCH v1 0/6] USB: Add support for multiple PHYs of same type
Hi, On Tuesday 22 January 2013 09:15 PM, kishon wrote: On Tuesday 22 January 2013 09:11 PM, Koen Kooi wrote: Op 22 jan. 2013, om 10:58 heeft Kishon Vijay Abraham I kis...@ti.com het volgende geschreven: This patch series adds support for adding multiple PHY's (of same type). The binding information has to be present in the PHY library (otg.c) in order for it to return the appropriate PHY whenever the USB controller request for the PHY. So added a new API usb_bind_phy() to pass the binding information. This API should be called by platform specific initialization code. So the binding should be done something like usb_bind_phy(musb-hdrc.0.auto, 0, omap-usb2.1.auto); specifying the USB controller device name, index, and the PHY device name. I have done this binding for OMAP platforms, but it should be done for all the platforms. After this design, the phy can be got by passing the USB controller device pointer and the index. Developed this patch series on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv after applying usb: musb: add driver for control module patch series and ARM: dts: omap: add dt data for MUSB Did basic enumeration testing in omap4 panda and omap3 beagle. With this patchset USB completely breaks on am33xx beaglebone, is that intended? Not really. Does am33xx makes use of omap2430.c? Which PHY does am33xx uses? I figured out it uses drivers/usb/musb/musb_dsps.c (So it doesn't use omap2430.c). I think it uses TWL4030_USB (TPS659x0) as PHY. Then we need to adapt am33xx to use devm_usb_get_phy_by_phandle. I'll see how to do it. Thank you for testing and reporting it :-) Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: nokia: Add mass storage driver to g_nokia
Hi,
On Tue, Jan 22, 2013 at 12:03:09PM +0100, Pali Rohár wrote:
On Monday 21 January 2013 09:05:06 Felipe Balbi wrote:
Hi,
On Sun, Jan 20, 2013 at 11:17:31AM +0100, Pali Rohár wrote:
On Sunday 20 January 2013 10:25:37 Felipe Balbi wrote:
On Sun, Jan 20, 2013 at 03:58:13AM +0100, Pali Rohár wrote:
Signed-off-by: Pali Rohár pali.ro...@gmail.com
NAK for two reasons:
a) the original Nokia kernel used a separate
g_file_storage gadget to use Mass Storage mode, use that
b) there is no commit log
Reason why add mass storage mode to g_nokia is to avoid
switching between g_{file,mass}_storage and g_nokia and to
have one gadget driver for Nokia N900. It is better to have
usb network and mass storage mode in one driver (and not to
unload load another).
I tested this patch with 3.8-rc3 kernel on Nokia N900 and
usb network with mass storage mode working without
problems.
Doesn't matter, in this case this is something which nokia
wrote to carry on their Maemo/MeeGo devices so unless someone
from Nokia says this is how they want to use nokia.c from now
on, I can't simply risk breaking all other users for your own
convenience.
Hello,
you may know that Nokia not working on any linux Maemo/MeeGo
systems anymore. And also that Nokia devices needs own patched
kernel. Also g_nokia gadget is for Nokia N900 and this device
with original Maemo 5 system which was supported by Nokia is
locked for patched 2.6.28 kernel. More drivers in 2.6.28 was not
upstreamed, so running other kernels will not work without
problems. And waiting what Nokia say is now irrelevant, because
nonsense, many guys (including myself) have n900 booting mainline
kernel.
N900 is at end-of-live cycle and Nokia not doing with linux
devices anymore. So I do not understand why current code cannot
be extended for more functionality. Because patch is not signed
by Nokia?
If I let your change in, you could be breaking the folks who are still
using n900 as their daily device. Remember that Mass Storage access to
the media, prevents phone from using mass storage too and the way Maemo
5 was done is that it will unload mass storage when that's not being
used.
There are more developers which playing with upstream kernel on
Nokia N900 and trying to use some modern linux distribution on
it. And who using upstream kernels on N900 also want some
additional functionality which was not in 2.6.28. And having mass
storage in g_nokia is usefull.
it makes no difference.
Also you can see that this patch simply adding new composite
gadget to exisitng driver. Nothing is removed, so original code
is compatible with these changes. If somebody still want (for
you could be breaking phone's own access to the memory card.
some reason) to switching between g_nokia and g_file_storage (ops,
it was renamed to g_mass_storage, so now it is broken on old
Nokia systems...) it is still possible.
no it's not, you can anyways make a symbolic link. Besides, before
removing g_file_storage we waited quite some time.
And when I looked into nokia 2.6.28 kernel, they also patched
g_file_storage, so I think it is incompatible with upstream too.
it's patched only for strings.
So why to care about current API implementation in upstream
kernel (do not allow to add new functionality) which is
incompatible with Nokia patched kernel?
Because I don't think g_nokia needs mass storage and because I want to
remove all gadget drivers from kernel (keep only function drivers).
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v6 5/8] usb: add usb port auto power off mechanism
On 2013/1/23 0:02, Greg KH wrote:
On Tue, Jan 22, 2013 at 11:32:13PM +0800, Lan Tianyu wrote:
On 2013/1/22 5:30, Greg KH wrote:
On Mon, Jan 21, 2013 at 10:18:04PM +0800, Lan Tianyu wrote:
@@ -127,7 +128,7 @@ static inline char *portspeed(struct usb_hub *hub, int
portstatus)
}
/* Note that hdev or one of its children must be locked! */
-static struct usb_hub *hdev_to_hub(struct usb_device *hdev)
+struct usb_hub *hdev_to_hub(struct usb_device *hdev)
This needs a better name now that this is a global function. No one
knows what a hdev is.
Actually the routine will only be used in the
driver/usb/core/(hub.c, port.c). Port also should be the part of
hub, right? Moving port related code to port.c is to make code more
clear. I am not sure whether we should rename it.
It is now a global symbol in the kernel name space, so yes, it should be
renamed.
If we renamed it, how about usb_hub_to_struct_hub? \
Should we do rename operation in a separate patch since
hdev_to_hub() is called many places in the hub.c?
That's fine with me.
{
if (!hdev || !hdev-actconfig || !hdev-maxchild)
return NULL;
@@ -393,7 +394,7 @@ static int clear_hub_feature(struct usb_device *hdev, int
feature)
/*
* USB 2.0 spec Section 11.24.2.2
*/
-static int clear_port_feature(struct usb_device *hdev, int port1, int feature)
+int clear_port_feature(struct usb_device *hdev, int port1, int feature)
This is now a global function, please put usb_ infront of it.
Same above?
Yes.
-static int hub_port_debounce(struct usb_hub *hub, int port1)
+int hub_port_debounce(struct usb_hub *hub, int port1, bool must_be_connected)
I hate boolean flags in functions that do different things depending on
the value. Can you just make two different functions here, and have
them call this private one with the proper flag set?
Sorry. I am not very sure I understand correctly.
Do you mean to create two wraps which call hub_port_debounce()?
Just like
hub_port_debounce_be_counted()
{
hub_port_debounce(...,..., true);
}
hub_port_debounce_be_counted()
{
hub_port_debounce(...,..., false);
}
If you name the functions differently, yes :)
@@ -3758,7 +3805,9 @@ static int hub_port_debounce(struct usb_hub *hub, int
port1)
if (!(portchange USB_PORT_STAT_C_CONNECTION)
(portstatus USB_PORT_STAT_CONNECTION) == connection) {
- stable_time += HUB_DEBOUNCE_STEP;
+ if (!must_be_connected || (connection
+ == USB_PORT_STAT_CONNECTION))
Please do:
if (!must_be_connected ||
(connection == USB_PORT_STAT_CONNECTION))
instead, that makes it much more readable.
Oh. I originally do the same thing. But there is following code
which requires this line to be more indention. This will cause this
line over 80 characters. So I had to break this line.
The above line, as written is under 80 characters, so I don't understand
the issue.
If I do following, scripts/checkpatch.pl will complain over 80 characters.
@@ -3767,7 +3814,9 @@
if (!(portchange USB_PORT_STAT_C_CONNECTION)
(portstatus USB_PORT_STAT_CONNECTION) == connection) {
- stable_time += HUB_DEBOUNCE_STEP;
+ if (!must_be_connected ||
+ (connection ==
USB_PORT_STAT_CONNECTION))
+ stable_time += HUB_DEBOUNCE_STEP;
if (stable_time = HUB_DEBOUNCE_STABLE)
break;
} else {
WARNING: line over 80 characters
#203: FILE: drivers/usb/core/hub.c:3818:
+ (connection ==
USB_PORT_STAT_CONNECTION))
If I use (connection USB_PORT_STAT_CONNECTION)), that will be ok.
I am curious about that checkpatch.pl considers a space or tab as a character?
I finally find that if I just do following, it also can work.
if (!must_be_connected || connection)
stable_time += HUB_DEBOUNCE_STEP;
Does this make sense? Since connection only will be assigned to the
result of portstatus USB_PORT_STAT_CONNECTION.
Connection is an enumerated type, please be explicit when testing it.
thanks,
greg k-h
--
Best Regards
Tianyu Lan
linux kernel enabling team
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] USB: EHCI: fix several bugs and error for v3.8
Greg: The following series fixes some bugs and build errors introduced into ehci-hcd during the v3.8 kernel development, partly as a result of moving over to the ehci-hcd is a library approach and partly as a result of the ARM multi-arch work: The ehci_stats structure is built conditionally, but the condition is defined in ehci-hcd.c rather than ehci.h. Consequently the platform drivers end up with an incorrect view of the ehci_hcd structure (discovered and fixed by Roger Quadros). The test for whether the Chipidea platform driver is present should be IS_ENABLED(), not defined(). Although space is reserved for a platform driver's private data at the end of the ehci_hcd structure, no name was ever provided for this space. An ARM allmodconfig build gets a conflict between ehci-mxc and ehci-platform. This conflict is resolved by converting ehci-mxc over to the new approach. Because this all fix bugs and build errors, they should all be merged before 3.8-final is released. 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 1/4] USB: EHCI: Move definition of EHCI_STATS to ehci.h
From 70a3621d583c0c76d0bf8239b27eb65d01d918b2 Mon Sep 17 00:00:00 2001
From: Roger Quadros rog...@ti.com
Date: Tue, 22 Jan 2013 14:37:57 +0200
Subject: [PATCH] USB: EHCI: Move defination of EHCI_STATS to ehci.h
Without this, platform drivers e.g. ehci-omap.c will see a
different version of struct ehci_hcd than ehci-hcd.c and
break reference to 'debug_dir' and 'priv' members when
CONFIG_USB_DEBUG is enabled.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-hcd.c |4
drivers/usb/host/ehci.h |4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 97b829e..5a35246 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -74,10 +74,6 @@ static const charhcd_name [] = ehci_hcd;
#undef VERBOSE_DEBUG
#undef EHCI_URB_TRACE
-#ifdef DEBUG
-#define EHCI_STATS
-#endif
-
/* magic numbers that can affect system performance */
#defineEHCI_TUNE_CERR 3 /* 0-3 qtd retries; 0 == don't
stop */
#defineEHCI_TUNE_RL_HS 4 /* nak throttle; see 4.9 */
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index e9f8c0e..31a935d 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -38,6 +38,10 @@ typedef __u16 __bitwise __hc16;
#endif
/* statistics can be kept for tuning/monitoring */
+#ifdef DEBUG
+#define EHCI_STATS
+#endif
+
struct ehci_stats {
/* irq usage */
unsigned long normal;
-- 1.7.4.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: [PATCH v1 0/6] USB: Add support for multiple PHYs of same type
Op 22 jan. 2013, om 17:16 heeft kishon kis...@ti.com het volgende geschreven: Hi, On Tuesday 22 January 2013 09:15 PM, kishon wrote: On Tuesday 22 January 2013 09:11 PM, Koen Kooi wrote: Op 22 jan. 2013, om 10:58 heeft Kishon Vijay Abraham I kis...@ti.com het volgende geschreven: This patch series adds support for adding multiple PHY's (of same type). The binding information has to be present in the PHY library (otg.c) in order for it to return the appropriate PHY whenever the USB controller request for the PHY. So added a new API usb_bind_phy() to pass the binding information. This API should be called by platform specific initialization code. So the binding should be done something like usb_bind_phy(musb-hdrc.0.auto, 0, omap-usb2.1.auto); specifying the USB controller device name, index, and the PHY device name. I have done this binding for OMAP platforms, but it should be done for all the platforms. After this design, the phy can be got by passing the USB controller device pointer and the index. Developed this patch series on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv after applying usb: musb: add driver for control module patch series and ARM: dts: omap: add dt data for MUSB Did basic enumeration testing in omap4 panda and omap3 beagle. With this patchset USB completely breaks on am33xx beaglebone, is that intended? Not really. Does am33xx makes use of omap2430.c? Which PHY does am33xx uses? I figured out it uses drivers/usb/musb/musb_dsps.c (So it doesn't use omap2430.c). I think it uses TWL4030_USB (TPS659x0) as PHY. Actually it uses nop-phy as a phy, which is missing from arch/arm/boot/dts/am33xx.dtsi, so mainline is already broken. But adding the nop-phy to the DT is easy enough to patch in locally. regards, Koen-- 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 net 2/3] net: cdc_mbim: send ZLP after max sized NTBs
Hi! On Tue, Jan 22, 2013 at 12:01 AM, Bjørn Mork bj...@mork.no wrote: Yauheni Kaliuta y.kali...@gmail.com writes: BM == Bjørn Mork writes: We normally avoid sending ZLPs by padding NTBs with a zero byte if the NTB is shorter than dwNtbOutMaxSize, resulting in a short USB packet instead of a ZLP. But in the case where the NTB length is exactly dwNtbOutMaxSize and this is an exact multiplum of wMaxPacketSize, then we must send a ZLP. The idea of NCM was to avoid extra ZLPs. If your transfer is exactly dwNtbOutMaxSize, it's known, you can submit such request on the receiver side and you do not need any EOT indicatation, so the frametime can be used for useful data. Yes, that makes sense. And I understand that both you and Alexey are of this opinion. But this idea is by no means made clear (to me) in the spec. I do not think the current wording is precise enough to expect every implementor to understand any such intent. The only place I find either short packet or ZLP mentioned in the NCM spec is in tables 3-1 and 3-2, describing the 16bit and 32bit NTH formats, in the description of the (d)wBlockLength fields. And even there it is only mentioned in the context of the special (d)wBlockLength = 0x handling. I agree, it could be a bit unclear, If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMax- PacketSize for the given pipe, then no ZLP shall be sent. is an independent clause. If the intent was to prevent ZLPs, then it would have been wise to write that in the NCM standard. As it stands you have to use a lot of imagination to read that intent into the current spec. Well, I hope the guys took your complains into account and will fix the wording in the future spec versions. -- 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 v6 5/8] usb: add usb port auto power off mechanism
On Wed, Jan 23, 2013 at 12:58:09AM +0800, Lan Tianyu wrote:
On 2013/1/23 0:02, Greg KH wrote:
On Tue, Jan 22, 2013 at 11:32:13PM +0800, Lan Tianyu wrote:
On 2013/1/22 5:30, Greg KH wrote:
@@ -3758,7 +3805,9 @@ static int hub_port_debounce(struct usb_hub *hub,
int port1)
if (!(portchange USB_PORT_STAT_C_CONNECTION)
(portstatus USB_PORT_STAT_CONNECTION) ==
connection) {
- stable_time += HUB_DEBOUNCE_STEP;
+ if (!must_be_connected || (connection
+ == USB_PORT_STAT_CONNECTION))
Please do:
if (!must_be_connected ||
(connection == USB_PORT_STAT_CONNECTION))
instead, that makes it much more readable.
Oh. I originally do the same thing. But there is following code
which requires this line to be more indention. This will cause this
line over 80 characters. So I had to break this line.
The above line, as written is under 80 characters, so I don't understand
the issue.
If I do following, scripts/checkpatch.pl will complain over 80 characters.
@@ -3767,7 +3814,9 @@
if (!(portchange USB_PORT_STAT_C_CONNECTION)
(portstatus USB_PORT_STAT_CONNECTION) == connection) {
- stable_time += HUB_DEBOUNCE_STEP;
+ if (!must_be_connected ||
+ (connection ==
USB_PORT_STAT_CONNECTION))
+ stable_time += HUB_DEBOUNCE_STEP;
if (stable_time = HUB_DEBOUNCE_STABLE)
break;
} else {
WARNING: line over 80 characters
#203: FILE: drivers/usb/core/hub.c:3818:
+ (connection ==
USB_PORT_STAT_CONNECTION))
Of course, which is why I didn't say to do that :)
See above for where to line up the line with the previous one, showing
that it all can fit just fine within 80 characters.
If I use (connection USB_PORT_STAT_CONNECTION)), that will be ok.
I am curious about that checkpatch.pl considers a space or tab as a character?
It understands the difference between tabs and spaces properly.
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 4/4] USB: EHCI: fix build error in ehci-mxc
On Tue, Jan 22, 2013 at 12:00:35PM -0500, Alan Stern wrote: This patch (as1643) fixes a build error in ehci-hcd when compiling for ARM with allmodconfig: drivers/usb/host/ehci-hcd.c:1285:0: warning: PLATFORM_DRIVER redefined [enabled by default] drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used [-Wunused-variable] drivers/usb/host/ehci-hcd.c:1285:0: warning: PLATFORM_DRIVER redefined [enabled by default] drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition The fix is to convert ehci-mxc over to the new ehci-hcd is a library scheme so that it can coexist peacefully with the ehci-platform driver. As part of the conversion the ehci_mxc_priv data structure, which was allocated dynamically, is now placed where it belongs: in the private area at the end of struct ehci_hcd. Signed-off-by: Alan Stern st...@rowland.harvard.edu Tested-by: Shawn Guo shawn@linaro.org --- drivers/usb/host/Kconfig|2 drivers/usb/host/Makefile |1 drivers/usb/host/ehci-hcd.c |6 -- drivers/usb/host/ehci-mxc.c | 127 +++- 4 files changed, 58 insertions(+), 78 deletions(-) This patch fails to apply: patching file drivers/usb/host/Kconfig patching file drivers/usb/host/Makefile patching file drivers/usb/host/ehci-hcd.c patching file drivers/usb/host/ehci-mxc.c Hunk #1 FAILED at 17. Hunk #2 succeeded at 112 (offset -1 lines). Hunk #3 succeeded at 129 (offset -1 lines). Hunk #4 succeeded at 167 (offset -1 lines). Hunk #5 succeeded at 194 (offset -1 lines). Hunk #6 succeeded at 214 (offset -1 lines). Hunk #7 succeeded at 242 (offset -1 lines). Hunk #8 succeeded at 254 (offset -1 lines). Hunk #9 succeeded at 277 (offset -1 lines). 1 out of 9 hunks FAILED -- saving rejects to file drivers/usb/host/ehci-mxc.c.rej Any ideas? I've applied the first three patches now, but not this one. 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: USB issue with kernel 3.6
Hi Alan, On Tue, Jan 22, 2013 at 11:09:43AM -0500, Alan Stern wrote: On Fri, 18 Jan 2013, Alan Stern wrote: Well, I guess there's no choice but to go back to the one-at-a-time approach. I'll write a proper patch for that. And here it is at last. This completely replaces the earlier patch. thanks for the patch, this will probably be week-end task. Usual question, should I remove the previous two patches or does this apply on top of them? You wrote replaces, I assume the second option is correct, but I would prefere to confirm... Thanks, bye, -- piergiorgio -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB issue with kernel 3.6
On Tue, 22 Jan 2013, Piergiorgio Sartor wrote: Hi Alan, On Tue, Jan 22, 2013 at 11:09:43AM -0500, Alan Stern wrote: On Fri, 18 Jan 2013, Alan Stern wrote: Well, I guess there's no choice but to go back to the one-at-a-time approach. I'll write a proper patch for that. And here it is at last. This completely replaces the earlier patch. thanks for the patch, this will probably be week-end task. Usual question, should I remove the previous two patches or does this apply on top of them? You wrote replaces, I assume the second option is correct, but I would prefere to confirm... Yes, remove all the previous patches before applying this one. 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 4/4] USB: EHCI: fix build error in ehci-mxc
On Tue, 22 Jan 2013, Greg KH wrote: This patch fails to apply: patching file drivers/usb/host/Kconfig patching file drivers/usb/host/Makefile patching file drivers/usb/host/ehci-hcd.c patching file drivers/usb/host/ehci-mxc.c Hunk #1 FAILED at 17. Hunk #2 succeeded at 112 (offset -1 lines). Hunk #3 succeeded at 129 (offset -1 lines). Hunk #4 succeeded at 167 (offset -1 lines). Hunk #5 succeeded at 194 (offset -1 lines). Hunk #6 succeeded at 214 (offset -1 lines). Hunk #7 succeeded at 242 (offset -1 lines). Hunk #8 succeeded at 254 (offset -1 lines). Hunk #9 succeeded at 277 (offset -1 lines). 1 out of 9 hunks FAILED -- saving rejects to file drivers/usb/host/ehci-mxc.c.rej Any ideas? I've applied the first three patches now, but not this one. I haven't synced with your repository for a couple of weeks. I'll do that shortly and adjust the patch. 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 v6 5/8] usb: add usb port auto power off mechanism
On 2013/1/23 1:18, Greg KH wrote:
On Wed, Jan 23, 2013 at 12:58:09AM +0800, Lan Tianyu wrote
The above line, as written is under 80 characters, so I don't understand
the issue.
If I do following, scripts/checkpatch.pl will complain over 80 characters.
@@ -3767,7 +3814,9 @@
if (!(portchange USB_PORT_STAT_C_CONNECTION)
(portstatus USB_PORT_STAT_CONNECTION) == connection) {
- stable_time += HUB_DEBOUNCE_STEP;
+ if (!must_be_connected ||
+ (connection ==
USB_PORT_STAT_CONNECTION))
+ stable_time += HUB_DEBOUNCE_STEP;
if (stable_time = HUB_DEBOUNCE_STABLE)
break;
} else {
WARNING: line over 80 characters
#203: FILE: drivers/usb/core/hub.c:3818:
+ (connection ==
USB_PORT_STAT_CONNECTION))
Of course, which is why I didn't say to do that :)
See above for where to line up the line with the previous one, showing
that it all can fit just fine within 80 characters.
Ok. I get it. learn one more trick. :)
Now I have two solutions. Which one do you think more readable?
@@ -3740,7 +3814,9 @@ static int hub_port_debounce(struct usb_hub *hub, int
port1)
if (!(portchange USB_PORT_STAT_C_CONNECTION)
(portstatus USB_PORT_STAT_CONNECTION) == connection) {
- stable_time += HUB_DEBOUNCE_STEP;
+ if (!must_be_connected ||
+ (connection USB_PORT_STAT_CONNECTION))
+ stable_time += HUB_DEBOUNCE_STEP;
if (stable_time = HUB_DEBOUNCE_STABLE)
break;
@@ -3740,7 +3814,9 @@ static int hub_port_debounce(struct usb_hub *hub, int
port1)
if (!(portchange USB_PORT_STAT_C_CONNECTION)
(portstatus USB_PORT_STAT_CONNECTION) == connection) {
- stable_time += HUB_DEBOUNCE_STEP;
+ if (!must_be_connected ||
+(connection == USB_PORT_STAT_CONNECTION))
+ stable_time += HUB_DEBOUNCE_STEP;
if (stable_time = HUB_DEBOUNCE_STABLE)
If I use (connection USB_PORT_STAT_CONNECTION)), that will be ok.
I am curious about that checkpatch.pl considers a space or tab as a character?
It understands the difference between tabs and spaces properly.
thanks,
greg k-h
--
Best Regards
Tianyu Lan
linux kernel enabling team
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB subsystem stops working
On Tue, 22 Jan 2013, Norbert Preining wrote: Hi Felipe, hi all, On Mo, 21 Jan 2013, Felipe Balbi wrote: Can you try rebuilding your kernel with CONFIG_USB_DEBUG=y and run your test again ? Maybe it gives us more information of what's going on. Ok, I can reliably reproduce the problem as follows: * connect the kindle, it goes into usb disk mode * !!! important !!! use the temporary gnome3 dbus window to Eject the device after that the device is not really ejected * use eject /dev/sdb after this the device is actually ejected * unplug and replug here the usb system does not recognize the device anymore, and does not react on any usb connections * call lsusb -v gets it back to normal * repeat the above I have collected the syslog output of one of the cycles starting from lsusb -v to get back to normal, plugging, ejecting with dbus window, eject with cmd line, plug/replug without effect, etc. The log can be found at http://www.preining.info/usb-syslog-prob.txt I have documented the steps *in* the log file by calling logger with the appropriate steps, so please seach for norbert: which will give you the comments I have written with logger and the sequence of actions. Hope that helps, and let me know if you want/need more details. It looks like things may improve if you do echo 50 /sys/bus/usb/devices/usb1/power/autosuspend_delay_ms Quite possiblly your problem was caused when the default autosuspend delay for hubs was changed from 2 seconds to 0. Increasing it to 50 ms might fix things. 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: USB subsystem stops working
On Tue, 22 Jan 2013, Alan Stern wrote: On Tue, 22 Jan 2013, Norbert Preining wrote: Hi Felipe, hi all, On Mo, 21 Jan 2013, Felipe Balbi wrote: Can you try rebuilding your kernel with CONFIG_USB_DEBUG=y and run your test again ? Maybe it gives us more information of what's going on. Ok, I can reliably reproduce the problem as follows: * connect the kindle, it goes into usb disk mode * !!! important !!! use the temporary gnome3 dbus window to Eject the device after that the device is not really ejected * use eject /dev/sdb after this the device is actually ejected * unplug and replug here the usb system does not recognize the device anymore, and does not react on any usb connections * call lsusb -v gets it back to normal * repeat the above I have collected the syslog output of one of the cycles starting from lsusb -v to get back to normal, plugging, ejecting with dbus window, eject with cmd line, plug/replug without effect, etc. The log can be found at http://www.preining.info/usb-syslog-prob.txt I have documented the steps *in* the log file by calling logger with the appropriate steps, so please seach for norbert: which will give you the comments I have written with logger and the sequence of actions. Hope that helps, and let me know if you want/need more details. It looks like things may improve if you do echo 50 /sys/bus/usb/devices/usb1/power/autosuspend_delay_ms Quite possiblly your problem was caused when the default autosuspend delay for hubs was changed from 2 seconds to 0. Increasing it to 50 ms might fix things. I did some testing over here. It looks like in addition to increasing the autosuspend delay, the following patch is needed. Alan Stern Index: usb-3.7/drivers/usb/host/ehci-hub.c === --- usb-3.7.orig/drivers/usb/host/ehci-hub.c +++ usb-3.7/drivers/usb/host/ehci-hub.c @@ -591,6 +591,7 @@ ehci_hub_status_data (struct usb_hcd *hc int ports, i, retval = 1; unsigned long flags; u32 ppcd = 0; + boolpolling = false; /* init status to no-changes */ buf [0] = 0; @@ -648,8 +649,15 @@ ehci_hub_status_data (struct usb_hcd *hc buf [1] |= 1 (i - 7); status = STS_PCD; } + if (ehci-reset_done[i]) + polling = true; } - /* FIXME autosuspend idle root hubs */ + + if (polling) + set_bit(HCD_FLAG_POLL_RH, hcd-flags); + else + clear_bit(HCD_FLAG_POLL_RH, hcd-flags); + spin_unlock_irqrestore (ehci-lock, flags); return status ? retval : 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
Root hub autosusend delay
Lei: It turns out that your patch setting the autosuspend delay for hubs to 0 causes problems for root hubs. They need a delay of at least 30 ms. When a child device sends a remote wakeup request, the root hub generates an interrupt. The HCD's interrupt handler sees what happened and requests a runtime resume for the root hub. However it can't tell the hub driver about the wakeup request until the port resume is finished, which takes about 25 ms. During that time, the hub driver won't know what has happened and so it will try to autosuspend. The autosuspend will fail because the port is resuming, but the hub driver will go right ahead and keep trying to autosuspend. This will continue until the port resume is complete. In order to avoid all these extra autosuspend attempts, the delay for root hubs should be set to something larger than 25 ms, such as 30 ms. Do you agree? 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
