Am Montag, 23. Juni 2003 07:22 schrieb David Brownell:
Oliver Neukum wrote:
what needs to be included to get 64bit DMA?
For a USB network driver, set NETIF_F_HIGHDMA.
Well, I should be more specific. What needs to be
#include ???
Regards
Oliver
Am Montag, 23. Juni 2003 07:26 schrieb David Brownell:
Oliver Neukum wrote:
looking through gadget it seems to me that two kinds of drivers
are mixed that shouldn't be mixed. Ether.c is a not a gadget driver
in the strict sense. It implements a class on the gadget's side.
Ether.c is a
hello!
Could you help me?
at MPC850 i let USB host work,but have some problems.the host driver is
m8xxhci.c of brad.
i usb the command :mknod sda b 8 0, mknod sda1 b 8 1,in the direction
of dev.is it ok?
when i mount OnlyDisk of Netac (mount /dev/sda1 /mnt/usbdisk),the
infomation
On Fri, Jun 20, 2003, Luck, Tony [EMAIL PROTECTED] wrote:
On Fri, Jun 20, 2003 at 04:11:07PM -0400, Johannes Erdfelt wrote:
Here's a patch from Tony Luck that fixes a problem with the UHCI
debugging code on architectures with big page sizes. We end up
allocating more than kmalloc
On Sun, 2003-06-22 at 16:06, Matthew Dharm wrote:
The problem as I see it is ATAPI devices. That means that sbp2, ide-scsi,
and usb-storage (all of which bridge ATAPI devices to the SCSI layer) will
be affected. These devices don't include the DBD bit in their command
specification -- the
Got this message upon booting 2.5.72 on my Sony Vaio C1VE Picturebook
with an internal USB memory stick reader:
Initializing USB Mass Storage driver...
usb-storage: This device (054c,0032) has an unneeded SubClass entry in
unusual_devs.h
Please send a copy of this message to
what needs to be included to get 64bit DMA?
For a USB network driver, set NETIF_F_HIGHDMA.
Well, I should be more specific. What needs to be
#include ???
find /usr/src/linux/include -name '*.h' |xargs grep NETIF_F_HIGHDMA
---
This SF.Net
Oliver Neukum wrote:
By analogy, you'd be arguing that audio.c is not a device driver
in the strict sense ...
Yes. We recognise the difference and put them into seperate directories.
We should do the same for the gadget side.
Maybe someday when the device side tree grows as unwieldy as
the host
On Mon, 23 Jun 2003, Stelian Pop wrote:
Got this message upon booting 2.5.72 on my Sony Vaio C1VE Picturebook
with an internal USB memory stick reader:
Initializing USB Mass Storage driver...
usb-storage: This device (054c,0032) has an unneeded SubClass entry in
unusual_devs.h
Hello,
thanks for replying.
Von: David Brownell [mailto:[EMAIL PROTECTED]
Eventually, we'll have it -- you saw a patch of mine to
handle it a while
back, that basically worked.
What basic kernel version are you referencing? On host side we still use
2.4.20 with tiny real time patches.
On Fri, 20 Jun 2003 14:22:10 -0600
Jackson Chan [EMAIL PROTECTED] wrote:
Secondly, I am trying to write a single output report to my device
that contains 5 bytes of data{0x13,0x13,0,0,0} through the Control
(0) endpoint via a SetReport command. I tried using hidiocsusage
and
Sorry for junk traffic,
has been answered before.
(Who doesn't hate M$ Outlook? :-| )
Siegfried.
---
This SF.Net email is sponsored by: INetU
Attention Web Developers Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We
Is it OK to have the USB transfer buffer (parameter 7 to usb_control_msg())
in kernel stack?
The documentation says that This buffer has to be allocated as a
non-pageable contiguous physical memory block and if it's placed in stack
it works on x86, but is it safe thing to do across all
On Mon, Jun 23, 2003 at 09:33:45AM -0500, James Bottomley wrote:
Have you actually heard of setting DBD causing a failure on ATAPI
devices?
I believe I have, but I can't site anything solid. Which means (likely)
that there were multiple possible explanations.
We've changed a lot of MODE_SENSE
Can usb_disconnect() and usb_probe() functions of a driver pre-empt the
driver in other parts? I mean, that if user has just called my open()
function in the driver, could usb_disconnect() happen before the system
call returns?
If usb_disconnect() can happen while already executing in open(), and
When an USB driver returns non-NULL from usb_probe(),
the interface is automatically allocated to it as if it would have
called usb_driver_claim_interface(). Right?
And this allocated interface does not need to be released at
usb_disconnect() i.e. usb_driver_release_interface() does not need to
On Mon, Jun 23, 2003 at 08:39:33PM +0300, Tuukka Toivonen wrote:
Can usb_disconnect() and usb_probe() functions of a driver pre-empt the
driver in other parts? I mean, that if user has just called my open()
function in the driver, could usb_disconnect() happen before the system
call returns?
From: Tuukka Toivonen [EMAIL PROTECTED]
Date: Mon, 23 Jun 2003 20:39:33 +0300 (EEST)
If usb_disconnect() can happen while already executing in open(), and if
the former frees the data structures used by the driver, then the latter
call might continue working with already freed memory region
On Mon, Jun 23, 2003 at 11:42:18AM -0400, Alan Stern wrote:
Congratulations! You're the first person to submit an email in response
to that new kernel log message.
To help determine the proper change needed to the unusual_devs.h file,
could you please also post the contents of your
On Monday 23 June 2003 19:53, Greg KH wrote:
On Mon, Jun 23, 2003 at 08:39:33PM +0300, Tuukka Toivonen wrote:
Can usb_disconnect() and usb_probe() functions of a driver pre-empt the
driver in other parts? I mean, that if user has just called my open()
function in the driver, could
On Mon, 23 Jun 2003, Pete Zaitcev wrote:
If usb_disconnect() can happen while already executing in open(), and if
the former frees the data structures used by the driver, then the latter
call might continue working with already freed memory region which could
lead to catastrophe.
This is why
On Mon, Jun 23, 2003 at 08:39:33PM +0300, Tuukka Toivonen wrote:
Can usb_disconnect() and usb_probe() functions of a driver pre-empt the
driver in other parts? I mean, that if user has just called my open()
function in the driver, could usb_disconnect() happen before the system
call returns?
On Llu, 2003-06-23 at 19:11, Tuukka Toivonen wrote:
Let's suppose user calls open() on my device. The first line of open()
call could lock semaphores, increase reference counts, whatever, but all is
useless if usb_disconnect() happens _after_ open() system call but _before_
the first line of
Date: Mon, 23 Jun 2003 21:11:35 +0300 (EEST)
From: Tuukka Toivonen [EMAIL PROTECTED]
If usb_disconnect() can happen while already executing in open(), and if
the former frees the data structures used by the driver, then the latter
call might continue working with already freed memory
Am Montag, 23. Juni 2003 19:39 schrieb Tuukka Toivonen:
Can usb_disconnect() and usb_probe() functions of a driver pre-empt the
driver in other parts? I mean, that if user has just called my open()
function in the driver, could usb_disconnect() happen before the system
call returns?
Yes.
Am Montag, 23. Juni 2003 20:11 schrieb Tuukka Toivonen:
On Mon, 23 Jun 2003, Pete Zaitcev wrote:
If usb_disconnect() can happen while already executing in open(), and if
the former frees the data structures used by the driver, then the latter
call might continue working with already freed
Eventually, we'll have it -- you saw a patch of mine to
handle it a while back, that basically worked.
What basic kernel version are you referencing?
As I already said in the duplicate message you sent
directly to me (I wish someone would fix whatever
mailer it is that does that): that patch
These questions seem to have gotten lost in the shuffle.
On Mon, 23 Jun 2003, Tuukka Toivonen wrote:
When an USB driver returns non-NULL from usb_probe(),
the interface is automatically allocated to it as if it would have
called usb_driver_claim_interface(). Right?
Yes.
And this allocated
Thanks Sergey,
I guess I falsely assumed that the report count(1) for Output Reports was
supported because it was supported for Input Reports(read). Do you know how
long things like this usually take to get fixed? Without this fix, USB
SMART Board interactive whiteboards won't work on Linux.
Can you also send the /proc/bus/usb/devices information with your floppy
drive plugged in?
Alan Stern
On Mon, 23 Jun 2003, Stelian Pop wrote:
Here they are.
Stelian.
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D:
On Mon, Jun 23, 2003 at 05:16:21PM -0400, Alan Stern wrote:
Can you also send the /proc/bus/usb/devices information with your floppy
drive plugged in?
Damn, I was sure I did. Sorry.
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso=
Am Montag, 23. Juni 2003 17:11 schrieb David Brownell:
Oliver Neukum wrote:
By analogy, you'd be arguing that audio.c is not a device driver
in the strict sense ...
Yes. We recognise the difference and put them into seperate directories.
We should do the same for the gadget side.
Maybe
Hi,
this tells the network layer that we can DMA from high memory
if the host controller supports it.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
On Mon, Jun 23, 2003 at 11:56:15PM +0200, Oliver Neukum wrote:
Am Montag, 23. Juni 2003 17:11 schrieb David Brownell:
Oliver Neukum wrote:
By analogy, you'd be arguing that audio.c is not a device driver
in the strict sense ...
Yes. We recognise the difference and put them into
On Sat, Jun 21, 2003 at 04:41:02PM +0800, David Glance wrote:
A change introduced into usb-uhci.c in 2.4.21 causes the kernel to
freeze when usb-uhci is used with any driver using one-shot interrupt
transfers. The attached fix was originally proposed by Frode Isaksen and
improved by Pete
Sergey, I think you are right about the bug.
This looks like a bug/misfeature in hiddev(output) - it does not support
items
with Report Count 1 (when the number of usages for a data item is less
than the
number of values).
When I add this logic to the hid-core.c( to .hid_add_field() ), I
On Tue, Jun 24, 2003 at 12:40:58AM +0200, Oliver Neukum wrote:
Hi,
this tells the network layer that we can DMA from high memory
if the host controller supports it.
Applied, thanks.
greg k-h
---
This SF.Net email is sponsored by: INetU
From: Greg KH [EMAIL PROTECTED]
Date: Mon, 23 Jun 2003 15:45:38 -0700
What problem does this cause with these drivers (the lego and visor
one.)?
The usb-uhci was an oops with a NULL pointer. In ohci case it wasn't
an oops, but something didn't work, I forgot the symptom.
With ohci, the driver doesn't work unless the patch is applied.
On Tue, 2003-06-24 at 07:47, Pete Zaitcev wrote:
From: Greg KH [EMAIL PROTECTED]
Date: Mon, 23 Jun 2003 15:45:38 -0700
What problem does this cause with these drivers (the lego and visor
one.)?
The usb-uhci was an oops
System freezes.
On Tue, 2003-06-24 at 06:45, Greg KH wrote:
On Sat, Jun 21, 2003 at 04:41:02PM +0800, David Glance wrote:
A change introduced into usb-uhci.c in 2.4.21 causes the kernel to
freeze when usb-uhci is used with any driver using one-shot interrupt
transfers. The attached fix was
unsubscribe
--- [EMAIL PROTECTED] wrote: Send
linux-usb-devel mailing list submissions to
[EMAIL PROTECTED]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
or, via email, send a message with subject or body
I saw that you enabled synaptics support always with the ps/2 driver. This is
evil as it kills my Synaptics touchpad on my Gateway 600 series laptop. With
2.4, I can use the synaptics driver for XFree on the web to use all the cool
features. With 2.5.before73-and-without-synaptics-support, I
42 matches
Mail list logo
