OK, here's the patch against 2.5.20. I broke into three pieces -- one
that pulls the PCI support out of core/hcd.c, one that fixes a bug or
two in the old ohci driver, and one for the new ohci driver that
splits the bus glue out and adds SA- support.
It works on SA-1110/SA-0 when dropped
I use the userspace driver for my Alcatel USB speedtouch modem.
On system shutdown I get the following oops. I have attached some
system info to this email.
Ciao,
Duncan.
ksymoops 2.4.5 on i586 2.4.19-pre10. Options used
-V (default)
-k /var/log/ksymoops/20020605092043.ksyms (specif
diff -X dontdiff.txt -Naur linux-2.5.20/drivers/usb/host/usb-ohci.c
linux-2.5.20-usbwork/drivers/usb/host/usb-ohci.c
--- linux-2.5.20/drivers/usb/host/usb-ohci.cSun Jun 2 18:44:44 2002
+++ linux-2.5.20-usbwork/drivers/usb/host/usb-ohci.cWed Jun 5 17:41:37 2002
@@ -66,7 +66,12 @@
#inclu
diff -X dontdiff.txt -Naur linux-2.5.20/drivers/usb/host/ohci-hcd.c
linux-2.5.20-usbwork/drivers/usb/host/ohci-hcd.c
--- linux-2.5.20/drivers/usb/host/ohci-hcd.cSun Jun 2 18:44:41 2002
+++ linux-2.5.20-usbwork/drivers/usb/host/ohci-hcd.cWed Jun 5 18:27:07 2002
@@ -12,6 +12,9 @@
*
*
The SA- OHCI (at least the one on my board) sometimes get in a
screwy mode and reports no interfaces. I haven't been able to track
down why yet.
-ch
> -Original Message-
> From: Greg KH [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 05, 2002 4:55 PM
> To: Christopher Hoover
>
Greg,
Ah. Our patches crossed in the mail.
I just sent a set of patches to linux-usb-devel against 2.5.20. There
are three parts -- one of them is pretty similar to yours below and the
other two address usb-ohci and ohci-hcd.
arm: the patch works in 2.5.18-rmk1 if you tweak the Makefiles an
> I seem to recall pointing you at usb-storage once already,
> as the only USB driver today which needs to do such stuff.
> It has a notion of device identity, based ISTR on serial
> numbers, and saves that state. UTSL.
You quote this as an example of how to do things.
I am not especially happy w
Hi all,
I'm developing a driver for our USB smart card reader.
We use a custom made USB-serial converter with interrupt endpoints.
In the open() method I want to start reading. Therefore I'm sending an INT URB.
But the system blocks after the usb_submit_urb() call.
What I am missing?
I attach
Could you submit this line to
/driver/usb/storage/unusual_devs.h ?
UNUSUAL_DEV( 0x0686, 0x400a, 0x0001, 0x0001, "Minolta", "Dimage S404",
US_SC_SCSI, US_PR_BULK, NULL, US_FL_START_STOP ),
according to http://www.qbik.ch/usb/devices/showdev.php?id=1187
--
Ernest Beinrohr, OERNii
eAdmin
> > The genric layer that did request the resumption must be told
> > that this was impossible and the device should be purged.
>
> Last time I did suspend/resume of a system with USB, the hub
> driver _already_ handled that. Presumably it still does.
Sadly I cannot test that. The ohci driver c
> Here's a patch against 2.5.20 that splits out the pci specific parts of
> hcd.c into hcd-pci.c.
>
> ...
>
> Christopher, does this patch make your patch easier?
>
> David, any complaints about this patch?
Only the interference with this patch. It's certainly
along the right lines,
Hi there.
Is this the right list on which to ask about the status of support for
specific USB devices? In case it is, I'm asking about the following
devices:
1. A friend of mine has a USB "Pen Camera" whose box labels it as
being the "Trio PenCam VGA" and is running the recently released
[EMAIL PROTECTED] wrote:
>>I seem to recall pointing you at usb-storage once already,
>>as the only USB driver today which needs to do such stuff.
>>It has a notion of device identity, based ISTR on serial
>>numbers, and saves that state. UTSL.
>
>
> You quote this as an example of how to do thi
This info needs to get to HID and/or usb-uhci-hcd folk, not me ... :)
Marcelo de Paula Bezerra wrote:
> On Thu, 2002-06-06 at 00:55, David Brownell wrote:
>
>
>>Modify the dbg statement -- it's just a regular printf format,
>>so add a "%d" and pass the return value in the argument list.
>>
>>-
On Thu, Jun 06, 2002 at 03:30:32PM +0100, Riley Williams wrote:
> Hi there.
>
> Is this the right list on which to ask about the status of support for
> specific USB devices? In case it is, I'm asking about the following
> devices:
Not really the correct place, there's a link off of linux-usb.or
On Thu, Jun 06, 2002 at 10:17:38AM -0700, David Brownell wrote:
> This info needs to get to HID and/or usb-uhci-hcd folk, not me ... :)
>
>
> Marcelo de Paula Bezerra wrote:
> >On Thu, 2002-06-06 at 00:55, David Brownell wrote:
> >
> >
> >>Modify the dbg statement -- it's just a regular printf f
Hi!
> > > 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
> > All calls are made with interrupts enabled, except for the
> > SUSPEND_POWER_DOWN level.
>
> This is a slight problem for USB. We need to switch on interupts
> to send a message to the device.
For example, to enable remote wakeup (whenever we start to
support that). I understand that a
> Named media is one of the standard models for volume management,
Yes, but the names used by usb-storage are sda, sdb, ...
Names that are quite unrelated to the media.
If I put card 1 in reader 1, and then card 2 in reader 1,
and then card 1 in reader 2 what do you want to happen?
No, names sho
Well, to defend Matt, he's doing the best that can be done under the circumstances.
A device driver is asked to do things that a higher layer should do.
But this should point us to not using this code unless really necessary.
If the bus is physically detached and reattached we can do nothing.
If
In the interest of de-complicating the API and code,
I wonder how folk would react to removing the flag
that enables bulk queuing ... doing it as needed but
without needing an explicit request.
How it works today: when the UHCI drivers find a
bulk URB being submitted to an endpoint that already
My only concern is that the behavior be _very_ well defined for this. I
can think of all sorts of corner-cases (URBs about to complete, endpoints
halted, zero-length packets, etc) which all need to be covered before we
make a change like this.
Matt
On Thu, Jun 06, 2002 at 12:41:54PM -0700, Davi
Matthew Dharm wrote:
> My only concern is that the behavior be _very_ well defined for this. I
> can think of all sorts of corner-cases (URBs about to complete, endpoints
> halted, zero-length packets, etc) which all need to be covered before we
> make a change like this.
I'm not clear on what y
On Thu, Jun 06, 2002 at 01:11:06PM -0700, David Brownell wrote:
> Matthew Dharm wrote:
> > My only concern is that the behavior be _very_ well defined for this. I
> > can think of all sorts of corner-cases (URBs about to complete, endpoints
> > halted, zero-length packets, etc) which all need to
Hi!
> What did seem to be missing was anything saying whether
> those device methods would be called in_interrupt() or
> whether instead they could sleep. I'd hope all of them
> would be specified to allow blocking as needed, like their
> current analogues in PCI and USB.
Look better, it was th
> ... though FWIW I missed seeing anything that showed how
> those API summaries would place constraints on allocating
> memory, so I didn't assume there could be any.
It specified that there would be no valid assumptions on the
order of devices woken up. Thus the devices that would be paged
to
Details: 2.5.18-rmk1 + 2.5.20 usb + my ohci-hcd (although it will happen
with usb-ohci-sa too as well as 2.5.18-rmk1 usb).
I can do small dd's off the device just fine:
==
Initializing USB Mass Storage driver...
usb.c: registe
On Thu, Jun 06, 2002 at 02:06:30PM -0700, David Brownell wrote:
> > I'd like to see all those URBs terminated immediately, but
> > I'm sure others would like to see them all executed as if nothing had
> > happened.
>
> I agree that it makes no sense to continue processing later URBs queued
> on t
More USB changes for 2.5.20
Pull from: bk://linuxusb.bkbits.net/linus-2.5
drivers/usb/class/Config.in |1
drivers/usb/class/Makefile |1
drivers/usb/class/usb-midi.c | 2228 +++
drivers/usb/class/usb-midi.h | 143 ++
drivers/usb/core/Makef
On Thu, Jun 06, 2002 at 03:30:32PM +0100, Riley Williams wrote:
> 2. I have a serial digital camera (the Fuji MX2700), and have obtained
> a USB reader for the SmartMedia cards that it takes. This reader
> came in a plain white box with nothing but the price sticker on it,
> and no m
# 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.447.2.5 -> 1.447.2.6
# drivers/usb/cor
# 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.447.2.6 -> 1.447.2.7
# drivers/usb/cla
# 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.466 -> 1.467
# drivers/usb/core/hc
On Thu, 6 Jun 2002 13:52, Brad Hards wrote:
> 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 moth
On Thu, Jun 06, 2002 at 09:51:03AM -0700, David Brownell wrote:
> > Here's a patch against 2.5.20 that splits out the pci specific parts of
> > hcd.c into hcd-pci.c.
> >
> > ...
> >
> > Christopher, does this patch make your patch easier?
> >
> > David, any complaints about this patch?
>
> On
On Thu, Jun 06, 2002 at 12:37:57AM -0700, Christopher Hoover wrote:
>
> The SA- OHCI (at least the one on my board) sometimes get in a
> screwy mode and reports no interfaces. I haven't been able to track
> down why yet.
So the USB device reports no interfaces? This isn't a host controlle
Note that this doesn't provide any reason not to get rid of that flag
a bit later in the 2.5 series.
This sub-thread addresses different issues related to bulk queueing.
Ones I agree also need to be handled consistently.
>>>I'd like to see all those URBs terminated immediately, but
>>>I'm sure
> I just sent on my previous hcd-pci.c split up patch to Linus, so
> hopefully it will make it into the next kernel release. Then I'd be
> glad to take either of David's or Christopher's patches on top of that
> one.
I took the two parts of my patch and sent them separately ... I
know those "uhc
This has two minor tweaks to the uhci-hcd driver:
- removes some duplicated code (HCD framework does that test)
- corrects a FIXME comment (no issue)
Appropriate for merging to Linus' latest.
- Dave
--- ./drivers/usb-dist/host/uhci-hcd.c Mon Jun 3 11:11:11 2002
+++ ./drivers/usb/host/uhci-h
As was discussed a few weeks back, this moves most of the
sanity checks and input conditioning for the HCD framework's
usb_submit_urb() support directly into usb_submit_urb(), so
that all HCDs (not just those using the sharable HCD framework
support) can rely on them.
Please merge to Linus' tree.
On Thu, Jun 06, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> This has two minor tweaks to the uhci-hcd driver:
>
> - removes some duplicated code (HCD framework does that test)
> - corrects a FIXME comment (no issue)
>
> Appropriate for merging to Linus' latest.
Looks good to me. Thanks fo
This patch allows ov511 to build again by removing references to
urb->next. It now resubmits in the completion handler and properly sets
urb->interval.
The driver compiles fine now, but I can't promise that it works since
2.5.20 wouldn't boot for me.
Please apply. Thanks!
--
Mark McClelland
So the keyboard generates 2 event devices?
1 for the regular keys, and another for the special keys? (this is
expected behavior).
Anyway, I'll contact the uchi mantainer again.
On Thu, 2002-06-06 at 19:00, Brad Hards wrote:
> On Thu, 6 Jun 2002 13:52, Brad Hards wrote:
> > On Thu, 6 Jun 2002 13:
On Mon, Jun 03, 2002 at 10:35:58PM -0700, Mark McClelland wrote:
> Jim Richardson wrote:
>
> >On Sat, Jun 01, 2002 at 11:23:47AM -0700, Dmitri wrote:
> >
> >
> >>On Wed, 2002-05-29 at 20:58, an unknown sender wrote:
> >>
> >>
> >>>The ProScope appears to use the Divio Prolink chipset, at leas
On Fri, 7 Jun 2002 14:35, Marcelo de Paula Bezerra wrote:
> So the keyboard generates 2 event devices?
> 1 for the regular keys, and another for the special keys? (this is
> expected behavior).
Yes. All works fine with OHCI (2.4 and 2.5).
> Anyway, I'll contact the uchi mantainer again.
I did a q
45 matches
Mail list logo