diff -X dontdiff.txt -Naur linux-2.5.20/drivers/usb/core/hcd.c
linux-2.5.20-usbwork/drivers/usb/core/hcd.c
--- linux-2.5.20/drivers/usb/core/hcd.c Sun Jun 2 18:44:50 2002
+++ linux-2.5.20-usbwork/drivers/usb/core/hcd.c Wed Jun 5 17:46:26 2002
@@ -44,9 +44,9 @@
#ifdef CONFIG_USB_DEBUG
-
On Wed, Jun 05, 2002 at 09:19:55PM -0700, Greg KH wrote:
>
> Hm, maybe I'll try that out later tonight...
Here's a patch against 2.5.20 that splits out the pci specific parts of
hcd.c into hcd-pci.c. It also removes a bunch of unneeded #includes in
hcd.c (if I've broken compilation on any other
On Thu, 2002-06-06 at 00:52, Brad Hards wrote:
> uhci.o
didn't work.
> usb-uhci.o
didn't work.
> usb-uhci-hcd.o
didn't work
> uhci-hcd.o
didn't work.
> You tried all four?
By looking at my syslog, I tested all and none worked. :(
_
On Wed, Jun 05, 2002 at 07:11:23PM -0700, David Brownell wrote:
> >>But before I do that, is the gist of the patch OK? I'm thinking
> >>specifically the export of those symbols out of usb/core/hcd.c.
>
> I think that's fine, and was going to merge that into a separate
> patch (you should see it
On Wed, Jun 05, 2002 at 11:58:42PM -0400, Doug Alcorn wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
>
> > Nice, does the driver use the usb-storage spec, or is it a vendor
> > specific protocol?
>
> The more I look at it the more I think it doesn't follow the
> mass-storage spec. Keep in mind th
THere is one called drivers/usb/usb-skeleton.c.
On Wed, 5 Jun 2002, Doug Alcorn wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
>
> > Nice, does the driver use the usb-storage spec, or is it a vendor
> > specific protocol?
>
> The more I look at it the more I think it doesn't follow the
> mass-st
Greg KH <[EMAIL PROTECTED]> writes:
> Nice, does the driver use the usb-storage spec, or is it a vendor
> specific protocol?
The more I look at it the more I think it doesn't follow the
mass-storage spec. Keep in mind that I'm pretty new to all this. So,
it takes me about three to four times a
On Thu, 6 Jun 2002 13:46, Marcelo de Paula Bezerra wrote:
> On Thu, 2002-06-06 at 00:24, David Brownell wrote:
> > So, why dies it give up? The diagnostic should give the status code.
> > Just knowing some call fails isn't so useful, but knowing _why_ it
> > does so is half way to knowing what's
On Thu, 6 Jun 2002 13:40, Marcelo de Paula Bezerra wrote:
> On Thu, 2002-06-06 at 00:24, Brad Hards wrote:
> > I have a similar keyboard (only Rev 1.14). I'll try it out on 2.5.
> >
> > Is there any chance that you can test this on another motherboard
> > (especially on OHCI, or an Intel UHCI)?
>
On Thu, 2002-06-06 at 00:24, David Brownell wrote:
>
> So, why dies it give up? The diagnostic should give the status code.
> Just knowing some call fails isn't so useful, but knowing _why_ it
> does so is half way to knowing what's wrong.
All I can do is put some printk's to see what did it re
On Thu, 2002-06-06 at 00:24, Brad Hards wrote:
> I have a similar keyboard (only Rev 1.14). I'll try it out on 2.5.
>
> Is there any chance that you can test this on another motherboard (especially
> on OHCI, or an Intel UHCI)?
I have no access to other hcis :(
All machines I have easy access
On Thu, 6 Jun 2002 13:06, Marcelo de Paula Bezerra wrote:
> My motherboard is an ASUS A7V133 based on VIA KT133A, the keyboard is a
> Microsoft Internet Keyboard Pro.
I have a similar keyboard (only Rev 1.14). I'll try it out on 2.5.
Is there any chance that you can test this on another motherboa
Marcelo de Paula Bezerra wrote:
> I exchanged some e-mail with Vojtech (input layer and usb_hid mantainer)
> until we found out that hid-core.c was giving up here:
>
> hid-core.c line 1331
> if ((n = hid_get_class_descriptor(dev, interface->bInterfaceNumber,
> HID_DT_REPORT, rdesc, rsize)) < 0) {
I exchanged some e-mail with Vojtech (input layer and usb_hid mantainer)
until we found out that hid-core.c was giving up here:
hid-core.c line 1331
if ((n = hid_get_class_descriptor(dev, interface->bInterfaceNumber,
HID_DT_REPORT, rdesc, rsize)) < 0) {
dbg("reading report descriptor fail
>>But before I do that, is the gist of the patch OK? I'm thinking
>>specifically the export of those symbols out of usb/core/hcd.c.
I think that's fine, and was going to merge that into a separate
patch (you should see it on linux-usb-devel later tonight). That
was one of those issues I was wa
Oliver Neukum wrote:
> Am Mittwoch, 5. Juni 2002 16:54 schrieb David Brownell:
>
>OK, but where do we handle the case where resumption is impossible
>because the device has been unplugged ?
If that's not already handled, it'd be a bug in the hub driver.
>>>
>>>Well, how will we h
On Wed, Jun 05, 2002 at 04:14:46PM -0700, Christopher Hoover wrote:
>
> The patch is host controller *independent* -- that code shouldn't ever
> access into that array unless there are elements in it.
Oh I understand the patch is independent, I'm just curious as to how you
are seeing this proble
On Wed, Jun 05, 2002 at 04:24:54PM -0700, Christopher Hoover wrote:
> > Would you mind making up a patch against a clean 2.5.20 (or
> > my usb-2.5 bk tree) with this change.
> >
> > I don't know if the ARM group wants to add this to their
> > tree, but I'm trying to remove the USB ARM portions
On Wed, Jun 05, 2002 at 04:32:08PM -0700, Tom Rini wrote:
> Currently, drivers/usb/core/drivers.c includes to get at
> . The following includes directly.
Applied, thanks.
greg k-h
___
Don't miss the 2002 Sprint PCS Application Deve
Currently, drivers/usb/core/drivers.c includes to get at
. The following includes directly.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
= drivers/usb/core/drivers.c 1.7 vs edited =
--- 1.7/drivers/usb/core/drivers.c Fri Apr 19 00:35:36 2002
+++ edited/drivers/usb/core/
> Would you mind making up a patch against a clean 2.5.20 (or
> my usb-2.5 bk tree) with this change.
>
> I don't know if the ARM group wants to add this to their
> tree, but I'm trying to remove the USB ARM portions from
> their tree, so they don't have to maintain them anymore :)
If rmk is
The patch is host controller *independent* -- that code shouldn't ever
access into that array unless there are elements in it.
> -Original Message-
> From: Greg KH [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 05, 2002 3:56 PM
> To: Christopher Hoover
> Cc: [EMAIL PROTECTED]; [EMAI
On Wed, Jun 05, 2002 at 03:40:32PM -0700, Christopher Hoover wrote:
>
> Fyi.
>
> -Original Message-
> From: Christopher Hoover [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 05, 2002 2:48 PM
> To: [EMAIL PROTECTED]
> Subject: [PATCH] ush-ohci fixes
>
>
>
>
> Move iounmap from co
On Wed, Jun 05, 2002 at 03:33:56PM -0700, Christopher Hoover wrote:
> If there are no interfaces on the active configuration, you get an
> oops. I'm guessing this probably shouldn't ever happen, but it does
> on occassion with the balky SA- OHCI HC.
How does this happen? It should be a host
On Wed, Jun 05, 2002 at 03:17:10PM -0700, Christopher Hoover wrote:
> [PATCH] SA- support for ohci-hcd
>
> This patch is a first cut at SA- support for ohci-hcd. It seems
> to limp along OK.
>
> I intentionally tried to change as little as possible for this first
> cut. Therefore the o
Fyi.
-Original Message-
From: Christopher Hoover [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 05, 2002 2:48 PM
To: [EMAIL PROTECTED]
Subject: [PATCH] ush-ohci fixes
Move iounmap from core to bus glue support (pci needs to iounamp,
sa- does not).
Pickup up fix for urb->next
On Wed, Jun 05, 2002 at 03:17:10PM -0700, Christopher Hoover wrote:
> [PATCH] SA- support for ohci-hcd
>
> This patch is a first cut at SA- support for ohci-hcd. It seems
> to limp along OK.
>
> I intentionally tried to change as little as possible for this first
> cut. Therefore the o
If there are no interfaces on the active configuration, you get an
oops. I'm guessing this probably shouldn't ever happen, but it does
on occassion with the balky SA- OHCI HC.
-ch
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
PATCH_FOLLOWS
KernelVersion: 2.5.18-rmk1
diff -X ../dontdiff
> IIRC, USB device state won't be saved across power transitions. It will
> look like a "disconnect", and "reconnect" on resume. (Forgive me if that's
> not the right USB terminology; I'm just guessing). In that case, when the
> controller gets the SUSPEND_DISABLE call, it can shutdown all the
>
Am Mittwoch, 5. Juni 2002 21:11 schrieb Patrick Mochel:
> On Wed, 5 Jun 2002, Oliver Neukum wrote:
> > > SUSPEND_DISABLE tells the device to stop I/O transactions. When it
> > > stops transactions, or what it should do with unfinished transactions
> > > is a policy of the driver. After this call,
Am Mittwoch, 5. Juni 2002 16:35 schrieb David Brownell:
> Oliver Neukum wrote:
> > Am Mittwoch, 5. Juni 2002 01:46 schrieb David Brownell:
> >>> http://marc.theaimsgroup.com/?l=linux-kernel&m=102320879912115&w=2
> >>> http://marc.theaimsgroup.com/?l=linux-kernel&m=102320879912113&w=2
> >>> http
Am Mittwoch, 5. Juni 2002 16:54 schrieb David Brownell:
> >>>OK, but where do we handle the case where resumption is impossible
> >>>because the device has been unplugged ?
> >>
> >>If that's not already handled, it'd be a bug in the hub driver.
> >
> > Well, how will we handle it with respect to
On Wed, Jun 05, 2002 at 04:08:02PM -0400, Doug Alcorn wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
>
> > But if this doesn't work for you, please let me know and I'll see what I
> > can do.
> >
> > What kind of USB development were you looking to do?
>
> I'll answer the second question first ;).
[PATCH] SA- support for ohci-hcd
This patch is a first cut at SA- support for ohci-hcd. It seems
to limp along OK.
I intentionally tried to change as little as possible for this first
cut. Therefore the organization of the code could be improved -- I
don't care for the .c includes, but
Greg KH <[EMAIL PROTECTED]> writes:
> But if this doesn't work for you, please let me know and I'll see what I
> can do.
>
> What kind of USB development were you looking to do?
I'll answer the second question first ;). My company is looking to
use a DataPlay (http://www.dataplay.com) device in
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.457 -> 1.458
# drivers/net/irda/ir
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.455 -> 1.456
# drivers/usb/core/me
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.456 -> 1.457
# drivers/usb/host/uh
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.454 -> 1.455
# drivers/usb/host/oh
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.453 -> 1.454
# drivers/usb/misc/e
USB changes for 2.5.20
Pull from: bk://linuxusb.bkbits.net/linus-2.5
drivers/net/irda/irda-usb.c|2
drivers/usb/core/message.c |2
drivers/usb/host/ohci-hcd.c| 29
drivers/usb/host/ohci-q.c | 121 ++---
dri
On Wed, 5 Jun 2002, Oliver Neukum wrote:
>
> > SUSPEND_DISABLE tells the device to stop I/O transactions. When it
> > stops transactions, or what it should do with unfinished transactions
> > is a policy of the driver. After this call, the driver should not
> > accept any other I/O requests.
>
On Wed, 5 Jun 2002, Oliver Neukum wrote:
>
> > Whether suspend is called with a given level is a policy of the
> > platform. Some levels may be omitted; drivers must not assume the
> > reception of any level. However, all levels must be called in the
> > order above; i.e. notification will alwa
On Tue, Jun 04, 2002 at 04:28:54PM -0700, David Brownell wrote:
> >>This one-liner fixes a problem in synchronous messaging
> >>with usb_bulk_msg(), usb_control_msg(), and everything
> >>that calls usb_control_msg(): you're not allowed to call
> >>blocking functions when you're already on a wait
On Wed, Jun 05, 2002 at 11:48:33AM -0400, Doug Alcorn wrote:
> Are there any migration plans to make the various BitKeeper
> repositories for USB inherited from the official BitKeeper repos? I'm
> trying to setup a development environment that is cloned from the
> official linux-2.4 repo but stil
Hi,
Here's Pat Mochel's patch to convert the USB core to using the new
driver model core. It's against 2.5.20, and has been forward ported
from 2.5.15, so some things might not be working properly. Also parts
of it are not good at all (the fs.c split is not ok to do for example).
I'm posting it
Are there any migration plans to make the various BitKeeper
repositories for USB inherited from the official BitKeeper repos? I'm
trying to setup a development environment that is cloned from the
official linux-2.4 repo but still has the updates from the usb-2.4
repo. I guess the only way to do
>>>OK, but where do we handle the case where resumption is impossible
>>>because the device has been unplugged ?
>>
>>If that's not already handled, it'd be a bug in the hub driver.
>
> Well, how will we handle it with respect to the resume function ?
> Do we report failure if there's no longer a
Oliver Neukum wrote:
> Am Mittwoch, 5. Juni 2002 01:46 schrieb David Brownell:
>
>>> http://marc.theaimsgroup.com/?l=linux-kernel&m=102320879912115&w=2
>>> http://marc.theaimsgroup.com/?l=linux-kernel&m=102320879912113&w=2
>>> http://marc.theaimsgroup.com/?l=linux-kernel&m=102320879912119&w=2
Am Mittwoch, 5. Juni 2002 16:19 schrieb David Brownell:
> Oliver Neukum wrote:
> >>>I agree. But usbcore should help as far as possible.
> >>
> >>What were you thinking would transform the "device model" level
> >>suspend/resume calls into USB level ones? :)
> >
> > OK, but where do we handle the
Oliver Neukum wrote:
>>>I agree. But usbcore should help as far as possible.
>>
>>What were you thinking would transform the "device model" level
>>suspend/resume calls into USB level ones? :)
>
> OK, but where do we handle the case where resumption is impossible
> because the device has been unp
> > I agree. But usbcore should help as far as possible.
>
> What were you thinking would transform the "device model" level
> suspend/resume calls into USB level ones? :)
OK, but where do we handle the case where resumption is impossible
because the device has been unplugged ?
> >>For example
> SUSPEND_DISABLE tells the device to stop I/O transactions. When it
> stops transactions, or what it should do with unfinished transactions
> is a policy of the driver. After this call, the driver should not
> accept any other I/O requests.
Does this mean that memory allocations in the suspend/
> Whether suspend is called with a given level is a policy of the
> platform. Some levels may be omitted; drivers must not assume the
> reception of any level. However, all levels must be called in the
> order above; i.e. notification will always come before disabling;
> disabling the device will
Am Mittwoch, 5. Juni 2002 01:46 schrieb David Brownell:
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=102320879912115&w=2
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=102320879912113&w=2
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=102320879912119&w=2
>
> By the way, this su
55 matches
Mail list logo
