On Thursday 10 May 2007, Patras, George wrote:
Hello,
I'm writing a gadget driver runing on a TI Davinci ARM using the musb_hdrc
controller driver (peripheral mode) and have run into the following:
I'm writing 600k of data via bulk ep IN to host, breaking it up into
32k blocks per
Hi,
it seems to me that you have to allow for drivers failling to restore
their devices' state. The obvious way would be to let post_reset()
return an error code and treat failure as unplug.
Regards
Oliver
On Wednesday 09 May 2007, Li Yang wrote:
For MPC831x support, change the ehci-fsl driver to preserve
bits set in platform code. Add a common CONFIG_USB_EHCI_FSL
to indicate presence of Freescale EHCI SOC. Add FSL_USB2_DR_OTG
operating mode support, thus both host and device can work for the
-Original Message-
From: David Brownell [mailto:[EMAIL PROTECTED]
Sent: Friday, May 11, 2007 4:03 PM
To: Li Yang-r58472
Cc: [EMAIL PROTECTED]; linux-usb-devel@lists.sourceforge.net
Subject: Re: [PATCH] ehci_fsl update for MPC831x support
On Wednesday 09 May 2007, Li Yang wrote:
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 6271187..8da3185 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -72,6 +72,12 @@ config USB_EHCI_BIG_ENDIAN_MMIO
depends on USB_EHCI_HCD
default n
+config USB_EHCI_FSL
+
For MPC831x support, change the ehci-fsl driver to preserve
bits set in platform code. Add a common CONFIG_USB_EHCI_FSL
to indicate presence of Freescale EHCI SOC. Add FSL_USB2_DR_OTG
operating mode support, thus both host and device can work for the
mini-ab receptacle. Note: this doesn't
On Thu, 10 May 2007, Greg KH wrote:
On Fri, May 04, 2007 at 11:56:18AM -0400, Alan Stern wrote:
From: Danny Budik [EMAIL PROTECTED]
This patch (as899) adds a new ioctl to usbfs: USBDEVFS_GETFRAMENUM.
It allows user programs to obtain the current Start-Of-Frame number on
a USB bus.
On Thu, 10 May 2007, Greg KH wrote:
On Thu, May 10, 2007 at 02:10:07PM -0400, Alan Stern wrote:
Greg:
You have applied most of the patches I sent, but not the USB-persist
ones. Any particular reason?
The main reason is that I'm still on the road, and I really want to
spend the
This patch (as905) removes a micro-optimization from the hub port
initialization code. Previously we had been using a short timeout on
the first attempt the read the device descriptor; now we will use the
standard timeout length.
It's not clear that the short timeout ever provided any benefit.
On Fri, 11 May 2007, Oliver Neukum wrote:
Hi,
it seems to me that you have to allow for drivers failling to restore
their devices' state. The obvious way would be to let post_reset()
return an error code and treat failure as unplug.
To begin with, you don't want to trait failure as unplug.
On Fri, 11 May 2007, James Graves wrote:
Hello Everyone,
We've started out testing of suspend / resume support for the Sierra
Wireless modem driver. For the testing, we're just putting the laptop
into hibernate mode. Suse 10.2 with the 2.6.21 kernel from kernel.org.
This is not a good
Am Mittwoch, 9. Mai 2007 17:09 schrieb Alan Stern:
On Wed, 9 May 2007, Oliver Neukum wrote:
Am Dienstag, 8. Mai 2007 23:59 schrieb Alan Stern:
On Tue, 8 May 2007, Oliver Neukum wrote:
Am Dienstag, 8. Mai 2007 20:59 schrieb Alan Stern:
2. I would prefer to have exclusion
On Friday 11 May 2007, James Graves wrote:
We've started out testing of suspend / resume support for the Sierra
Wireless modem driver. For the testing, we're just putting the laptop
into hibernate mode.
...
However, upon resume, the system appears to be completely disconnecting
Hello Everyone,
We've started out testing of suspend / resume support for the Sierra
Wireless modem driver. For the testing, we're just putting the laptop
into hibernate mode. Suse 10.2 with the 2.6.21 kernel from kernel.org.
However, things aren't working quite as expected with the USB
Am Freitag, 11. Mai 2007 16:27 schrieb Alan Stern:
On Fri, 11 May 2007, Oliver Neukum wrote:
Hi,
it seems to me that you have to allow for drivers failling to restore
their devices' state. The obvious way would be to let post_reset()
return an error code and treat failure as unplug.
Thanks. I will look at this patch this weekend.
-- Al
Quoting Oliver Neukum [EMAIL PROTECTED]:
Hi,
this fixes the flushing trouble due to its own buffering for this driver.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--
---
Thanks. I will look at this one, too, this weekend.
-- Al
Quoting Oliver Neukum [EMAIL PROTECTED]:
Hi,
you are submitting an URB with GFP_KERNEL holding a spinlock.
In this case the spinlock can be dropped earlier.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL
On Fri, 11 May 2007, Oliver Neukum wrote:
You are asking drivers to do something what some of them cannot do
in principle. To restore state from scratch you need to know the state
the device was in. Many drivers cannot know that.
Now perhaps you would like to add a subroutine to the core,
Hi,
I apologize if this has already been reported, I didn't find anything
with a quick search in the archives. I have been looking at the EHCI
code in 2.6.18 and found this:
In 2.6.18 ehci_irq() [1], starting at line 619 the code looks like this:
/* remote wakeup [4.3.1] */
619
Am Freitag, 11. Mai 2007 20:15 schrieb Alan Stern:
On the contrary. This propblem usually occurs during probe() where it is
handled exactly this way. You return an error.
The situations aren't parallel. During probe() the driver is supposed to
test the device to make sure it really can
On Fri, 11 May 2007, Oliver Neukum wrote:
Am Freitag, 11. Mai 2007 20:15 schrieb Alan Stern:
On the contrary. This propblem usually occurs during probe() where it is
handled exactly this way. You return an error.
The situations aren't parallel. During probe() the driver is supposed
Substitute USB instances of __attribute__ ((unused)) functions with the
newly introduced __maybe_unused.
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
drivers/usb/gadget/pxa2xx_udc.h |6 +++---
drivers/usb/host/ehci-dbg.c | 22 +++---
drivers/usb/host/ohci-dbg.c
Hi Alan,
thanks a lot for your reply.
Alan Stern wrote:
Your log annotations illustrate this misunderstanding. The going down
and coming back parts have nothing to do with Setup vs. Data stages.
Rather going down (or just S) means the message was Submitted to
usbcore, and coming back (or
On Fri, 11 May 2007, Alan Stern wrote:
Maybe they don't bother to do so; I'm not familiar with those drivers. So
all right, I'll write the routine for you.
And here you go. Better check with Greg to see if there's any objection
to exporting driver_probe_device() from the driver core.
I
I haven't personally run across an oops because of this, but I feel safer
with this fix in place.
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 40cf882..ba141ab 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@
25 matches
Mail list logo
