>>That'd certainly be a better approach for supporting sglist in the
>>usb-storage code than the alternatives I've heard so far.
>
> Could you elaborate ? This sounds interesting.
It's been discussed on linux-usb-devel more than once.
It's really a secondary or tertiary consideration. The top
p
On Wed, Jun 12, 2002 at 08:36:20PM -0400, Johannes Erdfelt wrote:
> On Wed, Jun 12, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> > - change usb_submit_urb and usb_alloc_urb apis
>
> Do you think it's a good idea to change the API in a stable kernel
> series?
When it fixes the real problems the
Here's a followup patch, should apply on top of what I sent
this morning ... please do so! (Sorry, same name but the
patch is different.)
Along with some cleanups, this actually restores a line that
was dropped somewhere in 2.5 ... basically, at least SiS and
OPTi violate the OHCI spec so they d
On Wed, Jun 12, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 12, 2002 at 04:50:30PM -0700, Jean Tourrilhes wrote:
> > Don't rush, I'm not sure if you are done with USB
> > changes. When the new HCD stuff will be in, I'm sure you will find
> > something else to tinker with.
>
> Heh,
Use __dma_buffer to align buffer in struct usb_hub and descriptor in
struct usb_device since both are used for DMA.
Patch is against 2.4.19-pre10.
Thanks,
Roland
drivers/usb/hub.h |3 ++-
include/linux/usb.h |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff -Naur linux
Here is the non-controversial part of the patch I posted last week.
It just gets rid of a few places where DMA is done to variables on the
stack. After discussion on lkml, I think we agreed that DMA into the
middle of kmalloc()'ed structs is wrong and should be fixed with
alignment macros. I'll
On Wed, Jun 12, 2002 at 04:50:30PM -0700, Jean Tourrilhes wrote:
> Don't rush, I'm not sure if you are done with USB
> changes. When the new HCD stuff will be in, I'm sure you will find
> something else to tinker with.
Heh, I _know_ I'm not done with USB changes :)
I'll just be backporting
Hello,
ioctl(LPGETSTATUS) is known to put the status into an int. The usblp
driver has a problem in this area as it does not put it into an int but
into a char. Let's see :
from drivers/char/lp.c : lp_ioctl :
int status
copy_to_user((int *) arg, &status, sizeof(int))
from drivers/
Am Donnerstag, 13. Juni 2002 00:51 schrieb David S. Miller:
>From: Oliver Neukum <[EMAIL PROTECTED]>
>Date: Wed, 12 Jun 2002 21:58:55 +0200
>
>Perhaps I might point out that we need a solution for 2.4.
>
> For 2.4.x just do the DMA alignment macro idea. That would
> be the easiest cha
On Wed, Jun 12, 2002 at 03:57:19PM -0700, Tom Rini wrote:
> On Wed, Jun 12, 2002 at 03:26:24PM -0700, Greg KH wrote:
> > On Wed, Jun 12, 2002 at 03:18:52PM -0700, Tom Rini wrote:
> > > On Wed, Jun 12, 2002 at 03:09:53PM -0700, Greg KH wrote:
> > > > On Wed, Jun 12, 2002 at 11:42:14AM -0700, Tom Ri
On Wed, Jun 12, 2002 at 03:26:24PM -0700, Greg KH wrote:
> On Wed, Jun 12, 2002 at 03:18:52PM -0700, Tom Rini wrote:
> > On Wed, Jun 12, 2002 at 03:09:53PM -0700, Greg KH wrote:
> > > On Wed, Jun 12, 2002 at 11:42:14AM -0700, Tom Rini wrote:
> > > > Since I've been looking at the serial stuff agai
From: Oliver Neukum <[EMAIL PROTECTED]>
Date: Wed, 12 Jun 2002 21:58:55 +0200
Perhaps I might point out that we need a solution for 2.4.
For 2.4.x just do the DMA alignment macro idea. That would
be the easiest change to verify.
On Wed, Jun 12, 2002 at 03:25:01PM -0700, Tom Rini wrote:
>
> Shouldn't the comment in include/linux/usb.h be updated to mention that
> only tables used for MODULE_DEVICE_TABLE should be __devinitdata ?
> Maybe:
> - * Declare the table as __devinitdata, and as a MODULE_DEVICE_TABLE.
> + * Decla
On Wed, Jun 12, 2002 at 10:29:42AM -0700, Greg KH wrote:
>
> And here's one that should get all of the __devinit issues for
> 2.4.19-pre10. I'll go make up a 2.5.21 version of this too.
Here's a copy against 2.5.21:
greg k-h
# This is a BitKeeper generated patch for the following project:
#
On Wed, Jun 12, 2002 at 03:18:52PM -0700, Tom Rini wrote:
> On Wed, Jun 12, 2002 at 03:09:53PM -0700, Greg KH wrote:
> > On Wed, Jun 12, 2002 at 11:42:14AM -0700, Tom Rini wrote:
> > > Since I've been looking at the serial stuff again, I just remembered
> > > that the USB serial stuff has similar
On Wed, Jun 12, 2002 at 10:29:42AM -0700, Greg KH wrote:
> On Wed, Jun 12, 2002 at 09:36:42AM -0700, Tom Rini wrote:
> > On Wed, Jun 12, 2002 at 09:29:47AM -0700, Tom Rini wrote:
> > > On Wed, Jun 12, 2002 at 12:02:52AM +0200, Jeroen Vreeken wrote:
> > > > Is it possible to add some printk() calls
On Wed, Jun 12, 2002 at 03:09:53PM -0700, Greg KH wrote:
> On Wed, Jun 12, 2002 at 11:42:14AM -0700, Tom Rini wrote:
> > Since I've been looking at the serial stuff again, I just remembered
> > that the USB serial stuff has similar (ab)uses of dep_mbool/dep_tristate
> > that drivers/usb/Config.in
On Wed, Jun 12, 2002 at 11:42:14AM -0700, Tom Rini wrote:
> Since I've been looking at the serial stuff again, I just remembered
> that the USB serial stuff has similar (ab)uses of dep_mbool/dep_tristate
> that drivers/usb/Config.in used to have.
This patch disables the ability to select any usb
On Wed, Jun 12, 2002 at 09:31:20AM -0700, David Brownell wrote:
> I tracked down some of those "can't enumerate" problems to a
> chip init problem. This patch detects and reports that case
> (better than the current nasty failure mode, and worth keeping
> even after we have a fix that works on OP
> Based on the discussion, I think the answer for now is to go with
> the (b) variant you had originally started with, using kmalloc for
> the buffers. The __dma_buffer style macro didn't seem popular;
> though I agree that it's not clear kmalloc() really solves it
> today. (Given DaveM's SPARC
Since I've been looking at the serial stuff again, I just remembered
that the USB serial stuff has similar (ab)uses of dep_mbool/dep_tristate
that drivers/usb/Config.in used to have.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
= drivers/usb/serial/Config.in 1.13 vs edited =
--
On Wed, Jun 12, 2002 at 11:05:00AM -0700, Greg KH wrote:
> On Wed, Jun 12, 2002 at 11:04:04AM -0700, Tom Rini wrote:
> > On Wed, Jun 12, 2002 at 10:29:42AM -0700, Greg KH wrote:
> > > On Wed, Jun 12, 2002 at 09:36:42AM -0700, Tom Rini wrote:
> > > > On Wed, Jun 12, 2002 at 09:29:47AM -0700, Tom Ri
On Wed, Jun 12, 2002 at 11:04:04AM -0700, Tom Rini wrote:
> On Wed, Jun 12, 2002 at 10:29:42AM -0700, Greg KH wrote:
> > On Wed, Jun 12, 2002 at 09:36:42AM -0700, Tom Rini wrote:
> > > On Wed, Jun 12, 2002 at 09:29:47AM -0700, Tom Rini wrote:
> > > > On Wed, Jun 12, 2002 at 12:02:52AM +0200, Jeroe
On Wed, Jun 12, 2002 at 10:29:42AM -0700, Greg KH wrote:
> On Wed, Jun 12, 2002 at 09:36:42AM -0700, Tom Rini wrote:
> > On Wed, Jun 12, 2002 at 09:29:47AM -0700, Tom Rini wrote:
> > > On Wed, Jun 12, 2002 at 12:02:52AM +0200, Jeroen Vreeken wrote:
> > > > Is it possible to add some printk() calls
On Wed, Jun 12, 2002 at 09:36:42AM -0700, Tom Rini wrote:
> On Wed, Jun 12, 2002 at 09:29:47AM -0700, Tom Rini wrote:
> > On Wed, Jun 12, 2002 at 12:02:52AM +0200, Jeroen Vreeken wrote:
> > > Is it possible to add some printk() calls in the probe function to
> > > determine where it goes wrong?
>
On Wed, Jun 12, 2002 at 09:29:47AM -0700, Tom Rini wrote:
> On Wed, Jun 12, 2002 at 12:02:52AM +0200, Jeroen Vreeken wrote:
> > Is it possible to add some printk() calls in the probe function to
> > determine where it goes wrong?
[snip]
> And the prink I inserted at the top of the function never g
I tracked down some of those "can't enumerate" problems to a
chip init problem. This patch detects and reports that case
(better than the current nasty failure mode, and worth keeping
even after we have a fix that works on OPTi/SiS/...) as well as
doing some other minor cleanup.
Please merge to
On Wed, Jun 12, 2002 at 12:02:52AM +0200, Jeroen Vreeken wrote:
> On 2002.06.11 23:54:42 +0200 Tom Rini wrote:
> > I'm seeing the following oops when I plug in my old Kensington video cam
> > (se401 driver used to work, but it's been 6+ months since I tried):
[snip]
> > Decoded:
> > >>NIP; c0195d9
Hi,
we are currently working here on a SA-1110 based PDA that will
come out soon. While fighting against USB, I faced the following
problem.
The system:
SA-1110 based PDA, USB over Serial Port 0 (UDC)
Linux 2.4.18-rmk4
Drivers in use: sa1100usb_core, usb_char
Power consumption:
I have three quick questions for USB people.
1.if anybody has tested usb slave mode on mpc823
pls. let me know the setup details like it was tested with which
host , at low or high speed and similar relevant stuff or any
problems faced..
is there any existing slave driver for that ?
2.I am g
Randy.Dunlap wrote:
> Do you have a USB protocol analyzer so that you can see what the
> device and bus are doing? You know that the device is stalling
> on this request (get string index = 100)?
Fortunately the USB device is also under my control, so theres no need
to dig out the protocol anal
On Tue, Jun 11, 2002 at 07:01:46PM -0700, David Brownell wrote:
<... ENXIO ...>
> It could be "usbmodules" talking to the device. I've noticed it doing
> that in the midel of some of my testing ... :)
But it happens also without and any other hotplug stuff. I can reproduce the
ENXIO just with
On Tue, Jun 11, 2002 at 07:01:46PM -0700, David Brownell wrote:
> Jun 6 00:56:06 thunderbird kernel: usb-uhci-hcd.c: ENXIO (Control)
> 8400, flags 0, urb efc879c0, burb efc87940, probably device driver
> bug
> >>>
> >>
> >>Ok, this is the usual ENXIO-problem:
> >>
> >>
> >>
33 matches
Mail list logo
