Re: [PATCH 1/1] usb: fix build error without CONFIG_USB_PHY
On Wed, Jun 19, 2013 at 10:11:05AM +0800, Peter Chen wrote:
on i386:
drivers/built-in.o: In function `ci_hdrc_probe':
core.c:(.text+0x20446b): undefined reference to `of_usb_get_phy_mode'
Signed-off-by: Peter Chen peter.c...@freescale.com
---
include/linux/usb/of.h | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
index e460a24..a0aa1c8 100644
--- a/include/linux/usb/of.h
+++ b/include/linux/usb/of.h
@@ -11,18 +11,22 @@
#include linux/usb/phy.h
#ifdef CONFIG_OF
let's use IS_ENABLED() here
-enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np);
#else
-static inline enum usb_phy_interface of_usb_get_phy_mode(struct device_node
*np)
+static inline enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np)
{
- return USBPHY_INTERFACE_MODE_UNKNOWN;
+ return USB_DR_MODE_UNKNOWN;
}
+#endif
-static inline enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np)
+#if defined(CONFIG_OF) defined(CONFIG_USB_PHY)
and here
+enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
+#else
+static inline enum usb_phy_interface of_usb_get_phy_mode(struct device_node
*np)
{
- return USB_DR_MODE_UNKNOWN;
+ return USBPHY_INTERFACE_MODE_UNKNOWN;
}
+
#endif
Also, why can't the same problem happen with of_usb_get_dr_mode() ??
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] build some drivers only when compile-testing
On 06/18/2013 06:04 PM, Greg Kroah-Hartman wrote: So currently I have what is attached... Comments? Looks good to me, want me to queue it up through my char/misc driver tree for 3.11? If there are no objections... Whoever picks that up, I would be happy 8-). -- js 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 1/1] usb: fix build error without CONFIG_USB_PHY
On Wed, Jun 19, 2013 at 09:25:27AM +0300, Felipe Balbi wrote:
On Wed, Jun 19, 2013 at 10:11:05AM +0800, Peter Chen wrote:
on i386:
drivers/built-in.o: In function `ci_hdrc_probe':
core.c:(.text+0x20446b): undefined reference to `of_usb_get_phy_mode'
Signed-off-by: Peter Chen peter.c...@freescale.com
---
include/linux/usb/of.h | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
index e460a24..a0aa1c8 100644
--- a/include/linux/usb/of.h
+++ b/include/linux/usb/of.h
@@ -11,18 +11,22 @@
#include linux/usb/phy.h
#ifdef CONFIG_OF
let's use IS_ENABLED() here
-enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np);
#else
-static inline enum usb_phy_interface of_usb_get_phy_mode(struct
device_node *np)
+static inline enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np)
{
- return USBPHY_INTERFACE_MODE_UNKNOWN;
+ return USB_DR_MODE_UNKNOWN;
}
+#endif
-static inline enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np)
+#if defined(CONFIG_OF) defined(CONFIG_USB_PHY)
and here
Will change
+enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
+#else
+static inline enum usb_phy_interface of_usb_get_phy_mode(struct
device_node *np)
{
- return USB_DR_MODE_UNKNOWN;
+ return USBPHY_INTERFACE_MODE_UNKNOWN;
}
+
#endif
Also, why can't the same problem happen with of_usb_get_dr_mode() ??
It is only related to CONFIG_OF, no relationship with other
configs.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] build some drivers only when compile-testing
On 17/06/13 23:05, Jiri Slaby wrote: The last point I inclined to the Greg's argument to remove the EXPERT dependency. So currently I have what is attached... Comments? The patch looks a bit odd with the USB_CHIPIDEA_IMX parts. You're not adding COMPILE_TEST there, but you're adding a totally new config option, and also changing the Makefile. Maybe that's ok, but there's no mention about this in the desc. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] build some drivers only when compile-testing
On 06/19/2013 09:10 AM, Tomi Valkeinen wrote: On 17/06/13 23:05, Jiri Slaby wrote: The last point I inclined to the Greg's argument to remove the EXPERT dependency. So currently I have what is attached... Comments? The patch looks a bit odd with the USB_CHIPIDEA_IMX parts. You're not adding COMPILE_TEST there, but you're adding a totally new config option, and also changing the Makefile. Look: +config USB_CHIPIDEA_IMX + bool ChipIdea IMX support + depends on OF_DEVICE (ARM || COMPILE_TEST) COMPILE_TEST added here -- js 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: Linux USB file storage gadget with new UDC
Hi, There is a mistake in the previous log file, because the fifo size is still set to 512 byte. Now i change it to 64 byte if it is Full speed. The FIFO size should always be set to the value in the endpoint descriptor, no matter what speed the connection is. The log file are attached. The log shows that your 64-byte transfers don't work very well. The first one didn't send any bytes. The second one sent only 4 bytes. And each of the ones after that sent 0 bytes. Alan Stern PS: Something was very wrong with the log file you posted. It is full of bad characters. You can it here: Yes, i see the bad characters in the log file. I apologize for that, my eyes was in pain after looking thru the log files and did not notice that when i attached the log file. The good news is i can get gadget to work with Lenovo x100e on Ubuntu and Windows. The change is adding more delay after writing to endpoint one IN FIFO register, for the case of writing more than the endpoint buffer size. However, the gadget only work on high-speed mode. If i disable ehci_hcd driver in Ubuntu (force it to be full speed), the same problem of SCSI_READ_10 command asking 4096 bytes and gadget returning the data, and gadget reset, still happens. 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: [PATCH] build some drivers only when compile-testing
On 19/06/13 10:12, Jiri Slaby wrote: On 06/19/2013 09:10 AM, Tomi Valkeinen wrote: On 17/06/13 23:05, Jiri Slaby wrote: The last point I inclined to the Greg's argument to remove the EXPERT dependency. So currently I have what is attached... Comments? The patch looks a bit odd with the USB_CHIPIDEA_IMX parts. You're not adding COMPILE_TEST there, but you're adding a totally new config option, and also changing the Makefile. Look: +config USB_CHIPIDEA_IMX + bool ChipIdea IMX support + depends on OF_DEVICE (ARM || COMPILE_TEST) COMPILE_TEST added here My point was that you're not adding COMPILE_TEST to an existing config option, you're creating a totally new config option. As I said, that's probably ok, but it'd be nice to mention extra things like that in the desc. The pedantic approach would be to do the makefile and Kconfig change in an earlier patch, and then add only COMPILE_TEST. Tomi signature.asc Description: OpenPGP digital signature
[PATCH v2 1/1] usb: fix build error without CONFIG_USB_PHY
on i386:
drivers/built-in.o: In function `ci_hdrc_probe':
core.c:(.text+0x20446b): undefined reference to `of_usb_get_phy_mode'
Signed-off-by: Peter Chen peter.c...@freescale.com
---
Changes for v2:
- Using IS_ENABLED to MACRO define
include/linux/usb/of.h | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
index e460a24..a0ef405 100644
--- a/include/linux/usb/of.h
+++ b/include/linux/usb/of.h
@@ -10,19 +10,23 @@
#include linux/usb/otg.h
#include linux/usb/phy.h
-#ifdef CONFIG_OF
-enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
+#if IS_ENABLED(CONFIG_OF)
enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np);
#else
-static inline enum usb_phy_interface of_usb_get_phy_mode(struct device_node
*np)
+static inline enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np)
{
- return USBPHY_INTERFACE_MODE_UNKNOWN;
+ return USB_DR_MODE_UNKNOWN;
}
+#endif
-static inline enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np)
+#if IS_ENABLED(CONFIG_OF) IS_ENABLED(CONFIG_USB_PHY)
+enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
+#else
+static inline enum usb_phy_interface of_usb_get_phy_mode(struct device_node
*np)
{
- return USB_DR_MODE_UNKNOWN;
+ return USBPHY_INTERFACE_MODE_UNKNOWN;
}
+
#endif
#endif /* __LINUX_USB_OF_H */
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] USB: initialize or shutdown PHY when add or remove host controller
Hi Chao,
On 06/19/2013 05:31 AM, Chao Xie wrote:
Some controller need software to initialize PHY before add
host controller, and shut down PHY after remove host controller.
Add the generic code for these controllers so they do not need
do it in its own host controller driver.
Signed-off-by: Chao Xie chao@marvell.com
---
drivers/usb/core/hcd.c | 24 +++-
1 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index d53547d..301c639 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -40,9 +40,11 @@
#include linux/platform_device.h
#include linux/workqueue.h
#include linux/pm_runtime.h
+#include linux/err.h
#include linux/usb.h
#include linux/usb/hcd.h
+#include linux/usb/phy.h
#include usb.h
@@ -2531,12 +2533,26 @@ int usb_add_hcd(struct usb_hcd *hcd,
*/
set_bit(HCD_FLAG_RH_RUNNING, hcd-flags);
+ /* In case hcd-phy contains the error code. */
+ if (IS_ERR(hcd-phy))
+ hcd-phy = NULL;
+
+ /* Initialize the PHY before other hardware operation. */
+ if (hcd-phy) {
+ retval = usb_phy_init(hcd-phy);
+ if (retval) {
+ dev_err(hcd-self.controller,
+ can't initialize phy\n);
+ goto err_hcd_driver_setup;
+ }
+ }
+
/* reset is misnamed; its role is now one-time init. the controller
* should already have been reset (and boot firmware kicked off etc).
*/
if (hcd-driver-reset (retval = hcd-driver-reset(hcd)) 0) {
dev_err(hcd-self.controller, can't setup\n);
- goto err_hcd_driver_setup;
+ goto err_hcd_driver_init_phy;
}
hcd-rh_pollable = 1;
@@ -2608,6 +2624,9 @@ err_hcd_driver_start:
if (usb_hcd_is_primary_hcd(hcd) hcd-irq 0)
free_irq(irqnum, hcd);
err_request_irq:
+err_hcd_driver_init_phy:
+ if (hcd-phy)
+ usb_phy_shutdown(hcd-phy);
err_hcd_driver_setup:
err_set_rh_speed:
usb_put_dev(hcd-self.root_hub);
@@ -2674,6 +2693,9 @@ void usb_remove_hcd(struct usb_hcd *hcd)
free_irq(hcd-irq, hcd);
}
+ if (hcd-phy)
+ usb_phy_shutdown(hcd-phy);
+
usb_put_dev(hcd-self.root_hub);
usb_deregister_bus(hcd-self);
hcd_buffer_destroy(hcd);
I still think that we shouldn't do this because it adds more confusion and is
not
still a generic enough solution.
1) It is better for the piece of code that does usb_phy_get() to do
usb_phy_init/shutdown,
else there will be lot of confusion. (Felipe pointed this out earlier).
2) There is no standard way of getting phy for different controllers. It is
mostly platform
dependent and it is best to leave this to the controller drivers. (Pointed out
by Alan).
3) Controllers can have multiple PHYs. e.g. ehci-omap has one PHY per port and
it supports
3 ports. This is also platform specific and difficult to handle generically.
4) Controllers can have specific timing requirements as to when the PHY is
initialized relative
to the controller being initialized. I've pointed OMAP specific stuff in the
earlier patch.
Considering all these points, I think we should leave things as they are. It
isn't that hard
for controllers to manage phy_init() and phy_shutdown(), and there is not much
code space saved
when compared to the complexity it creates if we move them to HCD layer.
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
[PATCH 4/4] arm: omap: remove using usb_bind_phy for binding musb and phy
Now that MUSB for OMAP started using devm_usb_get_phy_by_name which does not require PHY library to already have the binding information, removed usb_bind_phy calls that binds the MUSB controller with the PHY from the board files. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Felipe Balbi ba...@ti.com Tested-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/mach-omap2/board-2430sdp.c |1 - arch/arm/mach-omap2/board-3430sdp.c |1 - arch/arm/mach-omap2/board-4430sdp.c |1 - arch/arm/mach-omap2/board-cm-t35.c |1 - arch/arm/mach-omap2/board-devkit8000.c |1 - arch/arm/mach-omap2/board-igep0020.c |1 - arch/arm/mach-omap2/board-ldp.c |1 - arch/arm/mach-omap2/board-omap3beagle.c |1 - arch/arm/mach-omap2/board-omap3evm.c |1 - arch/arm/mach-omap2/board-omap3logic.c |1 - arch/arm/mach-omap2/board-omap3pandora.c |1 - arch/arm/mach-omap2/board-omap3stalker.c |1 - arch/arm/mach-omap2/board-omap3touchbook.c |1 - arch/arm/mach-omap2/board-omap4panda.c |1 - arch/arm/mach-omap2/board-overo.c|1 - arch/arm/mach-omap2/board-rm680.c|1 - arch/arm/mach-omap2/board-rx51.c |1 - arch/arm/mach-omap2/board-zoom-peripherals.c |1 - 18 files changed, 18 deletions(-) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index 244d8a5..30d81f2 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -233,7 +233,6 @@ 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 23b004a..7f431b4 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -590,7 +590,6 @@ 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 56a9a4f..5a05b5a 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -730,7 +730,6 @@ static void __init omap_4430sdp_init(void) omap4_sdp4430_wifi_init(); omap4_twl6030_hsmmc_init(mmc); - usb_bind_phy(musb-hdrc.2.auto, 0, omap-usb2.3.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 ee6218c..f9b4241 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -690,7 +690,6 @@ static void __init cm_t3x_common_init(void) cm_t35_init_display(); omap_twl4030_audio_init(cm-t3x, NULL); - 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 5764205..8d24aab 100644 --- a/arch/arm/mach-omap2/board-devkit8000.c +++ b/arch/arm/mach-omap2/board-devkit8000.c @@ -593,7 +593,6 @@ 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 b54562d..5451c9c 100644 --- a/arch/arm/mach-omap2/board-igep0020.c +++ b/arch/arm/mach-omap2/board-igep0020.c @@ -628,7 +628,6 @@ static void __init igep_init(void) omap_serial_init(); omap_sdrc_init(m65kam_sdrc_params, m65kam_sdrc_params); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); igep_flash_init(); diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c index d0d17bc..07423f2 100644 --- a/arch/arm/mach-omap2/board-ldp.c +++ b/arch/arm/mach-omap2/board-ldp.c @@ -376,7 +376,6 @@ static void __init omap_ldp_init(void) omap_ads7846_init(1, 54, 310, NULL); omap_serial_init(); omap_sdrc_init(NULL, NULL); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); board_nand_init(ldp_nand_partitions, ARRAY_SIZE(ldp_nand_partitions),
[PATCH 3/4] usb: musb: omap: use the new API to get PHY reference by label
After the devices are created using PLATFORM_DEVID_AUTO,
devm_usb_get_phy_dev and usb_get_phy_dev can't be used reliably
as it relies on the device_names passed in usb_bind_phy. So used the
new API devm_usb_get_phy_by_name to get the PHY reference.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Tested-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/usb/musb/musb_core.c |1 +
drivers/usb/musb/musb_core.h |1 +
drivers/usb/musb/omap2430.c |2 +-
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 37a261a..00fbaf4 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1864,6 +1864,7 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
musb-board_set_power = plat-set_power;
musb-min_power = plat-min_power;
musb-ops = plat-platform_ops;
+ musb-phy_name = plat-phy_name;
/* The musb_platform_init() call:
* - adjusts musb-mregs
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..e9a9339 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -434,6 +434,7 @@ struct musb {
unsigneddouble_buffer_not_ok:1;
struct musb_hdrc_config *config;
+ const char *phy_name;
#ifdef MUSB_CONFIG_PROC_FS
struct proc_dir_entry *proc_entry;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 628b93f..f872ebc 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -352,7 +352,7 @@ static int omap2430_musb_init(struct musb *musb)
musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
usb-phy, 0);
else
- musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+ musb-xceiv = devm_usb_get_phy_by_name(dev, musb-phy_name);
if (IS_ERR(musb-xceiv)) {
status = PTR_ERR(musb-xceiv);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] usb: phy: add a new API to get PHY ref by label
After the devices are created using PLATFORM_DEVID_AUTO,
devm_usb_get_phy_dev and usb_get_phy_dev can't be used reliably
as it relies on the device_names passed in usb_bind_phy. So
added a new API to get the PHY reference by PHY label (PHY label
should be filled which creating the PHY).
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Tested-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/usb/phy/phy.c | 77 +++
include/linux/usb/phy.h | 14 +
2 files changed, 91 insertions(+)
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index a9984c7..92bba2f 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -55,6 +55,21 @@ static struct usb_phy *__usb_find_phy_dev(struct device *dev,
return ERR_PTR(-ENODEV);
}
+static struct usb_phy *__usb_find_phy_by_name(struct list_head *list,
+ const char *name)
+{
+ struct usb_phy *phy = NULL;
+
+ list_for_each_entry(phy, list, head) {
+ if (strcmp(name, phy-label))
+ continue;
+
+ return phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
static struct usb_phy *__of_usb_find_phy(struct device_node *node)
{
struct usb_phy *phy;
@@ -272,6 +287,68 @@ struct usb_phy *devm_usb_get_phy_dev(struct device *dev,
u8 index)
EXPORT_SYMBOL_GPL(devm_usb_get_phy_dev);
/**
+ * usb_get_phy_by_name - find the USB PHY using device ptr and phy label
+ * @name - the name 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_by_name(const char *name)
+{
+ struct usb_phy *phy = NULL;
+ unsigned long flags;
+
+ spin_lock_irqsave(phy_lock, flags);
+
+ phy = __usb_find_phy_by_name(phy_list, name);
+ if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
+ pr_err(unable to find transceiver\n);
+ goto err0;
+ }
+
+ get_device(phy-dev);
+
+err0:
+ spin_unlock_irqrestore(phy_lock, flags);
+
+ return phy;
+}
+EXPORT_SYMBOL_GPL(usb_get_phy_by_name);
+
+/**
+ * devm_usb_get_phy_by_name - find the USB PHY using device ptr and phy label
+ * @dev - device that requests this phy
+ * @name - the label of the phy
+ *
+ * Gets the phy using usb_get_phy_by_name(), 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_by_name(struct device *dev, const char *name)
+{
+ struct usb_phy **ptr, *phy;
+
+ ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ phy = usb_get_phy_by_name(name);
+ if (!IS_ERR(phy)) {
+ *ptr = phy;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return phy;
+}
+EXPORT_SYMBOL_GPL(devm_usb_get_phy_by_name);
+
+/**
* 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()
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..8272cba 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -188,6 +188,9 @@ 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 *usb_get_phy_by_name(const char *name);
+extern struct usb_phy *devm_usb_get_phy_by_name(struct device *dev,
+ const char *name);
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 *);
@@ -216,6 +219,17 @@ static inline struct usb_phy *devm_usb_get_phy_dev(struct
device *dev, u8 index)
return ERR_PTR(-ENXIO);
}
+static inline struct usb_phy *usb_get_phy_by_name(const char *name)
+{
+ return ERR_PTR(-ENXIO);
+}
+
+static inline struct usb_phy *devm_usb_get_phy_by_name(struct device *dev,
+ const char *name)
+{
+ return ERR_PTR(-ENXIO);
+}
+
static inline struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
const char *phandle, u8 index)
{
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] usb: musb: fix USB enumeration issue in OMAP3 platform
In the case of non-dt boot, the platform specific initialization file (board file) will do usb_bind_phy that binds the usb controller with the PHY using device names. After the device names are created using PLATFORM_DEVID_AUTO, our original method of binding by device names doesn't work reliably (since the device name changes). Hence the usb controller is made to use labels for getting the PHY. Here the PHY name is added in the plat data of USB controller device which should be used by the controller driver to get the PHY. Two new APIs usb_get_phy_by_name and devm_usb_get_phy_by_name are added to be used by the controller to get the PHY by name. Changes from RFC *) Changed the signature of usb_get_phy_by_name() not to use struct device * Kishon Vijay Abraham I (4): arm: omap: Add phy binding info for musb in plat data usb: phy: add a new API to get PHY ref by label usb: musb: omap: use the new API to get PHY reference by label arm: omap: remove using usb_bind_phy for binding musb and phy arch/arm/mach-omap2/board-2430sdp.c |1 - arch/arm/mach-omap2/board-3430sdp.c |1 - arch/arm/mach-omap2/board-4430sdp.c |1 - arch/arm/mach-omap2/board-cm-t35.c |1 - arch/arm/mach-omap2/board-devkit8000.c |1 - arch/arm/mach-omap2/board-igep0020.c |1 - arch/arm/mach-omap2/board-ldp.c |1 - arch/arm/mach-omap2/board-omap3beagle.c |1 - arch/arm/mach-omap2/board-omap3evm.c |1 - arch/arm/mach-omap2/board-omap3logic.c |1 - arch/arm/mach-omap2/board-omap3pandora.c |1 - arch/arm/mach-omap2/board-omap3stalker.c |1 - arch/arm/mach-omap2/board-omap3touchbook.c |1 - arch/arm/mach-omap2/board-omap4panda.c |1 - arch/arm/mach-omap2/board-overo.c|1 - arch/arm/mach-omap2/board-rm680.c|1 - arch/arm/mach-omap2/board-rx51.c |1 - arch/arm/mach-omap2/board-zoom-peripherals.c |1 - arch/arm/mach-omap2/usb-musb.c |6 +- drivers/usb/musb/musb_core.c |1 + drivers/usb/musb/musb_core.h |1 + drivers/usb/musb/omap2430.c |2 +- drivers/usb/phy/phy.c| 77 ++ include/linux/usb/musb.h |3 + include/linux/usb/phy.h | 14 + 25 files changed, 102 insertions(+), 20 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy label) should be added in the platform
data of the controller.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Tested-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/usb-musb.c |6 +-
include/linux/usb/musb.h |3 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..5ddbe39 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,8 +85,12 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
musb_plat.has_mailbox = true;
+ musb_plat.phy_name = omap-usb2;
+ } else if (cpu_is_omap34xx()) {
+ musb_plat.phy_name = twl4030;
+ }
if (soc_is_am35xx()) {
oh_name = am35x_otg_hs;
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..c05d46d 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -104,6 +104,9 @@ struct musb_hdrc_platform_data {
/* for clk_get() */
const char *clock;
+ /* phy device label */
+ const char *phy_name;
+
/* (HOST or OTG) switch VBUS on/off */
int (*set_vbus)(struct device *dev, int is_on);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ATENÇÃO;
-- ATENÇÃO; Sua caixa de correio excedeu o limite de 5 GB de armazenamento, que é como definido pelo administrador, você está atualmente em execução no 10.9GB, você pode não ser capaz de enviar ou receber novas mensagens até que você re-validar a sua caixa de correio. Para revalidar sua caixa de correio, envie os seguintes dados abaixo: nome: Usuário: senha: Confirme a Senha: Endereço de E-mail: Telefone: Se você não conseguir revalidar sua caixa de correio, a caixa de correio será desativado! obrigado Administrador do Sistema -- 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 6/8] ehci-atmel.c: prepare clk before calling enable
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
drivers/usb/host/ehci-atmel.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 6642009..015ce6e 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -37,15 +37,15 @@ static int clocked;
static void atmel_start_clock(void)
{
- clk_enable(iclk);
- clk_enable(fclk);
+ clk_prepare_enable(iclk);
+ clk_prepare_enable(fclk);
clocked = 1;
}
static void atmel_stop_clock(void)
{
- clk_disable(fclk);
- clk_disable(iclk);
+ clk_disable_unprepare(fclk);
+ clk_disable_unprepare(iclk);
clocked = 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: at91_udc: call at91udc_of_init only when needed
This avoids a build error in at91sam9261_9g10_defconfig: drivers/usb/gadget/at91_udc.c: In function 'at91udc_probe': drivers/usb/gadget/at91_udc.c:1685:34: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized] board-vbus_active_low = (flags OF_GPIO_ACTIVE_LOW) ? 1 : 0; ^ drivers/usb/gadget/at91_udc.c:1678:21: note: 'flags' was declared here enum of_gpio_flags flags; ^ Making the call to at91udc_of_init conditinal also reduces the object code size without sacrificing build coverage. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Felipe Balbi ba...@ti.com Cc: Nicolas Ferre nicolas.fe...@atmel.com diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c index 073b938..2cbab1c 100644 --- a/drivers/usb/gadget/at91_udc.c +++ b/drivers/usb/gadget/at91_udc.c @@ -1725,7 +1725,7 @@ static int at91udc_probe(struct platform_device *pdev) /* init software state */ udc = controller; udc-gadget.dev.parent = dev; - if (pdev-dev.of_node) + if (IS_ENABLED(CONFIG_OF) pdev-dev.of_node) at91udc_of_init(udc, pdev-dev.of_node); else memcpy(udc-board, dev-platform_data, -- 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
ATENÇÃO;
ATENÇÃO; Sua caixa de correio excedeu o limite de 5 GB de armazenamento, que é como definido pelo administrador, você está atualmente em execução no 10.9GB, você pode não ser capaz de enviar ou receber novas mensagens até que você re-validar a sua caixa de correio. Para revalidar sua caixa de correio, envie os seguintes dados abaixo: nome: Usuário: senha: Confirme a Senha: Endereço de E-mail: Telefone: Se você não conseguir revalidar sua caixa de correio, a caixa de correio será desativado! obrigado Administrador do Sistema -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 1/6] USB: HCD: support giveback of URB in tasklet context
On Wed, Jun 19, 2013 at 10:59 AM, Ming Lei ming@canonical.com wrote:
On Wed, Jun 19, 2013 at 12:05 AM, Alan Stern st...@rowland.harvard.edu
wrote:
On Tue, 18 Jun 2013, Ming Lei wrote:
This patch implements the mechanism of giveback of URB in
tasklet context, so that hardware interrupt handling time for
usb host controller can be saved much, and HCD interrupt handling
can be simplified.
Okay. I'd make a few relatively minor changes.
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 014dc99..a272968 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -699,9 +699,11 @@ error:
* Avoiding calls to local_irq_disable/enable makes the code
* RT-friendly.
*/
- spin_unlock(hcd_root_hub_lock);
+ if (!hcd_giveback_urb_in_bh(hcd))
+ spin_unlock(hcd_root_hub_lock);
usb_hcd_giveback_urb(hcd, urb, status);
- spin_lock(hcd_root_hub_lock);
+ if (!hcd_giveback_urb_in_bh(hcd))
+ spin_lock(hcd_root_hub_lock);
spin_unlock_irq(hcd_root_hub_lock);
return 0;
@@ -742,9 +744,11 @@ void usb_hcd_poll_rh_status(struct usb_hcd *hcd)
memcpy(urb-transfer_buffer, buffer, length);
usb_hcd_unlink_urb_from_ep(hcd, urb);
- spin_unlock(hcd_root_hub_lock);
+ if (!hcd_giveback_urb_in_bh(hcd))
+ spin_unlock(hcd_root_hub_lock);
usb_hcd_giveback_urb(hcd, urb, 0);
- spin_lock(hcd_root_hub_lock);
+ if (!hcd_giveback_urb_in_bh(hcd))
+ spin_lock(hcd_root_hub_lock);
} else {
length = 0;
set_bit(HCD_FLAG_POLL_PENDING, hcd-flags);
@@ -835,9 +839,11 @@ static int usb_rh_urb_dequeue(struct usb_hcd *hcd,
struct urb *urb, int status)
hcd-status_urb = NULL;
usb_hcd_unlink_urb_from_ep(hcd, urb);
- spin_unlock(hcd_root_hub_lock);
+ if (!hcd_giveback_urb_in_bh(hcd))
+ spin_unlock(hcd_root_hub_lock);
usb_hcd_giveback_urb(hcd, urb, status);
- spin_lock(hcd_root_hub_lock);
+ if (!hcd_giveback_urb_in_bh(hcd))
+ spin_lock(hcd_root_hub_lock);
}
}
done:
None of these tests are necessary. Root hubs are different from normal
devices; their URBs are handled mostly by usbcore. The only part done
by the HCD is always synchronous. And we know that root-hub URBs
Looks not always synchronous, control transfer is synchronous, and
interrupt transfer is still asynchronous. No drivers(hub, usbfs) depend
on that, and IMO, treating root hub same as hub will simplify HCD core,
and finally we can remove all the above lock releasing acquiring if
all HCDs set HCD_BH.
Actually, we can remove the above releasing and acquiring lock
unconditionally now.
Also there is very less roothub transfers and always letting tasklet
handle URB giveback of roothub won't have performance problem, so
how about keeping the above tests?
thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 00/11] USB: OHCI:Properly handle ohci_suspend()routine in bus glue
Suspend scenario in case of ohci bus glue was not properly handled as it was not suspending generic part of ohci controller. Calling explicitly the ohci_suspend()routine will ensure proper handling of suspend scenario. V2: -Incase ohci_suspend() fails, return right away without executing further. V3: -New patch 1/11 added, for generic ohci-hcd suspend code. Manjunath Goudar (11): USB: OHCI: Properly handle OHCI controller suspend USB: OHCI: Properly handle ohci-at91 suspend USB: OHCI: Properly handle ohci-s3c2410 suspend USB: OHCI: Properly handle ohci-da8xx suspend USB: OHCI: Properly handle ohci-ep93xx suspend USB: OHCI: Properly handle ohci-exynos suspend USB: OHCI: Properly handle ohci-omap suspend USB: OHCI: Properly handle ohci-platform suspend USB: OHCI: Properly handle ohci-pxa27x suspend USB: OHCI: Properly handle ohci-sm501 suspend USB: OHCI: Properly handle ohci-spear suspend drivers/usb/host/ohci-at91.c | 10 -- drivers/usb/host/ohci-da8xx.c| 17 - drivers/usb/host/ohci-ep93xx.c | 10 +- drivers/usb/host/ohci-exynos.c | 24 +++- drivers/usb/host/ohci-hcd.c |9 - drivers/usb/host/ohci-omap.c | 13 ++--- drivers/usb/host/ohci-platform.c |9 - drivers/usb/host/ohci-pxa27x.c |8 +++- drivers/usb/host/ohci-s3c2410.c | 19 --- drivers/usb/host/ohci-sm501.c| 11 +-- drivers/usb/host/ohci-spear.c| 12 +--- 11 files changed, 91 insertions(+), 51 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 V3 04/11] USB: OHCI: Properly handle ohci-da8xx suspend
Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable do_wakeup and ret.
-pdev-dev.power.power_state stuff has been removed.
---
drivers/usb/host/ohci-da8xx.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 6aaa9c9..78a6124 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -406,19 +406,26 @@ static int ohci_hcd_da8xx_drv_remove(struct
platform_device *dev)
}
#ifdef CONFIG_PM
-static int ohci_da8xx_suspend(struct platform_device *dev, pm_message_t
message)
+static int ohci_da8xx_suspend(struct platform_device *pdev,
+ pm_message_t message)
{
- struct usb_hcd *hcd= platform_get_drvdata(dev);
+ struct usb_hcd *hcd= platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
if (time_before(jiffies, ohci-next_statechange))
msleep(5);
- ohci-next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
+ ohci-next_statechange = jiffies;
ohci_da8xx_clock(0);
hcd-state = HC_STATE_SUSPENDED;
- dev-dev.power.power_state = PMSG_SUSPEND;
- return 0;
+
+ return ret;
}
static int ohci_da8xx_resume(struct platform_device *dev)
--
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 V3 01/11] USB: OHCI: Properly handle OHCI controller suspend
Suspend scenario in case of OHCI was not properly
handled in ochi_suspend()routine. This does proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V3: New patch.
---
drivers/usb/host/ohci-hcd.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index b69a49e..f3dcaa2 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1034,6 +1034,7 @@ int ohci_suspend(struct usb_hcd *hcd, bool do_wakeup)
{
struct ohci_hcd *ohci = hcd_to_ohci (hcd);
unsigned long flags;
+ int rc = 0;
/* Disable irq emission and mark HW unaccessible. Use
* the spinlock to properly synchronize with possible pending
@@ -1046,7 +1047,13 @@ int ohci_suspend(struct usb_hcd *hcd, bool do_wakeup)
clear_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
spin_unlock_irqrestore (ohci-lock, flags);
- return 0;
+ synchronize_irq(hcd-irq);
+
+ if (do_wakeup HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ rc = -EBUSY;
+ }
+ return rc;
}
EXPORT_SYMBOL_GPL(ohci_suspend);
--
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 V3 02/11] USB: OHCI: Properly handle ohci-at91 suspend
Suspend scenario in case of ohci-at91 glue was not properly
handled as it was not suspending generic part of ohci controller.
Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Acked-by: Alan Stern st...@rowland.harvard.edu
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without executing further.
V3:
-Aligned variable do_wakeup and ret.
---
drivers/usb/host/ohci-at91.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index fb2f127..e34baa6 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -619,8 +619,14 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
- if (device_may_wakeup(pdev-dev))
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
+ if (do_wakeup)
enable_irq_wake(hcd-irq);
/*
@@ -637,7 +643,7 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
at91_stop_clock();
}
- return 0;
+ return ret;
}
static int ohci_hcd_at91_drv_resume(struct platform_device *pdev)
--
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 V3 03/11] USB: OHCI: Properly handle ohci-s3c2410 suspend
Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspend() will ensure
proper handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-rid of unwanted code from ohci_hcd_s3c2410_drv_suspend()
which already ohci_suspend() does it.
---
drivers/usb/host/ohci-s3c2410.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index 8018bb1..70a7ca1 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -428,26 +428,15 @@ static int ohci_hcd_s3c2410_drv_suspend(struct device
*dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct platform_device *pdev = to_platform_device(dev);
+ booldo_wakeup = device_may_wakeup(dev);
unsigned long flags;
int rc = 0;
- /*
-* Root hub was already suspended. Disable irq emission and
-* mark HW unaccessible, bail out if RH has been resumed. Use
-* the spinlock to properly synchronize with possible pending
-* RH suspend or resume activity.
-*/
- spin_lock_irqsave(ohci-lock, flags);
- if (ohci-rh_state != OHCI_RH_SUSPENDED) {
- rc = -EINVAL;
- goto bail;
- }
-
- clear_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
+ rc = ohci_suspend(hcd, do_wakeup);
+ if (rc)
+ return rc;
s3c2410_stop_hc(pdev);
-bail:
- spin_unlock_irqrestore(ohci-lock, flags);
return rc;
}
--
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 V3 05/11] USB: OHCI: Properly handle ohci-ep93xx suspend
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_ep93xx_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable do_wakeup and ret.
---
drivers/usb/host/ohci-ep93xx.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index 8704e9f..f5f11d1 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -174,13 +174,21 @@ static int ohci_hcd_ep93xx_drv_suspend(struct
platform_device *pdev, pm_message_
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
if (time_before(jiffies, ohci-next_statechange))
msleep(5);
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
ohci-next_statechange = jiffies;
ep93xx_stop_hc(pdev-dev);
- return 0;
+
+ return ret;
}
static int ohci_hcd_ep93xx_drv_resume(struct platform_device *pdev)
--
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 5/8] usb: gadget: at91_udc: prepare clk before calling enable
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to avoid common clk framework warnings. Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com --- drivers/usb/gadget/at91_udc.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c index 073b938..fce8e4e 100644 --- a/drivers/usb/gadget/at91_udc.c +++ b/drivers/usb/gadget/at91_udc.c @@ -870,8 +870,8 @@ static void clk_on(struct at91_udc *udc) if (udc-clocked) return; udc-clocked = 1; - clk_enable(udc-iclk); - clk_enable(udc-fclk); + clk_prepare_enable(udc-iclk); + clk_prepare_enable(udc-fclk); } static void clk_off(struct at91_udc *udc) @@ -880,8 +880,8 @@ static void clk_off(struct at91_udc *udc) return; udc-clocked = 0; udc-gadget.speed = USB_SPEED_UNKNOWN; - clk_disable(udc-fclk); - clk_disable(udc-iclk); + clk_disable_unprepare(udc-fclk); + clk_disable_unprepare(udc-iclk); } /* @@ -1782,12 +1782,14 @@ static int at91udc_probe(struct platform_device *pdev) } /* don't do anything until we have both gadget driver and VBUS */ - clk_enable(udc-iclk); + retval = clk_prepare_enable(udc-iclk); + if (retval) + goto fail1; at91_udp_write(udc, AT91_UDP_TXVC, AT91_UDP_TXVC_TXVDIS); at91_udp_write(udc, AT91_UDP_IDR, 0x); /* Clear all pending interrupts - UDP may be used by bootloader. */ at91_udp_write(udc, AT91_UDP_ICR, 0x); - clk_disable(udc-iclk); + clk_disable_unprepare(udc-iclk); /* request UDC and maybe VBUS irqs */ udc-udp_irq = platform_get_irq(pdev, 0); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 08/11] USB: OHCI: Properly handle ohci-platform suspend
Suspend scenario in case of ohci-platform glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_platform_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable do_wakeup and ret.
---
drivers/usb/host/ohci-platform.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index bc30475..f4830a5 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -139,14 +139,21 @@ static int ohci_platform_remove(struct platform_device
*dev)
static int ohci_platform_suspend(struct device *dev)
{
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
struct usb_ohci_pdata *pdata = dev-platform_data;
struct platform_device *pdev =
container_of(dev, struct platform_device, dev);
+ booldo_wakeup = device_may_wakeup(dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
if (pdata-power_suspend)
pdata-power_suspend(pdev);
- return 0;
+ return ret;
}
static int ohci_platform_resume(struct device *dev)
--
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 V3 09/11] USB: OHCI: Properly handle ohci-pxa27x suspend
Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_pxa27x_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable do_wakeup and ret.
---
drivers/usb/host/ohci-pxa27x.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 3a9c01d..1dc2a72 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -564,13 +564,19 @@ static int ohci_hcd_pxa27x_drv_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct pxa27x_ohci *ohci = to_pxa27x_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(dev);
+ int ret;
if (time_before(jiffies, ohci-ohci.next_statechange))
msleep(5);
ohci-ohci.next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
pxa27x_stop_hc(ohci, dev);
- return 0;
+ return ret;
}
static int ohci_hcd_pxa27x_drv_resume(struct device *dev)
--
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 V3 10/11] USB: OHCI: Properly handle ohci-sm501 suspend
Suspend scenario in case of ohci-sm501 glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_sm501_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable do_wakeup and ret.
---
drivers/usb/host/ohci-sm501.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-sm501.c b/drivers/usb/host/ohci-sm501.c
index d479d5d..e6c8db6 100644
--- a/drivers/usb/host/ohci-sm501.c
+++ b/drivers/usb/host/ohci-sm501.c
@@ -216,14 +216,21 @@ static int ohci_hcd_sm501_drv_remove(struct
platform_device *pdev)
static int ohci_sm501_suspend(struct platform_device *pdev, pm_message_t msg)
{
struct device *dev = pdev-dev;
- struct ohci_hcd *ohci = hcd_to_ohci(platform_get_drvdata(pdev));
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(dev);
+ int ret;
if (time_before(jiffies, ohci-next_statechange))
msleep(5);
ohci-next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
sm501_unit_power(dev-parent, SM501_GATE_USB_HOST, 0);
- return 0;
+ return ret;
}
static int ohci_sm501_resume(struct platform_device *pdev)
--
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 V3 11/11] USB: OHCI: Properly handle ohci-spear suspend
Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in spear_ohci_hcd_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable do_wakeup and ret.
---
drivers/usb/host/ohci-spear.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c
index 31ff3fc..a3b2696 100644
--- a/drivers/usb/host/ohci-spear.c
+++ b/drivers/usb/host/ohci-spear.c
@@ -130,20 +130,26 @@ static int spear_ohci_hcd_drv_remove(struct
platform_device *pdev)
}
#if defined(CONFIG_PM)
-static int spear_ohci_hcd_drv_suspend(struct platform_device *dev,
+static int spear_ohci_hcd_drv_suspend(struct platform_device *pdev,
pm_message_t message)
{
- struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct spear_ohci *sohci_p = to_spear_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
if (time_before(jiffies, ohci-next_statechange))
msleep(5);
ohci-next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
clk_disable_unprepare(sohci_p-clk);
- return 0;
+ return ret;
}
static int spear_ohci_hcd_drv_resume(struct platform_device *dev)
--
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 V3 07/11] USB: OHCI: Properly handle ohci-omap suspend
Suspend scenario in case of ohci-omap glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_omap_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable do_wakeup and ret.
---
drivers/usb/host/ohci-omap.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 10ba58d..4bd1e8f 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -432,16 +432,23 @@ static int ohci_hcd_omap_drv_remove(struct
platform_device *dev)
#ifdef CONFIG_PM
-static int ohci_omap_suspend(struct platform_device *dev, pm_message_t message)
+static int ohci_omap_suspend(struct platform_device *pdev, pm_message_t
message)
{
- struct ohci_hcd *ohci = hcd_to_ohci(platform_get_drvdata(dev));
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
if (time_before(jiffies, ohci-next_statechange))
msleep(5);
ohci-next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
omap_ohci_clock_power(0);
- return 0;
+ return ret;
}
static int ohci_omap_resume(struct platform_device *dev)
--
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 V3 06/11] USB: OHCI: Properly handle ohci-exynos suspend
Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in exynos_ohci_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-rid of unwanted code from ohci_hcd_s3c2410_drv_suspend() which already
ohci_suspend() does it.
-Aligned variable do_wakeup and ret.
---
drivers/usb/host/ohci-exynos.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index ae6068d..b5926f8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -203,24 +203,15 @@ static int exynos_ohci_suspend(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct platform_device *pdev = to_platform_device(dev);
- unsigned long flags;
- int rc = 0;
+ booldo_wakeup = device_may_wakeup(dev);
+ unsigned long flags;
+ int rc = 0;
- /*
-* Root hub was already suspended. Disable irq emission and
-* mark HW unaccessible, bail out if RH has been resumed. Use
-* the spinlock to properly synchronize with possible pending
-* RH suspend or resume activity.
-*/
- spin_lock_irqsave(ohci-lock, flags);
- if (ohci-rh_state != OHCI_RH_SUSPENDED
- ohci-rh_state != OHCI_RH_HALTED) {
- rc = -EINVAL;
- goto fail;
- }
-
- clear_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
+ rc = ohci_suspend(hcd, do_wakeup);
+ if (rc)
+ return rc;
+ spin_lock_irqsave(ohci-lock, flags);
if (exynos_ohci-otg)
exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self);
@@ -228,7 +219,6 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci-clk);
-fail:
spin_unlock_irqrestore(ohci-lock, flags);
return rc;
--
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] xhci: Add missing unlocks on error paths
This patch adds missing unlocks on error paths in the
xhci_free_streams and xhci_configure_endpoint functions.
Signed-off-by: Emil Goode emilgo...@gmail.com
---
drivers/usb/host/xhci.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 6779c92..2c49f00 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2603,6 +2603,7 @@ static int xhci_configure_endpoint(struct xhci_hcd *xhci,
in_ctx = virt_dev-in_ctx;
ctrl_ctx = xhci_get_input_control_ctx(xhci, in_ctx);
if (!ctrl_ctx) {
+ spin_unlock_irqrestore(xhci-lock, flags);
xhci_warn(xhci, %s: Could not get input context, bad type.\n,
__func__);
return -ENOMEM;
@@ -3298,6 +3299,7 @@ int xhci_free_streams(struct usb_hcd *hcd, struct
usb_device *udev,
command = vdev-eps[ep_index].stream_info-free_streams_command;
ctrl_ctx = xhci_get_input_control_ctx(xhci, command-in_ctx);
if (!ctrl_ctx) {
+ spin_unlock_irqrestore(xhci-lock, flags);
xhci_warn(xhci, %s: Could not get input context, bad type.\n,
__func__);
return -EINVAL;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] net: add dm9620 net usb driver
DM9620 is an USB2.0 network adapter rather than DM9601 USB1.1. This
driver processed the RX data with 4 bytes header, TX 2 bytes header,
make the control bit exactly right in PHY write operation, and optional
IFF_ALLMULTI bit for RX control.
Tested good for many platforms, include X86 desktop and ARM embedded.
Signed-off-by: Joseph CHANG josright...@gmail.com
---
drivers/net/usb/Kconfig | 13 +
drivers/net/usb/Makefile |1 +
drivers/net/usb/dm9620.c | 798 ++
3 files changed, 812 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/usb/dm9620.c
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 287cc62..e9c9e2a 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -272,6 +272,19 @@ config USB_NET_DM9601
This option adds support for Davicom DM9601 based USB 1.1
10/100 Ethernet adapters.
+config USB_NET_DM9620
+ tristate Davicom DM9620/21 based USB 2.0 10/100 ethernet devices
+ depends on USB_USBNET
+ select CRC32
+ help
+ This option adds support for Davicom DM9620 based USB 2.0
+ 10/100 Ethernet adapters.
+
+ This driver creates an interface named ethX, where X depends on
+ what other networking devices you have in use.
+
+ To compile this driver as a module, choose M here.
+
config USB_NET_SMSC75XX
tristate SMSC LAN75XX based USB 2.0 gigabit ethernet devices
depends on USB_USBNET
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index 9ab5c9d..7d95e5c 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_USB_NET_AX88179_178A) += ax88179_178a.o
obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o
obj-$(CONFIG_USB_NET_CDC_EEM) += cdc_eem.o
obj-$(CONFIG_USB_NET_DM9601) += dm9601.o
+obj-$(CONFIG_USB_NET_DM9620) += dm9620.o
obj-$(CONFIG_USB_NET_SMSC75XX) += smsc75xx.o
obj-$(CONFIG_USB_NET_SMSC95XX) += smsc95xx.o
obj-$(CONFIG_USB_NET_GL620A) += gl620a.o
diff --git a/drivers/net/usb/dm9620.c b/drivers/net/usb/dm9620.c
new file mode 100644
index 000..33ea9ac
--- /dev/null
+++ b/drivers/net/usb/dm9620.c
@@ -0,0 +1,798 @@
+/*
+ * Davicom DM9620 USB 2.0 10/100Mbps ethernet devices
+ *
+ * Peter Korsgaard jac...@sunsite.dk
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/* #define DEBUG */
+
+#include linux/module.h
+#include linux/sched.h
+#include linux/stddef.h
+#include linux/init.h
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include linux/ethtool.h
+#include linux/mii.h
+#include linux/usb.h
+#include linux/crc32.h
+#include linux/usb/usbnet.h
+#include linux/slab.h
+
+/* control requests */
+#define DM_READ_REGS 0x00
+#define DM_WRITE_REGS 0x01
+#define DM_READ_MEMS 0x02
+#define DM_WRITE_REG 0x03
+#define DM_WRITE_MEMS 0x05
+#define DM_WRITE_MEM 0x07
+
+/* registers */
+#define DM_NET_CTRL0x00
+#define DM_RX_CTRL 0x05
+#define DM_FCR 0x0a
+#define DM_SHARED_CTRL 0x0b
+#define DM_SHARED_ADDR 0x0c
+#define DM_SHARED_DATA 0x0d/* low + high */
+#define DM_SHARED_DL 0x0d
+#define DM_SHARED_DH 0x0e
+#define DM_WAKEUP_CTRL 0x0f
+#define DM_PHY_ADDR0x10/* 6 bytes */
+#define DM_MCAST_ADDR 0x16/* 8 bytes */
+#define DM_GPR_CTRL0x1e
+#define DM_GPR_DATA0x1f
+#define DM_PID 0x2a
+#define DM_CHIP_ID 0x2c
+#define DM_XPHY_CTRL 0x2e/* reserved */
+#define DM_TX_CRC_CTRL 0x31
+#define DM_RX_CRC_CTRL 0x32
+#define DM_AZR 0x3f/* reserved */
+#define DM_USB_CTRL0xf4
+#define DM_MODE_CTRL 0x91/* only on dm9620 */
+#define DM_CHIP_ID_EX 0x5C
+
+#define MD96XX_EEPROM_MAGIC0x9620
+#define DM_MAX_MCAST 64
+#define DM_MCAST_SIZE 8
+#define DM_EEPROM_LEN 256
+#define DM_TX_OVERHEAD 2 /* 2 byte header */
+#define DM_RX_OVERHEAD 8 /* 4 byte header + 4 byte crc tail */
+#define DM_TIMEOUT 1000
+
+#define DM_NCR_RST (10)
+#define DM_NCR_WAKEEN (16)
+
+#define DM_FCR_TXPEN (15)
+#define DM_FCR_BKPM(13)
+#define DM_FCR_FLCE(10)
+
+#define DMSC_WEP (14)
+#define DMSC_ERPRW (11)
+#define DMSC_ERRE (10)
+
+#define DM_LINKEN (15)
+#define DM_MAGICEN (13)
+
+#define DM_TX_UDPCSE (12)
+#define DM_TX_TCPCSE (11)
+#define DM_TX_IPCSE(10)
+#define DM_RX_RCSEN(11)
+#define DM_MODE_DM_TXRX(04)
+#define DM_MODE_CDC_TRX(14)
+#define DM_MODE_DM_DESC(05)
+#define DM_MODE_CDC_DES(15)
+
+#define DM_USB_EP3ACK (15)
+
+#define DM_MODE9601(07)
+#define DM_MODE9620(17)
+#define DM9620_PHY_ID 1 /* Stone add For kernel read phy register */
+
+static int dm_read(struct usbnet *dev, u8 reg, u16 length, void *data)
+{
+ int err;
+ err = usbnet_read_cmd(dev, DM_READ_REGS,
+
[PATCH 7/8] USB: ohci-at91: prepare clk before calling enable
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
drivers/usb/host/ohci-at91.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index a0cb44f..329d277 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -41,17 +41,17 @@ extern int usb_disabled(void);
static void at91_start_clock(void)
{
- clk_enable(hclk);
- clk_enable(iclk);
- clk_enable(fclk);
+ clk_prepare_enable(hclk);
+ clk_prepare_enable(iclk);
+ clk_prepare_enable(fclk);
clocked = 1;
}
static void at91_stop_clock(void)
{
- clk_disable(fclk);
- clk_disable(iclk);
- clk_disable(hclk);
+ clk_disable_unprepare(fclk);
+ clk_disable_unprepare(iclk);
+ clk_disable_unprepare(hclk);
clocked = 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 05/11] USB: OHCI: Properly handle ohci-ep93xx suspend
Hello.
On 19-06-2013 16:12, Manjunath Goudar wrote:
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_ep93xx_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable do_wakeup and ret.
---
drivers/usb/host/ohci-ep93xx.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index 8704e9f..f5f11d1 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -174,13 +174,21 @@ static int ohci_hcd_ep93xx_drv_suspend(struct
platform_device *pdev, pm_message_
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
There was no need to use tabs here, didn't you see that here the
variables aren't aligned?
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 09/11] USB: OHCI: Properly handle ohci-pxa27x suspend
On 19-06-2013 16:12, Manjunath Goudar wrote:
Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_pxa27x_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable do_wakeup and ret.
---
drivers/usb/host/ohci-pxa27x.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 3a9c01d..1dc2a72 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -564,13 +564,19 @@ static int ohci_hcd_pxa27x_drv_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct pxa27x_ohci *ohci = to_pxa27x_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(dev);
+ int ret;
And again, no variable name alignment was needed.
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 11/11] USB: OHCI: Properly handle ohci-spear suspend
On 19-06-2013 16:12, Manjunath Goudar wrote:
Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in spear_ohci_hcd_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable do_wakeup and ret.
---
drivers/usb/host/ohci-spear.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c
index 31ff3fc..a3b2696 100644
--- a/drivers/usb/host/ohci-spear.c
+++ b/drivers/usb/host/ohci-spear.c
@@ -130,20 +130,26 @@ static int spear_ohci_hcd_drv_remove(struct
platform_device *pdev)
}
#if defined(CONFIG_PM)
-static int spear_ohci_hcd_drv_suspend(struct platform_device *dev,
+static int spear_ohci_hcd_drv_suspend(struct platform_device *pdev,
pm_message_t message)
{
- struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct spear_ohci *sohci_p = to_spear_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
Sigh...
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] net: add dm9620 net usb driver
Hi Joseph,
had a fast look...
[ ... ]
+static int dm9620_set_eeprom(struct net_device *net,
+ struct ethtool_eeprom *eeprom, u8 *data)
+{
+ struct usbnet *dev = netdev_priv(net);
+ int offset = eeprom-offset;
+ int len = eeprom-len;
+ int done;
+
+ if (eeprom-magic != MD96XX_EEPROM_MAGIC) {
+ netdev_err(dev-net, EEPROM: magic value mismatch, magic =
0x%x\n,
+ eeprom-magic);
+ return -EINVAL;
+ }
+
+ while (len 0) {
+ if (len 1 || offset 1) {
+ int which = offset 1;
+ u8 tmp[2];
+ dm_read_eeprom_word(dev, offset / 2, tmp);
+ tmp[which] = *data;
+ dm_write_eeprom_word(dev, offset / 2, tmp);
+ mdelay(10);
Please don't use mdelay, use msleep or possibly
msleep_interruptable
+ done = 1;
+ } else {
+ dm_write_eeprom_word(dev, offset / 2, data);
+ done = 2;
+ }
+ data += done;
+ offset += done;
+ len -= done;
+ }
+ return 0;
+}
[ ... ]
+static int dm9620_bind(struct usbnet *dev, struct usb_interface *intf)
+{
+ int ret;
+ u8 mac[ETH_ALEN], id;
+ u16 value;
+
+ ret = usbnet_get_endpoints(dev, intf);
+ if (ret)
+ goto out;
maybe here is better
if (ret)
return ret;
+
+ dev-net-netdev_ops = dm9620_netdev_ops;
+ dev-net-ethtool_ops = dm9620_ethtool_ops;
+ dev-net-hard_header_len += DM_TX_OVERHEAD;
+ dev-hard_mtu = dev-net-mtu + dev-net-hard_header_len;
+
+ /* ftp fail fixed */
+ dev-rx_urb_size = dev-net-mtu + ETH_HLEN + DM_RX_OVERHEAD+1;
+
+ dev-mii.dev = dev-net;
+ dev-mii.mdio_read = dm9620_mdio_read;
+ dev-mii.mdio_write = dm9620_mdio_write;
+ dev-mii.phy_id_mask = 0x1f;
+ dev-mii.reg_num_mask = 0x1f;
+ dev-mii.phy_id = DM9620_PHY_ID;
+
+ /* reset */
+ dm_write_reg(dev, DM_NET_CTRL, 1);
+ udelay(20);
from Documentation/timers/timers-howto.txt:
SLEEPING FOR A FEW USECS ( ~10us? ):
* Use udelay
use udelay if you want to sleep for less than 10us, otherwise use
usleep_range
+
+ /* read MAC */
+ if (dm_read(dev, DM_PHY_ADDR, ETH_ALEN, mac) 0) {
+ netdev_err(dev-net, Error reading MAC address\n);
+ ret = -ENODEV;
+ goto out;
+ }
you can get read of the 'out' label if in all the goto you use
you just 'return -ENODEV;' instead of 'goto out;'
+
+ /* Overwrite the auto-generated address only with good ones */
+ if (is_valid_ether_addr(mac))
+ memcpy(dev-net-dev_addr, mac, ETH_ALEN);
+ else {
+ netdev_warn(dev-net,
+ dm9620: No valid MAC address in EEPROM, using %pM\n,
+ dev-net-dev_addr);
+ __dm9620_set_mac_address(dev);
+ }
+
+ if (dm_read_reg(dev, DM_CHIP_ID, id) 0) {
+ netdev_err(dev-net, Error reading chip ID\n);
+ ret = -ENODEV;
+ goto out;
same here
+ }
+
+ dm_read(dev, DM_PID, 2, value);
+
+ /* Add for check Product dm9620a/21a */
+ if (value == 0x1269 || value == 0x0269)
+ dm_write_reg(dev, DM_MODE_CTRL, DM_MODE9620 | DM_MODE_CDC_DES);
+ else
+ dm_write_reg(dev, DM_MODE_CTRL, DM_MODE9620);
+
+ dm_write_reg(dev, DM_RX_CRC_CTRL, DM_RX_RCSEN);
+
+ /* power up phy */
+ dm_write_reg(dev, DM_GPR_CTRL, 1);
+ dm_write_reg(dev, DM_GPR_DATA, 0);
+
+ /* receive broadcast packets */
+ dm9620_set_multicast(dev-net);
+
+ dm9620_mdio_write(dev-net, dev-mii.phy_id, MII_BMCR, BMCR_RESET);
+
+ /* TX Pause Packet Enable */
+ dm_write_reg(dev, DM_FCR, DM_FCR_TXPEN | DM_FCR_BKPM | DM_FCR_FLCE);
+
+ /* ADVERTISE_PAUSE_CAP */
+ dm9620_mdio_write(dev-net, dev-mii.phy_id, MII_ADVERTISE,
+ ADVERTISE_ALL | ADVERTISE_CSMA | ADVERTISE_PAUSE_CAP);
+
+ dm_write_reg(dev, DM_USB_CTRL, DM_USB_EP3ACK);
+
+ mii_nway_restart(dev-mii);
+
+out:
+ return ret;
yeah... you wouldn't need this anymore
+}
+
+void dm9620_unbind(struct usbnet *dev, struct usb_interface *intf)
Should this be static?
+{
+ netdev_warn(dev-net, [dm962] Linux Driver = V2.6 - unbind\n);
+}
+
+static int dm9620_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
+{
+ u8 status;
+ int len;
+
+ /* format:
+b0: rx_flag
+b1: rx status
+b2: packet length (incl crc) low
+b3: packet length (incl crc) high
+b4..n-4: packet data
+bn-3..bn: ethernet crc
+ */
Allow me this nitpick please check the coding style for comments
in Documentation/CodyngStyle:
For files in net/ and drivers/net/ the preferred
[RFC PATCH 5/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host
Add the Idle state pins for USB host and enable WAKEUP on
DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index d3808ed..f1d56c2 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -89,12 +89,7 @@
};
omap3_pmx_core {
- pinctrl-names = default;
- pinctrl-0 =
- hsusbb2_pins
- ;
-
- hsusbb2_pins: pinmux_hsusbb2_pins {
+ hsusb2_pins: pinmux_hsusb2_pins {
pinctrl-single,pins =
0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
@@ -110,6 +105,25 @@
0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
;
};
+
+ /* WAKEUP enabled on DIR, DAT0-3 */
+ hsusb2_idle_pins: pinmux_hsusb2_idle_pins {
+ pinctrl-single,pins =
+ 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x5c4 (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* etk_d12.hsusb2_dir */
+ 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3)
/* etk_d13.hsusb2_nxt */
+ 0x5c8 (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* etk_d14.hsusb2_data0 */
+ 0x5cA (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* etk_d15.hsusb2_data1 */
+ 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
+ 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
+ 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
+ 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_somi.hsusb2_data5 */
+ 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs0.hsusb2_data6 */
+ 0x1ae (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* mcspi2_cs1.hsusb2_data3 */
+ ;
+ interrupts = 77; /* route padconf wakeup to EHCI IRQ */
+ };
};
i2c1 {
@@ -181,6 +195,9 @@
};
usbhshost {
+ pinctrl-names = default, idle;
+ pinctrl-0 = hsusb2_pins;
+ pinctrl-1 = hsusb2_idle_pins;
port2-mode = ehci-phy;
};
--
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
[RFC PATCH 6/6] ARM: OMAP3: Enable Hardware Save and Restore for USB Host
To ensure hardware context is restored while resuming from
OFF mode we need to enable the Hardware SAR bit for the
USB Host power domain.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/powerdomains3xxx_data.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index f0e14e9..9554d2b 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -289,13 +289,7 @@ static struct powerdomain usbhost_pwrdm = {
.prcm_offs= OMAP3430ES2_USBHOST_MOD,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_RET,
- /*
-* REVISIT: Enabling usb host save and restore mechanism seems to
-* leave the usb host domain permanently in ACTIVE mode after
-* changing the usb host power domain state from OFF to active once.
-* Disabling for now.
-*/
- /*.flags = PWRDM_HAS_HDWR_SAR,*/ /* for USBHOST ctrlr only */
+ .flags= PWRDM_HAS_HDWR_SAR, /* for USBHOST ctrlr only */
.banks= 1,
.pwrsts_mem_ret = {
[0] = PWRSTS_RET, /* MEMRETSTATE */
--
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
[RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
Runtime suspend the controller during bus suspend and resume it
during bus resume. This will ensure that the USB Host power domain
enters lower power state and does not prevent the SoC from
endering deeper sleep states.
Remote wakeup will come up as an interrupt while the controller
is suspended, so tackle it carefully using a workqueue.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-omap.c | 82 ++
1 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 16d7150..91f14f1 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -44,6 +44,8 @@
#include linux/usb/hcd.h
#include linux/of.h
#include linux/dma-mapping.h
+#include linux/workqueue.h
+#include linux/spinlock.h
#include ehci.h
@@ -69,6 +71,7 @@ static const char hcd_name[] = ehci-omap;
struct omap_hcd {
struct usb_phy *phy[OMAP3_HS_USB_PORTS]; /* one PHY for each port */
int nports;
+ struct work_struct work;
};
static inline void ehci_write(void __iomem *base, u32 reg, u32 val)
@@ -81,6 +84,76 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
return __raw_readl(base + reg);
}
+static void omap_ehci_work(struct work_struct *work)
+{
+ struct omap_hcd *omap = container_of(work, struct omap_hcd, work);
+ struct ehci_hcd *ehci = container_of((void *) omap,
+ struct ehci_hcd, priv);
+ struct usb_hcd *hcd = ehci_to_hcd(ehci);
+ struct device *dev = hcd-self.controller;
+
+ pm_runtime_get_sync(dev);
+ enable_irq(hcd-irq);
+ /*
+* enable_irq() should preempt us with a pending IRQ
+* so we can be sure that IRQ handler completes before
+* we call pm_runtime_put_sync()
+*/
+ pm_runtime_put_sync(dev);
+}
+
+static irqreturn_t omap_ehci_irq(struct usb_hcd *hcd)
+{
+ struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)-priv;
+ struct device *dev = hcd-self.controller;
+ irqreturn_t ret;
+
+ if (pm_runtime_suspended(dev)) {
+ schedule_work(omap-work);
+ disable_irq_nosync(hcd-irq);
+ ret = IRQ_HANDLED;
+ } else
+ ret = ehci_irq(hcd);
+
+ return ret;
+}
+
+#ifdef CONFIG_PM
+static int omap_ehci_bus_suspend(struct usb_hcd *hcd)
+{
+ struct device *dev;
+ int ret;
+
+ dev = hcd-self.controller;
+ ret = ehci_bus_suspend(hcd);
+ if (ret)
+ return ret;
+
+ ret = pm_runtime_put_sync(dev);
+ if (ret 0 !(ret == -EBUSY || ret == -EAGAIN)) {
+ dev_err(dev, Failed to runtime suspend :%d\n, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int omap_ehci_bus_resume(struct usb_hcd *hcd)
+{
+ struct device *dev;
+ int ret;
+
+ dev = hcd-self.controller;
+ ret = pm_runtime_get_sync(dev);
+ if (ret 0) {
+ dev_err(dev, Failed to runtime resume :%d\n, ret);
+ return ret;
+ }
+
+ return ehci_bus_resume(hcd);
+}
+#endif /* CONFIG_PM */
+
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
@@ -88,6 +161,11 @@ static struct hc_driver __read_mostly ehci_omap_hc_driver;
static const struct ehci_driver_overrides ehci_omap_overrides __initdata = {
.extra_priv_size = sizeof(struct omap_hcd),
+#ifdef CONFIG_PM
+ .bus_suspend = omap_ehci_bus_suspend,
+ .bus_resume = omap_ehci_bus_resume,
+#endif
+ .irq = omap_ehci_irq,
};
/**
@@ -163,6 +241,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
omap = (struct omap_hcd *)hcd_to_ehci(hcd)-priv;
omap-nports = pdata-nports;
+ INIT_WORK(omap-work, omap_ehci_work);
platform_set_drvdata(pdev, hcd);
@@ -257,6 +336,9 @@ static int ehci_hcd_omap_remove(struct platform_device
*pdev)
struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)-priv;
int i;
+ if (pm_runtime_suspended(dev))
+ pm_runtime_get_sync(dev);
+
usb_remove_hcd(hcd);
for (i = 0; i omap-nports; i++) {
--
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
[RFC PATCH 0/6] Suspend USB Host controller on bus suspend
Hi, This series attempts to suspend the OMAP EHCI host controller on USB Bus suspend. This will cause its parent, the OMAP USB Host Module as well as the USB TLL Module to be put in suspend and hence allow the USB power domain to be put in a lower power state. Then we no longer prevent the rest of the OMAP SoC from entering lower power states like RETention or OFF mode when USB (or system) is suspended. This was one of the main reason why EHCI_OMAP is still not enabled in OMAP2 defconfig. In order for remote wakeup or hub events (connect/disconnect) to be detected while in suspend, we need to rely on the IO daisy chaining mechanism on OMAP. This is nothing but configuring a pin to be wakeup capable and triggering an interrupt on any pin activity while the hardware module or the entire SoC is in sleep state. For this to work, we rely on the wakeup feature added to the omap-pinctrl-single driver in [1]. This takes care of routing IO pad wakeup interrupt to the right driver's interrupt handler (i.e. ehci_irq in our case). The pin state information for DEFAULT and IDLE is specified for the omap3beagle-xm board in patch 5. So this is tested only on omap3beagle-xm board. As the omap-ehci controller driver needs to do some additional work to put itself into suspend/resume and make sure it is resumed to process an interrupt, we need to be able to override irq, bus_suspend, and bus_resume handlers. This provision is done in patch 3. Patch 2 uses pinctrl framework to toggle USB host pins from DEFAULT state when active to IDLE state with wakeups enabled while in suspend. Patch 5 implements the suspend feature in ehci-omap driver and ensures that we don't loose events while in suspend. Please let me know what you think about it. I'm not 100% confident about tackling interrupt when the device is runtime suspended in patch 5. Please let me know if a race condition is possible here. [1] - OMAP pinctrl wakeup support http://thread.gmane.org/gmane.linux.ports.arm.omap/99010/focus=99041 cheers, -roger Roger Quadros (6): mfd: omap-usb-host: move initialization to module_init() mfd: omap-usb-host: Put pins in IDLE state on suspend USB: ehci: allow controller drivers to override irq bus_suspend/resume USB: ehci-omap: Suspend the controller during bus suspend ARM: dts: omap3beagle-xm: Add idle state pins for USB host ARM: OMAP3: Enable Hardware Save and Restore for USB Host arch/arm/boot/dts/omap3-beagle-xm.dts | 29 -- arch/arm/mach-omap2/powerdomains3xxx_data.c |8 +-- drivers/mfd/omap-usb-host.c | 56 +++--- drivers/mfd/omap-usb-tll.c |8 +-- drivers/usb/host/ehci-hcd.c |9 +++- drivers/usb/host/ehci-hub.c |6 +- drivers/usb/host/ehci-omap.c| 82 +++ drivers/usb/host/ehci.h |6 ++ 8 files changed, 172 insertions(+), 32 deletions(-) -- 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
[RFC PATCH 2/6] mfd: omap-usb-host: Put pins in IDLE state on suspend
In order to support wake up from suspend use the pinctrl
framework to put the USB host pins in IDLE state during suspend.
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 46 +++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 6601a49..171cc3b 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -31,6 +31,7 @@
#include linux/of.h
#include linux/of_platform.h
#include linux/err.h
+#include linux/pinctrl/consumer.h
#include omap-usb.h
@@ -111,6 +112,10 @@ struct usbhs_hcd_omap {
struct usbhs_omap_platform_data *pdata;
u32 usbhs_rev;
+
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *pins_default;
+ struct pinctrl_state *pins_idle;
};
/*-*/
@@ -325,6 +330,10 @@ static int usbhs_runtime_resume(struct device *dev)
dev_dbg(dev, usbhs_runtime_resume\n);
+ if (!IS_ERR(omap-pins_default))
+ if (pinctrl_select_state(omap-pinctrl, omap-pins_default))
+ dev_err(dev, Could not select DEFAULT pin state\n);
+
omap_tll_enable(pdata);
if (!IS_ERR(omap-ehci_logic_fck))
@@ -402,6 +411,10 @@ static int usbhs_runtime_suspend(struct device *dev)
omap_tll_disable(pdata);
+ if (!IS_ERR(omap-pins_idle))
+ if (pinctrl_select_state(omap-pinctrl, omap-pins_idle))
+ dev_err(dev, Could not select IDLE pin state\n);
+
return 0;
}
@@ -608,6 +621,30 @@ static int usbhs_omap_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ omap-pinctrl = devm_pinctrl_get(dev);
+ if (!IS_ERR(omap-pinctrl)) {
+ omap-pins_default = pinctrl_lookup_state(omap-pinctrl,
+PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(omap-pins_default))
+ dev_err(dev, Could not get DEFAULT state pins\n);
+
+ omap-pins_idle = pinctrl_lookup_state(omap-pinctrl,
+ PINCTRL_STATE_IDLE);
+ if (IS_ERR(omap-pins_idle))
+ dev_err(dev, Could not get IDLE state pins\n);
+
+ } else {
+ dev_info(dev, pinctrl_get error\n);
+ if (PTR_ERR(omap-pinctrl) == -EPROBE_DEFER) {
+ dev_info(dev, defer\n);
+ return -EPROBE_DEFER;
+ }
+
+ omap-pins_default = omap-pins_idle = ERR_PTR(-EINVAL);
+ dev_dbg(dev, Proceeding without pinctrl: %ld\n,
+ PTR_ERR(omap-pinctrl));
+ }
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
omap-uhh_base = devm_ioremap_resource(dev, res);
if (IS_ERR(omap-uhh_base))
@@ -796,6 +833,10 @@ static int usbhs_omap_probe(struct platform_device *pdev)
}
}
+ if (!IS_ERR(omap-pins_default))
+ if (pinctrl_select_state(omap-pinctrl, omap-pins_default))
+ dev_err(dev, Could not select DEFAULT pin state\n);
+
return 0;
err_alloc:
@@ -872,6 +913,11 @@ static int usbhs_omap_remove(struct platform_device *pdev)
/* remove children */
device_for_each_child(pdev-dev, NULL, usbhs_omap_remove_child);
+
+ if (!IS_ERR(omap-pins_idle))
+ if (pinctrl_select_state(omap-pinctrl, omap-pins_idle))
+ dev_err(pdev-dev, Could not select IDLE pin
state\n);
+
return 0;
}
--
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
[RFC PATCH 1/6] mfd: omap-usb-host: move initialization to module_init()
We no longer need to be initialized in any particular order
so move driver initialization to the standard place i.e. module_init()
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 10 +-
drivers/mfd/omap-usb-tll.c |8 +---
2 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 759fae3..6601a49 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -908,15 +908,7 @@ static int __init omap_usbhs_drvinit(void)
{
return platform_driver_probe(usbhs_omap_driver, usbhs_omap_probe);
}
-
-/*
- * init before ehci and ohci drivers;
- * The usbhs core driver should be initialized much before
- * the omap ehci and ohci probe functions are called.
- * This usbhs core driver should be initialized after
- * usb tll driver
- */
-fs_initcall_sync(omap_usbhs_drvinit);
+module_init(omap_usbhs_drvinit);
static void __exit omap_usbhs_drvexit(void)
{
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index e59ac4c..fb7c73e 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -482,13 +482,7 @@ static int __init omap_usbtll_drvinit(void)
{
return platform_driver_register(usbtll_omap_driver);
}
-
-/*
- * init before usbhs core driver;
- * The usbtll driver should be initialized before
- * the usbhs core driver probe function is called.
- */
-fs_initcall(omap_usbtll_drvinit);
+module_init(omap_usbtll_drvinit);
static void __exit omap_usbtll_drvexit(void)
{
--
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 0/7] Common Clock Framework support for Samsung S3C64xx
On 06/06/13 08:57, Tomasz Figa wrote: This series is an attempt to move clock support on Samsung S3C64xx SoCs to Common Clock Framework. Looks good :) First, support for PLL types present on S3C64xx SoCs is added to Samsung Common Clock Framework driver. Then the main clock driver for mentioned SoCs is introduced. Further patches contain fixes for drivers to make them compliant with CCF semantics, migration of platform code to use the new clock driver and removal of old clock management code. Depends on: - [PATCH 0/6] Samsung watchdog support clean-up http://thread.gmane.org/gmane.linux.kernel.samsung-soc/18736/focus=18989 - [PATCH 00/15] Final Samsung PWM support cleanup http://www.spinics.net/lists/arm-kernel/msg248725.html BTW, Tomasz, so how was going on above PWM patches? On S3C6410-based Tiny6410 board (Mini6410-compatible): Tested-by: Tomasz Figatomasz.f...@gmail.com Tomasz Figa (7): clk: samsung: pll: Add support for PLL6552 and PLL6553 clk: samsung: Add clock driver for S3C64xx SoCs ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros ARM: s3c64xx: dma: Use clk_prepare_enable/clk_disable_unprepare usb: host: ohci-s3c2410 Use clk_prepare_enable/clk_disable_unprepare ARM: s3c64xx: Migrate clock handling to Common Clock Framework ARM: s3c64xx: Remove old clock management code -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Common Clock Framework support for Samsung S3C64xx
On Wednesday 19 of June 2013 23:17:06 Kukjin Kim wrote: On 06/06/13 08:57, Tomasz Figa wrote: This series is an attempt to move clock support on Samsung S3C64xx SoCs to Common Clock Framework. Looks good :) Thanks. First, support for PLL types present on S3C64xx SoCs is added to Samsung Common Clock Framework driver. Then the main clock driver for mentioned SoCs is introduced. Further patches contain fixes for drivers to make them compliant with CCF semantics, migration of platform code to use the new clock driver and removal of old clock management code. Depends on: - [PATCH 0/6] Samsung watchdog support clean-up http://thread.gmane.org/gmane.linux.kernel.samsung-soc/18736/focus= 18989 - [PATCH 00/15] Final Samsung PWM support cleanup http://www.spinics.net/lists/arm-kernel/msg248725.html BTW, Tomasz, so how was going on above PWM patches? I have them ready now, but the PWM maintainer has some objections, which will hopefully be resolved soon. Best regards, Tomasz On S3C6410-based Tiny6410 board (Mini6410-compatible): Tested-by: Tomasz Figatomasz.f...@gmail.com Tomasz Figa (7): clk: samsung: pll: Add support for PLL6552 and PLL6553 clk: samsung: Add clock driver for S3C64xx SoCs ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros ARM: s3c64xx: dma: Use clk_prepare_enable/clk_disable_unprepare usb: host: ohci-s3c2410 Use clk_prepare_enable/clk_disable_unprepare ARM: s3c64xx: Migrate clock handling to Common Clock Framework ARM: s3c64xx: Remove old clock management code -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] clk: samsung: Add clock driver for S3C64xx SoCs
On 06/13/13 06:38, Tomasz Figa wrote: [...] Another thing is that it's unlikely for any new SoC from S3C64xx series to show up, so basically the clock list is fixed. Sure. I can take this into clk-next along with patch #1, or if you prefer: Acked-by: Mike Turquettemturque...@linaro.org Thanks. IMHO with all the remaining platform patches in this series, it should go through Samsung tree. Mike, thanks for your ack. Let me take this whole series into samsung tree when ready for other dependencies like PWM... - Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 05/11] USB: OHCI: Properly handle ohci-ep93xx suspend
On 19 June 2013 20:12, Manjunath Goudar manjunath.gou...@linaro.org wrote: On 19 June 2013 18:13, Sergei Shtylyov sergei.shtyl...@cogentembedded.com On 19-06-2013 16:12, Manjunath Goudar wrote: struct usb_hcd *hcd = platform_get_drvdata(pdev); struct ohci_hcd *ohci = hcd_to_ohci(hcd); + booldo_wakeup = device_may_wakeup(pdev-dev); + int ret; There was no need to use tabs here, didn't you see that here the variables aren't aligned? Instead of gmail you can use thunderbird mail there it is showing proper alignment. First try to understand what the actual comment is. He isn't complaining about bad alignment but as hcd and ohci aren't aligned with tabs, you don't require to add tabs to do_wakeup and ret. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/1] Intel xhci: rework EHCI/xHCI port switching
On 06/18/2013 05:39 PM, Alan Stern wrote: On Mon, 17 Jun 2013, Sarah Sharp wrote: Correct me if I'm wrong here. The original idea was to switch everything over to xHCI during some early stage (like when the xHCI controller is first passed to the pci-quirks.c code) and switch back to EHCI at shutdown. As a refinement, you want to switch over to xHCI again following system resume, in case the BIOS messed things up. Is there anything else? Yes, that was the idea. Why does the old code need to be changed? The only problem I see is that it may be a little too elaborate. For example, why bother trying to do the switch when the EHCI controller resumes? Won't everything work okay if you wait until the xHCI controller resumes? The code needs to be changed because we don't want to keep adding new PCI IDs for all the new Intel hosts. Okay. That's simple enough; just remove the product ID checks. Mathias also didn't like that we inefficiently walked the PCI bus, looking for the xHCI host in the EHCI resume routine, so he stored the xHCI pointer. Perhaps this would be more clear if these two goals were broken up into two patches? Why not just remove all that stuff from the EHCI resume routine? It would be a lot simpler. See below. Why does the code check so hard to see whether or not there are any switchable ports? Why not just always try to set the switch on any Intel controller? Not all ports may be exposed on the platform (because there are different skews). If we don't check which ports to switchover, some BIOSes freak out on either shutdown, or suspend. I don't remember which. So we need to pay attention to the port switchover masks. Sorry, I wasn't clear. Yes, by all means, do check the switchover masks. But there's no need to check the product ID; checking just the vendor ID should be good enough. Why is it necessary to search through all the PCI devices? Why is it necessary to store any sort of list of switchable controllers? We don't know which host will resume from suspend first. Assume we have a broken BIOS that switches ports back to EHCI on resume. We don't want the USB core to notice EHCI connects and start servicing them before xHCI resumes. Therefore, we need to have both the xHCI and the EHCI resume functions attempt to switch the ports over to xHCI. The USB core won't notice anything, because the hub driver doesn't start running again until after all the devices (including host controllers) have been resumed. In other words, the khubd thread is freezable. (This is not by some random chance; it was an explicit decision that we don't want the hub driver mucking things up while we're in the middle of a big transition like system suspend or resume. You can rely on it.) So it won't matter if a device gets switched over to EHCI for a while. When the xHCI controller resumes, the device will get switched back to it, and usbcore will see only that there was a disconnect/reconnect during suspend. That means for EHCI, we either need to search the PCI tree for the xHCI host on resume (because that's where the port switchover mechanism registers are), or we need to store the xHCI PCI host pointer somewhere. Mathias chose to store the pointer. The reasoning above shows that there's no need either to search the entire PCI tree or to store any host controller pointers. Why should hot-unplug be an issue? Or multiple xHCI controllers? This is not a problem right now, I'm perhaps being paranoid. :) For all current Intel systems, AFAIK, there will only be one xHCI host controller, and it will be a part of the PCH, so you won't see any PCI hot unplug events unless someone removes the entire PCH (which I don't know if we support?). Even if someone in the future decides to put an Intel xHCI controller on a PCIe card, there shouldn't be any trouble if you handle things as decribed above. Agreed? Thanks for the explanation, I'll write a much simpler patch and remove portswitching from EHCI resume. -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug] USB 2.0 Ports Dont Work on Sony Vaio Laptop
On Wed, 19 Jun 2013, Ming Lei wrote: Hi, Recently, there is one bug report from Ubuntu community: USB 2.0 Ports Dont Work on Sony Vaio Laptop and the problem exists on upstream kernel too. The built-in two USB 2.0 devices can be recognized correctly, but external devices can't be recognized when the device is connected to USB 2.0 port. Also, the USB 2.0 bus can be waken up successfully via /sys/bus/devices/.../power/control, but still can't find external connected devices, and no any 'dmesg' log with CONFIG_USB_DEBUG enabled after the device is plugged into 2.0 ports. See detailed log in below link: https://bugs.launchpad.net/bugs/1172908 No such problem on Windows. There's a good chance this problem was caused by a change in the xhci-hcd driver. Anyway, it looks like the best way of finding the problem is git bisect. 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: [RFC PATCH 0/6] Suspend USB Host controller on bus suspend
On Wed, 19 Jun 2013, Roger Quadros wrote: Hi, This series attempts to suspend the OMAP EHCI host controller on USB Bus suspend. Why do you want to suspend the host controller during bus suspend? They are two different operations and should be carried out at two different times. The controller should be suspended during controller suspend, not during bus suspend. As the omap-ehci controller driver needs to do some additional work to put itself into suspend/resume and make sure it is resumed to process an interrupt, we need to be able to override irq, bus_suspend, and bus_resume handlers. This provision is done in patch 3. Do you still need to override these things if you do the controller suspend at the right time? 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: [Bug] USB 2.0 Ports Dont Work on Sony Vaio Laptop
Hi, Thanks for your reply. On Wed, Jun 19, 2013 at 11:17 PM, Alan Stern st...@rowland.harvard.edu wrote: On Wed, 19 Jun 2013, Ming Lei wrote: Hi, Recently, there is one bug report from Ubuntu community: USB 2.0 Ports Dont Work on Sony Vaio Laptop and the problem exists on upstream kernel too. The built-in two USB 2.0 devices can be recognized correctly, but external devices can't be recognized when the device is connected to USB 2.0 port. Also, the USB 2.0 bus can be waken up successfully via /sys/bus/devices/.../power/control, but still can't find external connected devices, and no any 'dmesg' log with CONFIG_USB_DEBUG enabled after the device is plugged into 2.0 ports. See detailed log in below link: https://bugs.launchpad.net/bugs/1172908 No such problem on Windows. There's a good chance this problem was caused by a change in the xhci-hcd driver. I am wondering why xhci-hcd may cause the problem since the affected hub is 'Intel Corp. Integrated Rate Matching Hub' which is connected to EHCI root hub. Also tests showed that there is power provided by port of the 'Integrated Rate Matching Hub', but can't detect connection. Anyway, it looks like the best way of finding the problem is git bisect. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 2/6] USB: disable IRQs deliberately when calling complete()
On Wed, 19 Jun 2013, Ming Lei wrote: On Wed, Jun 19, 2013 at 12:36 AM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 18 Jun 2013, Ming Lei wrote: We disable local IRQs here in case of running complete() by tasklet to avoid possible deadlock because drivers may call spin_lock() to hold lock which might be acquired in one hard interrupt handler. The local_irq_save()/local_irq_restore() around complete() will be removed if current USB drivers have been cleaned up and no one may trigger the above deadlock situation when running complete() in tasklet. This should be part of the first patch, not added on separately. Yes, but I want to highlight the change since that will be removed after drivers have been cleaned up. I don't think it's necessary to highlight anything, and it seems silly to add new code in one patch and then change it in the very next 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
[PATCH 4/8] usb: musb: provide empty dma_controller_create() in PIO mode
Add a dma_controller_create() returning NULL so a few ifdefs can
dropped.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/musb_dma.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h
index 3603711..c8e67fd 100644
--- a/drivers/usb/musb/musb_dma.h
+++ b/drivers/usb/musb/musb_dma.h
@@ -175,9 +175,20 @@ struct dma_controller {
/* called after channel_program(), may indicate a fault */
extern void musb_dma_completion(struct musb *musb, u8 epnum, u8 transmit);
+#ifdef CONFIG_MUSB_PIO_ONLY
+static inline struct dma_controller *dma_controller_create(struct musb *m,
+ void __iomem *io)
+{
+ return NULL;
+}
+
+static inline void dma_controller_destroy(struct dma_controller *d) { }
+
+#else
extern struct dma_controller *dma_controller_create(struct musb *, void
__iomem *);
extern void dma_controller_destroy(struct dma_controller *);
+#endif
#endif /* __MUSB_DMA_H__ */
--
1.8.3.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: [RFC PATCH v1 1/6] USB: HCD: support giveback of URB in tasklet context
On Wed, 19 Jun 2013, Ming Lei wrote:
@@ -835,9 +839,11 @@ static int usb_rh_urb_dequeue(struct usb_hcd *hcd,
struct urb *urb, int status)
hcd-status_urb = NULL;
usb_hcd_unlink_urb_from_ep(hcd, urb);
- spin_unlock(hcd_root_hub_lock);
+ if (!hcd_giveback_urb_in_bh(hcd))
+ spin_unlock(hcd_root_hub_lock);
usb_hcd_giveback_urb(hcd, urb, status);
- spin_lock(hcd_root_hub_lock);
+ if (!hcd_giveback_urb_in_bh(hcd))
+ spin_lock(hcd_root_hub_lock);
}
}
done:
None of these tests are necessary. Root hubs are different from normal
devices; their URBs are handled mostly by usbcore. The only part done
by the HCD is always synchronous. And we know that root-hub URBs
Looks not always synchronous, control transfer is synchronous, and
interrupt transfer is still asynchronous. No drivers(hub, usbfs) depend
on that, and IMO, treating root hub same as hub will simplify HCD core,
and finally we can remove all the above lock releasing acquiring if
all HCDs set HCD_BH.
Also there is very less roothub transfers and always letting tasklet
handle URB giveback of roothub won't have performance problem, so
how about keeping the above tests?
If you want to use the tasklets for root-hub URBs, okay. There's no
reason to check the HCD_BH flag, though, because HCDs have only minimal
involvement in root-hub URBs. In particular, HCD's don't call
usb_hcd_giveback_urb() for them.
So you can use the tasklets for _all_ root-hub URBs. Then the tests
above aren't necessary, and neither are the spinlock operations.
@@ -2573,6 +2687,16 @@ int usb_add_hcd(struct usb_hcd *hcd,
device_can_wakeup(hcd-self.root_hub-dev))
dev_dbg(hcd-self.controller, supports USB remote
wakeup\n);
+ if (usb_hcd_is_primary_hcd(hcd)) {
+ retval = init_giveback_urb_bh(hcd);
+ if (retval)
+ goto err_init_giveback_bh;
+ } else {
+ /* share tasklet handling with primary hcd */
+ hcd-async_bh = hcd-primary_hcd-async_bh;
+ hcd-periodic_bh = hcd-primary_hcd-periodic_bh;
+ }
Is there any reason why a secondary HCD can't have its own tasklets?
I didn't do that because both primary and secondary HCDs share one
hard interrupt handler, so basically there is no obvious advantage to
do that.
If the bh structures are embedded directly in the hcd structure, it
won't be possible for a secondary hcd to share its tasklets with the
primary hcd. Not sharing seems simpler, and there's no obvious
disadvantage either.
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 2/8] usb: musb: musbhsdma: drop the controller check in dma_controller_destroy()
This check is hardly required and alas is wrong. 'c' might be NULL but the chances are low that 'controller' after the container_of() becomes NULL. Since no other DMA implementation is doing that and musb-core does not call it with a NULL pointer it can dropped. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/usb/musb/musbhsdma.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c index 3d1fd52..3f5e121 100644 --- a/drivers/usb/musb/musbhsdma.c +++ b/drivers/usb/musb/musbhsdma.c @@ -371,9 +371,6 @@ void dma_controller_destroy(struct dma_controller *c) struct musb_dma_controller *controller = container_of(c, struct musb_dma_controller, controller); - if (!controller) - return; - if (controller-irq) free_irq(controller-irq, c); -- 1.8.3.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
random musb bits, mostly dma, nothing serious
Hi Felipe, here is a bunch of small musb patches. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] usb: musb: replace ifndef with ifdef for CONFIG_MUSB_PIO_ONLY
The ifdef reads somehow better than an ifndef Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/usb/musb/musb_dma.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h index 1b6b827..8919ce2 100644 --- a/drivers/usb/musb/musb_dma.h +++ b/drivers/usb/musb/musb_dma.h @@ -62,10 +62,10 @@ struct musb_hw_ep; #defineDMA_ADDR_INVALID(~(dma_addr_t)0) -#ifndef CONFIG_MUSB_PIO_ONLY -#defineis_dma_capable()(1) -#else +#ifdef CONFIG_MUSB_PIO_ONLY #defineis_dma_capable()(0) +#else +#defineis_dma_capable()(1) #endif #ifdef CONFIG_USB_TI_CPPI_DMA -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] usb: musb: core: call dma_controller_destroy() in the err path
The cleanup in the error is missing the dma controller. The structure is allocated at runtime and ux500 allocates even a little more than just this struct. So cleanup! Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/usb/musb/musb_core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index b33bed5..9b774e7 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -1933,6 +1933,8 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl) musb_gadget_cleanup(musb); fail3: + if (musb-dma_controller) + dma_controller_destroy(musb-dma_controller); pm_runtime_put_sync(musb-controller); fail2: -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] usb: musb: remove a few is_dma_capable() in init/exit code
This patch removes is_dma_capable() and an ifdef in the init/exit path around init/de-init of the dma_controller. Since we have the empty stubs in the PIO code we can call it without gcc trouble. Earlier we had an ifdef and the is_dma_capable() macro where gcc ignored the if (0) path even that the function was not around :) Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/usb/musb/musb_core.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index a4434d2..b33bed5 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -1764,7 +1764,7 @@ static void musb_free(struct musb *musb) disable_irq_wake(musb-nIrq); free_irq(musb-nIrq, musb); } - if (is_dma_capable() musb-dma_controller) + if (musb-dma_controller) dma_controller_destroy(musb-dma_controller); musb_host_free(musb); @@ -1840,12 +1840,11 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl) pm_runtime_get_sync(musb-controller); -#ifndef CONFIG_MUSB_PIO_ONLY if (use_dma dev-dma_mask) musb-dma_controller = dma_controller_create(musb, musb-mregs); -#endif + /* ideally this would be abstracted in platform setup */ - if (!is_dma_capable() || !musb-dma_controller) + if (!musb-dma_controller) dev-dma_mask = NULL; /* be sure interrupts are disabled before connecting ISR */ -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] usb: musb: unmap reqs in musb_gadget_queue()'s error case
If the descriptor is missing the reqeust is never unmapped. This patch changes this and renames the cleanup label to unlock since there is no cleanup done. The cleanup would revert the allocation of ressource (i.e. this dma mapping) but it does not, it simply unlocks and returns. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/usb/musb/musb_gadget.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index 0414bc1..96632f9 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -1266,7 +1266,8 @@ static int musb_gadget_queue(struct usb_ep *ep, struct usb_request *req, dev_dbg(musb-controller, req %p queued to %s while ep %s\n, req, ep-name, disabled); status = -ESHUTDOWN; - goto cleanup; + unmap_dma_buffer(request, musb); + goto unlock; } /* add request to the list */ @@ -1276,7 +1277,7 @@ static int musb_gadget_queue(struct usb_ep *ep, struct usb_request *req, if (!musb_ep-busy request-list == musb_ep-req_list.next) musb_ep_restart(musb, request); -cleanup: +unlock: spin_unlock_irqrestore(musb-lock, lockflags); return status; } -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] usb: musb: dma: merge -start/stop into create/destroy
The core code creates a controller and immediately after that it calls
the -start() callback. This one might drop an error but nobody cares.
The same thing happens in the destroy corner: First -stop() called
followed by destroy callback. So why not merge those two into the same
function since there is no difference.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/cppi_dma.c | 18 +-
drivers/usb/musb/musb_core.c | 18 --
drivers/usb/musb/musb_dma.h | 2 --
drivers/usb/musb/musbhsdma.c | 16 +++-
drivers/usb/musb/tusb6010_omap.c | 24
drivers/usb/musb/ux500_dma.c | 19 ---
6 files changed, 20 insertions(+), 77 deletions(-)
diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c
index 9db211e..904fb85 100644
--- a/drivers/usb/musb/cppi_dma.c
+++ b/drivers/usb/musb/cppi_dma.c
@@ -150,14 +150,11 @@ static void cppi_pool_free(struct cppi_channel *c)
c-last_processed = NULL;
}
-static int cppi_controller_start(struct dma_controller *c)
+static void cppi_controller_start(struct cppi *controller)
{
- struct cppi *controller;
void __iomem*tibase;
int i;
- controller = container_of(c, struct cppi, controller);
-
/* do whatever is necessary to start controller */
for (i = 0; i ARRAY_SIZE(controller-tx); i++) {
controller-tx[i].transmit = true;
@@ -212,8 +209,6 @@ static int cppi_controller_start(struct dma_controller *c)
/* disable RNDIS mode, also host rx RNDIS autorequest */
musb_writel(tibase, DAVINCI_RNDIS_REG, 0);
musb_writel(tibase, DAVINCI_AUTOREQ_REG, 0);
-
- return 0;
}
/*
@@ -222,14 +217,12 @@ static int cppi_controller_start(struct dma_controller *c)
* De-Init the DMA controller as necessary.
*/
-static int cppi_controller_stop(struct dma_controller *c)
+static void cppi_controller_stop(struct cppi *controller)
{
- struct cppi *controller;
void __iomem*tibase;
int i;
struct musb *musb;
- controller = container_of(c, struct cppi, controller);
musb = controller-musb;
tibase = controller-tibase;
@@ -255,8 +248,6 @@ static int cppi_controller_stop(struct dma_controller *c)
/*disable tx/rx cppi */
musb_writel(tibase, DAVINCI_TXCPPI_CTRL_REG, DAVINCI_DMA_CTRL_DISABLE);
musb_writel(tibase, DAVINCI_RXCPPI_CTRL_REG, DAVINCI_DMA_CTRL_DISABLE);
-
- return 0;
}
/* While dma channel is allocated, we only want the core irqs active
@@ -1321,8 +1312,6 @@ struct dma_controller *dma_controller_create(struct musb
*musb, void __iomem *mr
controller-tibase = mregs - DAVINCI_BASE_OFFSET;
controller-musb = musb;
- controller-controller.start = cppi_controller_start;
- controller-controller.stop = cppi_controller_stop;
controller-controller.channel_alloc = cppi_channel_allocate;
controller-controller.channel_release = cppi_channel_release;
controller-controller.channel_program = cppi_channel_program;
@@ -1351,6 +1340,7 @@ struct dma_controller *dma_controller_create(struct musb
*musb, void __iomem *mr
controller-irq = irq;
}
+ cppi_controller_start(controller);
return controller-controller;
}
@@ -1363,6 +1353,8 @@ void dma_controller_destroy(struct dma_controller *c)
cppi = container_of(c, struct cppi, controller);
+ cppi_controller_stop(cppi);
+
if (cppi-irq)
free_irq(cppi-irq, cppi-musb);
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 29a24ce..a4434d2 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1764,12 +1764,8 @@ static void musb_free(struct musb *musb)
disable_irq_wake(musb-nIrq);
free_irq(musb-nIrq, musb);
}
- if (is_dma_capable() musb-dma_controller) {
- struct dma_controller *c = musb-dma_controller;
-
- (void) c-stop(c);
- dma_controller_destroy(c);
- }
+ if (is_dma_capable() musb-dma_controller)
+ dma_controller_destroy(musb-dma_controller);
musb_host_free(musb);
}
@@ -1845,14 +1841,8 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
pm_runtime_get_sync(musb-controller);
#ifndef CONFIG_MUSB_PIO_ONLY
- if (use_dma dev-dma_mask) {
- struct dma_controller *c;
-
- c = dma_controller_create(musb, musb-mregs);
- musb-dma_controller = c;
- if (c)
- (void) c-start(c);
- }
+ if (use_dma dev-dma_mask)
+ musb-dma_controller = dma_controller_create(musb, musb-mregs);
#endif
/* ideally this would be
[PATCH 8/8] usb: musb: omap2430: make it compile again
it does not compile since 09fc7d (usb: musb: fix incorrect usage of
resource pointer). What makes me wonder most is if source of the
Tested-by tag :)
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/omap2430.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index c7c1d7a..4315d35 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -481,7 +481,7 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int omap2430_probe(struct platform_device *pdev)
{
- struct resource musb_resouces[2];
+ struct resource musb_resources[2];
struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data;
struct omap_musb_board_data *data;
struct platform_device *musb;
@@ -568,7 +568,7 @@ static int omap2430_probe(struct platform_device *pdev)
INIT_WORK(glue-omap_musb_mailbox_work, omap_musb_mailbox_work);
- memset(musb_resouces, 0x00, sizeof(*musb_resources) *
+ memset(musb_resources, 0x00, sizeof(*musb_resources) *
ARRAY_SIZE(musb_resources));
musb_resources[0].name = pdev-resource[0].name;
--
1.8.3.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: [RFC PATCH v1 4/6] USB: EHCI: don't release ehci-lock if URB giveback in tasklet context
On Wed, 19 Jun 2013, Ming Lei wrote: On Wed, Jun 19, 2013 at 12:43 AM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 18 Jun 2013, Ming Lei wrote: If HCD_BH is set for HC driver's flags, URB giveback will be done in tasklet context instead of interrupt context, so the ehci-lock needn't to be released any more before calling usb_hcd_giveback_urb(). It is premature to do this now. This should be part of the 6/6 patch, It is fine since HCD_BH isn't enabled. It's not fine. It will work -- nothing will crash -- but that doesn't mean it is good style. when it won't be necessary to test hcd_giveback_urb_in_bh(). Keeping it is easy to compare test results between running complete() in tasklet and in hard irq handler. It's just as easy to do your tests by keeping two copies of ehci-hcd.ko lying around; one with your changes and one without. You can insmod whichever one you want to test. Also it might be helpful for out of tree drivers. But it isn't a big deal, I can merge it to 6/6 if you care. Yes, please. 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 v7 1/9] drivers: phy: add generic PHY framework
Hi,
On 06/13/2013 10:43 AM, Kishon Vijay Abraham I wrote:
+/**
+ * phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ * @priv: private data from phy driver
+ *
+ * Called to create a phy using phy framework.
+ */
+struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
+ const char *label, void *priv)
+{
+ int ret;
+ struct phy *phy;
+
+ if (!dev) {
+ dev_WARN(dev, no device provided for PHY\n);
+ ret = -EINVAL;
+ goto err0;
+ }
+
+ phy = kzalloc(sizeof(*phy), GFP_KERNEL);
+ if (!phy) {
+ ret = -ENOMEM;
+ goto err0;
+ }
+
+ device_initialize(phy-dev);
+
+ phy-dev.class = phy_class;
+ phy-dev.parent = dev;
+ phy-dev.of_node = dev-of_node;
+ phy-id = id;
+ phy-ops = ops;
+ phy-label = label;
Perhaps we could make it:
phy-label = kstrdup(label, GFP_KERNEL);
and free the label in phy_destroy() ?
That way the users would't need to keep the label around. It might
be useful when PHY provider generates the labels dynamically. I guess
it is OK for PHY providers to hard code the labels and having the PHY
user drivers passed labels in platform data ?
+ dev_set_drvdata(phy-dev, priv);
+
+ ret = dev_set_name(phy-dev, %s.%d, dev_name(dev), id);
+ if (ret)
+ goto err1;
+
+ ret = device_add(phy-dev);
+ if (ret)
+ goto err1;
+
+ if (pm_runtime_enabled(dev))
+ pm_runtime_enable(phy-dev);
+
+ return phy;
+
+err1:
+ put_device(phy-dev);
+ kfree(phy);
+
+err0:
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(phy_create);
+/**
+ * phy_destroy() - destroy the phy
+ * @phy: the phy to be destroyed
+ *
+ * Called to destroy the phy.
+ */
+void phy_destroy(struct phy *phy)
+{
+ pm_runtime_disable(phy-dev);
+ device_unregister(phy-dev);
Isn't kfree(phy); missing here ?
+}
+EXPORT_SYMBOL_GPL(phy_destroy);
Thanks,
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: [Bug] USB 2.0 Ports Dont Work on Sony Vaio Laptop
On Wed, 19 Jun 2013, Ming Lei wrote: There's a good chance this problem was caused by a change in the xhci-hcd driver. I am wondering why xhci-hcd may cause the problem since the affected hub is 'Intel Corp. Integrated Rate Matching Hub' which is connected to EHCI root hub. It's just a guess. You pointed out that the problem seems to be related to port routing, and the port routing code is part of the xHCI driver. The original bug report on Launchpad doesn't mention any earlier kernels working. Maybe the problem was caused by a change somewhere else, such as a change in the BIOS. 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: [RFC PATCH v1 5/6] USB: EHCI: improve interrupt qh unlink
On Wed, 19 Jun 2013, Ming Lei wrote: The approach used in this patch is wrong. You shouldn't start the unlink, then wait, then finish the unlink. Consider what would happen What you mentioned above is just what the patch is doing, :-) start_unlink_intr() only sets the qh as QH_STATE_UNLINK_WAIT, puts the qh into one wait list and starts a timer, if it is expired the qh will be started to unlink, otherwise the qh can be recovered to QH_STATE_LINKED immediately if there is one URB submitted. Okay, maybe I was fooled by your use of QH_STATE_UNLINK_WAIT. Setting the state to that value means that the QH is going to be unlinked after a time delay. However, that's not what you mean; you mean that after a time delay you will decide whether or not to unlink the QH. I think you should copy the approach used for the async QHs. So unlinking intr qh becomes a 3-stage process: - wait(qh return to linked state if URB is submitted during the period, otherwise go to start unlink) - start unlink(do unlink, and wait for end of unlink) - end unlink if an URB were submitted during the delay: It would have to wait until If an URB were submitted during the delay, the previous wait is canceled immediately, and the qh state is recovered to linked state, please see cancel_unlink_wait_intr() called in intr_submit(). Right. But you're not allowed to do that after changing qh-state. One of the invariants of the driver is that once qh-state takes on any value other than QH_STATE_LINKED (or, temporarily, QH_STATE_COMPLETING), the QH must be unlinked. The state can't change back to QH_STATE_LINKED without first passing through QH_STATE_IDLE. Also, it's silly to check whether or not giveback uses a tasklet. We know that following the 6/6 patch it will. Even if it doesn't, there's no harm in waiting a little while before unlinking an empty interrupt QH. It is still for the test reason, since the patch may cause recursion if HCD_BH isn't set. How can it cause recursion? The async unlink code doesn't. 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] build some drivers only when compile-testing
On Tue, Jun 18, 2013 at 11:34:26AM +0300, Felipe Balbi wrote: MUSB alone has 8 different arch choices. Before, it used to be that core driver was dependendent on all of them, so whenever someone wanted to build MUSB for another arch, they had to introdude their glue code and modify the dependency of the core driver. Also EHCI, it works on pretty much everything, so does DWC3. DWC3 already has three possibilities but I know of at least 3 others which could show up soonish. If the number of architectures supported is getting large enough then it's probably reasonable to just enable the driver all the time, probably it'll also appear on some PCI cards or something anyway. The things people are complaining about here are things that are clearly unlikely to appear on other architectures like a particular SoC vendor's custom IPs that they don't license out. signature.asc Description: Digital signature
Re: [RFC PATCH 2/6] mfd: omap-usb-host: Put pins in IDLE state on suspend
Hi Roger, Roger Quadros rog...@ti.com writes: In order to support wake up from suspend use the pinctrl framework to put the USB host pins in IDLE state during suspend. CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com You should use helpers for this now in the pinctrl core: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html Kevin -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] musb: musb: dsps: support multiple instances
On 06/18/2013 10:27 AM, Felipe Balbi wrote:
--- a/arch/arm/boot/dts/am33xx.dtsi +++
b/arch/arm/boot/dts/am33xx.dtsi @@ -341,6 +341,14 @@ port1-mode =
3; power = 250; ti,hwmods = usb_otg_hs; + phys =
nopphy0 nopphy1; + }; + + nopphy0: usbphy@0 { +
compatible = usb-nop-xceiv; + }; +nopphy1:
usbphy@1 { +
compatible = usb-nop-xceiv; };
mac: ethernet@4a10 {
Any opinion on those phy nodes? Is it likely that we need a real phy
driver here and also expose a little more information like the memory
register or reset / vcc supply?
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 6/6] ARM: OMAP3: Enable Hardware Save and Restore for USB Host
Hello.
On 06/19/2013 06:05 PM, Roger Quadros wrote:
To ensure hardware context is restored while resuming from
OFF mode we need to enable the Hardware SAR bit for the
USB Host power domain.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/powerdomains3xxx_data.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index f0e14e9..9554d2b 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -289,13 +289,7 @@ static struct powerdomain usbhost_pwrdm = {
.prcm_offs= OMAP3430ES2_USBHOST_MOD,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_RET,
- /*
-* REVISIT: Enabling usb host save and restore mechanism seems to
-* leave the usb host domain permanently in ACTIVE mode after
-* changing the usb host power domain state from OFF to active once.
-* Disabling for now.
-*/
- /*.flags = PWRDM_HAS_HDWR_SAR,*/ /* for USBHOST ctrlr only */
+ .flags= PWRDM_HAS_HDWR_SAR, /* for USBHOST ctrlr only */
Looks like you're not indenting = right, in accordance to the other
fields...
.banks= 1,
.pwrsts_mem_ret = {
[0] = PWRSTS_RET, /* MEMRETSTATE */
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 05/11] USB: OHCI: Properly handle ohci-ep93xx suspend
Hello.
On 06/19/2013 06:42 PM, Manjunath Goudar wrote:
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_ep93xx_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
mailto:manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de mailto:a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
mailto:st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com mailto:g...@kroah.com
Cc: linux-usb@vger.kernel.org mailto:linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable do_wakeup and ret.
---
drivers/usb/host/ohci-ep93xx.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-__ep93xx.c
b/drivers/usb/host/ohci-__ep93xx.c
index 8704e9f..f5f11d1 100644
--- a/drivers/usb/host/ohci-__ep93xx.c
+++ b/drivers/usb/host/ohci-__ep93xx.c
@@ -174,13 +174,21 @@ static int
ohci_hcd_ep93xx_drv_suspend(__struct platform_device *pdev,
pm_message_
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
There was no need to use tabs here, didn't you see that here the
variables aren't aligned?
WBR, Sergei
Instead of gmail you can use thunderbird mail there it is showing
proper alignment.
Imagine, I'm using Thinderbird. :-D
And you're using HTML reply format, unwelcome on the Linux mailing
lists.
Manjunath Goudar
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
Hi Roger, Roger Quadros rog...@ti.com writes: Runtime suspend the controller during bus suspend and resume it during bus resume. This will ensure that the USB Host power domain enters lower power state and does not prevent the SoC from endering deeper sleep states. Remote wakeup will come up as an interrupt while the controller is suspended, so tackle it carefully using a workqueue. I don't think you need a special workqueue here. The workqueue of the PM core (pm_wq) will be used if you just use an asynchronous 'get' in the ISR. Then, the driver's own runtime PM callbacks can be used instead of an additional workqueue. Another thing to worry about here when using runtime PM to implement suspend/resume is that runtime PM can be disabled from userspace (e.g. echo disabled /sys/devices/.../power/control.) If that's the case, all the pm_runtime_suspended() checks will always fail becuase that call also checks if runtime PM is disabled. You'll likely want to use the pm_runtime_status_suspended() check instead, which checks only the status, and doesn't matter if runtime PM is currently disabled. Because of the corner issues here, please test system suspend/resume when runtime PM has been disabled. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 5/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host
Roger Quadros rog...@ti.com writes:
Add the Idle state pins for USB host and enable WAKEUP on
DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
This one doesn't apply...
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index d3808ed..f1d56c2 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -89,12 +89,7 @@
};
omap3_pmx_core {
- pinctrl-names = default;
- pinctrl-0 =
- hsusbb2_pins
- ;
-
- hsusbb2_pins: pinmux_hsusbb2_pins {
This omap3_pmx_core section doesn't exist upstream in the xM DTS file
(but does in omap3-beagle.dts.)
Is there a dependency patch missing?
Kevin
--
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
Hardware bug in Intel USB-2 hub?
Sarah: This report surfaced in Bugzilla #59011 (see especially comments #38 and #39). Toralf reports, among other things, that the integrated rate-matching hub in his ThinkPad T420 (6 Series/C200 Series chipset) isn't behaving the way it should. The particular symptom is that when the hub is suspended, it does not relay wakeup requests from a downstream port to its upstream port, if the downstream device is connected at low speed and the downstream port's suspend feature isn't set. This happens with the 3.10-rc kernels, because commit 0aa2832dd0d9 changed system suspend to do a USB global bus suspend. None of the ports on non-SuperSpeed hubs are explicitly put into suspend mode; instead, everything on the bus goes into suspend when the root hub stops sending packets. The problem is easy to test on any system running a 3.10-rc kernel. Simply plug a low-speed USB keyboard (almost all keyboards are low speed) into a USB-2 port, suspend the system, and then see if typing on the keyboard will wake up the computer. I have tested a couple of external USB-2 hubs; one of them behaved correctly and one didn't. Regardless, it was surprising to see Toralf's report that an Intel hub doesn't work right. I don't have any machines with a comparable chipset, so I can't test one of those integrated hubs directly. Can somebody at Intel look into this? 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
Section mismatch in drivers/usb/gadget/fotg210-udc.c
Hi guys, This was seen on a linux-next (Jun18th tree) allmodconfig build: WARNING: drivers/usb/gadget/fotg210-udc.o(.data+0x0): Section mismatch in reference from the variable fotg210_driver to the function .init.text:fotg210_udc_probe() The variable fotg210_driver references the function __init fotg210_udc_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console Paul. -- 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 5/6] USB: OHCI: make ohci-at91 a separate driver
On Wed, 12 Jun 2013, Manjunath Goudar wrote:
Separate the TI OHCI Atmel host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
V2:
-Set non-standard fields in ohci_at91_hc_driver manually, rather than
relying on an expanded struct ohci_driver_overrides.
-Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
relying on ohci_hub_control and hub_status_data being exported.
-ohci_setup() has been removed because it is called in .reset member
of the ohci_hc_driver structure.
@@ -111,6 +125,8 @@ static void usb_hcd_at91_remove (struct usb_hcd *, struct
platform_device *);
static int usb_hcd_at91_probe(const struct hc_driver *driver,
struct platform_device *pdev)
{
+ struct at91_usbh_data *board;
+ struct ohci_hcd *ohci;
Variables are supposed to be not aligned at all (in which case you
don't use tabs) or all aligned the same way. In this case you put a
tab before the *board; therefore the *ohci should line up with it.
No, this isn't an artifact of my email program. They really are not
aligned.
@@ -163,8 +179,11 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
goto err5;
}
+ board = hcd-self.controller-platform_data;
+ ohci = hcd_to_ohci(hcd);
+ ohci-num_ports = board-ports;
at91_start_hc(pdev);
- ohci_hcd_init(hcd_to_ohci(hcd));
+ ohci_setup(hcd);
Didn't you say above that this version of the patch removes the call to
ohci_setup()?
@@ -686,7 +631,7 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
* REVISIT: some boards will be able to turn VBUS off...
*/
if (at91_suspend_entering_slow_clock()) {
- ohci_usb_reset (ohci);
+ ohci_restart(ohci);
Why did you change this? Did we discuss it earlier?
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
question about USB interface probe order and synchronization
Hi, I am attempting to debug a problem where the hwa_hc module occasionally fails to start correctly when an HWA device is plugged in. An HWA device consists of two USB interfaces each with its own driver: the radio control interface (hwa_rc.ko), and the host controller interface (hwa_hc.ko). Both of these modules depend on a common subcomponent (uwb.ko) but they do not depend directly on each other as far as depmod is concerned. When the device is plugged in, hwa_rc receives a probe event. It then does a device_add after setting the class to uwb_rc to add itself to the system. When the hwa_hc probe event happens for the host controller interface, it attempts to find a handle to the RC object using class_find_device to find a uwb_rc class device with a common parent device ptr. Usually, the radio controller interface is able to register itself before the host controller interface looks for it, but occasionally the order is reversed and the lookup fails causing the host controller probe to fail. So, my question is. Is there a better way for one interface driver to get a handle to the device object of another interface on the same USB device at probe time? Thanks, Tom Pugliese -- 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 6/6] USB: OHCI: make ohci-s3c2410 a separate driver
On Wed, 12 Jun 2013, Manjunath Goudar wrote: Separate the Samsung OHCI S3C host controller driver from ohci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM; it would be nice to have in 3.11. V2: -Set non-standard fields in ohci_s3c2410_hc_driver manually, rather than relying on an expanded struct ohci_driver_overrides. -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than relying on ohci_hub_control and hub_status_data being exported. -ohci_setup() has been removed because it is called in .reset member of the ohci_hc_driver structure. diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index e4dc9ab..0b7b0f7 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -390,6 +390,14 @@ config USB_OHCI_HCD_SPEAR Enables support for the on-chip OHCI controller on ST SPEAr chips. +config USB_OHCI_HCD_S3C +tristate Support for S3C on-chip OHCI USB controller +depends on USB_OHCI_HCD (ARCH_S3C24XX) || (ARCH_S3C64XX) The use of parentheses here is wrong. +static int (*orig_ohci_hub_control)(struct usb_hcd *hcd, u16 typeReq, u16 wValue, +u16 wIndex, char *buf, u16 wLength); Avoid having more than 80 columns in a line. @@ -371,10 +388,9 @@ static int usb_hcd_s3c2410_probe(const struct hc_driver *driver, goto err_put; } + ohci_setup(hcd); s3c2410_start_hc(dev, hcd); I thought this patch was supposed to get rid of the call to ohci_setup()? 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: question about USB interface probe order and synchronization
On Wed, Jun 19, 2013 at 03:33:51PM -0500, Thomas Pugliese wrote: Hi, I am attempting to debug a problem where the hwa_hc module occasionally fails to start correctly when an HWA device is plugged in. An HWA device consists of two USB interfaces each with its own driver: the radio control interface (hwa_rc.ko), and the host controller interface (hwa_hc.ko). Both of these modules depend on a common subcomponent (uwb.ko) but they do not depend directly on each other as far as depmod is concerned. Why don't we just build them both together, as they aren't ever used separately, right? Would that solve your issue? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] usb: phy: tegra: remove duplicated include from phy-tegra-usb.c
From: Wei Yongjun yongjun_...@trendmicro.com.cn Remove duplicated include. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn --- drivers/usb/phy/phy-tegra-usb.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c index 3446245..cec0855 100644 --- a/drivers/usb/phy/phy-tegra-usb.c +++ b/drivers/usb/phy/phy-tegra-usb.c @@ -34,7 +34,6 @@ #include asm/mach-types.h #include linux/usb/ehci_def.h #include linux/usb/tegra_usb_phy.h -#include linux/module.h #define ULPI_VIEWPORT 0x170 -- 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: initialize or shutdown PHY when add or remove host controller
On Wed, Jun 19, 2013 at 3:51 PM, Roger Quadros rog...@ti.com wrote:
Hi Chao,
On 06/19/2013 05:31 AM, Chao Xie wrote:
Some controller need software to initialize PHY before add
host controller, and shut down PHY after remove host controller.
Add the generic code for these controllers so they do not need
do it in its own host controller driver.
Signed-off-by: Chao Xie chao@marvell.com
---
drivers/usb/core/hcd.c | 24 +++-
1 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index d53547d..301c639 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -40,9 +40,11 @@
#include linux/platform_device.h
#include linux/workqueue.h
#include linux/pm_runtime.h
+#include linux/err.h
#include linux/usb.h
#include linux/usb/hcd.h
+#include linux/usb/phy.h
#include usb.h
@@ -2531,12 +2533,26 @@ int usb_add_hcd(struct usb_hcd *hcd,
*/
set_bit(HCD_FLAG_RH_RUNNING, hcd-flags);
+ /* In case hcd-phy contains the error code. */
+ if (IS_ERR(hcd-phy))
+ hcd-phy = NULL;
+
+ /* Initialize the PHY before other hardware operation. */
+ if (hcd-phy) {
+ retval = usb_phy_init(hcd-phy);
+ if (retval) {
+ dev_err(hcd-self.controller,
+ can't initialize phy\n);
+ goto err_hcd_driver_setup;
+ }
+ }
+
/* reset is misnamed; its role is now one-time init. the controller
* should already have been reset (and boot firmware kicked off etc).
*/
if (hcd-driver-reset (retval = hcd-driver-reset(hcd)) 0) {
dev_err(hcd-self.controller, can't setup\n);
- goto err_hcd_driver_setup;
+ goto err_hcd_driver_init_phy;
}
hcd-rh_pollable = 1;
@@ -2608,6 +2624,9 @@ err_hcd_driver_start:
if (usb_hcd_is_primary_hcd(hcd) hcd-irq 0)
free_irq(irqnum, hcd);
err_request_irq:
+err_hcd_driver_init_phy:
+ if (hcd-phy)
+ usb_phy_shutdown(hcd-phy);
err_hcd_driver_setup:
err_set_rh_speed:
usb_put_dev(hcd-self.root_hub);
@@ -2674,6 +2693,9 @@ void usb_remove_hcd(struct usb_hcd *hcd)
free_irq(hcd-irq, hcd);
}
+ if (hcd-phy)
+ usb_phy_shutdown(hcd-phy);
+
usb_put_dev(hcd-self.root_hub);
usb_deregister_bus(hcd-self);
hcd_buffer_destroy(hcd);
I still think that we shouldn't do this because it adds more confusion and is
not
still a generic enough solution.
1) It is better for the piece of code that does usb_phy_get() to do
usb_phy_init/shutdown,
else there will be lot of confusion. (Felipe pointed this out earlier).
2) There is no standard way of getting phy for different controllers. It is
mostly platform
dependent and it is best to leave this to the controller drivers. (Pointed
out by Alan).
3) Controllers can have multiple PHYs. e.g. ehci-omap has one PHY per port
and it supports
3 ports. This is also platform specific and difficult to handle generically.
4) Controllers can have specific timing requirements as to when the PHY is
initialized relative
to the controller being initialized. I've pointed OMAP specific stuff in the
earlier patch.
Considering all these points, I think we should leave things as they are. It
isn't that hard
for controllers to manage phy_init() and phy_shutdown(), and there is not
much code space saved
when compared to the complexity it creates if we move them to HCD layer.
In fact, the PHY setting and handling is related to platform or SOC,
and for different SOC they can
have same EHCI HCD but they PHY handling can be different.
Omap'a case is the example, and i think some other vendors may have
silimar cases.
From above point, It is better to leave the PHY initialization and
shutdown to be done by each echi-xxx driver.
So Alan and Felipe
What are your ideas about it?
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: [RFC PATCH v1 1/6] USB: HCD: support giveback of URB in tasklet context
On Wed, Jun 19, 2013 at 11:37 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 19 Jun 2013, Ming Lei wrote:
@@ -835,9 +839,11 @@ static int usb_rh_urb_dequeue(struct usb_hcd *hcd,
struct urb *urb, int status)
hcd-status_urb = NULL;
usb_hcd_unlink_urb_from_ep(hcd, urb);
- spin_unlock(hcd_root_hub_lock);
+ if (!hcd_giveback_urb_in_bh(hcd))
+ spin_unlock(hcd_root_hub_lock);
usb_hcd_giveback_urb(hcd, urb, status);
- spin_lock(hcd_root_hub_lock);
+ if (!hcd_giveback_urb_in_bh(hcd))
+ spin_lock(hcd_root_hub_lock);
}
}
done:
None of these tests are necessary. Root hubs are different from normal
devices; their URBs are handled mostly by usbcore. The only part done
by the HCD is always synchronous. And we know that root-hub URBs
Looks not always synchronous, control transfer is synchronous, and
interrupt transfer is still asynchronous. No drivers(hub, usbfs) depend
on that, and IMO, treating root hub same as hub will simplify HCD core,
and finally we can remove all the above lock releasing acquiring if
all HCDs set HCD_BH.
Also there is very less roothub transfers and always letting tasklet
handle URB giveback of roothub won't have performance problem, so
how about keeping the above tests?
If you want to use the tasklets for root-hub URBs, okay. There's no
reason to check the HCD_BH flag, though, because HCDs have only minimal
involvement in root-hub URBs. In particular, HCD's don't call
usb_hcd_giveback_urb() for them.
Looks both root hub's control and interrupt transfer call usb_hcd_giveback_urb()
to complete URBs, don't they?
So you can use the tasklets for _all_ root-hub URBs. Then the tests
above aren't necessary, and neither are the spinlock operations.
Yes, that is what I am going to do.
@@ -2573,6 +2687,16 @@ int usb_add_hcd(struct usb_hcd *hcd,
device_can_wakeup(hcd-self.root_hub-dev))
dev_dbg(hcd-self.controller, supports USB remote
wakeup\n);
+ if (usb_hcd_is_primary_hcd(hcd)) {
+ retval = init_giveback_urb_bh(hcd);
+ if (retval)
+ goto err_init_giveback_bh;
+ } else {
+ /* share tasklet handling with primary hcd */
+ hcd-async_bh = hcd-primary_hcd-async_bh;
+ hcd-periodic_bh = hcd-primary_hcd-periodic_bh;
+ }
Is there any reason why a secondary HCD can't have its own tasklets?
I didn't do that because both primary and secondary HCDs share one
hard interrupt handler, so basically there is no obvious advantage to
do that.
If the bh structures are embedded directly in the hcd structure, it
won't be possible for a secondary hcd to share its tasklets with the
primary hcd. Not sharing seems simpler, and there's no obvious
disadvantage either.
OK, I will let secondary HCD have its own tasklet in v2.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 4/6] USB: EHCI: don't release ehci-lock if URB giveback in tasklet context
On Wed, Jun 19, 2013 at 11:47 PM, Alan Stern st...@rowland.harvard.edu wrote: On Wed, 19 Jun 2013, Ming Lei wrote: On Wed, Jun 19, 2013 at 12:43 AM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 18 Jun 2013, Ming Lei wrote: If HCD_BH is set for HC driver's flags, URB giveback will be done in tasklet context instead of interrupt context, so the ehci-lock needn't to be released any more before calling usb_hcd_giveback_urb(). It is premature to do this now. This should be part of the 6/6 patch, It is fine since HCD_BH isn't enabled. It's not fine. It will work -- nothing will crash -- but that doesn't mean it is good style. when it won't be necessary to test hcd_giveback_urb_in_bh(). Keeping it is easy to compare test results between running complete() in tasklet and in hard irq handler. It's just as easy to do your tests by keeping two copies of ehci-hcd.ko lying around; one with your changes and one without. You can insmod whichever one you want to test. Also it might be helpful for out of tree drivers. But it isn't a big deal, I can merge it to 6/6 if you care. Yes, please. OK. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/6] USB: OHCI: make ohci-exynos a separate driver
On Thursday, June 13, 2013 12:54 AM, Manjunath Goudar wrote: Separate the Samsung OHCI EXYNOS host controller driver from ohci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM; it would be nice to have in 3.11. V2: -exynos_ohci_hcd structure assignment error fixed. -Removed multiple usb_create_hcd() from prob funtion. -platform_set_drvdata() called before exynos_ohci_phy_enable(). -ohci_setup() removed because it is called in .reset member of the ohci_hc_driver structure Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org Cc: Arnd Bergmann a...@arndb.de Cc: Jingoo Han jg1@samsung.com Cc: Kukjin Kim kgene@samsung.com Cc: Greg KH g...@kroah.com Cc: Alan Stern st...@rowland.harvard.edu Cc: linux-usb@vger.kernel.org --- drivers/usb/host/Kconfig |2 +- drivers/usb/host/Makefile |1 + drivers/usb/host/ohci-exynos.c | 167 +--- drivers/usb/host/ohci-hcd.c| 18 - 4 files changed, 71 insertions(+), 117 deletions(-) CC'ed Vivek Gautam Hi Manjunath Goudar, It looks good. I tested this patch on Exynos4210. It works properly. I really appreciate your work. Acked-by: Jingoo Han jg1@samsung.com Also, I agree on Alan's opinion. +#define DRIVER_DESC OHCI exynos driver Please, replace 'exynos' with 'EXYNOS'. Best regards, Jingoo Han -- 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 1/1] usb: fix build error without CONFIG_USB_PHY
On 06/19/13 00:20, Peter Chen wrote:
on i386:
drivers/built-in.o: In function `ci_hdrc_probe':
core.c:(.text+0x20446b): undefined reference to `of_usb_get_phy_mode'
Signed-off-by: Peter Chen peter.c...@freescale.com
Reported-by: Randy Dunlap rdun...@infradead.org
Acked-by: Randy Dunlap rdun...@infradead.org
Thanks.
---
Changes for v2:
- Using IS_ENABLED to MACRO define
include/linux/usb/of.h | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
index e460a24..a0ef405 100644
--- a/include/linux/usb/of.h
+++ b/include/linux/usb/of.h
@@ -10,19 +10,23 @@
#include linux/usb/otg.h
#include linux/usb/phy.h
-#ifdef CONFIG_OF
-enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
+#if IS_ENABLED(CONFIG_OF)
enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np);
#else
-static inline enum usb_phy_interface of_usb_get_phy_mode(struct device_node
*np)
+static inline enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np)
{
- return USBPHY_INTERFACE_MODE_UNKNOWN;
+ return USB_DR_MODE_UNKNOWN;
}
+#endif
-static inline enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np)
+#if IS_ENABLED(CONFIG_OF) IS_ENABLED(CONFIG_USB_PHY)
+enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
+#else
+static inline enum usb_phy_interface of_usb_get_phy_mode(struct device_node
*np)
{
- return USB_DR_MODE_UNKNOWN;
+ return USBPHY_INTERFACE_MODE_UNKNOWN;
}
+
#endif
#endif /* __LINUX_USB_OF_H */
--
~Randy
--
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 v7 1/9] drivers: phy: add generic PHY framework
Hi,
On Wednesday 19 June 2013 09:19 PM, Sylwester Nawrocki wrote:
Hi,
On 06/13/2013 10:43 AM, Kishon Vijay Abraham I wrote:
+/**
+ * phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ * @priv: private data from phy driver
+ *
+ * Called to create a phy using phy framework.
+ */
+struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
+ const char *label, void *priv)
+{
+ int ret;
+ struct phy *phy;
+
+ if (!dev) {
+ dev_WARN(dev, no device provided for PHY\n);
+ ret = -EINVAL;
+ goto err0;
+ }
+
+ phy = kzalloc(sizeof(*phy), GFP_KERNEL);
+ if (!phy) {
+ ret = -ENOMEM;
+ goto err0;
+ }
+
+ device_initialize(phy-dev);
+
+ phy-dev.class = phy_class;
+ phy-dev.parent = dev;
+ phy-dev.of_node = dev-of_node;
+ phy-id = id;
+ phy-ops = ops;
+ phy-label = label;
Perhaps we could make it:
phy-label = kstrdup(label, GFP_KERNEL);
and free the label in phy_destroy() ?
yeah.. Fixed.
That way the users would't need to keep the label around. It might
be useful when PHY provider generates the labels dynamically. I guess
it is OK for PHY providers to hard code the labels and having the PHY
user drivers passed labels in platform data ?
yeah. But the only concern here is there is no way to enforce the
labels are passed in platform data. The PHY user driver can also
hard code the labels while getting the reference to the PHY and we can
catch such cases only by review.
+ dev_set_drvdata(phy-dev, priv);
+
+ ret = dev_set_name(phy-dev, %s.%d, dev_name(dev), id);
+ if (ret)
+ goto err1;
+
+ ret = device_add(phy-dev);
+ if (ret)
+ goto err1;
+
+ if (pm_runtime_enabled(dev))
+ pm_runtime_enable(phy-dev);
+
+ return phy;
+
+err1:
+ put_device(phy-dev);
+ kfree(phy);
+
+err0:
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(phy_create);
+/**
+ * phy_destroy() - destroy the phy
+ * @phy: the phy to be destroyed
+ *
+ * Called to destroy the phy.
+ */
+void phy_destroy(struct phy *phy)
+{
+ pm_runtime_disable(phy-dev);
+ device_unregister(phy-dev);
Isn't kfree(phy); missing here ?
Not actually. Its done in phy_release (class's dev_release method)
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: Detecting start/stop streaming for UVC webcam with bulk transfer mode
Hi Laurent, Thanks for your mail, On Tue, Jun 18, 2013 at 6:12 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Chetan, On Tuesday 18 June 2013 11:17:40 Chetan Nanda wrote: Hi, I am currently working with UVC camera device which send data using bulk transfer for preview and capture. I have modified UVC gadget driver to start bulk streaming on receiving first UVC_VS_COMMIT_CONTROL request from host side. But currently not able to detect when to stop the streaming. I am running Cheese Application on host side to test start/stop streaming. UVC gadget driver's 'uvc_function_set_alt' function is getting called when closing the cheese application, but this function is also (sometime) getting called when starting the cheese application on HOST side, also some time this function gets called after receiving first COMMIT_CONTROL. So, currently I am not able to find a proper way for starting / stopping streaming for UVC bulk transfer. Anyone has successfully implemented the start/stop streaming usecase for bulk mode? That's in my opinion one of the shortcomings of the UVC specification. There is no explicit way to start streaming on bulk endpoints. One option would be to start streaming when receiving the first IN token on the bulk endpoint, and to stop streaming when no bulk activity has been detected for a given amount of time. A bit hackish, but I'm not sure if there's any other practical way. We are using DWC3 usb device controller and tried to look into the dwc3 driver code to check a place where we can identify first IN token from HOST side. I tried modify 'dwc3_endpoint_interrupt' function in file 'drivers/usb/dwc3/gadget.c' in case 'case DWC3_DEPEVT_XFERNOTREADY:' to start streaming for the first time when this case hit. I am not sure if this is the right place for this, I will dig more into the DWC3 spec and code. Any pointer would be very helpful. -- Regards, Laurent Pinchart Thanks, Chetan Nanda -- 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
