On 02/20/2013 05:57 PM, Yinghai Lu wrote:
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke 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 rec
On Thu, Feb 21 2013, Maxin B. John wrote:
> Hi,
>
> On Thu, Feb 21, 2013 at 2:06 AM, Greg KH wrote:
>> On Thu, Feb 21, 2013 at 01:57:51AM +0200, maxin.j...@gmail.com wrote:
>>> From: "Maxin B. John"
>>>
>>> Fixes this build failure:
>>> gcc -Wall -Wextra -g -lpthread -I../include -o testusb testu
On Thu, Feb 21 2013, maxin.j...@gmail.com wrote:
> From: "Maxin B. John"
>
> 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/li
Change the board support for usb as extern chip is supported
in marvell usb PHY driver.
Signed-off-by: Chao Xie
---
arch/arm/mach-mmp/ttc_dkb.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
index 5622092..0ba89
It does the similar things as what we do for udc driver.
Signed-off-by: Chao Xie
Acked-by: Alan Stern
---
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..ae
It does the similar things as what we do for udc driver.
Signed-off-by: Chao Xie
---
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/drive
Change the board support for usb as extern chip is supported
in marvell usb PHY driver
Signed-off-by: Chao Xie
---
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 f84613
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
Signed-off-by: Chao Xie
---
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/ar
for brownstone board, add the udc/otg/ehci support
Signed-off-by: Chao Xie
---
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 5cb
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
---
arch/arm/mach-mmp/devices.c | 278 -
arch/arm/mach-mmp/include/mach/regs-usb.h | 253 --
2 f
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 e
add the udc/otg/ehci devices for mmp2
Signed-off-by: Chao Xie
---
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/includ
for ttc_dkb board, add udc/otg/ehci support
Signed-off-by: Chao Xie
---
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
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:
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
---
arch/arm/mach-mmp/include/mach/pxa910.h |7 ---
arch/arm/mach-mmp/pxa910.c |4
2 files changed, 8 insertions(+), 3 deletio
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 ena
Originaly, udc 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 ena
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 dr
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 en
> 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
>
> before anything, out
> -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
> > +#include
>
> this doesn't exist anymore (moved to uapi/linux/usb/ch11.h) have you
> buil
> 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 threa
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 init
Hi,
On Thu, Feb 21, 2013 at 2:06 AM, Greg KH wrote:
> On Thu, Feb 21, 2013 at 01:57:51AM +0200, maxin.j...@gmail.com wrote:
>> From: "Maxin B. John"
>>
>> Fixes this build failure:
>> gcc -Wall -Wextra -g -lpthread -I../include -o testusb testusb.c
>> gcc -Wall -Wextra -g -lpthread -I../include
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 does
On Wed, Feb 20, 2013 at 05:48:38PM -0500, Valdis Kletnieks wrote:
> 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
On Thu, Feb 21, 2013 at 01:57:51AM +0200, maxin.j...@gmail.com wrote:
> From: "Maxin B. John"
>
> 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
From: "Maxin B. John"
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/functio
On Wed, 20 Feb 2013 10:20:07 -0500 (EST)
Alan Stern 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
On Wed, Feb 20, 2013 at 12:35:11PM -0500, Alan Stern wrote:
> On Wed, 20 Feb 2013, Don Zickus wrote:
> > 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
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
Thanks Alan. Replies inline.
On Wed, Feb 20, 2013 at 7:30 AM, Alan Stern 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
On Mon, Feb 18, 2013 at 01:59:23PM -0500, Tony Camuso wrote:
> The difference between v2 and v3 of this patch was mostly cosmetic.
>
> (!(xhci_all_ports_seen_u0(xhci))
>... was changed to...
> !(xhci_all_ports_seen_u0(xhci))
>
> And ...
> "Compliance Mode Recovery Timer Deleted!\n"
>... w
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 iss
Oliver Neukum 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.
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 Res
On Wed, 20 Feb 2013, Fabio Estevam wrote:
> From: Fabio Estevam
>
> 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 s
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
> initia
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 o
From: Fabio Estevam
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-usb&m=1361388961
From: Fabio Estevam
Since commit c0304996b (USB: ehci-mxc: remove Efika MX-specific CHRGVBUS hack)
there is no need to include , so remove it.
Signed-off-by: Fabio Estevam
Acked-by: Alan Stern
---
Changes since v1:
- Added Alan's ack
drivers/usb/host/ehci-mxc.c |4
1 file changed, 4
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 di
On Wed, 20 Feb 2013, Fabio Estevam wrote:
> From: Fabio Estevam
>
> 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
> ---
> drivers/usb/host/ehci-mxc.c |3 +--
> 1 file cha
On Wed, 20 Feb 2013, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Since commit c0304996b (USB: ehci-mxc: remove Efika MX-specific CHRGVBUS
> hack)
> there is no need to include , so remove it.
>
> Signed-off-by: Fabio Estevam
> ---
> drivers/usb/host/ehci-mxc.c |4
> 1 file chang
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,
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
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,
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. S
From: Fabio Estevam
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
---
drivers/usb/host/ehci-mxc.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/h
From: Fabio Estevam
Since commit c0304996b (USB: ehci-mxc: remove Efika MX-specific CHRGVBUS hack)
there is no need to include , so remove it.
Signed-off-by: Fabio Estevam
---
drivers/usb/host/ehci-mxc.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/host/ehci-mxc.c b/d
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 wa
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
On Tue, 19 Feb 2013, Stefan Tauner wrote:
> On Tue, 19 Feb 2013 13:27:49 -0500 (EST)
> Alan Stern 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 s
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.
On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke 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 int
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_
On Fri, 15 Feb 2013, Manjunath Goudar wrote:
> Separate the vt8500 host controller driver from ehci-hcd host code
> into its own driver module.
>
> In V2:
> Change the GPL to GPL v2 MODULE_LICENSE
Same comments as for the other patches.
You know, when you submit a series of patches all doing b
On Fri, 15 Feb 2013, Manjunath Goudar wrote:
> Separate the Nuvoton On-Chip host controller driver
> from ehci-hcd host code into its own static driver module.
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -238,7 +238,7 @@ config USB_EHCI_MV
> only be EHCI host. O
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 so
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 optio
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
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
It's generally a good idea to
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
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).
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 (rathe
Move port drain-delay handling to a separate function.
Signed-off-by: Johan Hovold
---
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/driv
Untangle port-shutdown logic and make sure the initialised flag is
always cleared for non-console ports.
Signed-off-by: Johan Hovold
---
drivers/tty/tty_port.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index b7ff5
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 drai
On Fri, 15 Feb 2013, Arnd Bergmann wrote:
> From: Manjunath Goudar
>
> 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
From: Fabio Estevam
Staticize usbmisc_imx6q_drv_init/exit() to fix the following sparse warnings:
drivers/usb/chipidea/usbmisc_imx6q.c:147:12: warning: symbol
'usbmisc_imx6q_drv_init' was not declared. Should it be static?
drivers/usb/chipidea/usbmisc_imx6q.c:153:13: warning: symbol
'usbmisc_i
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
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? AFAI
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 retr
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 motherboa
It seems that my initial reply did not made it to the mailing list.
I'm reposting it below with links to scribd for the logs.
Would like to note, that the flooding of debug messages continue's
(indefinitly??) after the first USB connection attempt. So, the log
messages of the file containing the b
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
ge
On 02/19/2013 04:48 PM, Sarah Sharp wrote:
Hi Tony,
Greg closed the usb-next tree for 3.9 two weeks ago. The bug fix
patches will have to go in after the 3.9 merge window closes
(approximately two weeks from now).
Understood.
Sorry for the lack of response, I was on vacation. I'll review y
HI,
On Tue, Feb 19, 2013 at 06:50:06PM -0800, Paul Zimmerman wrote:
> +#include
> +#include
apparently not used.
> +#include
not used.
> +#include
not used
> +#include
not used either
> +#include
> +#include
not used
> +#include
not used
> +#include
not used.
> +#include
>
CONFIG_USB_MUSB_DEBUG option was removed in
5c8a86e usb: musb: drop unneeded musb_debug trickery
to cleanup the code from driver specific debug facilities. This patch
drops the last references to the musb debug config option,
unconditionally enabling all debug code paths, thus letting that code
Hi,
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
before anything, out of curiosity, do you have DWC2 PCI configured with
OTG support ? I remember that on HAPS6x configuri
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
Hi,
On Tue, Feb 19, 2013 at 06:50:08PM -0800, Paul Zimmerman wrote:
> Add the DWC2 Kconfig and Makefile, and modify the USB Kconfig and
> Makefile to include them
>
> Signed-off-by: Paul Zimmerman
> ---
> drivers/usb/Kconfig | 2 ++
> drivers/usb/Makefile | 2 ++
> drivers/usb/dwc2
Hi,
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 ?
> - I
2013/2/19 Soar Hung :
> Hi all,
>
> I checkout the usb-next branch (on 2/18) and following the
> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild to build the kernel.
>
> After reboot, the new kernel version is Linux dev 3.8.0-rc5-usbnext #1 SMP
> Mon Feb 18 18:04:02 CST 2013 i686 i686 i386 GNU/
84 matches
Mail list logo
