date:20130220

On Tue, 19 Feb 2013, Dâniel Fraga wrote:

 https://bugzilla.kernel.org/show_bug.cgi?id=54111
 
   Posting this regression here as suggested by Greg Kroah-Hartman.
 
   After upgrading from kernel 3.7.0 to 3.8.0, the
 USB devices (keyboard, mouse etc) will not work at all. My motherboard
 is an Asus P8Z68-V PRO/GEN3 and I am NOT using USB 3.0 because I don't
 have any USB 3.0 device.
 
 First, here it's the options used in 3.7.0 and 3.8.0:

...

 CONFIG_USB_EHCI_HCD=m
 CONFIG_USB_EHCI_PCI=m

 
   I attached the 3.8.0 kernel log output. If you need more
 information just ask. I just can't test it when booting into 3.8.0
 because the keyboard/mouse will not work. But I can test patches if you
 want. Thanks.

...

 And lsmod | grep usb:

The important module does not contain usb in its name.  :-(

Probably this is not a bug at all, but simply a failure to load the 
ehci-pci module.  If the USB modules are loaded from your initramsfs 
image, make sure that the image contains the ehci-pci.ko file.

Alan Stern

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

Re: [PATCH] xhci - clarify compliance mode debug messages

2013-02-20 Thread Tony Camuso


On 02/20/2013 10:15 AM, Alan Stern wrote:

On Tue, 19 Feb 2013, Sarah Sharp wrote:


The one thing I wanted to check was my understanding of the hibernate
flow path.  As you mentioned, I thought that xhci_suspend would be
called in the hibernate path, but it's not.


Are you sure about that?  AFAICT it should be called -- although it
gets called during the poweroff phase of hibernation, not the freeze
phase.

core/hcd-pci.c: usb_hcd_pci_pm_ops.poweroff = hcd_pci_suspend
core/hcd-pci.c: hcd_pci_suspend calls suspend_common
core/hcd-pci.c: suspend_common calls hcd-driver-pci_suspend
host/xhci-pci.c: xhci_pci_hc_driver.pci_suspend = xhci_pci_suspend
host/xhci-pci.c: xhci_pci_suspend calls xhci_suspend


We instrumented the code, and when invoking pm-hibernate, we did
not flow through xhci_suspend(), where the timer is deleted.



This should not be necessary.



System was crashing on resume-from-hibernate. Not crashing with
the patch.



--
To unsubscribe from this list: send the line unsubscribe 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] xhci - clarify compliance mode debug messages

On Wed, 20 Feb 2013, Tony Camuso wrote:

 On 02/20/2013 10:15 AM, Alan Stern wrote:
  On Tue, 19 Feb 2013, Sarah Sharp wrote:
 
  The one thing I wanted to check was my understanding of the hibernate
  flow path.  As you mentioned, I thought that xhci_suspend would be
  called in the hibernate path, but it's not.
 
  Are you sure about that?  AFAICT it should be called -- although it
  gets called during the poweroff phase of hibernation, not the freeze
  phase.
 
  core/hcd-pci.c: usb_hcd_pci_pm_ops.poweroff = hcd_pci_suspend
  core/hcd-pci.c: hcd_pci_suspend calls suspend_common
  core/hcd-pci.c: suspend_common calls hcd-driver-pci_suspend
  host/xhci-pci.c: xhci_pci_hc_driver.pci_suspend = xhci_pci_suspend
  host/xhci-pci.c: xhci_pci_suspend calls xhci_suspend
 
 We instrumented the code, and when invoking pm-hibernate, we did
 not flow through xhci_suspend(), where the timer is deleted.

If you instrumented the code then you ought to know how the actual 
behavior differs from what I outlined above.  Where is the difference?

  This should not be necessary.
 
 
 System was crashing on resume-from-hibernate. Not crashing with
 the patch.

You misunderstood.  I didn't mean that no changes were necessary; I 
meant that it shouldn't be necessary to search for some obscure 
function that gets called on both the suspend hibernation pathways.

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 2/2] USB: EHCI: make ehci-orion a separate driver

On Fri, 15 Feb 2013, Arnd Bergmann wrote:

 From: Manjunath Goudar manjunath.gou...@linaro.org
 
 With the multiplatform changes in arm-soc tree, it becomes
 possible to enable the mvebu platform (which uses
 ehci-orion) at the same time as other platforms that require
 a conflicting EHCI bus glue. At the moment, this results
 in a warning like
 
 drivers/usb/host/ehci-hcd.c:1297:0: warning: PLATFORM_DRIVER redefined 
 [enabled by default]
 drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the 
 previous definition
 drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined 
 but not used [-Wunused-variable]
 
 and an ehci driver that only works on one of them.
 
 With the infrastructure added by Alan Stern in patch 3e0232039
 USB: EHCI: prepare to make ehci-hcd a library module, we can
 avoid this problem by turning a bus glue into a separate
 module, as we do here for the orion bus glue.

One more comment on this patch...

 --- a/drivers/usb/host/Kconfig
 +++ b/drivers/usb/host/Kconfig
 @@ -162,6 +162,14 @@ config USB_EHCI_HCD_OMAP
 Enables support for the on-chip EHCI controller on
 OMAP3 and later chips.
  
 +config USB_EHCI_HCD_ORION
 +tristate  Support for Marvell Orion on-chip EHCI USB controller
 +depends on USB_EHCI_HCD  PLAT_ORION
 +default y
 +---help---
 +  Enables support for the on-chip EHCI controller on
 +  Morvell Orion chips.

Currently there is no Kconfig option to control specifically whether
the ehci-orion driver gets built; it always gets built whenever
CONFIG_PLAT_ORION and CONFIG_USB_EHCI_HCD are both enabled.

Do you think it is a good idea to add an option for this?  Should it at
least be non-interactive, so that the driver always gets built under
the same conditions as currently?  A later patch can make it 
interactive, if desired.

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/4] TTY: fix close of uninitialised ports

Make sure we do not make tty-driver callbacks or wait for port to drain
on uninitialised ports (e.g. when open failed) in
tty_port_close_start().

No callback, such as flush_buffer or wait_until_sent, needs to be made
on a port that has never been opened. Neither does it make much sense to
add drain delay for an uninitialised port.

Currently a drain delay of up to two seconds could be added when a tty
fails to open.

Signed-off-by: Johan Hovold jhov...@gmail.com
---
 drivers/tty/tty_port.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index fcb4ccb..2ff454c 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -454,14 +454,16 @@ int tty_port_close_start(struct tty_port *port,
set_bit(ASYNCB_CLOSING, port-flags);
tty-closing = 1;
spin_unlock_irqrestore(port-lock, flags);
-   /* Don't block on a stalled port, just pull the chain */
-   if (tty-flow_stopped)
-   tty_driver_flush_buffer(tty);
-   if (test_bit(ASYNCB_INITIALIZED, port-flags) 
-   port-closing_wait != ASYNC_CLOSING_WAIT_NONE)
-   tty_wait_until_sent_from_close(tty, port-closing_wait);
-   if (port-drain_delay)
-   tty_port_drain_delay(port, tty);
+
+   if (test_bit(ASYNCB_INITIALIZED, port-flags)) {
+   /* Don't block on a stalled port, just pull the chain */
+   if (tty-flow_stopped)
+   tty_driver_flush_buffer(tty);
+   if (port-closing_wait != ASYNC_CLOSING_WAIT_NONE)
+   tty_wait_until_sent_from_close(tty, port-closing_wait);
+   if (port-drain_delay)
+   tty_port_drain_delay(port, tty);
+   }
/* Flush the ldisc buffering */
tty_ldisc_flush(tty);
 
-- 
1.8.1.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/4] TTY: clean up port drain-delay handling

Move port drain-delay handling to a separate function.

Signed-off-by: Johan Hovold jhov...@gmail.com
---
 drivers/tty/tty_port.c | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 506f579..fcb4ccb 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -408,6 +408,20 @@ int tty_port_block_til_ready(struct tty_port *port,
 }
 EXPORT_SYMBOL(tty_port_block_til_ready);
 
+static void tty_port_drain_delay(struct tty_port *port, struct tty_struct *tty)
+{
+   unsigned int bps = tty_get_baud_rate(tty);
+   long timeout;
+
+   if (bps  1200) {
+   timeout = (HZ * 10 * port-drain_delay) / bps;
+   timeout = max_t(long, timeout, HZ / 10);
+   } else {
+   timeout = 2 * HZ;
+   }
+   schedule_timeout_interruptible(timeout);
+}
+
 int tty_port_close_start(struct tty_port *port,
struct tty_struct *tty, struct file *filp)
 {
@@ -446,17 +460,8 @@ int tty_port_close_start(struct tty_port *port,
if (test_bit(ASYNCB_INITIALIZED, port-flags) 
port-closing_wait != ASYNC_CLOSING_WAIT_NONE)
tty_wait_until_sent_from_close(tty, port-closing_wait);
-   if (port-drain_delay) {
-   unsigned int bps = tty_get_baud_rate(tty);
-   long timeout;
-
-   if (bps  1200)
-   timeout = max_t(long,
-   (HZ * 10 * port-drain_delay) / bps, HZ / 10);
-   else
-   timeout = 2 * HZ;
-   schedule_timeout_interruptible(timeout);
-   }
+   if (port-drain_delay)
+   tty_port_drain_delay(port, tty);
/* Flush the ldisc buffering */
tty_ldisc_flush(tty);
 
-- 
1.8.1.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 0/4] TTY: port hangup and close fixes

These patches against tty-next fix a few issues with tty-port hangup and
close.

The first and third patch are essentially clean ups.

The second patch makes sure DTR is dropped also on hangup and that DTR
is only dropped for initialised ports (where is could have been raised
in the first place).

The fourth and final patch, make sure no tty callbacks are made from
tty_port_close_start when the port has not been initialised (successfully
opened). This was previously only done for wait_until_sent but there's
no reason to call flush_buffer or to honour port drain delay either.
The latter could cause a failed open to stall for up to two seconds.

As a side-effect, this patches also fix an issue in USB-serial where we
could get tty-port callbacks on an uninitialised port after having hung
up and unregistered a device after disconnect.

Johan


Changes since RFC-series:
 - fix up the two driver relying on tty_port_close_start directly but
   that did not manage DTR themselves


Johan Hovold (4):
  TTY: clean up port shutdown
  TTY: fix DTR not being dropped on hang up
  TTY: clean up port drain-delay handling
  TTY: fix close of uninitialised ports

 drivers/tty/mxser.c|  4 +++
 drivers/tty/n_gsm.c|  4 +++
 drivers/tty/tty_port.c | 71 ++
 3 files changed, 51 insertions(+), 28 deletions(-)

-- 
1.8.1.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 2/4] TTY: fix DTR not being dropped on hang up

Move HUPCL handling to port shutdown so that DTR is dropped also on hang
up (tty_port_close is a noop for hung-up ports).

Also do not try to drop DTR for uninitialised ports where it has never
been raised (e.g. after a failed open).

Nine drivers currently call tty_port_close_start directly (rather than
through tty_port_close) and seven of them lower DTR as part of their
close (if the port has been initialised). Fixup the remaining two
drivers so that it continues to be lowered also on normal (non-HUP)
close. [ Note that most of those other seven drivers did not expect DTR
to have been dropped by tty_port_close_start in the first place. ]

Signed-off-by: Johan Hovold jhov...@gmail.com
---
 drivers/tty/mxser.c|  4 
 drivers/tty/n_gsm.c|  4 
 drivers/tty/tty_port.c | 23 +--
 3 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index 484b6a3..c547887 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -1084,6 +1084,10 @@ static void mxser_close(struct tty_struct *tty, struct 
file *filp)
mutex_lock(port-mutex);
mxser_close_port(port);
mxser_flush_buffer(tty);
+   if (test_bit(ASYNCB_INITIALIZED, port-flags)) {
+   if (tty-termios.c_cflag  HUPCL)
+   tty_port_lower_dtr_rts(port);
+   }
mxser_shutdown_port(port);
clear_bit(ASYNCB_INITIALIZED, port-flags);
mutex_unlock(port-mutex);
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 4a43ef5d7..049013e 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2968,6 +2968,10 @@ static void gsmtty_close(struct tty_struct *tty, struct 
file *filp)
if (tty_port_close_start(dlci-port, tty, filp) == 0)
goto out;
gsm_dlci_begin_close(dlci);
+   if (test_bit(ASYNCB_INITIALIZED, dlci-port.flags)) {
+   if (tty-termios.c_cflag  HUPCL)
+   tty_port_lower_dtr_rts(dlci-port);
+   }
tty_port_close_end(dlci-port, tty);
tty_port_tty_set(dlci-port, NULL);
 out:
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 57a061e..506f579 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -198,15 +198,25 @@ EXPORT_SYMBOL(tty_port_tty_set);
 
 static void tty_port_shutdown(struct tty_port *port)
 {
+   struct tty_struct *tty = tty_port_tty_get(port);
+
mutex_lock(port-mutex);
if (port-console)
goto out;
 
if (test_and_clear_bit(ASYNCB_INITIALIZED, port-flags)) {
+   /*
+* Drop DTR/RTS if HUPCL is set. This causes any attached
+* modem to hang up the line.
+*/
+   if (!tty || tty-termios.c_cflag  HUPCL)
+   tty_port_lower_dtr_rts(port);
+
if (port-ops-shutdown)
port-ops-shutdown(port);
}
 out:
+   tty_kref_put(tty);
mutex_unlock(port-mutex);
 }
 
@@ -225,15 +235,13 @@ void tty_port_hangup(struct tty_port *port)
spin_lock_irqsave(port-lock, flags);
port-count = 0;
port-flags = ~ASYNC_NORMAL_ACTIVE;
-   if (port-tty) {
+   if (port-tty)
set_bit(TTY_IO_ERROR, port-tty-flags);
-   tty_kref_put(port-tty);
-   }
-   port-tty = NULL;
spin_unlock_irqrestore(port-lock, flags);
+   tty_port_shutdown(port);
+   tty_port_tty_set(port, NULL);
wake_up_interruptible(port-open_wait);
wake_up_interruptible(port-delta_msr_wait);
-   tty_port_shutdown(port);
 }
 EXPORT_SYMBOL(tty_port_hangup);
 
@@ -452,11 +460,6 @@ int tty_port_close_start(struct tty_port *port,
/* Flush the ldisc buffering */
tty_ldisc_flush(tty);
 
-   /* Drop DTR/RTS if HUPCL is set. This causes any attached modem to
-  hang up the line */
-   if (tty-termios.c_cflag  HUPCL)
-   tty_port_lower_dtr_rts(port);
-
/* Don't call port-drop for the last reference. Callers will want
   to drop the last active reference in -shutdown() or the tty
   shutdown path */
-- 
1.8.1.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: [V2 1/8] USB: EHCI: make ehci-spear a separate driver

On Fri, 15 Feb 2013, Manjunath Goudar wrote:

 Separate the SPEAr host controller driver from ehci-hcd host code
 into its own driver module.
 
 In V2:
 Replaced spear as SPEAr everywhere, leaving functions/variables/config 
 options.

 --- a/drivers/usb/host/Kconfig
 +++ b/drivers/usb/host/Kconfig
 @@ -162,6 +162,14 @@ config USB_EHCI_HCD_OMAP
 Enables support for the on-chip EHCI controller on
 OMAP3 and later chips.
  
 +config USB_EHCI_HCD_SPEAR
 +tristate Support for ST SPEAr on-chip EHCI USB controller
 +depends on USB_EHCI_HCD  PLAT_SPEAR
 +default y
 +---help---
 +  Enables support for the on-chip EHCI controller on
 +  ST SPEAr chips.

Is it a good idea to make this option interactive?  That might cause 
people to disable it by mistake.

 --- a/drivers/usb/host/Makefile
 +++ b/drivers/usb/host/Makefile
 @@ -27,7 +27,7 @@ obj-$(CONFIG_USB_EHCI_HCD)  += ehci-hcd.o
  obj-$(CONFIG_USB_EHCI_PCI)   += ehci-pci.o
  obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)  += ehci-platform.o
  obj-$(CONFIG_USB_EHCI_MXC)   += ehci-mxc.o
 -
 +obj-$(CONFIG_USB_EHCI_HCD_SPEAR)+= ehci-spear.o

Please don't eliminate the blank line that separates the EHCI drivers 
from the following non-EHCI drivers.

  obj-$(CONFIG_USB_OXU210HP_HCD)   += oxu210hp-hcd.o
  obj-$(CONFIG_USB_ISP116X_HCD)+= isp116x-hcd.o
  obj-$(CONFIG_USB_ISP1362_HCD)+= isp1362-hcd.o

 --- a/drivers/usb/host/ehci-spear.c
 +++ b/drivers/usb/host/ehci-spear.c

 +static const char hcd_name[] = ehci-SPEAr;

 @@ -209,11 +188,35 @@ static struct platform_driver spear_ehci_hcd_driver = {
   .remove = spear_ehci_hcd_drv_remove,
   .shutdown   = usb_hcd_platform_shutdown,
   .driver = {
 - .name = spear-ehci,
 + .name = hcd_name,

You must not change the driver's name.  It won't work on non-DT 
systems; the platform bus relies on matching drivers to devices by 
comparing their names.

   .bus = platform_bus_type,
   .pm = ehci_spear_pm_ops,
   .of_match_table = of_match_ptr(spear_ehci_id_table),
   }
  };
  
 -MODULE_ALIAS(platform:spear-ehci);

You must not remove the MODULE_ALIAS.

 +static const struct ehci_driver_overrides spear_overrides __initdata = {
 + .reset = ehci_spear_setup,
 +};

You forgot to use the .extra_priv_size field.  It will allow the driver 
to be simplified by storing the clk field of struct spear_ehci in the 
private part of the ehci_hcd structure.

Also, you can completely eliminate the ehci_spear_setup routine if you 
move the lines

/* registers start at offset 0x0 */
ehci-caps = hcd-regs;

into spear_ehci_hcd_drv_probe.

 +MODULE_DESCRIPTION(DRIVER_DESC);
 +MODULE_LICENSE(GPL);

There probably should be a MODULE_AUTHOR field, yes?

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: [V2 3/8] USB: EHCI: make ehci-s5p a separate driver

On Fri, 15 Feb 2013, Manjunath Goudar wrote:

 --- a/drivers/usb/host/ehci-s5p.c
 +++ b/drivers/usb/host/ehci-s5p.c
 @@ -20,6 +20,17 @@
  #include linux/usb/phy.h
  #include linux/usb/samsung_usb_phy.h
  #include plat/usb-phy.h
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/usb.h
 +#include linux/usb/hcd.h
 +#include linux/io.h
 +#include linux/usb/otg.h
 +#include linux/dma-mapping.h

It's generally a good idea to keep these #include's in alphabetical 
order, as near as possible.

 @@ -322,5 +305,27 @@ static struct platform_driver s5p_ehci_driver = {
   .of_match_table = of_match_ptr(exynos_ehci_match),
   }
  };
 +static const struct ehci_driver_overrides s5p_overrides __initdata = {
 + .reset = ehci_setup,

Not needed.  But you can use .extra_priv_size to eliminate the separate 
allocation of the s5p_ehci_hcd structure.  Once you do that, the .dev 
and .hcd members of the structure will be unnecessary.

 +MODULE_DESCRIPTION(DRIVER_DESC);
  MODULE_ALIAS(platform:s5p-ehci);
 +MODULE_LICENSE(GPL);

Should be GPLv2.

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 2/2] USB: EHCI: make ehci-orion a separate driver

2013-02-20 Thread Arnd Bergmann

On Wednesday 20 February 2013, Alan Stern wrote:
 Currently there is no Kconfig option to control specifically whether
 the ehci-orion driver gets built; it always gets built whenever
 CONFIG_PLAT_ORION and CONFIG_USB_EHCI_HCD are both enabled.
 
 Do you think it is a good idea to add an option for this?  Should it at
 least be non-interactive, so that the driver always gets built under
 the same conditions as currently?  A later patch can make it 
 interactive, if desired.

I think it's good to have it interactive, because we are now building for
multiplatform with Orion being one of many. It's useful to be able to
build EHCI_HCD=y AND EHCD_HCD_ORION=m.

However, you are right that this is a change that was not mentioned in
the patch description and would better have been kept separate or
at least explicitly spelled out.

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

Re: [V2 6/8] USB: EHCI: make ehci-msm a separate driver

On Fri, 15 Feb 2013, Manjunath Goudar wrote:

 Separate the Qualcomm On-Chip host controller driver from ehci-hcd host code
 into its own driver module.

 --- a/drivers/usb/host/ehci-msm.c
 +++ b/drivers/usb/host/ehci-msm.c

 +static const char hcd_name[] = msm_hsusb_host;

This should be something more like ehci-msm.  Of course, that means 
you have to leave the ehci_msm_driver.driver.name field unchanged.

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 2/2] USB: EHCI: make ehci-orion a separate driver

2013-02-20 Thread Jason Cooper

Alan,

On Wed, Feb 20, 2013 at 04:27:04PM +, Arnd Bergmann wrote:
 On Wednesday 20 February 2013, Alan Stern wrote:
  Currently there is no Kconfig option to control specifically whether
  the ehci-orion driver gets built; it always gets built whenever
  CONFIG_PLAT_ORION and CONFIG_USB_EHCI_HCD are both enabled.
  
  Do you think it is a good idea to add an option for this?  Should it at
  least be non-interactive, so that the driver always gets built under
  the same conditions as currently?  A later patch can make it 
  interactive, if desired.
 
 I think it's good to have it interactive, because we are now building for
 multiplatform with Orion being one of many. It's useful to be able to
 build EHCI_HCD=y AND EHCD_HCD_ORION=m.

Yes, explicit is preferable.  On kirkwood usb has it's own gateable
clock.  The user should be able to conserve power by unloading the
module or building without it.

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe 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] pci: do not try to assign irq 255

2013-02-20 Thread Yinghai Lu

On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke h...@suse.de wrote:

 Apparently this device is meant to use MSI _only_ so the BIOS developer
 didn't feel the need to assign an INTx here.

 According to PCI-3.0, section 6.8 (Message Signalled Interrupts):
 It is recommended that devices implement interrupt pins to
 provide compatibility in systems that do not support MSI
 (devices default to interrupt pins). However, it is expected
 that the need for interrupt pins will diminish over time.
 Devices that do not support interrupt pins due to pin
 constraints (rely on polling for device service) may implement
 messages to increase performance without adding additional pins. 
 Therefore, system configuration software must not assume that a
 message capable device has an interrupt pin.

 Which sounds to me as if the implementation is valid...

it seems you mess pin with interrupt line.

current code:
unsigned char irq;

pci_read_config_byte(dev, PCI_INTERRUPT_PIN, irq);
dev-pin = irq;
if (irq)
pci_read_config_byte(dev, PCI_INTERRUPT_LINE, irq);
dev-irq = irq;

so if the device does not have interrupt pin implemented, pin should be zero.
and  pin and irq in dev should
be all 0.

Thanks

Yinghai
--
To unsubscribe from this list: send the line unsubscribe 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] xhci - clarify compliance mode debug messages

2013-02-20 Thread Don Zickus

On Wed, Feb 20, 2013 at 10:54:40AM -0500, Alan Stern wrote:
 On Wed, 20 Feb 2013, Tony Camuso wrote:
 
  On 02/20/2013 10:15 AM, Alan Stern wrote:
   On Tue, 19 Feb 2013, Sarah Sharp wrote:
  
   The one thing I wanted to check was my understanding of the hibernate
   flow path.  As you mentioned, I thought that xhci_suspend would be
   called in the hibernate path, but it's not.
  
   Are you sure about that?  AFAICT it should be called -- although it
   gets called during the poweroff phase of hibernation, not the freeze
   phase.
  
   core/hcd-pci.c: usb_hcd_pci_pm_ops.poweroff = hcd_pci_suspend
   core/hcd-pci.c: hcd_pci_suspend calls suspend_common
   core/hcd-pci.c: suspend_common calls hcd-driver-pci_suspend
   host/xhci-pci.c: xhci_pci_hc_driver.pci_suspend = xhci_pci_suspend
   host/xhci-pci.c: xhci_pci_suspend calls xhci_suspend
  
  We instrumented the code, and when invoking pm-hibernate, we did
  not flow through xhci_suspend(), where the timer is deleted.
 
 If you instrumented the code then you ought to know how the actual 
 behavior differs from what I outlined above.  Where is the difference?

Hi Alan,

I worked with Tony on this issue.  The instrumentation we did was to add
printks in the xhci_suspend, xhci_resume and
compliance_mode_recovery_timer_init.

What we noticed was that the xhci_suspend was not called during hibernate.
As a result the timer was not deleted.  During the resume, xhci_init
called compliance_mode_recovery_timer_init which caused the initial panic
(adding an existing timer).

We added code to compliance_mode_recovery_timer_init to bail if the timer
was already enabled.  This lead us to the second problem at the bottom of
xhci_resume where compliance_mode_recovery_timer_init was called again.

We did not attempt to understand the mechanics of how suspend/hibernate
and resume worked.  We just assumed based on the hibernate flag to
xhci_resume there were two code paths.

If the expectation is that xhci_suspend should be called during hibernate,
I can work with Tony to figure out why this is not happening.  Solving
that problem would partially solve our problem.  We would still need the
!hibernate flag at the bottom of xhci_resume to surround the timer check
to deal with xhci_init calling the same init function.

Cheers,
Don
--
To unsubscribe from this list: send the line unsubscribe 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] usb/core: add current frame_number sysfs attr to hcd

On Tue, 19 Feb 2013, Stefan Tauner wrote:

 On Tue, 19 Feb 2013 13:27:49 -0500 (EST)
 Alan Stern st...@rowland.harvard.edu wrote:
 
   Adding a completely new API that returns a timestamp associated with
   the start/end/fixed offset of a frame number sounds like a perfect
   solution for my problem. I am not sure what you mean with completion
   (interrupt). AFAICS that term is used mainly/only in relation to
   (signaling) completed URBs. How does that fit together? What can I do
   to make it happen?  
  
  Yes, completion interrupts are used for signalling when an URB
  completes.  That's most of the signalling the CPU gets from a host
  controller; other things like port connect and disconnect are 
  comparatively rare.
 
 Hm but there are also other potential interrupt sources at least for
 some HCD types that could be used, e.g. OHCI_INTR_SF at the start of
 frames in OHCI or the Frame List Rollover interrupt in EHCI?

Yes.  (Although the Frame List Rollover interrupt fires at a rather low 
frequency.)

Don't forget -- if this ever does manage to get into the kernel, it 
will be necessary to modify more than just the EHCI and OHCI drivers.  
The kernel contains a whole bunch of host controller drivers, and every 
one would need to be updated.

 The drawback of using other interrupt sources like OHCI_INTR_SF would
 be of course that they... interrupt, a lot :)
 Maybe the gathering through normally unused interrupts could be
 enabled/disabled with ioctls (and while that is disabled the value is
 only updated on completed URBs)?

Sure, if you want to make things even more complicated...

 What kind of interface do you propose? I would say a single file in
 sysfs with one line frame counter and one line timestamp, but the sysfs
 docs clearly don't encourage mixing types like this, if I understand
 it right. Of course we need to make sure that the corresponding values
 can be retrieved safely in sync...

In fact, I think this interface is so unlikely to be used by more than 
a few people that I propose not adding it at all.  :-)

For your own purposes, of course, you can do whatever you want.

 Do you know about a comparable API I could look at?

Nothing other than the ones you're already aware of.

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] xhci - clarify compliance mode debug messages

On Wed, 20 Feb 2013, Don Zickus wrote:

 On Wed, Feb 20, 2013 at 10:54:40AM -0500, Alan Stern wrote:
  On Wed, 20 Feb 2013, Tony Camuso wrote:
  
   On 02/20/2013 10:15 AM, Alan Stern wrote:
On Tue, 19 Feb 2013, Sarah Sharp wrote:
   
The one thing I wanted to check was my understanding of the hibernate
flow path.  As you mentioned, I thought that xhci_suspend would be
called in the hibernate path, but it's not.
   
Are you sure about that?  AFAICT it should be called -- although it
gets called during the poweroff phase of hibernation, not the freeze
phase.
   
core/hcd-pci.c: usb_hcd_pci_pm_ops.poweroff = hcd_pci_suspend
core/hcd-pci.c: hcd_pci_suspend calls suspend_common
core/hcd-pci.c: suspend_common calls hcd-driver-pci_suspend
host/xhci-pci.c: xhci_pci_hc_driver.pci_suspend = xhci_pci_suspend
host/xhci-pci.c: xhci_pci_suspend calls xhci_suspend
   
   We instrumented the code, and when invoking pm-hibernate, we did
   not flow through xhci_suspend(), where the timer is deleted.
  
  If you instrumented the code then you ought to know how the actual 
  behavior differs from what I outlined above.  Where is the difference?
 
 Hi Alan,
 
 I worked with Tony on this issue.  The instrumentation we did was to add
 printks in the xhci_suspend, xhci_resume and
 compliance_mode_recovery_timer_init.
 
 What we noticed was that the xhci_suspend was not called during hibernate.

I bet it really was called, but you didn't realize it because of the 
way you monitored the output from the printks.  You looked at the log 
buffer or the kernel log file after resuming, right?  You didn't have a 
serial console attached to another machine, to capture the output as 
it occurred.

This makes a difference, because output that occurs after the memory
image is stored on disk will not be present in the image and hence will
not be visible after you resume from hibernation.

Of course, in your case this doesn't matter.  In the memory image, the
timer is active.  Hence it is still active when the system resumes,
even though xhci_suspend _was_ called.

 As a result the timer was not deleted.  During the resume, xhci_init
 called compliance_mode_recovery_timer_init which caused the initial panic
 (adding an existing timer).
 
 We added code to compliance_mode_recovery_timer_init to bail if the timer
 was already enabled.  This lead us to the second problem at the bottom of
 xhci_resume where compliance_mode_recovery_timer_init was called again.
 
 We did not attempt to understand the mechanics of how suspend/hibernate
 and resume worked.  We just assumed based on the hibernate flag to
 xhci_resume there were two code paths.

If you want to handle hibernation correctly, you have to understand how 
it works.  It is all described in excruciating detail in 
Documentation/power/devices.txt.

 If the expectation is that xhci_suspend should be called during hibernate,
 I can work with Tony to figure out why this is not happening.  Solving
 that problem would partially solve our problem.  We would still need the
 !hibernate flag at the bottom of xhci_resume to surround the timer check
 to deal with xhci_init calling the same init function.

Resuming from hibernation is not like resuming from system suspend, for 
two important reasons:

After hibernation, the system has gone through a complete
reboot.  The BIOS has probably made changes, and devices
generally need to be completely reinitialized.

The state a driver sees following hibernation is the state
that existed during the freeze phase, which is different
from what you get during system suspend (and also different
from what you get during later phases of hibernation).

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: -drop_endpoint being called for disabled endpoints

On Tue, Feb 19, 2013 at 11:51:46AM -0500, Alan Stern wrote:
 On Tue, 19 Feb 2013, Felipe Balbi wrote:
 
we will still see the warning since usbcore will continue to call
-drop_endpoint() for disabled eps.
   
   But if xhci-hcd is fixed properly, it won't print out those warnings 
   when drop_endpoint is called for eps that were disabled by a device 
   reset.
  
  why not fixing at usbcore level and we will never have such an issue
  again with any new drivers. Currently the only user for
  -drop_endpoint() is xhci, but what if another driver decides to use it
  and makes a similar 'mistake' ?
  
  It might be just me, but it sounds better that usbcore doesn't even call
  -drop_endpoint() for endpoints which it knows are disabled.
 
 Part of the problem here is that ep-enabled is owned by usbcore, not 
 by the HCD.  The HCD should not be allowed to change it.

 Furthermore, enabling an endpoint involves changes to the core data 
 structures as well as to the HCD's structures and the hardware.  
 Resetting a device may affect the hardware and the HCD, but it doesn't 
 affect the core structures.

The second paragraph sounds right, but the message isn't actually about
ep-enabled.  I think it's about how the USB core manages the
usb_device's ep_in and ep_out arrays.

When usb_reset_and_verify_device() is called, it goes through port
initialization (including resetting the device).  At that point, all
endpoints (except the default control endpoint) are marked as disabled
by the xHCI host, and both the host and driver drop any bandwidth
resources allocated to non-default endpoints.

Then usb_reset_and_verify_device() attempts to reinstate the old
configuration and alt settings.  usb_hcd_alloc_bandwidth() gets called
with udev-actconfig, so that the configuration and all alt setting 0
interfaces are restored.  That calls into the xHCI driver to drop any
endpoints in the udev-ep_out[] or udev-ep_in[] arrays.  I think that's
what triggers the warning.  The USB core still keeps the old
usb_host_endpoint structure pointers after the device has been reset.

The function usb_disable_interface() clears out the ep_out and ep_in
arrays, but that isn't called by usb_reset_and_verify_device() until
after the configuration has been re-installed in the xHCI host.  It's
called just before attempting to re-install the old alt settings.  I'm
not sure why the code is written that way.  Perhaps the USB core needs
those endpoints to stick around because of later error paths?  Alan?

  But I have no strong feelings either way, it just feels/sounds better
  what I suggested ;-)
 
 I think we should wait to hear what Sarah has to say.

We could just remove the warning.  It was mostly put in to help me debug
the new bandwidth allocation code, and just in case there was a host
controller who accidentially mis-managed the endpoint context state.

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

[PATCH 1/2] usb: host: ehci-mxc: Remove unneeded header file

From: Fabio Estevam fabio.este...@freescale.com

Since commit c0304996b (USB: ehci-mxc: remove Efika MX-specific CHRGVBUS hack) 
there is no need to include asm/mach-types.h, so remove it.

Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
 drivers/usb/host/ehci-mxc.c |4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index e9301fb..18c30af 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -28,11 +28,7 @@
 #include linux/slab.h
 #include linux/usb.h
 #include linux/usb/hcd.h
-
 #include linux/platform_data/usb-ehci-mxc.h
-
-#include asm/mach-types.h
-
 #include ehci.h
 
 #define DRIVER_DESC Freescale On-Chip EHCI Host driver
-- 
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 2/2] usb: host: ehci-mxc: Indicate succesful probe

From: Fabio Estevam fabio.este...@freescale.com

Rather than reporting that the controller is about to be initialized, it is more
useful to indicate a succesful probe instead.

Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
 drivers/usb/host/ehci-mxc.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index 18c30af..df2d0bf 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -57,8 +57,6 @@ static int ehci_mxc_drv_probe(struct platform_device *pdev)
struct device *dev = pdev-dev;
struct ehci_hcd *ehci;
 
-   dev_info(pdev-dev, initializing i.MX USB Controller\n);
-
if (!pdata) {
dev_err(dev, No platform data given, bailing out.\n);
return -EINVAL;
@@ -157,6 +155,7 @@ static int ehci_mxc_drv_probe(struct platform_device *pdev)
if (ret)
goto err_add;
 
+   dev_info(pdev-dev, initialized succesfully\n);
return 0;
 
 err_add:
-- 
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: Not enough resource for old configuration after USB bus reset

On Fri, Feb 01, 2013 at 02:09:24PM +0800, 洪崇耕 wrote:
Hi,

According to xHCI spec Rev1 page 125, Endpoint context state diagram.

When reset device, the endpoint state transit to disabled state.

Right. And the endpoint resources are supposed to be dropped by the
Reset Device command. Section 4.6.11 says the host should Free any
bandwidth allocated to the periodic endpoints and Free any internal
resources associated with the endpoint.

After the device is reset, the USB core re-instates the configuration,
with alternate setting 0 for all interfaces. The xHCI driver will issue
a Configure Endpoint command with the add flag set for those endpoints.
According to section 4.6.6, if that command is successful, the host
should set the endpoint output context state to running. Is your
host setting the endpoint context state to running?

Then the USB core attempts to re-instate any interfaces that weren't
originally at alt setting zero. That means dropping and adding
endpoints. The endpoint context state should be running at that point,
so the call to drop_endpoints should succeed. If that's true,
we shouldn't ever add an endpoint context twice.

(However, note that your test code doesn't change any alternate
interface settings before resetting the device. That means you're not
running into the case in the third paragraph. Unless you're resetting a
device with a driver bound to it, and the driver is re-installing a
different alternate interface setting.)

Are you sure the TI host and your host isn't neglecting to drop endpoint
resources when the Reset Device command is handled?

Sarah Sharp

From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Thursday, January 31, 2013 12:22 AM
To: 洪崇耕
Cc: linux-usb@vger.kernel.org
Subject: RE: Not enough resource for old configuration after USB bus reset

On Wed, 30 Jan 2013, [big5] x R wrote:

Hi all,

We try to reproduce the problem on general desktop with ubuntu 12.04.1 and
12.10, and got some information below:

1. If we use xHci with Ti TUSB7340 chip, do bus reset or plug/unplug 1000+
times, the host fail to configure the device.
If we use xHci with Fresco chip, it operats without error.

2. If the usb device contains only Control/Bulk type endpoints, it's all
right.
If it contains interrupt/isoc (periodic) endpoint, it will fail with
bandwidth error.
I check the source and find that the bandwidth_error is the
TRB_completion_code of configure_endpoint command.

In addition, I try to study the usb_reset_and_verify_device and want to
consult the following question.

When reseting a device, hcd will invoke usb_hcd_alloc_bandwidth, this
function will drop the endpoints and add the endpoints.

When executing drop_endpoint, the function shows error message xHCI called
with disabled ep.
And I confirm that ep_state of end point context is in disabled state this
time.

Why is the endpoint already disabled? It shouldn't be.

Then usb_hcd_alloc_bandwidth invokes add_endpoint.
Last, sending a configure endpoint command to complete the change.

The xHCI spec says configure endpoint should ignore disabled endpoints
drop flag and do nothing.
So the source is correct according to spec.
But the overall behavior is adding the endpoint without dropping the old
endpoint.

Is this what we want? Don't we need dropping endpoints to release the
bandwidth and/or resource before the endpoints goes to disabled state
without freeing bandwidth?

Yes. It would work okay if the endpoint wasn't already disabled. Can you
figure out how the endpoint became disabled in the first place?

Alan Stern

N?妓緶r??y???匒淅炮v傂?)瑎{.n?+?極?{捱?傂n?r←屹??螐?刻俾ｐ埂??嶭?(剝???摃j???m翯z嫡??僠fㄑ搬??坍?m
--
To unsubscribe from this list: send the line unsubscribe 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] xhci - clarify compliance mode debug messages

2013-02-20 Thread Tony Camuso


On 02/20/2013 12:35 PM, Alan Stern wrote:


I bet it really was called, but you didn't realize it because of the
way you monitored the output from the printks.  You looked at the
log buffer or the kernel log file after resuming, right?  You didn't
have a serial console attached to another machine, to capture the
output as it occurred.



Actually, we did have a serial console connected.
 

This makes a difference, because output that occurs after the memory
image is stored on disk will not be present in the image and hence
will not be visible after you resume from hibernation.

Of course, in your case this doesn't matter.  In the memory image,
the timer is active.  Hence it is still active when the system
resumes, even though xhci_suspend _was_ called.



Could be because the printk's are not synchronous with execution.

Upon resuming from hibernate, we'd see a the call trace, which
indicated list_add() corruption where the compliance mode timer was
added to the timer list in xhci.

Don't know why we didn't crash right there. Maybe something needs
to change in list_add(), too.

However, we did not see this behavior when returning from suspend.


If you want to handle hibernation correctly, you have to understand
how it works.  It is all described in excruciating detail in
Documentation/power/devices.txt.



Homework assignment. :)


Resuming from hibernation is not like resuming from system suspend,
for two important reasons:

After hibernation, the system has gone through a complete reboot.
The BIOS has probably made changes, and devices generally need to be
completely reinitialized.

The state a driver sees following hibernation is the state that
existed during the freeze phase, which is different from what you
get during system suspend (and also different from what you get
during later phases of hibernation).



Because we didn't see our printks in xhci_suspend(), we assumed,
perhaps erroneously, that we never entered and the compliance
mode timer was never deleted. We thought that the call trace
with list_add() corruption was a smoking gun, and our patch did
make the problem go away.

We will have another look ...
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] USB: EHCI: make ehci-orion a separate driver

2013-02-20 Thread Greg KH

On Tue, Feb 19, 2013 at 08:24:38AM +0100, Andrew Lunn wrote:
 
 GregKH: Please can you drop this patch from usb-next. It breaks more
 than it fixes.

I've now reverted both of these, and the follow-on patch that Arnd sent
in.

Arnd, sorry, but please be more careful, especially when you ask for
patches to be rushed into the tree...

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/2] USB: EHCI: make ehci-orion a separate driver

2013-02-20 Thread Arnd Bergmann

On Wednesday 20 February 2013, Greg KH wrote:
 On Tue, Feb 19, 2013 at 08:24:38AM +0100, Andrew Lunn wrote:
  
  GregKH: Please can you drop this patch from usb-next. It breaks more
  than it fixes.
 
 I've now reverted both of these, and the follow-on patch that Arnd sent
 in.
 
 Arnd, sorry, but please be more careful, especially when you ask for
 patches to be rushed into the tree...

Yes, I understand. I'll try to come up with a less invasive way to
deal with the build error in 3.9 once the ARM multiplatform branch
gets pulled.

I guess we could either forbid the combinations that are now broken
using Kconfig dependencies, or add just add separate registriation
paths to ehci_hcd_init() and ehci_hcd_cleanup() as we have for
powerpc, although Alan did not like that too much last time I
suggested it.

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

Re: [PATCH 1/2] usb: host: ehci-mxc: Remove unneeded header file

On Wed, 20 Feb 2013, Fabio Estevam wrote:

 From: Fabio Estevam fabio.este...@freescale.com
 
 Since commit c0304996b (USB: ehci-mxc: remove Efika MX-specific CHRGVBUS 
 hack) 
 there is no need to include asm/mach-types.h, so remove it.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---
  drivers/usb/host/ehci-mxc.c |4 
  1 file changed, 4 deletions(-)
 
 diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
 index e9301fb..18c30af 100644
 --- a/drivers/usb/host/ehci-mxc.c
 +++ b/drivers/usb/host/ehci-mxc.c
 @@ -28,11 +28,7 @@
  #include linux/slab.h
  #include linux/usb.h
  #include linux/usb/hcd.h
 -
  #include linux/platform_data/usb-ehci-mxc.h
 -
 -#include asm/mach-types.h
 -
  #include ehci.h
  
  #define DRIVER_DESC Freescale On-Chip EHCI Host driver

Acked-by: Alan Stern st...@rowland.harvard.edu

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

Re: [PATCH 2/2] usb: host: ehci-mxc: Indicate succesful probe

On Wed, 20 Feb 2013, Fabio Estevam wrote:

 From: Fabio Estevam fabio.este...@freescale.com
 
 Rather than reporting that the controller is about to be initialized, it is 
 more
 useful to indicate a succesful probe instead.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---
  drivers/usb/host/ehci-mxc.c |3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)
 
 diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
 index 18c30af..df2d0bf 100644
 --- a/drivers/usb/host/ehci-mxc.c
 +++ b/drivers/usb/host/ehci-mxc.c
 @@ -57,8 +57,6 @@ static int ehci_mxc_drv_probe(struct platform_device *pdev)
   struct device *dev = pdev-dev;
   struct ehci_hcd *ehci;
  
 - dev_info(pdev-dev, initializing i.MX USB Controller\n);
 -
   if (!pdata) {
   dev_err(dev, No platform data given, bailing out.\n);
   return -EINVAL;
 @@ -157,6 +155,7 @@ static int ehci_mxc_drv_probe(struct platform_device 
 *pdev)
   if (ret)
   goto err_add;
  
 + dev_info(pdev-dev, initialized succesfully\n);
   return 0;

Plenty of drivers don't include any message like this at all.  You 
might as well get rid of it entirely.

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] xhci - clarify compliance mode debug messages

On Wed, 20 Feb 2013, Tony Camuso wrote:

 On 02/20/2013 12:35 PM, Alan Stern wrote:
 
  I bet it really was called, but you didn't realize it because of the
  way you monitored the output from the printks.  You looked at the
  log buffer or the kernel log file after resuming, right?  You didn't
  have a serial console attached to another machine, to capture the
  output as it occurred.
 
 
 Actually, we did have a serial console connected.

And you didn't see any indication that xhci_suspend was called?  Odd...  
Did you remember to specify no_console_suspend on the boot command 
line?

  This makes a difference, because output that occurs after the memory
  image is stored on disk will not be present in the image and hence
  will not be visible after you resume from hibernation.
 
  Of course, in your case this doesn't matter.  In the memory image,
  the timer is active.  Hence it is still active when the system
  resumes, even though xhci_suspend _was_ called.
 
 
 Could be because the printk's are not synchronous with execution.

No, I believe they are synchronous when you use a serial console.  
Somebody can let us know if I am wrong.

 Upon resuming from hibernate, we'd see a the call trace, which
 indicated list_add() corruption where the compliance mode timer was
 added to the timer list in xhci.

Naturally, since it hadn't been removed from the timer list when the
memory image was created.

 Don't know why we didn't crash right there. Maybe something needs
 to change in list_add(), too.

You mean you want the kernel to crash in situations where it currently
continues to operate okay (albeit with some memory corruption)?  That 
doesn't seem very productive.  :-)

 However, we did not see this behavior when returning from suspend.

Of course.  Suspend does not create or restore a memory image, whereas 
hibernate does.

  Resuming from hibernation is not like resuming from system suspend,
  for two important reasons:
 
  After hibernation, the system has gone through a complete reboot.
  The BIOS has probably made changes, and devices generally need to be
  completely reinitialized.
 
  The state a driver sees following hibernation is the state that
  existed during the freeze phase, which is different from what you
  get during system suspend (and also different from what you get
  during later phases of hibernation).
 
 
 Because we didn't see our printks in xhci_suspend(), we assumed,
 perhaps erroneously, that we never entered and the compliance
 mode timer was never deleted. We thought that the call trace
 with list_add() corruption was a smoking gun, and our patch did
 make the problem go away.
 
 We will have another look ...

My guess is that xhci_suspend _was_ entered and the timer was deleted
from the list, but when you resumed from hibernation it was back on the
list again.

This may sound strangely futile -- changes made during xhci_suspend are 
gone when hibernation ends.  But that's true only for changes to 
memory.  Changes made to the hardware _will_ have an effect (at least 
until the system shuts down as the final stage of hibernation).

Alan Stern

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

[PATCH v2 1/2] usb: host: ehci-mxc: Remove unneeded header file

From: Fabio Estevam fabio.este...@freescale.com

Since commit c0304996b (USB: ehci-mxc: remove Efika MX-specific CHRGVBUS hack) 
there is no need to include asm/mach-types.h, so remove it.

Signed-off-by: Fabio Estevam fabio.este...@freescale.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
Changes since v1:
- Added Alan's ack
 drivers/usb/host/ehci-mxc.c |4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index e9301fb..18c30af 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -28,11 +28,7 @@
 #include linux/slab.h
 #include linux/usb.h
 #include linux/usb/hcd.h
-
 #include linux/platform_data/usb-ehci-mxc.h
-
-#include asm/mach-types.h
-
 #include ehci.h
 
 #define DRIVER_DESC Freescale On-Chip EHCI Host driver
-- 
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 v2 2/2] usb: host: ehci-mxc: Remove dev_info on probe

From: Fabio Estevam fabio.este...@freescale.com

It is not very useful to indicate the the driver is about to be probed.

Quoting Alan Stern [1]:

Plenty of drivers don't include any message like this at all.  You
might as well get rid of it entirely.

Remove such dev_info().

[1] http://marc.info/?l=linux-usbm=136138896132433w=2

Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- Ged rid of dev_info
 drivers/usb/host/ehci-mxc.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index 18c30af..b5b7be4 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -57,8 +57,6 @@ static int ehci_mxc_drv_probe(struct platform_device *pdev)
struct device *dev = pdev-dev;
struct ehci_hcd *ehci;
 
-   dev_info(pdev-dev, initializing i.MX USB Controller\n);
-
if (!pdata) {
dev_err(dev, No platform data given, bailing out.\n);
return -EINVAL;
-- 
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: Not enough resource for old configuration after USB bus reset

On Wed, Feb 20, 2013 at 10:14:46AM -0800, Sarah Sharp wrote:
 Are you sure the TI host and your host isn't neglecting to drop endpoint
 resources when the Reset Device command is handled?

I double checked your test file on the latest Intel xHCI host, and it's
up to over 4,000 successful resets of a USB mouse with a periodic IN
endpoint.

I tried it with a USB ethernet dongle, but after about a hundred resets,
the device returned different device descriptors.  The USB core treated
it as a new device and assigned it a different address, which caused the
script to fail since the /dev/bus/usb files went away.  Was there a
different device you would like me to test with?

Basically, I think this is a host-specific bug.  We can certainly work
around it in the xHCI driver with a quirk for all hosts that have this
resource tracking problem.  We would issue a Configure Endpoint command
to drop all endpoints before the Reset Device command.  However, I would
really suggest you fix your host controller.

Can you send me the output of `sudo lspci -vvv` and `sudo lspci -vvv -n`
when the TI host is attached to your system?  I'll send you a patch with
the workaround fix to test.  We can also add a quirk for your host, if
your host controller is already available with this issue, and you're
planning on having the mainline kernel support your host controller.

Sarah Sharp
--
To unsubscribe from this list: send the line unsubscribe 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: -drop_endpoint being called for disabled endpoints

On Wed, 20 Feb 2013, Sarah Sharp wrote:

 The second paragraph sounds right, but the message isn't actually about
 ep-enabled.  I think it's about how the USB core manages the
 usb_device's ep_in and ep_out arrays.
 
 When usb_reset_and_verify_device() is called, it goes through port
 initialization (including resetting the device).  At that point, all
 endpoints (except the default control endpoint) are marked as disabled
 by the xHCI host, and both the host and driver drop any bandwidth
 resources allocated to non-default endpoints.
 
 Then usb_reset_and_verify_device() attempts to reinstate the old
 configuration and alt settings.  usb_hcd_alloc_bandwidth() gets called
 with udev-actconfig, so that the configuration and all alt setting 0
 interfaces are restored.  That calls into the xHCI driver to drop any
 endpoints in the udev-ep_out[] or udev-ep_in[] arrays.  I think that's
 what triggers the warning.

That's right.

  The USB core still keeps the old
 usb_host_endpoint structure pointers after the device has been reset.
 
 The function usb_disable_interface() clears out the ep_out and ep_in
 arrays, but that isn't called by usb_reset_and_verify_device() until
 after the configuration has been re-installed in the xHCI host.  It's
 called just before attempting to re-install the old alt settings.  I'm
 not sure why the code is written that way.  Perhaps the USB core needs
 those endpoints to stick around because of later error paths?  Alan?

usb_reset_and_verify_device doesn't disable endpoints before the reset
and re-enable them afterward because until xHCI appeared, there was no
reason to do so.  It would just have been a waste of time and space;
other host controllers don't care whether endpoints are enabled or not
when they aren't actively in use.

This is a symptom of a more general problem.  Until xHCI, the USB
stack's requirements for managing endpoints were based mostly on what
EHCI needs.  As a result they weren't a very good match for xHCI's
requirements, and we never really tried to straighten out the mess.

I have to agree; it would be cleaner to disable all the non-default
endpoints before calling hub_port_init.

 We could just remove the warning.  It was mostly put in to help me debug
 the new bandwidth allocation code, and just in case there was a host
 controller who accidentially mis-managed the endpoint context state.

No objection.

Alan Stern

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

Re: [PATCH v2 2/2] usb: host: ehci-mxc: Remove dev_info on probe

On Wed, 20 Feb 2013, Fabio Estevam wrote:

 From: Fabio Estevam fabio.este...@freescale.com
 
 It is not very useful to indicate the the driver is about to be probed.
 
 Quoting Alan Stern [1]:
 
 Plenty of drivers don't include any message like this at all.  You
 might as well get rid of it entirely.
 
 Remove such dev_info().
 
 [1] http://marc.info/?l=linux-usbm=136138896132433w=2
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---
 Changes since v1:
 - Ged rid of dev_info
  drivers/usb/host/ehci-mxc.c |2 --
  1 file changed, 2 deletions(-)
 
 diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
 index 18c30af..b5b7be4 100644
 --- a/drivers/usb/host/ehci-mxc.c
 +++ b/drivers/usb/host/ehci-mxc.c
 @@ -57,8 +57,6 @@ static int ehci_mxc_drv_probe(struct platform_device *pdev)
   struct device *dev = pdev-dev;
   struct ehci_hcd *ehci;
  
 - dev_info(pdev-dev, initializing i.MX USB Controller\n);
 -
   if (!pdata) {
   dev_err(dev, No platform data given, bailing out.\n);
   return -EINVAL;

Acked-by: Alan Stern st...@rowland.harvard.edu

--
To unsubscribe from this list: send the line unsubscribe 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: test procedure for cdc-wdm

2013-02-20 Thread Bjørn Mork

Oliver Neukum oli...@neukum.org wrote:

Hi,

I am no longer sure about my test procedure for cdc-wdm.
Do you have a test script?

No, I don't. I probably should have a better system, but I usually just try 
some operations I consider normal usage.

I am also including what I currently have for your review.

Looks fine to me. I am not able to test it right now, as I am on vacation as 
usual :) This time skiing in the mountains. 

Please submit it if it works for you, and I will test when I am back next week. 

Bjørn


@@ -478,6 +493,7 @@ retry:
   spin_unlock_irq(desc-iuspin);
   goto retry;
   }
+
   if (!desc-reslength) { /* zero length read */
   dev_dbg(desc-intf-dev, %s: zero length - clearing 
 WDM_READ\n,
__func__);
   clear_bit(WDM_READ, desc-flags);

This looks spurious though. You may want to drop that line.






--
To unsubscribe from this list: send the line unsubscribe 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: Not enough resource for old configuration after USB bus reset

On Wed, Feb 20, 2013 at 03:21:19PM -0500, Alan Stern wrote:
 On Wed, 20 Feb 2013, Sarah Sharp wrote:
 
  Basically, I think this is a host-specific bug.  We can certainly work
  around it in the xHCI driver with a quirk for all hosts that have this
  resource tracking problem.  We would issue a Configure Endpoint command
  to drop all endpoints before the Reset Device command.  However, I would
  really suggest you fix your host controller.
 
 It might not hurt to do this anyway, as a sort of defensive 
 programming.  After all, device resets are not a hot path.

I'll agree that it's not a hot path.  I'm just concerned that if we add
too much defensive behavior, we'll end up triggering different host
controller quirks.  So I would rather modify behavior for particular
host controllers.

I reserve the right to change my mind about that, of course. :)  I might
agree with you when I start running out of bits in xhci-quirks.

Sarah Sharp
--
To unsubscribe from this list: send the line unsubscribe 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: tuning EHCI_TUNE_CERR

2013-02-20 Thread Haribabu Narayanan

Thanks Alan.  Replies inline.

On Wed, Feb 20, 2013 at 7:30 AM, Alan Stern st...@rowland.harvard.edu wrote:
 On Wed, 20 Feb 2013, Haribabu Narayanan wrote:

 Hi all,

We are facing an issue in one of our platforms which seems to be
 indirectly related to how close USB transactions are attempted (in
 case of failed transactions).  In the EHCI layer, we have these two
 defines that deal with retries for failed USB transactions:

 #define EHCI_TUNE_CERR  3
 #define QH_XACTERR_MAX  32

Would appreciate any help with the following questions:

 - Are EHCI_TUNE_CERR and QH_XACTERR_MAX applicable to exactly the same
 set of bus-level errors (namely the single error: XactErr) ?  Or in
 other words, are only the errors that are retried in EHCI-software by
 using QH_XACTERR_MAX benefiting by the use of EHCI_TUNE_CERR set to a
 value  1?

 Yes, I believe so.  It would be necessary to read through the EHCI spec
 very closely to make sure, however.  You'd have to check that in every
 situation where the error counter decrements to 0, the transaction
 fails with XactErr status.

Probably difficult to check this as it is not possible to simulate all
kinds of bus errors.

But yes, EHCI states that CERR is decremented only for Transaction
Errors (3.5.3 qTD Token) (Babble and Buffer error are excluded from
Transaction Errors here ).  I think for all other errors for which
CERR is not decremented, having CERR-1 or CERR-3 does not make any
difference.  Given all this, I was wondering it if is safe to conclude
that if the TD is halted purely because of CERR going from 1-0 it can
be only due to an XactErr which means XactErr is going to be flagged.
Which would directly mean there is nothing lost in terms of overall
retries by making EHCI_TUNE_CERR - 1.

This involves a lot of inferences though and hence I wasn't so sure.


 - We are contemplating reducing EHCI_TUNE_CERR  from 3 to 1 (while
 keeping QH_XACTERR_MAX the same).  This helps us because SW is
 involved with subsequent retries and there is a finite amount of delay
 involved there.  What are the effects on the system if we do this ?  I
 can think of the following few :

 (a) Possible reduced throughput in case the USB device responds poorly

 Yes.

 (b) Possibility of more frequent interrupts to the system during the
 duration where XactErrs are encountered

 This will be a very small effect.  Most likely all three retries would
 occur during the same microframe anyway, and interrupts occur only at
 microframe boundaries.

Good point.  But looking through the code and spec., it looks like the
default is 8uFrames (or 1 mS) and the code doesn't seem to be touching
it?


 (c) Possible impact on the robustness (of dealing with badly behaving
 devices or bad bus conditions) as the effective number of retries are
 now reduced from 32*3 to 32*1.  We can surely counter this by
 increasing QH_XACTERR_MAX to (32*3)

 Again unlikely to have much effect.  If the device or bus is that badly
 behaved or that noisy, you probably shouldn't be using it at all.

   are there any more that we are missing?

 I can't think of any.  Have you tried making this change?  Does it
 really help at all?

Yes.   We seem to have run into a silicon bug where very frequent
retries gives issues.  I have verified that it helps by setting
CERR-1 ., however, wasn't sure how sound that approach is.


 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

Wonky PS2-USB converter issues...

2013-02-20 Thread Valdis Kletnieks

Quite some time ago, I posted about a problematic PS2-USB converter
that I used to connect an old PS2-connector keyboard to my laptop
dock, where the keyboard wouldn't be recognized at boot unless
I unplugged and reconnected it.

Well, I've recently figured out (partly by obtaining a converter
from a different vendor) that the converters both work correctly
when plugged into a USB port that's physically on my Dell Latitude
laptop - but they have issues and require a reconnect cycle when
plugged into the docking station for the laptop. (It took a long time
to figure this out, because *of course* you plug this sort of stuff
into the docking station specifically so you don't have to plug it
in every morning).

So obviously, it isn't the converter that is the problem, but the docking
station is doing something stupid.  Anybody have suggestions on figuring out
what it's doing wrong?



pgptVuWKDGiDg.pgp
Description: PGP signature

Re: Kernel 3.8.0: USB devices don't work at all (regression from 3.7.0). Log attached.

2013-02-20 Thread Dâniel Fraga

On Wed, 20 Feb 2013 10:20:07 -0500 (EST)
Alan Stern st...@rowland.harvard.edu wrote:

 The important module does not contain usb in its name.  :-(
 
 Probably this is not a bug at all, but simply a failure to load the 
 ehci-pci module.  If the USB modules are loaded from your initramsfs 
 image, make sure that the image contains the ehci-pci.ko file.

Bingo! 

ehci-pci.ko is a new module in 3.8.0 right?

So now I can just load ehci-pci instead of ehci-hcd right?

Very nice, thanks for the hint! Now everything is perfect!

-- 
Linux 3.8.0: Unicycling Gorilla
http://www.youtube.com/DanielFragaBR
http://www.libertarios.org.br
--
To unsubscribe from this list: send the line unsubscribe 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] tools: usb: ffs-test: Fix build failure

2013-02-20 Thread maxin . john

From: Maxin B. John maxin.j...@enea.com

Fixes this build failure:
gcc -Wall -Wextra -g -lpthread -I../include -o testusb testusb.c
gcc -Wall -Wextra -g -lpthread -I../include -o ffs-test ffs-test.c
In file included from ffs-test.c:41:0:
../../include/linux/usb/functionfs.h:4:39: fatal error:
uapi/linux/usb/functionfs.h: No such file or directory
compilation terminated.
make: *** [ffs-test] Error 1

Signed-off-by: Maxin B. John maxin.j...@enea.com
---
 tools/usb/ffs-test.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/usb/ffs-test.c b/tools/usb/ffs-test.c
index 8674b9e..fe1e66b 100644
--- a/tools/usb/ffs-test.c
+++ b/tools/usb/ffs-test.c
@@ -38,7 +38,7 @@
 #include unistd.h
 #include tools/le_byteshift.h
 
-#include ../../include/linux/usb/functionfs.h
+#include ../../include/uapi/linux/usb/functionfs.h
 
 
 / Little Endian Handling /
-- 
1.7.7

--
To unsubscribe from this list: send the line unsubscribe 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] tools: usb: ffs-test: Fix build failure

2013-02-20 Thread Greg KH

On Thu, Feb 21, 2013 at 01:57:51AM +0200, maxin.j...@gmail.com wrote:
 From: Maxin B. John maxin.j...@enea.com
 
 Fixes this build failure:
 gcc -Wall -Wextra -g -lpthread -I../include -o testusb testusb.c
 gcc -Wall -Wextra -g -lpthread -I../include -o ffs-test ffs-test.c
 In file included from ffs-test.c:41:0:
 ../../include/linux/usb/functionfs.h:4:39: fatal error:
 uapi/linux/usb/functionfs.h: No such file or directory
 compilation terminated.
 make: *** [ffs-test] Error 1

This is a build failure where, 3.8, or linux-next, or somewhere else?

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: Wonky PS2-USB converter issues...

2013-02-20 Thread Valdis . Kletnieks

On Wed, 20 Feb 2013 16:07:49 -0800, Greg Kroah-Hartman said:

 PS-2 connectors can not normally handle hotplugging, the protocol
 doesn't allow it, and for some unlucky devices, it could actually fry
 the motherboard or the PS-2 device.

 So that's probably the issue here, the device just doesn't support it,
 sorry.

You mis-understood the problem.

This works:

PS/2 keyboard plugged into this device:
Bus 006 Device 002: ID 0e8f:0020 GreenAsia Inc. USB to PS/2 Adapter
USB side of device plugged into USB port on the Latitude laptop.
Power up, boot - the keyboard works.

If you plug the USB side of the GreenAsia adapter into a USB slot on
the dock, the keyboard is dead and not recognized by the system.  However,
replugging the USB, or unplug/plug the PS/2 side, and it becomes recognized
and starts working.

This tells me that the dock is doing something busted with USB that the laptop
does correctly, and not enumerating devices until something happens to whack it
upside the head. I was hoping to identify it and maybe quirk it.



pgpz8SBNr_8yy.pgp
Description: PGP signature

Re: [PATCH] tools: usb: ffs-test: Fix build failure

2013-02-20 Thread Maxin B. John

Hi,

On Thu, Feb 21, 2013 at 2:06 AM, Greg KH gre...@linuxfoundation.org wrote:
 On Thu, Feb 21, 2013 at 01:57:51AM +0200, maxin.j...@gmail.com wrote:
 From: Maxin B. John maxin.j...@enea.com

 Fixes this build failure:
 gcc -Wall -Wextra -g -lpthread -I../include -o testusb testusb.c
 gcc -Wall -Wextra -g -lpthread -I../include -o ffs-test ffs-test.c
 In file included from ffs-test.c:41:0:
 ../../include/linux/usb/functionfs.h:4:39: fatal error:
 uapi/linux/usb/functionfs.h: No such file or directory
 compilation terminated.
 make: *** [ffs-test] Error 1

 This is a build failure where, 3.8, or linux-next, or somewhere else?

It is in 3.8

 thanks,

 greg k-h

Best Regards,
Maxin
--
To unsubscribe from this list: send the line unsubscribe 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/4] TTY: port hangup and close fixes

2013-02-20 Thread Peter Hurley

On Wed, 2013-02-20 at 17:02 +0100, Johan Hovold wrote:
 These patches against tty-next fix a few issues with tty-port hangup and
 close.
 
 The first and third patch are essentially clean ups.
 
 The second patch makes sure DTR is dropped also on hangup and that DTR
 is only dropped for initialised ports (where is could have been raised
 in the first place).
 
 The fourth and final patch, make sure no tty callbacks are made from
 tty_port_close_start when the port has not been initialised (successfully
 opened). This was previously only done for wait_until_sent but there's
 no reason to call flush_buffer or to honour port drain delay either.
 The latter could cause a failed open to stall for up to two seconds.
 
 As a side-effect, this patches also fix an issue in USB-serial where we
 could get tty-port callbacks on an uninitialised port after having hung
 up and unregistered a device after disconnect.
 
 Johan

Looks good to me. No further objections :)

 Changes since RFC-series:
  - fix up the two driver relying on tty_port_close_start directly but
that did not manage DTR themselves
 
 
 Johan Hovold (4):
   TTY: clean up port shutdown
   TTY: fix DTR not being dropped on hang up
   TTY: clean up port drain-delay handling
   TTY: fix close of uninitialised ports
 
  drivers/tty/mxser.c|  4 +++
  drivers/tty/n_gsm.c|  4 +++
  drivers/tty/tty_port.c | 71 
 ++
  3 files changed, 51 insertions(+), 28 deletions(-)
 


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

RE: [PATCH v4 0/5] DWC2 DesignWare HS OTG driver

2013-02-20 Thread Paul Zimmerman

 From: Felipe Balbi [mailto:ba...@ti.com]
 Sent: Wednesday, February 20, 2013 12:29 AM
 On Tue, Feb 19, 2013 at 06:50:03PM -0800, Paul Zimmerman wrote:
  Here is v4 of the DWC2 patch set. I made most of the changes you asked
  for, except for the following:
  - I did not convert to a threaded IRQ handler. I would like to postpone
that for now.
 
 without any reasoning ?

The HSOTG core enables SOF interrupts in some cases, so it has to respond
in less than 125us to interrupts. I'm afraid with a threaded IRQ handler the
latency for handling SOFs could be too large.

I'm not saying I won't do it eventually, I'd just rather not open that possible
can of worms right now.

  - I did not convert to devm_request_and_ioremap() in the probe function,
because that requires a struct resource, which you don't have in a PCI
driver. Perhaps I'm missing something.
 
 look at line 287 on include/linux/pci.h

Ah, that's what I was missing. Yes, that makes the probe() code much
nicer, thanks.

  - I removed a few unneeded module parameters, but left the rest for now.
I discovered that some of the parameters need to be set to non-
hardware-default values, or else the driver doesn't work correctly.
 
 isn't that something which is wrong with your FPGA model ? IIRC you can
 change register default values via coreConsultant.

Building and validating a new FPGA image is a lengthy task. If I can make
things work by tweaking some module parameters, so much the better.
Plus, as part of our validation testing we try with different values for things
like FIFO sizes and DMA modes. Building a new FPGA image to tweak
stuff like that is just not practical.

-- 
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 v4 3/5] HCD descriptor DMA support for the DWC2 driver

2013-02-20 Thread Paul Zimmerman

 -Original Message-
 From: Felipe Balbi [mailto:ba...@ti.com]
 Sent: Wednesday, February 20, 2013 1:20 AM
 
 On Tue, Feb 19, 2013 at 06:50:06PM -0800, Paul Zimmerman wrote:
 
  +#include linux/usb/hcd.h
  +#include linux/usb/ch11.h
 
 this doesn't exist anymore (moved to uapi/linux/usb/ch11.h) have you
 build tested ?

It compiles here using 3.8-rc1. I can see that the file is under uapi/ but
the build still finds it. Maybe there is some kbuild magic that is making
this work?

The rest of your comments I will implement. Thanks!

-- 
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 v4 4/5] PCI bus interface for the DWC2 driver

2013-02-20 Thread Paul Zimmerman

 From: Felipe Balbi [mailto:ba...@ti.com]
 Sent: Wednesday, February 20, 2013 12:50 AM
 
 On Tue, Feb 19, 2013 at 06:50:07PM -0800, Paul Zimmerman wrote:
  This file contains the PCI bus interface glue for the DWC2
  driver
 
  Signed-off-by: Paul Zimmerman pa...@synopsys.com
 
 before anything, out of curiosity, do you have DWC2 PCI configured with
 OTG support ? I remember that on HAPS6x configuring DWC3 PCI OTG would
 take too much space on the FPGA and that would cause difficulties on
 timing closure, but perhaps dwc2 is smaller ?!?

Yes, our standard HSOTG FPGA image is configured with OTG support. I'm
not sure how difficult it is to synthesize, that work is done by a team on
another continent ;)

  +static void dwc2_driver_remove(struct pci_dev *dev)
  +{
  +   struct dwc2_device *otg_dev = pci_get_drvdata(dev);
  +
  +   dev_dbg(dev-dev, %s(%p)\n, __func__, dev);
  +
  +   if (!otg_dev) {
  +   dev_dbg(dev-dev, %s: otg_dev NULL!\n, __func__);
  +   return;
  +   }
 
 this check can be removed, drivers core guarantees that pci_dev *dev
 will always be true and, since you clearly and unconditionally call
 pci_set_drvdata(), otg_dev will always be valid.

This function is called as part of the failure path from dwc2_driver_probe(),
and it's possible that pci_set_drvdata() has not been called yet.

  +
  +   dev_dbg(dev-dev, otg_dev-hsotg = %p\n, otg_dev-hsotg);
  +   if (otg_dev-hsotg)
  +   dwc2_hcd_remove(dev-dev, otg_dev);
  +   else
  +   dev_dbg(dev-dev, %s: otg_dev-hsotg NULL!\n, __func__);
 
 this check can be removed I guess. You shouldn't be able to remove what
 wasn't registered.

Ditto.

  +   /* Map the DWC_otg Core memory into virtual address space */
  +   dev-current_state = PCI_D0;
  +   dev-dev.power.power_state = PMSG_ON;
 
 no no no... you shouldn't access these directly.
 
 Plese use pci_set_state(dev, PCI_D0) and
 dev_pm_qos_constraints_init(dev-dev);

I will switch to pci_set_power_state(dev, PCI_D0), I guess that's what
you meant? I can't get dev_pm_qos_constraints_init() to compile, so
I think I'll leave that out for now. I don't have any PM support in the
driver yet, anyway.

For the rest of your comments I will implement the changes that
you suggested. Thanks.

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

[V8 PATCH 03/16] usb: ehci: ehci-mv: use PHY driver for ehci

Originaly, ehci driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of enabling device tree for ehci driver.

Signed-off-by: Chao Xie chao@marvell.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
 drivers/usb/host/ehci-mv.c |   48 ++-
 1 files changed, 16 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index 3065809..3e89bd4 100644
--- a/drivers/usb/host/ehci-mv.c
+++ b/drivers/usb/host/ehci-mv.c
@@ -15,17 +15,18 @@
 #include linux/clk.h
 #include linux/err.h
 #include linux/usb/otg.h
+#include linux/usb/mv_usb2.h
 #include linux/platform_data/mv_usb.h
 
 #define CAPLENGTH_MASK (0xff)
 
 struct ehci_hcd_mv {
struct usb_hcd *hcd;
+   struct usb_phy *phy;
 
/* Which mode does this ehci running OTG/Host ? */
int mode;
 
-   void __iomem *phy_regs;
void __iomem *cap_regs;
void __iomem *op_regs;
 
@@ -56,22 +57,15 @@ static void ehci_clock_disable(struct ehci_hcd_mv *ehci_mv)
 
 static int mv_ehci_enable(struct ehci_hcd_mv *ehci_mv)
 {
-   int retval;
-
ehci_clock_enable(ehci_mv);
-   if (ehci_mv-pdata-phy_init) {
-   retval = ehci_mv-pdata-phy_init(ehci_mv-phy_regs);
-   if (retval)
-   return retval;
-   }
 
-   return 0;
+   return usb_phy_init(ehci_mv-phy);
 }
 
 static void mv_ehci_disable(struct ehci_hcd_mv *ehci_mv)
 {
-   if (ehci_mv-pdata-phy_deinit)
-   ehci_mv-pdata-phy_deinit(ehci_mv-phy_regs);
+   usb_phy_shutdown(ehci_mv-phy);
+
ehci_clock_disable(ehci_mv);
 }
 
@@ -184,22 +178,7 @@ static int mv_ehci_probe(struct platform_device *pdev)
}
}
 
-   r = platform_get_resource_byname(pdev, IORESOURCE_MEM, phyregs);
-   if (r == NULL) {
-   dev_err(pdev-dev, no phy I/O memory resource defined\n);
-   retval = -ENODEV;
-   goto err_clear_drvdata;
-   }
-
-   ehci_mv-phy_regs = devm_ioremap(pdev-dev, r-start,
-resource_size(r));
-   if (ehci_mv-phy_regs == 0) {
-   dev_err(pdev-dev, failed to map phy I/O memory\n);
-   retval = -EFAULT;
-   goto err_clear_drvdata;
-   }
-
-   r = platform_get_resource_byname(pdev, IORESOURCE_MEM, capregs);
+   r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!r) {
dev_err(pdev-dev, no I/O memory resource defined\n);
retval = -ENODEV;
@@ -214,6 +193,13 @@ static int mv_ehci_probe(struct platform_device *pdev)
goto err_clear_drvdata;
}
 
+   ehci_mv-phy = devm_usb_get_phy_dev(pdev-dev, MV_USB2_PHY_INDEX);
+   if (IS_ERR_OR_NULL(ehci_mv-phy)) {
+   dev_err(pdev-dev, failed to get the outer phy\n);
+   retval = PTR_ERR(ehci_mv-phy);
+   goto err_clear_drvdata;
+   }
+
retval = mv_ehci_enable(ehci_mv);
if (retval) {
dev_err(pdev-dev, init phy error %d\n, retval);
@@ -241,11 +227,12 @@ static int mv_ehci_probe(struct platform_device *pdev)
ehci_mv-mode = pdata-mode;
if (ehci_mv-mode == MV_USB_MODE_OTG) {
 #ifdef CONFIG_USB_OTG_UTILS
-   ehci_mv-otg = devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
+   ehci_mv-otg = devm_usb_get_phy_dev(pdev-dev,
+   MV_USB2_OTG_PHY_INDEX);
if (IS_ERR_OR_NULL(ehci_mv-otg)) {
dev_err(pdev-dev,
unable to find transceiver\n);
-   retval = -ENODEV;
+   retval = PTR_ERR(ehci_mv-otg);
goto err_disable_clk;
}
 
@@ -275,9 +262,6 @@ static int mv_ehci_probe(struct platform_device *pdev)
}
}
 
-   if (pdata-private_init)
-   pdata-private_init(ehci_mv-op_regs, ehci_mv-phy_regs);
-
dev_info(pdev-dev,
 successful find EHCI device with regs 0x%p irq %d
  working in %s mode\n, hcd-regs, hcd-irq,
-- 
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

[V8 PATCH 01/16] usb: phy: mv_usb2: add PHY driver for marvell usb2 controller

The PHY is seperated from usb controller.
The usb controller used in marvell pxa168/pxa910/mmp2 are same,
but PHY initialization may be different.
the usb controller can support udc/otg/ehci, and for each of
the mode, it need PHY to initialized before use the controller.
Direclty writing the phy driver will make the usb controller
driver to be simple and portable.
The PHY driver will be used by marvell udc/otg/ehci.

Signed-off-by: Chao Xie chao@marvell.com
---
 drivers/usb/phy/Kconfig  |7 +
 drivers/usb/phy/Makefile |1 +
 drivers/usb/phy/mv_usb2_phy.c|  402 ++
 include/linux/platform_data/mv_usb.h |9 +-
 include/linux/usb/mv_usb2.h  |   32 +++
 5 files changed, 448 insertions(+), 3 deletions(-)
 create mode 100644 drivers/usb/phy/mv_usb2_phy.c
 create mode 100644 include/linux/usb/mv_usb2.h

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 65217a5..5479760 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -73,3 +73,10 @@ config SAMSUNG_USBPHY
help
  Enable this to support Samsung USB phy controller for samsung
  SoCs.
+
+config MV_USB2_PHY
+   tristate Marvell USB 2.0 PHY Driver
+   depends on USB || USB_GADGET
+   help
+ Enable this to support Marvell USB 2.0 phy driver for Marvell
+ SoC.
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index b13faa1..3835316 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_MV_U3D_PHY)  += mv_u3d_phy.o
 obj-$(CONFIG_USB_EHCI_TEGRA)   += tegra_usb_phy.o
 obj-$(CONFIG_USB_RCAR_PHY) += rcar-phy.o
 obj-$(CONFIG_SAMSUNG_USBPHY)   += samsung-usbphy.o
+obj-$(CONFIG_MV_USB2_PHY)  += mv_usb2_phy.o
diff --git a/drivers/usb/phy/mv_usb2_phy.c b/drivers/usb/phy/mv_usb2_phy.c
new file mode 100644
index 000..a81e5e4
--- /dev/null
+++ b/drivers/usb/phy/mv_usb2_phy.c
@@ -0,0 +1,402 @@
+/*
+ * Copyright (C) 2013 Marvell Inc.
+ *
+ * Author:
+ * Chao Xie xiechao.m...@gmail.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/resource.h
+#include linux/delay.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/io.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/export.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/platform_data/mv_usb.h
+#include linux/usb/phy.h
+#include linux/usb/mv_usb2.h
+
+/* phy regs */
+#define UTMI_REVISION  0x0
+#define UTMI_CTRL  0x4
+#define UTMI_PLL   0x8
+#define UTMI_TX0xc
+#define UTMI_RX0x10
+#define UTMI_IVREF 0x14
+#define UTMI_T00x18
+#define UTMI_T10x1c
+#define UTMI_T20x20
+#define UTMI_T30x24
+#define UTMI_T40x28
+#define UTMI_T50x2c
+#define UTMI_RESERVE   0x30
+#define UTMI_USB_INT   0x34
+#define UTMI_DBG_CTL   0x38
+#define UTMI_OTG_ADDON 0x3c
+
+/* For UTMICTRL Register */
+#define UTMI_CTRL_USB_CLK_EN(1  31)
+/* pxa168 */
+#define UTMI_CTRL_SUSPEND_SET1  (1  30)
+#define UTMI_CTRL_SUSPEND_SET2  (1  29)
+#define UTMI_CTRL_RXBUF_PDWN(1  24)
+#define UTMI_CTRL_TXBUF_PDWN(1  11)
+
+#define UTMI_CTRL_INPKT_DELAY_SHIFT 30
+#define UTMI_CTRL_INPKT_DELAY_SOF_SHIFT28
+#define UTMI_CTRL_PU_REF_SHIFT 20
+#define UTMI_CTRL_ARC_PULLDN_SHIFT  12
+#define UTMI_CTRL_PLL_PWR_UP_SHIFT  1
+#define UTMI_CTRL_PWR_UP_SHIFT  0
+
+/* For UTMI_PLL Register */
+#define UTMI_PLL_PLLCALI12_SHIFT   29
+#define UTMI_PLL_PLLCALI12_MASK(0x3  29)
+
+#define UTMI_PLL_PLLVDD18_SHIFT27
+#define UTMI_PLL_PLLVDD18_MASK (0x3  27)
+
+#define UTMI_PLL_PLLVDD12_SHIFT25
+#define UTMI_PLL_PLLVDD12_MASK (0x3  25)
+
+#define UTMI_PLL_CLK_BLK_EN_SHIFT   24
+#define CLK_BLK_EN  (0x1  24)
+#define PLL_READY   (0x1  23)
+#define KVCO_EXT(0x1  22)
+#define VCOCAL_START(0x1  21)
+
+#define UTMI_PLL_KVCO_SHIFT

[V8 PATCH 04/16] usb: otg: mv_otg: use PHY driver for otg

Originaly, otg driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of enabling device tree for otg driver.

Signed-off-by: Chao Xie chao@marvell.com
---
 drivers/usb/otg/mv_otg.c |   50 ++---
 drivers/usb/otg/mv_otg.h |2 +-
 2 files changed, 21 insertions(+), 31 deletions(-)

diff --git a/drivers/usb/otg/mv_otg.c b/drivers/usb/otg/mv_otg.c
index b6a9be3..7282b0d 100644
--- a/drivers/usb/otg/mv_otg.c
+++ b/drivers/usb/otg/mv_otg.c
@@ -25,6 +25,7 @@
 #include linux/usb/otg.h
 #include linux/usb/gadget.h
 #include linux/usb/hcd.h
+#include linux/usb/mv_usb2.h
 #include linux/platform_data/mv_usb.h
 
 #include mv_otg.h
@@ -261,14 +262,12 @@ static int mv_otg_enable_internal(struct mv_otg *mvotg)
dev_dbg(mvotg-pdev-dev, otg enabled\n);
 
otg_clock_enable(mvotg);
-   if (mvotg-pdata-phy_init) {
-   retval = mvotg-pdata-phy_init(mvotg-phy_regs);
-   if (retval) {
-   dev_err(mvotg-pdev-dev,
-   init phy error %d\n, retval);
-   otg_clock_disable(mvotg);
-   return retval;
-   }
+   retval = usb_phy_init(mvotg-outer_phy);
+   if (retval) {
+   dev_err(mvotg-pdev-dev,
+   init phy error %d\n, retval);
+   otg_clock_disable(mvotg);
+   return retval;
}
mvotg-active = 1;
 
@@ -288,8 +287,7 @@ static void mv_otg_disable_internal(struct mv_otg *mvotg)
 {
if (mvotg-active) {
dev_dbg(mvotg-pdev-dev, otg disabled\n);
-   if (mvotg-pdata-phy_deinit)
-   mvotg-pdata-phy_deinit(mvotg-phy_regs);
+   usb_phy_shutdown(mvotg-outer_phy);
otg_clock_disable(mvotg);
mvotg-active = 0;
}
@@ -729,6 +727,7 @@ static int mv_otg_probe(struct platform_device *pdev)
/* OTG common part */
mvotg-pdev = pdev;
mvotg-phy.dev = pdev-dev;
+   mvotg-phy.type = USB_PHY_TYPE_USB2;
mvotg-phy.otg = otg;
mvotg-phy.label = driver_name;
mvotg-phy.state = OTG_STATE_UNDEFINED;
@@ -741,23 +740,8 @@ static int mv_otg_probe(struct platform_device *pdev)
for (i = 0; i  OTG_TIMER_NUM; i++)
init_timer(mvotg-otg_ctrl.timer[i]);
 
-   r = platform_get_resource_byname(mvotg-pdev,
-IORESOURCE_MEM, phyregs);
-   if (r == NULL) {
-   dev_err(pdev-dev, no phy I/O memory resource defined\n);
-   retval = -ENODEV;
-   goto err_destroy_workqueue;
-   }
-
-   mvotg-phy_regs = devm_ioremap(pdev-dev, r-start, resource_size(r));
-   if (mvotg-phy_regs == NULL) {
-   dev_err(pdev-dev, failed to map phy I/O memory\n);
-   retval = -EFAULT;
-   goto err_destroy_workqueue;
-   }
-
-   r = platform_get_resource_byname(mvotg-pdev,
-IORESOURCE_MEM, capregs);
+   r = platform_get_resource(mvotg-pdev,
+IORESOURCE_MEM, 0);
if (r == NULL) {
dev_err(pdev-dev, no I/O memory resource defined\n);
retval = -ENODEV;
@@ -770,6 +754,12 @@ static int mv_otg_probe(struct platform_device *pdev)
retval = -EFAULT;
goto err_destroy_workqueue;
}
+   mvotg-outer_phy = devm_usb_get_phy_dev(pdev-dev, MV_USB2_PHY_INDEX);
+   if (IS_ERR_OR_NULL(mvotg-outer_phy)) {
+   dev_err(pdev-dev, can not find outer phy\n);
+   retval = PTR_ERR(mvotg-outer_phy);
+   goto err_destroy_workqueue;
+   }
 
/* we will acces controller register, so enable the udc controller */
retval = mv_otg_enable_internal(mvotg);
@@ -830,7 +820,7 @@ static int mv_otg_probe(struct platform_device *pdev)
goto err_disable_clk;
}
 
-   retval = usb_add_phy(mvotg-phy, USB_PHY_TYPE_USB2);
+   retval = usb_add_phy_dev(mvotg-phy);
if (retval  0) {
dev_err(pdev-dev, can't register transceiver, %d\n,
retval);
@@ -841,7 +831,7 @@ static int mv_otg_probe(struct platform_device *pdev)
if (retval  0) {
dev_dbg(pdev-dev,
Can't register sysfs attr group: %d\n, retval);
-   goto err_remove_phy;
+   goto err_remove_otg_phy;
}
 
spin_lock_init(mvotg-wq_lock);
@@ -856,7 +846,7 @@ static int mv_otg_probe(struct platform_device *pdev)
 
return 0;
 
-err_remove_phy:
+err_remove_otg_phy:
usb_remove_phy(mvotg-phy);
 err_disable_clk:

[V8 PATCH 00/16] mv-usb phy enhancement patches

The patches are divied into 2 parts

1. PHY driver
To remove the callbacks in the platform data, a usb PHY driver
for marvell udc/otg/ehci is written.
For device tree support, it is not good to pass the callback
pointers by platform data. The PHY driver also removes the
block.

  usb: phy: mv_usb2: add PHY driver for marvell usb2 controller
  usb: gadget: mv_udc: use PHY driver for udc
  usb: ehci: ehci-mv: use PHY driver for ehci
  usb: otg: mv_otg: use PHY driver for otg
Above patches are marvell usb PHY driver support.

  arm: mmp2: change the defintion of usb devices
  arm: pxa910: change the defintion of usb devices
  arm: brownstone: add usb support for the board
  arm: ttc_dkb: add usb support
  arm: mmp: remove the usb phy setting
  arm: mmp: remove usb devices from pxa168
Above patches are for SOC/board support for marvell usb PHY
driver.

2. external chip support
The marvell usb controller can detect the vbus/idpin, but it
need PHY and usb clocks to be enabled.
Based on measurement it will import 15mA current, and increase
the power when the usb is not used.
Using a external chip to detect vbus/idpin changes will save
the power.
In fact the marvell PMIC 88pm860x and 88pm80x can do it. The
drivers are located at drivers/mfd.
So add a middle layer in the marvell usb PHY driver.
PMIC call the APIs in middle driver to registers the callback
for vbus/idpin detection/query
udc/otg/ehci driver will call the APIs to get vbus/idpin changes
and query the states of the vbus/idpin.
  usb: phy: mv_usb2_phy: add externel chip support
  usb: gadget: mv_udc: add extern chip support
  usb: ehci: ehci-mv: add extern chip support
  usb: otg: mv_otg: add extern chip support
Above patches are the middle layer suppor for udc/otg/ehci

  arm: mmp: add extern chip support for brownstone
  arm: mmp: add extern chip support for ttc_dkb
Above patches are corresponding board file changes

V2-V1:
  Change the Signed-off-by to be right email address

v3-v2
  re-format the patches to new code base

v4-v3
  1. make mv udc gadget driver depend on ARCH_PXA and ARCH_MMP
  2. remove __devinit and __devexit
  3. make the driver compiled successful if CONFIG_MV_USB2_PHY is not defined.
  The modified patches are
  usb: gadget: mv_udc: make mv_udc depends on ARCH_MMP or ARCH_PXA
  usb: phy: mv_usb2: add PHY driver for marvell usb2 controller

v5-v4
  make the struct mv_usb2_extern_chip member -head to be
  struct atomic_notifier_head instead of struct atomic_notifier_head *.

v6-v5
  the bug fix patches are merged.
  Removed the dependcy of ARCH_MMP and ARCH_PXA, and make the driver can be
  compiled for x86.
  The device tree support patches need modification, remove them from this
  patch series, and they will be submitted in another series.


v7-v6
  Use usb_add_phy_dev and related APIs to add PHY drivers.
  Removed the device tree support in PHY driver. It will be added in another
  patch series.

v8-v7
  bugs fix in phy driver.
  directly use devm_usb_get_phy_dev return value for error return.

Chao Xie (16):
  usb: phy: mv_usb2: add PHY driver for marvell usb2 controller
  usb: gadget: mv_udc: use PHY driver for udc
  usb: ehci: ehci-mv: use PHY driver for ehci
  usb: otg: mv_otg: use PHY driver for otg
  arm: mmp2: change the defintion of usb devices
  arm: pxa910: change the defintion of usb devices
  arm: brownstone: add usb support for the board
  arm: ttc_dkb: add usb support
  arm: mmp: remove the usb phy setting
  arm: mmp: remove usb devices from pxa168
  usb: phy: mv_usb2_phy: add externel chip support
  usb: gadget: mv_udc: add extern chip support
  usb: ehci: ehci-mv: add extern chip support
  usb: otg: mv_otg: add extern chip support
  arm: mmp: add extern chip support for brownstone
  arm: mmp: add extern chip support for ttc_dkb

 arch/arm/mach-mmp/brownstone.c|   66 +
 arch/arm/mach-mmp/devices.c   |  278 --
 arch/arm/mach-mmp/include/mach/mmp2.h |4 +
 arch/arm/mach-mmp/include/mach/pxa910.h   |7 +-
 arch/arm/mach-mmp/include/mach/regs-usb.h |  253 
 arch/arm/mach-mmp/mmp2.c  |4 +
 arch/arm/mach-mmp/pxa168.c|   42 ---
 arch/arm/mach-mmp/pxa910.c|4 +
 arch/arm/mach-mmp/ttc_dkb.c   |   52 +++-
 drivers/usb/gadget/mv_udc.h   |5 +-
 drivers/usb/gadget/mv_udc_core.c  |  101 ---
 drivers/usb/host/ehci-mv.c|   64 ++---
 drivers/usb/otg/mv_otg.c  |  122 
 drivers/usb/otg/mv_otg.h  |5 +-
 drivers/usb/phy/Kconfig   |7 +
 drivers/usb/phy/Makefile  |1 +
 drivers/usb/phy/mv_usb2_phy.c |  451 +
 include/linux/platform_data/mv_usb.h  |   22 +-
 include/linux/usb/mv_usb2.h   |  121 
 19 files changed, 856 insertions(+), 753 deletions(-)
 delete mode 100644 arch/arm/mach-mmp/include/mach/regs-usb.h

[V8 PATCH 06/16] arm: pxa910: change the defintion of usb devices

because phy is seperated from the usb controller driver,
we can use the common pxa_device_desc for device register.

Signed-off-by: Chao Xie chao@marvell.com
---
 arch/arm/mach-mmp/include/mach/pxa910.h |7 ---
 arch/arm/mach-mmp/pxa910.c  |4 
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-mmp/include/mach/pxa910.h 
b/arch/arm/mach-mmp/include/mach/pxa910.h
index 3b58a3b..26ea4fe 100644
--- a/arch/arm/mach-mmp/include/mach/pxa910.h
+++ b/arch/arm/mach-mmp/include/mach/pxa910.h
@@ -20,9 +20,10 @@ extern struct pxa_device_desc pxa910_device_pwm2;
 extern struct pxa_device_desc pxa910_device_pwm3;
 extern struct pxa_device_desc pxa910_device_pwm4;
 extern struct pxa_device_desc pxa910_device_nand;
-extern struct platform_device pxa168_device_u2o;
-extern struct platform_device pxa168_device_u2ootg;
-extern struct platform_device pxa168_device_u2oehci;
+extern struct pxa_device_desc pxa910_device_u2o;
+extern struct pxa_device_desc pxa910_device_u2ootg;
+extern struct pxa_device_desc pxa910_device_u2oehci;
+extern struct pxa_device_desc pxa910_device_u2ophy;
 
 extern struct platform_device pxa910_device_gpio;
 extern struct platform_device pxa910_device_rtc;
diff --git a/arch/arm/mach-mmp/pxa910.c b/arch/arm/mach-mmp/pxa910.c
index 8b1e16f..65174f7 100644
--- a/arch/arm/mach-mmp/pxa910.c
+++ b/arch/arm/mach-mmp/pxa910.c
@@ -138,6 +138,10 @@ PXA910_DEVICE(pwm2, pxa910-pwm, 1, NONE, 0xd401a400, 
0x10);
 PXA910_DEVICE(pwm3, pxa910-pwm, 2, NONE, 0xd401a800, 0x10);
 PXA910_DEVICE(pwm4, pxa910-pwm, 3, NONE, 0xd401ac00, 0x10);
 PXA910_DEVICE(nand, pxa3xx-nand, -1, NAND, 0xd4283000, 0x80, 97, 99);
+PXA910_DEVICE(u2ophy, pxa910-usb-phy, -1, NONE, 0xd4207000, 0x1ff);
+PXA910_DEVICE(u2o, mv-udc, -1, USB1, 0xd4208100, 0x1ff);
+PXA910_DEVICE(u2ootg, mv-otg, -1, USB1, 0xd4208100, 0x1ff);
+PXA910_DEVICE(u2oehci, mv-ehci, -1, USB1, 0xd4208100, 0x1ff);
 
 struct resource pxa910_resource_gpio[] = {
{
-- 
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

[V8 PATCH 05/16] arm: mmp2: change the defintion of usb devices

add the udc/otg/ehci devices for mmp2

Signed-off-by: Chao Xie chao@marvell.com
---
 arch/arm/mach-mmp/include/mach/mmp2.h |4 
 arch/arm/mach-mmp/mmp2.c  |4 
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mmp/include/mach/mmp2.h 
b/arch/arm/mach-mmp/include/mach/mmp2.h
index c4ca4d1..58e96b0 100644
--- a/arch/arm/mach-mmp/include/mach/mmp2.h
+++ b/arch/arm/mach-mmp/include/mach/mmp2.h
@@ -31,6 +31,10 @@ extern struct pxa_device_desc mmp2_device_sdh2;
 extern struct pxa_device_desc mmp2_device_sdh3;
 extern struct pxa_device_desc mmp2_device_asram;
 extern struct pxa_device_desc mmp2_device_isram;
+extern struct pxa_device_desc mmp2_device_u2o;
+extern struct pxa_device_desc mmp2_device_u2ootg;
+extern struct pxa_device_desc mmp2_device_u2oehci;
+extern struct pxa_device_desc mmp2_device_u2ophy;
 
 extern struct platform_device mmp2_device_gpio;
 
diff --git a/arch/arm/mach-mmp/mmp2.c b/arch/arm/mach-mmp/mmp2.c
index 3a3768c..73edbfc 100644
--- a/arch/arm/mach-mmp/mmp2.c
+++ b/arch/arm/mach-mmp/mmp2.c
@@ -153,6 +153,10 @@ MMP2_DEVICE(sdh3, sdhci-pxav3, 3, MMC4, 0xd4281800, 
0x120);
 MMP2_DEVICE(asram, asram, -1, NONE, 0xe000, 0x4000);
 /* 0xd100 ~ 0xd101 is reserved for secure processor */
 MMP2_DEVICE(isram, isram, -1, NONE, 0xd102, 0x18000);
+MMP2_DEVICE(u2ophy, mmp2-usb-phy, -1, NONE, 0xd4207000, 0x1ff);
+MMP2_DEVICE(u2o, mv-udc, -1, USB_OTG, 0xd4208100, 0x1ff);
+MMP2_DEVICE(u2ootg, mv-otg, -1, USB_OTG, 0xd4208100, 0x1ff);
+MMP2_DEVICE(u2oehci, mv-ehci, -1, USB_OTG, 0xd4208100, 0x1ff);
 
 struct resource mmp2_resource_gpio[] = {
{
-- 
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

[V8 PATCH 08/16] arm: ttc_dkb: add usb support

for ttc_dkb board, add udc/otg/ehci support

Signed-off-by: Chao Xie chao@marvell.com
---
 arch/arm/mach-mmp/ttc_dkb.c |   50 +-
 1 files changed, 39 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
index ce55fd8..5622092 100644
--- a/arch/arm/mach-mmp/ttc_dkb.c
+++ b/arch/arm/mach-mmp/ttc_dkb.c
@@ -18,6 +18,8 @@
 #include linux/i2c/pca953x.h
 #include linux/gpio.h
 #include linux/mfd/88pm860x.h
+#include linux/usb/phy.h
+#include linux/usb/mv_usb2.h
 #include linux/platform_data/mv_usb.h
 
 #include asm/mach-types.h
@@ -27,7 +29,6 @@
 #include mach/mfp-pxa910.h
 #include mach/pxa910.h
 #include mach/irqs.h
-#include mach/regs-usb.h
 
 #include common.h
 
@@ -158,20 +159,24 @@ static struct i2c_board_info ttc_dkb_i2c_info[] = {
 };
 
 #ifdef CONFIG_USB_SUPPORT
-#if defined(CONFIG_USB_MV_UDC) || defined(CONFIG_USB_EHCI_MV_U2O)
 
 static char *pxa910_usb_clock_name[] = {
-   [0] = U2OCLK,
+   [0] = usb_clk,
 };
 
+static struct mv_usb_phy_platform_data ttc_usb_phy_pdata = {
+   .clknum = 1,
+   .clkname= pxa910_usb_clock_name,
+};
+
+#if defined(CONFIG_USB_MV_UDC) || defined(CONFIG_USB_EHCI_MV_U2O)
+
 static struct mv_usb_platform_data ttc_usb_pdata = {
.clknum = 1,
.clkname= pxa910_usb_clock_name,
.vbus   = NULL,
.mode   = MV_USB_MODE_OTG,
.otg_force_a_bus_req = 1,
-   .phy_init   = pxa_usb_phy_init,
-   .phy_deinit = pxa_usb_phy_deinit,
.set_vbus   = NULL,
 };
 #endif
@@ -198,19 +203,42 @@ static void __init ttc_dkb_init(void)
pxa910_add_twsi(0, NULL, ARRAY_AND_SIZE(ttc_dkb_i2c_info));
platform_add_devices(ARRAY_AND_SIZE(ttc_dkb_devices));
 
+#ifdef CONFIG_USB_SUPPORT
+   pxa_register_device(pxa910_device_u2ophy, ttc_usb_phy_pdata,
+   sizeof(ttc_usb_phy_pdata));
+#endif
+
 #ifdef CONFIG_USB_MV_UDC
-   pxa168_device_u2o.dev.platform_data = ttc_usb_pdata;
-   platform_device_register(pxa168_device_u2o);
+   /* for usb2 phy */
+   usb_bind_phy(pxa910_device_u2o.drv_name, MV_USB2_PHY_INDEX,
+   pxa910_device_u2ophy.drv_name);
+#ifdef CONFIG_USB_MV_OTG
+   /* for usb2 otg phy */
+   usb_bind_phy(pxa910_device_u2o.drv_name, MV_USB2_OTG_PHY_INDEX,
+   pxa910_device_u2ootg.drv_name);
+#endif
+   pxa_register_device(pxa910_device_u2o, ttc_usb_pdata,
+   sizeof(ttc_usb_pdata));
 #endif
 
 #ifdef CONFIG_USB_EHCI_MV_U2O
-   pxa168_device_u2oehci.dev.platform_data = ttc_usb_pdata;
-   platform_device_register(pxa168_device_u2oehci);
+   /* for usb2 phy */
+   usb_bind_phy(pxa910_device_u2oehci.drv_name, MV_USB2_PHY_INDEX,
+   pxa910_device_u2ophy.drv_name);
+#ifdef CONFIG_USB_MV_OTG
+   /* for usb2 otg phy */
+   usb_bind_phy(pxa910_device_u2oehci.drv_name, MV_USB2_OTG_PHY_INDEX,
+   pxa910_device_u2ootg.drv_name);
+#endif
+   pxa_register_device(pxa910_device_u2oehci, ttc_usb_pdata,
+   sizeof(ttc_usb_pdata));
 #endif
 
 #ifdef CONFIG_USB_MV_OTG
-   pxa168_device_u2ootg.dev.platform_data = ttc_usb_pdata;
-   platform_device_register(pxa168_device_u2ootg);
+   usb_bind_phy(pxa910_device_u2ootg.drv_name, MV_USB2_PHY_INDEX,
+   pxa910_device_u2ophy.drv_name);
+   pxa_register_device(pxa910_device_u2ootg, ttc_usb_pdata,
+   sizeof(ttc_usb_pdata));
 #endif
 }
 
-- 
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

[V8 PATCH 09/16] arm: mmp: remove the usb phy setting

phy setting are formatted into a phy driver at drivers/usb/phy,
we do not need do the setting in SOC files.

Signed-off-by: Chao Xie chao@marvell.com
---
 arch/arm/mach-mmp/devices.c   |  278 -
 arch/arm/mach-mmp/include/mach/regs-usb.h |  253 --
 2 files changed, 0 insertions(+), 531 deletions(-)
 delete mode 100644 arch/arm/mach-mmp/include/mach/regs-usb.h

diff --git a/arch/arm/mach-mmp/devices.c b/arch/arm/mach-mmp/devices.c
index dd2d8b1..af341e5 100644
--- a/arch/arm/mach-mmp/devices.c
+++ b/arch/arm/mach-mmp/devices.c
@@ -15,7 +15,6 @@
 #include mach/irqs.h
 #include mach/devices.h
 #include mach/cputype.h
-#include mach/regs-usb.h
 
 int __init pxa_register_device(struct pxa_device_desc *desc,
void *data, size_t size)
@@ -72,280 +71,3 @@ int __init pxa_register_device(struct pxa_device_desc *desc,
return platform_device_add(pdev);
 }
 
-#if defined(CONFIG_USB) || defined(CONFIG_USB_GADGET)
-
-/*
- * The registers read/write routines
- */
-
-static unsigned int u2o_get(void __iomem *base, unsigned int offset)
-{
-   return readl_relaxed(base + offset);
-}
-
-static void u2o_set(void __iomem *base, unsigned int offset,
-   unsigned int value)
-{
-   u32 reg;
-
-   reg = readl_relaxed(base + offset);
-   reg |= value;
-   writel_relaxed(reg, base + offset);
-   readl_relaxed(base + offset);
-}
-
-static void u2o_clear(void __iomem *base, unsigned int offset,
-   unsigned int value)
-{
-   u32 reg;
-
-   reg = readl_relaxed(base + offset);
-   reg = ~value;
-   writel_relaxed(reg, base + offset);
-   readl_relaxed(base + offset);
-}
-
-static void u2o_write(void __iomem *base, unsigned int offset,
-   unsigned int value)
-{
-   writel_relaxed(value, base + offset);
-   readl_relaxed(base + offset);
-}
-
-#if defined(CONFIG_USB_MV_UDC) || defined(CONFIG_USB_EHCI_MV)
-
-#if defined(CONFIG_CPU_PXA910) || defined(CONFIG_CPU_PXA168)
-
-static DEFINE_MUTEX(phy_lock);
-static int phy_init_cnt;
-
-static int usb_phy_init_internal(void __iomem *base)
-{
-   int loops;
-
-   pr_info(Init usb phy!!!\n);
-
-   /* Initialize the USB PHY power */
-   if (cpu_is_pxa910()) {
-   u2o_set(base, UTMI_CTRL, (1UTMI_CTRL_INPKT_DELAY_SOF_SHIFT)
-   | (1UTMI_CTRL_PU_REF_SHIFT));
-   }
-
-   u2o_set(base, UTMI_CTRL, 1UTMI_CTRL_PLL_PWR_UP_SHIFT);
-   u2o_set(base, UTMI_CTRL, 1UTMI_CTRL_PWR_UP_SHIFT);
-
-   /* UTMI_PLL settings */
-   u2o_clear(base, UTMI_PLL, UTMI_PLL_PLLVDD18_MASK
-   | UTMI_PLL_PLLVDD12_MASK | UTMI_PLL_PLLCALI12_MASK
-   | UTMI_PLL_FBDIV_MASK | UTMI_PLL_REFDIV_MASK
-   | UTMI_PLL_ICP_MASK | UTMI_PLL_KVCO_MASK);
-
-   u2o_set(base, UTMI_PLL, 0xeeUTMI_PLL_FBDIV_SHIFT
-   | 0xbUTMI_PLL_REFDIV_SHIFT | 3UTMI_PLL_PLLVDD18_SHIFT
-   | 3UTMI_PLL_PLLVDD12_SHIFT | 3UTMI_PLL_PLLCALI12_SHIFT
-   | 1UTMI_PLL_ICP_SHIFT | 3UTMI_PLL_KVCO_SHIFT);
-
-   /* UTMI_TX */
-   u2o_clear(base, UTMI_TX, UTMI_TX_REG_EXT_FS_RCAL_EN_MASK
-   | UTMI_TX_TXVDD12_MASK | UTMI_TX_CK60_PHSEL_MASK
-   | UTMI_TX_IMPCAL_VTH_MASK | UTMI_TX_REG_EXT_FS_RCAL_MASK
-   | UTMI_TX_AMP_MASK);
-   u2o_set(base, UTMI_TX, 3UTMI_TX_TXVDD12_SHIFT
-   | 4UTMI_TX_CK60_PHSEL_SHIFT | 4UTMI_TX_IMPCAL_VTH_SHIFT
-   | 8UTMI_TX_REG_EXT_FS_RCAL_SHIFT | 3UTMI_TX_AMP_SHIFT);
-
-   /* UTMI_RX */
-   u2o_clear(base, UTMI_RX, UTMI_RX_SQ_THRESH_MASK
-   | UTMI_REG_SQ_LENGTH_MASK);
-   u2o_set(base, UTMI_RX, 7UTMI_RX_SQ_THRESH_SHIFT
-   | 2UTMI_REG_SQ_LENGTH_SHIFT);
-
-   /* UTMI_IVREF */
-   if (cpu_is_pxa168())
-   /* fixing Microsoft Altair board interface with NEC hub issue -
-* Set UTMI_IVREF from 0x4a3 to 0x4bf */
-   u2o_write(base, UTMI_IVREF, 0x4bf);
-
-   /* toggle VCOCAL_START bit of UTMI_PLL */
-   udelay(200);
-   u2o_set(base, UTMI_PLL, VCOCAL_START);
-   udelay(40);
-   u2o_clear(base, UTMI_PLL, VCOCAL_START);
-
-   /* toggle REG_RCAL_START bit of UTMI_TX */
-   udelay(400);
-   u2o_set(base, UTMI_TX, REG_RCAL_START);
-   udelay(40);
-   u2o_clear(base, UTMI_TX, REG_RCAL_START);
-   udelay(400);
-
-   /* Make sure PHY PLL is ready */
-   loops = 0;
-   while ((u2o_get(base, UTMI_PLL)  PLL_READY) == 0) {
-   mdelay(1);
-   loops++;
-   if (loops  100) {
-   printk(KERN_WARNING calibrate timeout, UTMI_PLL %x\n,
-   u2o_get(base, UTMI_PLL));
-   break;
-   }
-

[V8 PATCH 11/16] usb: phy: mv_usb2_phy: add externel chip support

For the vbus and idpin detection. It may be completed by some
external chip, for example the pmic chip 88pm860x in driver/mfd
can do it.
Although the usb controller can detect the vbus and id pin, but
it need clock on and PHY enabled to detect the
vbus/idpin. It will increase the power.
Using the external chip to detect vbus/idpin can save the power.

Signed-off-by: Chao Xie chao@marvell.com
---
 drivers/usb/phy/mv_usb2_phy.c|   49 +++
 include/linux/platform_data/mv_usb.h |   15 ++
 include/linux/usb/mv_usb2.h  |   89 ++
 3 files changed, 143 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/phy/mv_usb2_phy.c b/drivers/usb/phy/mv_usb2_phy.c
index a81e5e4..cbf207c 100644
--- a/drivers/usb/phy/mv_usb2_phy.c
+++ b/drivers/usb/phy/mv_usb2_phy.c
@@ -129,6 +129,53 @@ enum mv_usb2_phy_type {
MMP2_USB,
 };
 
+int mv_usb2_register_notifier(struct mv_usb2_phy *phy,
+   struct notifier_block *nb)
+{
+   int ret;
+
+   if (!phy)
+   return -ENODEV;
+
+   ret = atomic_notifier_chain_register(phy-extern_chip.head, nb);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+EXPORT_SYMBOL(mv_usb2_register_notifier);
+
+int mv_usb2_unregister_notifier(struct mv_usb2_phy *phy,
+   struct notifier_block *nb)
+{
+   int ret;
+
+   if (!phy)
+   return -ENODEV;
+
+   ret = atomic_notifier_chain_unregister(phy-extern_chip.head, nb);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+EXPORT_SYMBOL(mv_usb2_unregister_notifier);
+
+int mv_usb2_notify(struct mv_usb2_phy *phy, unsigned long val, void *v)
+{
+   int ret;
+
+   if (!phy)
+   return -ENODEV;
+
+   ret = atomic_notifier_call_chain(phy-extern_chip.head, val, v);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+EXPORT_SYMBOL(mv_usb2_notify);
+
 static unsigned int u2o_get(void __iomem *base, unsigned int offset)
 {
return readl(base + offset);
@@ -363,6 +410,8 @@ static int mv_usb2_phy_probe(struct platform_device *pdev)
 
usb_add_phy_dev(mv_phy-phy);
 
+   ATOMIC_INIT_NOTIFIER_HEAD(mv_phy-extern_chip.head);
+
platform_set_drvdata(pdev, mv_phy);
 
return 0;
diff --git a/include/linux/platform_data/mv_usb.h 
b/include/linux/platform_data/mv_usb.h
index fd3d1b4..dc25d60 100644
--- a/include/linux/platform_data/mv_usb.h
+++ b/include/linux/platform_data/mv_usb.h
@@ -28,16 +28,13 @@ enum {
VBUS_HIGH   = 1  0,
 };
 
-struct mv_usb_addon_irq {
-   unsigned intirq;
-   int (*poll)(void);
-};
-
+#define MV_USB_HAS_VBUS_DETECTION  (1  0)
+#define MV_USB_HAS_IDPIN_DETECTION (1  1)
 struct mv_usb_platform_data {
unsigned intclknum;
char**clkname;
-   struct mv_usb_addon_irq *id;/* Only valid for OTG. ID pin change*/
-   struct mv_usb_addon_irq *vbus;  /* valid for OTG/UDC. VBUS change*/
+
+   unsigned intextern_attr;
 
/* only valid for HCD. OTG or Host only*/
unsigned intmode;
@@ -45,9 +42,7 @@ struct mv_usb_platform_data {
/* This flag is used for that needs id pin checked by otg */
unsigned intdisable_otg_clock_gating:1;
/* Force a_bus_req to be asserted */
-unsigned intotg_force_a_bus_req:1;
-
-   int (*set_vbus)(unsigned int vbus);
+   unsigned intotg_force_a_bus_req:1;
 };
 
 struct mv_usb_phy_platform_data {
diff --git a/include/linux/usb/mv_usb2.h b/include/linux/usb/mv_usb2.h
index 77250f5..f0bfacb 100644
--- a/include/linux/usb/mv_usb2.h
+++ b/include/linux/usb/mv_usb2.h
@@ -18,6 +18,33 @@
 #define MV_USB2_PHY_INDEX  0
 #define MV_USB2_OTG_PHY_INDEX  1
 
+enum {
+   EVENT_VBUS,
+   EVENT_ID,
+};
+
+struct pxa_usb_vbus_ops {
+   int (*get_vbus)(unsigned int *level);
+   int (*set_vbus)(unsigned int level);
+   int (*init)(void);
+};
+
+struct pxa_usb_idpin_ops {
+   int (*get_idpin)(unsigned int *level);
+   int (*init)(void);
+};
+
+struct pxa_usb_extern_ops {
+   struct pxa_usb_vbus_ops vbus;
+   struct pxa_usb_idpin_opsidpin;
+};
+
+struct mv_usb2_extern_chip {
+   unsigned int id;
+   struct pxa_usb_extern_ops ops;
+   struct atomic_notifier_head head;
+};
+
 struct mv_usb2_phy {
struct usb_phy  phy;
struct platform_device  *pdev;
@@ -27,6 +54,68 @@ struct mv_usb2_phy {
void __iomem*base;
struct clk  **clks;
unsigned intclks_num;
+   struct mv_usb2_extern_chip extern_chip;
 };
 
+#if defined(CONFIG_MV_USB2_PHY) || defined(CONFIG_MV_USB2_PHY_MODULE)
+#define mv_usb2_has_extern_call(phy, o, f, arg...)( \
+{ \
+   int ret;\
+   ret = (!phy ? 0 : ((phy-extern_chip.ops.o.f) ? \
+   1 : 0));

[V8 PATCH 10/16] arm: mmp: remove usb devices from pxa168

Signed-off-by: Chao Xie chao@marvell.com
---
 arch/arm/mach-mmp/pxa168.c |   42 --
 1 files changed, 0 insertions(+), 42 deletions(-)

diff --git a/arch/arm/mach-mmp/pxa168.c b/arch/arm/mach-mmp/pxa168.c
index b7f074f..dd3a68b 100644
--- a/arch/arm/mach-mmp/pxa168.c
+++ b/arch/arm/mach-mmp/pxa168.c
@@ -28,7 +28,6 @@
 #include mach/mfp.h
 #include linux/dma-mapping.h
 #include mach/pxa168.h
-#include mach/regs-usb.h
 
 #include common.h
 #include clock.h
@@ -135,47 +134,6 @@ struct platform_device pxa168_device_gpio = {
.resource   = pxa168_resource_gpio,
 };
 
-struct resource pxa168_usb_host_resources[] = {
-   /* USB Host conroller register base */
-   [0] = {
-   .start  = PXA168_U2H_REGBASE + U2x_CAPREGS_OFFSET,
-   .end= PXA168_U2H_REGBASE + USB_REG_RANGE,
-   .flags  = IORESOURCE_MEM,
-   .name   = capregs,
-   },
-   /* USB PHY register base */
-   [1] = {
-   .start  = PXA168_U2H_PHYBASE,
-   .end= PXA168_U2H_PHYBASE + USB_PHY_RANGE,
-   .flags  = IORESOURCE_MEM,
-   .name   = phyregs,
-   },
-   [2] = {
-   .start  = IRQ_PXA168_USB2,
-   .end= IRQ_PXA168_USB2,
-   .flags  = IORESOURCE_IRQ,
-   },
-};
-
-static u64 pxa168_usb_host_dmamask = DMA_BIT_MASK(32);
-struct platform_device pxa168_device_usb_host = {
-   .name = pxa-sph,
-   .id   = -1,
-   .dev  = {
-   .dma_mask = pxa168_usb_host_dmamask,
-   .coherent_dma_mask = DMA_BIT_MASK(32),
-   },
-
-   .num_resources = ARRAY_SIZE(pxa168_usb_host_resources),
-   .resource  = pxa168_usb_host_resources,
-};
-
-int __init pxa168_add_usb_host(struct mv_usb_platform_data *pdata)
-{
-   pxa168_device_usb_host.dev.platform_data = pdata;
-   return platform_device_register(pxa168_device_usb_host);
-}
-
 void pxa168_restart(char mode, const char *cmd)
 {
soft_restart(0x);
-- 
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

[V8 PATCH 07/16] arm: brownstone: add usb support for the board

for brownstone board, add the udc/otg/ehci support

Signed-off-by: Chao Xie chao@marvell.com
---
 arch/arm/mach-mmp/brownstone.c |   68 
 1 files changed, 68 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index 5cb769c..f84613a 100644
--- a/arch/arm/mach-mmp/brownstone.c
+++ b/arch/arm/mach-mmp/brownstone.c
@@ -18,6 +18,9 @@
 #include linux/regulator/max8649.h
 #include linux/regulator/fixed.h
 #include linux/mfd/max8925.h
+#include linux/usb/phy.h
+#include linux/usb/mv_usb2.h
+#include linux/platform_data/mv_usb.h
 
 #include asm/mach-types.h
 #include asm/mach/arch.h
@@ -195,6 +198,31 @@ static struct sram_platdata mmp2_isram_platdata = {
.granularity= SRAM_GRANULARITY,
 };
 
+#ifdef CONFIG_USB_SUPPORT
+
+static char *mmp2_usb_clock_name[] = {
+   [0] = usb_clk,
+};
+
+static struct mv_usb_phy_platform_data brownstone_usb_phy_pdata = {
+   .clknum = 1,
+   .clkname= mmp2_usb_clock_name,
+};
+
+#if defined(CONFIG_USB_MV_UDC) || defined(CONFIG_USB_EHCI_MV_U2O)
+
+static struct mv_usb_platform_data brownstone_usb_pdata = {
+   .clknum = 1,
+   .clkname= mmp2_usb_clock_name,
+   .vbus   = NULL,
+   .mode   = MV_USB_MODE_OTG,
+   .otg_force_a_bus_req = 1,
+   .set_vbus   = NULL,
+};
+#endif
+#endif
+
+
 static void __init brownstone_init(void)
 {
mfp_config(ARRAY_AND_SIZE(brownstone_pin_config));
@@ -211,6 +239,46 @@ static void __init brownstone_init(void)
 
/* enable 5v regulator */
platform_device_register(brownstone_v_5vp_device);
+
+#ifdef CONFIG_USB_SUPPORT
+   pxa_register_device(mmp2_device_u2ophy, brownstone_usb_phy_pdata,
+   sizeof(brownstone_usb_phy_pdata));
+#endif
+
+#ifdef CONFIG_USB_MV_UDC
+   /* for usb2 phy */
+   usb_bind_phy(mmp2_device_u2o.drv_name, MV_USB2_PHY_INDEX,
+   mmp2_device_u2ophy.drv_name);
+#ifdef CONFIG_USB_MV_OTG
+   /* for usb2 otg phy */
+   usb_bind_phy(mmp2_device_u2o.drv_name, MV_USB2_OTG_PHY_INDEX,
+   mmp2_device_u2ootg.drv_name);
+#endif
+   pxa_register_device(mmp2_device_u2o, brownstone_usb_pdata,
+   sizeof(brownstone_usb_pdata));
+#endif
+
+#ifdef CONFIG_USB_EHCI_MV_U2O
+   /* for usb2 phy */
+   usb_bind_phy(mmp2_device_u2oehci.dev_name, MV_USB2_PHY_INDEX,
+   mmp2_device_u2ophy.dev_name);
+#ifdef CONFIG_USB_MV_OTG
+   /* for usb2 otg phy */
+   usb_bind_phy(mmp2_device_u2oehci.drv_name, MV_USB2_OTG_PHY_INDEX,
+   mmp2_device_u2ootg.drv_name);
+#endif
+   pxa_register_device(mmp2_device_u2oehci, brownstone_usb_pdata,
+   sizeof(brownstone_usb_pdata));
+#endif
+
+#ifdef CONFIG_USB_MV_OTG
+   /* for usb2 phy */
+   usb_bind_phy(mmp2_device_u2ootg.dev_name, MV_USB2_PHY_INDEX,
+   mmp2_device_u2ophy.dev_name);
+   pxa_register_device(mmp2_device_u2ootg, brownstone_usb_pdata,
+   sizeof(brownstone_usb_pdata));
+#endif
+
 }
 
 MACHINE_START(BROWNSTONE, Brownstone Development Platform)
-- 
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

[V8 PATCH 12/16] usb: gadget: mv_udc: add extern chip support

Because arch-mmp will make use of irq domain for irq
allocation, the irqs allocated for PMIC is dynamical.
The vbus/idpin irqs from PMIC can not be passed by platform data.
Using the extern chip APIs provides by PHY driver can solve this
problem.
Marvell usb PHY driver provides a middle layer.
The PMIC usb drivers will help to register the callbacks in the
marvell usb PHY driver.
udc/otg/ehci driver will call the callbacks.
Then we do not need pass the information in platform data. It will
remove another block in the way of enabling device tree for usb.

Signed-off-by: Chao Xie chao@marvell.com
---
 drivers/usb/gadget/mv_udc.h  |3 ++
 drivers/usb/gadget/mv_udc_core.c |   56 +-
 2 files changed, 40 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/gadget/mv_udc.h b/drivers/usb/gadget/mv_udc.h
index f339df4..5d44a6f 100644
--- a/drivers/usb/gadget/mv_udc.h
+++ b/drivers/usb/gadget/mv_udc.h
@@ -178,6 +178,9 @@ struct mv_udc {
struct platform_device  *dev;
int irq;
 
+   unsigned intextern_attr;
+   struct notifier_block   notifier;
+
struct mv_cap_regs __iomem  *cap_regs;
struct mv_op_regs __iomem   *op_regs;
unsigned intmax_eps;
diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c
index 4876d2f..04b4195 100644
--- a/drivers/usb/gadget/mv_udc_core.c
+++ b/drivers/usb/gadget/mv_udc_core.c
@@ -2075,27 +2075,32 @@ static irqreturn_t mv_udc_irq(int irq, void *dev)
return IRQ_HANDLED;
 }
 
-static irqreturn_t mv_udc_vbus_irq(int irq, void *dev)
+static int mv_udc_vbus_notifier_call(struct notifier_block *nb,
+   unsigned long val, void *v)
 {
-   struct mv_udc *udc = (struct mv_udc *)dev;
+   struct mv_udc *udc = container_of(nb, struct mv_udc, notifier);
 
/* polling VBUS and init phy may cause too much time*/
-   if (udc-qwork)
+   if (udc-qwork  val == EVENT_VBUS)
queue_work(udc-qwork, udc-vbus_work);
 
-   return IRQ_HANDLED;
+   return 0;
 }
 
 static void mv_udc_vbus_work(struct work_struct *work)
 {
struct mv_udc *udc;
-   unsigned int vbus;
+   struct mv_usb2_phy *mv_phy;
+   unsigned int vbus = VBUS_LOW;
 
udc = container_of(work, struct mv_udc, vbus_work);
-   if (!udc-pdata-vbus)
+   if (!(udc-extern_attr  MV_USB_HAS_VBUS_DETECTION))
+   return;
+
+   mv_phy = container_of(udc-phy, struct mv_usb2_phy, phy);
+   if (mv_usb2_extern_call(mv_phy, vbus, get_vbus, vbus))
return;
 
-   vbus = udc-pdata-vbus-poll();
dev_info(udc-dev-dev, vbus is %d\n, vbus);
 
if (vbus == VBUS_HIGH)
@@ -2117,11 +2122,17 @@ static void gadget_release(struct device *_dev)
 static int mv_udc_remove(struct platform_device *pdev)
 {
struct mv_udc *udc;
+   struct mv_usb2_phy *mv_phy;
 
udc = platform_get_drvdata(pdev);
 
+   mv_phy = container_of(udc-phy, struct mv_usb2_phy, phy);
+
usb_del_gadget_udc(udc-gadget);
 
+   if (udc-extern_attr  MV_USB_HAS_VBUS_DETECTION)
+   mv_usb2_unregister_notifier(mv_phy, udc-notifier);
+
if (udc-qwork) {
flush_workqueue(udc-qwork);
destroy_workqueue(udc-qwork);
@@ -2149,6 +2160,7 @@ static int mv_udc_probe(struct platform_device *pdev)
 {
struct mv_usb_platform_data *pdata = pdev-dev.platform_data;
struct mv_udc *udc;
+   struct mv_usb2_phy *mv_phy;
int retval = 0;
int clk_i = 0;
struct resource *r;
@@ -2167,6 +2179,7 @@ static int mv_udc_probe(struct platform_device *pdev)
}
 
udc-done = release_done;
+   udc-extern_attr = pdata-extern_attr;
udc-pdata = pdev-dev.platform_data;
spin_lock_init(udc-lock);
 
@@ -2203,6 +2216,7 @@ static int mv_udc_probe(struct platform_device *pdev)
dev_err(pdev-dev, failed to map I/O memory\n);
return -EBUSY;
}
+   mv_phy = container_of(udc-phy, struct mv_usb2_phy, phy);
 
udc-phy = devm_usb_get_phy_dev(pdev-dev, MV_USB2_PHY_INDEX);
if (IS_ERR_OR_NULL(udc-phy))
@@ -2315,17 +2329,8 @@ static int mv_udc_probe(struct platform_device *pdev)
/* VBUS detect: we can disable/enable clock on demand.*/
if (udc-transceiver)
udc-clock_gating = 1;
-   else if (pdata-vbus) {
+   else if (udc-extern_attr  MV_USB_HAS_VBUS_DETECTION) {
udc-clock_gating = 1;
-   retval = devm_request_threaded_irq(pdev-dev,
-   pdata-vbus-irq, NULL,
-   mv_udc_vbus_irq, IRQF_ONESHOT, vbus, udc);
-   if (retval) {
-   dev_info(pdev-dev,
-   Can not request irq for VBUS, 
-

[V8 PATCH 14/16] usb: otg: mv_otg: add extern chip support

It does the similar things as what we do for udc driver.
Signed-off-by: Chao Xie chao@marvell.com
---
 drivers/usb/otg/mv_otg.c |   72 +++--
 drivers/usb/otg/mv_otg.h |3 ++
 2 files changed, 40 insertions(+), 35 deletions(-)

diff --git a/drivers/usb/otg/mv_otg.c b/drivers/usb/otg/mv_otg.c
index 7282b0d..9b3789a 100644
--- a/drivers/usb/otg/mv_otg.c
+++ b/drivers/usb/otg/mv_otg.c
@@ -59,10 +59,13 @@ static char *state_string[] = {
 static int mv_otg_set_vbus(struct usb_otg *otg, bool on)
 {
struct mv_otg *mvotg = container_of(otg-phy, struct mv_otg, phy);
-   if (mvotg-pdata-set_vbus == NULL)
+   struct mv_usb2_phy *mv_phy = container_of(mvotg-outer_phy,
+   struct mv_usb2_phy, phy);
+
+   if (!mv_usb2_has_extern_call(mv_phy, vbus, set_vbus))
return -ENODEV;
 
-   return mvotg-pdata-set_vbus(on);
+   return mv_usb2_extern_call(mv_phy, vbus, set_vbus, on);
 }
 
 static int mv_otg_set_host(struct usb_otg *otg,
@@ -184,14 +187,14 @@ static void mv_otg_init_irq(struct mv_otg *mvotg)
mvotg-irq_status = OTGSC_INTSTS_A_SESSION_VALID
| OTGSC_INTSTS_A_VBUS_VALID;
 
-   if (mvotg-pdata-vbus == NULL) {
+   if (!(mvotg-extern_attr  MV_USB_HAS_VBUS_DETECTION)) {
mvotg-irq_en |= OTGSC_INTR_B_SESSION_VALID
| OTGSC_INTR_B_SESSION_END;
mvotg-irq_status |= OTGSC_INTSTS_B_SESSION_VALID
| OTGSC_INTSTS_B_SESSION_END;
}
 
-   if (mvotg-pdata-id == NULL) {
+   if (!(mvotg-extern_attr  MV_USB_HAS_IDPIN_DETECTION)) {
mvotg-irq_en |= OTGSC_INTR_USB_ID;
mvotg-irq_status |= OTGSC_INTSTS_USB_ID;
}
@@ -303,11 +306,16 @@ static void mv_otg_update_inputs(struct mv_otg *mvotg)
 {
struct mv_otg_ctrl *otg_ctrl = mvotg-otg_ctrl;
u32 otgsc;
+   unsigned int vbus, idpin;
+   struct mv_usb2_phy *mv_phy = container_of(mvotg-outer_phy,
+   struct mv_usb2_phy, phy);
 
otgsc = readl(mvotg-op_regs-otgsc);
 
-   if (mvotg-pdata-vbus) {
-   if (mvotg-pdata-vbus-poll() == VBUS_HIGH) {
+   if (mvotg-extern_attr  MV_USB_HAS_VBUS_DETECTION) {
+   if (mv_usb2_extern_call(mv_phy, vbus, get_vbus, vbus))
+   return;
+   if (vbus == VBUS_HIGH) {
otg_ctrl-b_sess_vld = 1;
otg_ctrl-b_sess_end = 0;
} else {
@@ -319,8 +327,11 @@ static void mv_otg_update_inputs(struct mv_otg *mvotg)
otg_ctrl-b_sess_end = !!(otgsc  OTGSC_STS_B_SESSION_END);
}
 
-   if (mvotg-pdata-id)
-   otg_ctrl-id = !!mvotg-pdata-id-poll();
+   if (mvotg-extern_attr  MV_USB_HAS_IDPIN_DETECTION) {
+   if (mv_usb2_extern_call(mv_phy, idpin, get_idpin, idpin))
+   return;
+   otg_ctrl-id = !!idpin;
+   }
else
otg_ctrl-id = !!(otgsc  OTGSC_STS_USB_ID);
 
@@ -502,7 +513,7 @@ static irqreturn_t mv_otg_irq(int irq, void *dev)
 * if we have vbus, then the vbus detection for B-device
 * will be done by mv_otg_inputs_irq().
 */
-   if (mvotg-pdata-vbus)
+   if (mvotg-extern_attr  MV_USB_HAS_VBUS_DETECTION)
if ((otgsc  OTGSC_STS_USB_ID) 
!(otgsc  OTGSC_INTSTS_USB_ID))
return IRQ_NONE;
@@ -515,9 +526,10 @@ static irqreturn_t mv_otg_irq(int irq, void *dev)
return IRQ_HANDLED;
 }
 
-static irqreturn_t mv_otg_inputs_irq(int irq, void *dev)
+static int mv_otg_notifier_call(struct notifier_block *nb,
+   unsigned long val, void *v)
 {
-   struct mv_otg *mvotg = dev;
+   struct mv_otg *mvotg = container_of(nb, struct mv_otg, notifier);
 
/* The clock may disabled at this time */
if (!mvotg-active) {
@@ -527,7 +539,7 @@ static irqreturn_t mv_otg_inputs_irq(int irq, void *dev)
 
mv_otg_run_state_machine(mvotg, 0);
 
-   return IRQ_HANDLED;
+   return 0;
 }
 
 static ssize_t
@@ -660,9 +672,15 @@ static struct attribute_group inputs_attr_group = {
 int mv_otg_remove(struct platform_device *pdev)
 {
struct mv_otg *mvotg = platform_get_drvdata(pdev);
+   struct mv_usb2_phy *mv_phy = container_of(mvotg-outer_phy,
+   struct mv_usb2_phy, phy);
 
sysfs_remove_group(mvotg-pdev-dev.kobj, inputs_attr_group);
 
+   if ((mvotg-extern_attr  MV_USB_HAS_VBUS_DETECTION) ||
+   (mvotg-extern_attr  MV_USB_HAS_IDPIN_DETECTION))
+   mv_usb2_unregister_notifier(mv_phy, mvotg-notifier);
+
if (mvotg-qwork) {
flush_workqueue(mvotg-qwork);
destroy_workqueue(mvotg-qwork);
@@ -682,6 +700,7 @@ static int mv_otg_probe(struct platform_device *pdev)
struct mv_otg

[V8 PATCH 15/16] arm: mmp: add extern chip support for brownstone

Change the board support for usb as extern chip is supported
in marvell usb PHY driver

Signed-off-by: Chao Xie chao@marvell.com
---
 arch/arm/mach-mmp/brownstone.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index f84613a..eb92419 100644
--- a/arch/arm/mach-mmp/brownstone.c
+++ b/arch/arm/mach-mmp/brownstone.c
@@ -214,10 +214,8 @@ static struct mv_usb_phy_platform_data 
brownstone_usb_phy_pdata = {
 static struct mv_usb_platform_data brownstone_usb_pdata = {
.clknum = 1,
.clkname= mmp2_usb_clock_name,
-   .vbus   = NULL,
.mode   = MV_USB_MODE_OTG,
.otg_force_a_bus_req = 1,
-   .set_vbus   = NULL,
 };
 #endif
 #endif
-- 
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

[V8 PATCH 13/16] usb: ehci: ehci-mv: add extern chip support

It does the similar things as what we do for udc driver.

Signed-off-by: Chao Xie chao@marvell.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
 drivers/usb/host/ehci-mv.c |   16 ++--
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index 3e89bd4..ae5d8dc 100644
--- a/drivers/usb/host/ehci-mv.c
+++ b/drivers/usb/host/ehci-mv.c
@@ -138,6 +138,7 @@ static int mv_ehci_probe(struct platform_device *pdev)
struct ehci_hcd *ehci;
struct ehci_hcd_mv *ehci_mv;
struct resource *r;
+   struct mv_usb2_phy *mv_phy;
int clk_i, retval = -ENODEV;
u32 offset;
size_t size;
@@ -199,6 +200,7 @@ static int mv_ehci_probe(struct platform_device *pdev)
retval = PTR_ERR(ehci_mv-phy);
goto err_clear_drvdata;
}
+   mv_phy = container_of(ehci_mv-phy, struct mv_usb2_phy, phy);
 
retval = mv_ehci_enable(ehci_mv);
if (retval) {
@@ -251,8 +253,8 @@ static int mv_ehci_probe(struct platform_device *pdev)
goto err_disable_clk;
 #endif
} else {
-   if (pdata-set_vbus)
-   pdata-set_vbus(1);
+   if (mv_usb2_has_extern_call(mv_phy, vbus, set_vbus))
+   mv_usb2_extern_call(mv_phy, vbus, set_vbus, 1);
 
retval = usb_add_hcd(hcd, hcd-irq, IRQF_SHARED);
if (retval) {
@@ -270,8 +272,8 @@ static int mv_ehci_probe(struct platform_device *pdev)
return 0;
 
 err_set_vbus:
-   if (pdata-set_vbus)
-   pdata-set_vbus(0);
+   if (mv_usb2_has_extern_call(mv_phy, vbus, set_vbus))
+   mv_usb2_extern_call(mv_phy, vbus, set_vbus, 0);
 err_disable_clk:
mv_ehci_disable(ehci_mv);
 err_clear_drvdata:
@@ -286,6 +288,7 @@ static int mv_ehci_remove(struct platform_device *pdev)
 {
struct ehci_hcd_mv *ehci_mv = platform_get_drvdata(pdev);
struct usb_hcd *hcd = ehci_mv-hcd;
+   struct mv_usb2_phy *mv_phy;
 
if (hcd-rh_registered)
usb_remove_hcd(hcd);
@@ -293,9 +296,10 @@ static int mv_ehci_remove(struct platform_device *pdev)
if (!IS_ERR_OR_NULL(ehci_mv-otg))
otg_set_host(ehci_mv-otg-otg, NULL);
 
+   mv_phy = container_of(ehci_mv-phy, struct mv_usb2_phy, phy);
if (ehci_mv-mode == MV_USB_MODE_HOST) {
-   if (ehci_mv-pdata-set_vbus)
-   ehci_mv-pdata-set_vbus(0);
+   if (mv_usb2_has_extern_call(mv_phy, vbus, set_vbus))
+   mv_usb2_extern_call(mv_phy, vbus, set_vbus, 1);
 
mv_ehci_disable(ehci_mv);
}
-- 
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

[V8 PATCH 16/16] arm: mmp: add extern chip support for ttc_dkb