Re: [PATCH 1/1] usb: fix build error without CONFIG_USB_PHY

[Peter Chen]

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 
> > ---
> >  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 
> >  
> >  #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

[Tomi Valkeinen]

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

[Jiri Slaby]

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

[victor yeo]

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

[Tomi Valkeinen]

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

[Peter Chen]

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 
---
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 
 #include 
 
-#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

[Roger Quadros]

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 
> ---
>  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 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> +#include 
>  
>  #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

[Kishon Vijay Abraham I]

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 
Acked-by: Felipe Balbi 
Tested-by: Tomi Valkeinen 
---
 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),
ZOOM_NAND_CS, 

[PATCH 3/4] usb: musb: omap: use the new API to get PHY reference by label

[Kishon Vijay Abraham I]

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 
Acked-by: Felipe Balbi 
Tested-by: Tomi Valkeinen 
---
 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

[Kishon Vijay Abraham I]

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 
Acked-by: Felipe Balbi 
Tested-by: Tomi Valkeinen 
---
 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

[Kishon Vijay Abraham I]

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

[Kishon Vijay Abraham I]

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 
Acked-by: Felipe Balbi 
Tested-by: Tomi Valkeinen 
---
 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;

[Administrador do Sistema]

-- 
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

[Boris BREZILLON]

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.

Signed-off-by: Boris BREZILLON 
---
 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

[Arnd Bergmann]

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 
Cc: Felipe Balbi 
Cc: Nicolas Ferre 

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;

[Administrador do Sistema]

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

[Ming Lei]

On Wed, Jun 19, 2013 at 10:59 AM, Ming Lei  wrote:
> On Wed, Jun 19, 2013 at 12:05 AM, Alan Stern  
> 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

[Manjunath Goudar]

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

[Manjunath Goudar]

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 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
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

[Manjunath Goudar]

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 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
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

[Manjunath Goudar]

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 
Acked-by: Alan Stern 
Cc: Arnd Bergmann 
Cc: Greg KH 
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

[Manjunath Goudar]

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 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
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

[Manjunath Goudar]

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 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
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

[Boris BREZILLON]

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.

Signed-off-by: Boris BREZILLON 
---
 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

[Manjunath Goudar]

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 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
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

[Manjunath Goudar]

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 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
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

[Manjunath Goudar]

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 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
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

[Manjunath Goudar]

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 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
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

[Manjunath Goudar]

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 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
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

[Manjunath Goudar]

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 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
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

[Emil Goode]

This patch adds missing unlocks on error paths in the
xhci_free_streams and xhci_configure_endpoint functions.

Signed-off-by: Emil Goode 
---
 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

[Joseph CHANG]

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 
---
 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 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* 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 (1<<0)
+#define DM_NCR_WAKEEN  (1<<6)
+
+#define DM_FCR_TXPEN   (1<<5)
+#define DM_FCR_BKPM(1<<3)
+#define DM_FCR_FLCE(1<<0)
+
+#define DMSC_WEP   (1<<4)
+#define DMSC_ERPRW (1<<1)
+#define DMSC_ERRE  (1<<0)
+
+#define DM_LINKEN  (1<<5)
+#define DM_MAGICEN (1<<3)
+
+#define DM_TX_UDPCSE   (1<<2)
+#define DM_TX_TCPCSE   (1<<1)
+#define DM_TX_IPCSE(1<<0)
+#define DM_RX_RCSEN(1<<1)
+#define DM_MODE_DM_TXRX(0<<4)
+#define DM_MODE_CDC_TRX(1<<4)
+#define DM_MODE_DM_DESC(0<<5)
+#define DM_MODE_CDC_DES(1<<5)
+
+#define DM_USB_EP3ACK  (1<<5)
+
+#define DM_MODE9601(0<<7)
+#define DM_MODE9620(1<<7)
+#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,
+  USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+  0, reg, data, length);
+   if (err != length && err >= 0)
+

[PATCH 7/8] USB: ohci-at91: prepare clk before calling enable

[Boris BREZILLON]

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.

Signed-off-by: Boris BREZILLON 
---
 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

[Sergei Shtylyov]

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 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
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 06/11] USB: OHCI: Properly handle ohci-exynos suspend

[Sergei Shtylyov]

On 19-06-2013 16:12, Manjunath Goudar wrote:


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 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
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;


   Sigh, here there was no any alignment of variable names, why you 
aligned your variables? Doing everything with the single template? :-)


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 08/11] USB: OHCI: Properly handle ohci-platform suspend

[Sergei Shtylyov]

On 19-06-2013 16:12, Manjunath Goudar wrote:


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 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
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);


   Again, the above variables weren't aligned. I bet you were just 
cut-and-pasting the same code without looking... :-/



+   booldo_wakeup = device_may_wakeup(dev);
+   int ret;


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

[Sergei Shtylyov]

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 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
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

[Sergei Shtylyov]

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 
Cc: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg KH 
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

[Andi Shyti]

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: pack

[RFC PATCH 5/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host

[Roger Quadros]

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 
Signed-off-by: Roger Quadros 
---
 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

[Roger Quadros]

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 
---
 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

[Roger Quadros]

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 
---
 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 
 #include 
 #include 
+#include 
+#include 
 
 #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

[Roger Quadros]

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 3/6] USB: ehci: allow controller drivers to override irq & bus_suspend/resume

[Roger Quadros]

Some drivers (e.g. ehci_omap) need to do additional work in
bus suspend/resume and interrupt handler to support low power
modes and remote wakeup.
Allow drivers to override these functions through ehci_driver_overrides.

Also export the ehci_irq(), ehci_bus_suspend() and ehci_bus_resume()
functions so they can be called from the controller drivers.

CC: Alan Stern 
Signed-off-by: Roger Quadros 
---
 drivers/usb/host/ehci-hcd.c |9 -
 drivers/usb/host/ehci-hub.c |6 --
 drivers/usb/host/ehci.h |6 ++
 3 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 246e124..8d35dd4 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -681,7 +681,7 @@ EXPORT_SYMBOL_GPL(ehci_setup);
 
 /*-*/
 
-static irqreturn_t ehci_irq (struct usb_hcd *hcd)
+irqreturn_t ehci_irq(struct usb_hcd *hcd)
 {
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
u32 status, masked_status, pcd_status = 0, cmd;
@@ -828,6 +828,7 @@ dead:
usb_hcd_poll_rh_status(hcd);
return IRQ_HANDLED;
 }
+EXPORT_SYMBOL_GPL(ehci_irq);
 
 /*-*/
 
@@ -1211,6 +1212,12 @@ void ehci_init_driver(struct hc_driver *drv,
drv->hcd_priv_size += over->extra_priv_size;
if (over->reset)
drv->reset = over->reset;
+   if (over->bus_suspend)
+   drv->bus_suspend = over->bus_suspend;
+   if (over->bus_resume)
+   drv->bus_resume = over->bus_resume;
+   if (over->irq)
+   drv->irq = over->irq;
}
 }
 EXPORT_SYMBOL_GPL(ehci_init_driver);
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 9ab4a4d..1fc03f9 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -218,7 +218,7 @@ static void ehci_adjust_port_wakeup_flags(struct ehci_hcd 
*ehci,
spin_unlock_irq(&ehci->lock);
 }
 
-static int ehci_bus_suspend (struct usb_hcd *hcd)
+int ehci_bus_suspend(struct usb_hcd *hcd)
 {
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
int port;
@@ -348,10 +348,11 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
hrtimer_cancel(&ehci->hrtimer);
return 0;
 }
+EXPORT_SYMBOL_GPL(ehci_bus_suspend);
 
 
 /* caller has locked the root hub, and should reset/reinit on error */
-static int ehci_bus_resume (struct usb_hcd *hcd)
+int ehci_bus_resume(struct usb_hcd *hcd)
 {
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
u32 temp;
@@ -489,6 +490,7 @@ static int ehci_bus_resume (struct usb_hcd *hcd)
spin_unlock_irq(&ehci->lock);
return -ESHUTDOWN;
 }
+EXPORT_SYMBOL_GPL(ehci_bus_resume);
 
 #else
 
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 7c978b2..992d626 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -795,15 +795,21 @@ static inline u32 hc32_to_cpup (const struct ehci_hcd 
*ehci, const __hc32 *x)
 struct ehci_driver_overrides {
size_t  extra_priv_size;
int (*reset)(struct usb_hcd *hcd);
+   int (*bus_suspend)(struct usb_hcd *hcd);
+   int (*bus_resume)(struct usb_hcd *hcd);
+   irqreturn_t (*irq) (struct usb_hcd *hcd);
 };
 
 extern voidehci_init_driver(struct hc_driver *drv,
const struct ehci_driver_overrides *over);
 extern int ehci_setup(struct usb_hcd *hcd);
+extern irqreturn_t ehci_irq(struct usb_hcd *hcd);
 
 #ifdef CONFIG_PM
 extern int ehci_suspend(struct usb_hcd *hcd, bool do_wakeup);
 extern int ehci_resume(struct usb_hcd *hcd, bool hibernated);
+extern int ehci_bus_suspend(struct usb_hcd *hcd);
+extern int ehci_bus_resume(struct usb_hcd *hcd);
 #endif /* CONFIG_PM */
 
 #endif /* __LINUX_EHCI_HCD_H */
-- 
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

[Roger Quadros]

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 
Signed-off-by: Roger Quadros 
---
 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 
 #include 
 #include 
+#include 
 
 #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()

[Roger Quadros]

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 
Signed-off-by: Roger Quadros 
---
 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

[Kukjin Kim]

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 Figa

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

[Tomasz Figa]

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 Figa
> > 
> > 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] build some drivers only when compile-testing

[Greg Kroah-Hartman]

On Wed, Jun 19, 2013 at 09:12:56AM +0200, 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)

Ah, what about all of the chipidea chips on x86 boxes (yes, they are
rare, but they are present, so you can't just turn them off for that
whole platform here.

I'd leave chipidea alone, it's getting more prelevant, not on a desktop
or server, but in SoC systems, which is x86 for a lot of devices.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/7] clk: samsung: Add clock driver for S3C64xx SoCs

[Kukjin Kim]

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 Turquette


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

[Viresh Kumar]

On 19 June 2013 20:12, Manjunath Goudar  wrote:
> On 19 June 2013 18:13, Sergei Shtylyov 
>> 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

[Mathias Nyman]

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

[Alan Stern]

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

[Alan Stern]

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

[Ming Lei]

Hi,

Thanks for your reply.

On Wed, Jun 19, 2013 at 11:17 PM, Alan Stern  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()

[Alan Stern]

On Wed, 19 Jun 2013, Ming Lei wrote:

> On Wed, Jun 19, 2013 at 12:36 AM, Alan Stern  
> 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

[Sebastian Andrzej Siewior]

Add a dma_controller_create() returning NULL so a few ifdefs can
dropped.

Signed-off-by: Sebastian Andrzej Siewior 
---
 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

[Alan Stern]

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()

[Sebastian Andrzej Siewior]

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 
---
 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

[Sebastian Andrzej Siewior]

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

[Sebastian Andrzej Siewior]

The ifdef reads somehow better than an ifndef

Signed-off-by: Sebastian Andrzej Siewior 
---
 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

[Sebastian Andrzej Siewior]

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 
---
 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

[Sebastian Andrzej Siewior]

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 
---
 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

[Sebastian Andrzej Siewior]

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 
---
 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

[Sebastian Andrzej Siewior]

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 
---
 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
/* 

[PATCH 8/8] usb: musb: omap2430: make it compile again

[Sebastian Andrzej Siewior]

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 
---
 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

[Alan Stern]

On Wed, 19 Jun 2013, Ming Lei wrote:

> On Wed, Jun 19, 2013 at 12:43 AM, Alan Stern  
> 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

[Sylwester Nawrocki]

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

[Alan Stern]

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

[Alan Stern]

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

[Mark Brown]

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

[Kevin Hilman]

Hi Roger,

Roger Quadros  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 
> Signed-off-by: Roger Quadros 

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

[Sebastian Andrzej Siewior]

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

[Sergei Shtylyov]

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 
---
  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

[Sergei Shtylyov]

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 mailto:manjunath.gou...@linaro.org>>
Cc: Arnd Bergmann mailto:a...@arndb.de>>
Cc: Alan Stern mailto:st...@rowland.harvard.edu>>
Cc: Greg KH mailto: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



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

[Kevin Hilman]

Hi Roger,

Roger Quadros  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

[Kevin Hilman]

Roger Quadros  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 
> Signed-off-by: Roger Quadros 

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?

[Alan Stern]

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

[Paul Gortmaker]

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

[Alan Stern]

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

[Thomas Pugliese]

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

[Alan Stern]

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

[Greg KH]

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

[Wei Yongjun]

From: Wei Yongjun 

Remove duplicated include.

Signed-off-by: Wei Yongjun 
---
 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 
 #include 
 #include 
-#include 
 
 #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

[Chao Xie]

On Wed, Jun 19, 2013 at 3:51 PM, Roger Quadros  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 
>> ---
>>  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 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  #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

[Ming Lei]

On Wed, Jun 19, 2013 at 11:37 PM, Alan Stern  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

[Ming Lei]

On Wed, Jun 19, 2013 at 11:47 PM, Alan Stern  wrote:
> On Wed, 19 Jun 2013, Ming Lei wrote:
>
>> On Wed, Jun 19, 2013 at 12:43 AM, Alan Stern  
>> 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

[Jingoo Han]

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 
> Cc: Arnd Bergmann 
> Cc: Jingoo Han 
> Cc: Kukjin Kim 
> Cc: Greg KH 
> Cc: Alan Stern 
> 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 


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

[Randy Dunlap]

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 

Reported-by: Randy Dunlap 
Acked-by: Randy Dunlap 

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 
>  #include 
>  
> -#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

[Kishon Vijay Abraham I]

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

[Chetan Nanda]

Hi Laurent,

Thanks for your mail,

On Tue, Jun 18, 2013 at 6:12 PM, Laurent Pinchart
 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

Re: [RFC PATCH v1 5/6] USB: EHCI: improve interrupt qh unlink

[Ming Lei]

On Wed, Jun 19, 2013 at 11:44 PM, Alan Stern  wrote:
> 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

Here the meaning of intr qh's QH_STATE_UNLINK_WAIT is a bit different
with async qh's.

> 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.

Yes, that is the difference with async QH.

>
> I think you should copy the approach used for the async QHs.

Yes, we can copy, but current async unlinking has some disadvantages,
see below.

>> 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.

IMO, there is no any side effect when we change the state to
QH_STATE_UNLINK_WAIT and later change back to QH_STATE_LINKED
later under this situation.

The reason why I use QH_STATE_UNLINK_WAIT here is for avoiding
unnecessary CPU wakeup.  Without the state, the unlink wait timer
is still triggered to check if there are intr QHs to be unlinked, but in most of
situations, there aren't QHs to be unlinked since tasklet is surely run
before the wait timer is expired. So generally, without knowing the wait state,
CPU wakeup events may be introduced unnecessarily.

Considered that the interval of interrupt endpoint might be very
small(e.g. 125us,
1ms) and some devices have very frequent intr event, I think we
need to pay attention to the problem.

Even on async QH situation, we might need to consider the problem too
since some application(eg. bulk only mass storage on xhci) may have
thousands of interrupts per seconds during data transfer, so CPU wakeup
events could be increased much by letting wait timer expire unnecessarily.

Also the async QH unlink approach has another disadvantage:

- if there are several QHs which are become empty during one wait period,
the hrtimer has to be scheduled several times for starting unlink one qh
each time. And after introducing the unlink wait list like the patch, we only
need schedule the hrtimer one time for unlinking all these empty QHs.

Finally, unlink wait for intr qh is only needed when the qh is completed
right now, and other cases(eg. unlink) needn't the wait.

The attached patch removes the QH_STATE_UNLINK_WAIT, and can
avoid the above disadvantages of async QH unlink, could you comment
on the new patch?

---
 drivers/usb/host/ehci-hcd.c   |8 +++---
 drivers/usb/host/ehci-hub.c   |1 +
 drivers/usb/host/ehci-sched.c |   54 ++---
 drivers/usb/host/ehci-timer.c |   45 +-
 drivers/usb/host/ehci.h   |3 +++
 5 files changed, 103 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 246e124..35b4148 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -304,7 +304,8 @@ static void end_unlink_async(struct ehci_hcd *ehci);
 static void unlink_empty_async(struct ehci_hcd *ehci);
 static void unlink_empty_async_suspended(struct ehci_hcd *ehci);
 static void ehci_work(struct ehci_hcd *ehci);
-static void start_unlink_intr(struct ehci_hcd *ehci, struct ehci_qh *qh);
+static void start_unlink_intr(struct ehci_hcd *ehci, struct ehci_qh *qh,
+ bool wait);
 static void end_unlink_intr(struct ehci_hcd *ehci, struct ehci_qh *qh);

 #include "ehci-timer.c"
@@ -484,6 +485,7 @@ static int ehci_init(struct usb_hcd *hcd)
ehci->periodic_size = DEFAULT_I_TDPS;
INIT_LIST_HEAD(&ehci->async_unlink);
INIT_LIST_HEAD(&ehci->async_idle);
+   INIT_LIST_HEAD(&ehci->i