On Sun, Mar 13, 2005 at 10:21:38PM -0500, Alan Stern wrote:
On Sun, 13 Mar 2005, Ben Dooks wrote:
This is an updated patch for the OHCI host controller
on the Samsung S3C24xx series of CPUs. The patch is
an re-work of the previous patch sent to the list,
with some tidying, and updated
www.xuzhou89189.com
0516-8990316 QQ:356268656
010-68405330
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype.
In usb 1.1 specification 5.8.4(page 47):Bulk
transfers can be used only by full-speed devices.I
think Bulk transfers and Interrupt Transfers are
same(all are IN OUT tokens and DATA HandShake pakets)
in the protocol level.Can it work If i implement a
bulk pipe in low-speed device? Is it bandwidth
Or could I simply pass the intf pointer from usb_hid_configure()
to hid_parse_report() and there assign it to device-intf so it can
be dereferenced later?
Passing the interface to parse_report() sounds simplest.
Ok, I went for that solution, and it seems to work for me (although
most dbg
On Sat, 12 Mar 2005, Grant Grundler wrote:
Maybe this would help narrow the search?
| Date: Tue, 6 Mar 2001 20:20:25 +0300
| From: Ivan Kokshaysky [EMAIL PROTECTED]
| To: Grant Grundler [EMAIL PROTECTED]
| Cc: linux-kernel@vger.kernel.org
...
| The other part of the comment I added was:
Brian Murphy wrote:
Oliver Neukum wrote:
Could you make a single patch for that?
Regards
Oliver
Here are the patches resubmitted with the exporting of symbols split
off to
a seperate patch.
/Brian
Make sure
On Mon, 14 Mar 2005, Brian Murphy wrote:
This was nice in theory and partially fixes the problem (no more crash)
unfortunately
the module removal hangs if the data interface is attempted to be
removed first.
This seems to be because usb_driver_claim_interface is not the same as
On Mon, 14 Mar 2005, camel yang wrote:
In usb 1.1 specification 5.8.4(page 47):Bulk
transfers can be used only by full-speed devices.I
think Bulk transfers and Interrupt Transfers are
same(all are IN OUT tokens and DATA HandShake pakets)
in the protocol level.Can it work If i implement a
On Sun, 13 Mar 2005, Guilhem Lavaux wrote:
Hi,
Here is the syslog corresponding to your request. I've added a few
comments to show you the moment the events happen.
You're seeing two different errors here. And there are a few things
in the log I don't understand; it's possible that your
Am Montag, 14. März 2005 16:57 schrieb Brian Murphy:
The best fix I have found so far is to detect if the disconnect function
is called first
with the data interface and just return without doing anything, waiting
to be called
with the control interface (see attached patch). This fixes
On Monday 14 March 2005 7:57 am, Brian Murphy wrote:
Brian Murphy wrote:
This seems to be because usb_driver_claim_interface is not the same as
claiming the interface in the probe routine causing the call to
usb_driver_release_interface to not decrement some reference
count somewhere.
Replying myself, after several sleepless nights I've found the problem
and solution.
I'm having problem with several embeded machines using USB2.0
Whenever I try to stream bulk URBs (that is, resubmit the URB
immedaitely
from inside the irq handler), the kernel oopses somewhere in keventd.
I'm
On Monday 14 March 2005 12:35 pm, Petr Nejedly wrote:
The problem was that the buffer passed in URBs was allocated using
pci_alloc_consistent(). When I changed this to kmalloced buffer, it started
working reliably. I'll notify DVB developers about this.
I still don't know why does it *really*
On Mon, 14 Mar 2005, Guilhem Lavaux wrote:
Ok. A new log is attached (gzipped). I have also attached
'before_unplugging' which the file named uhci/:00:1d.0 in debugfs
before I unplug the usb key the first time.
'after_plugging.after_rmmod' is after having removed and inserted again
On Sun, Mar 13, 2005 at 02:54:37AM +0530, Jayaprakash Shanmugam wrote:
Thanks David. I am one of the victims of Monta Vista.
Then complain to them about this, nothing we can do here with their
kernels...
Good luck,
greg k-h
---
SF email is
Fix gcc printk arg type and other function parameter warnings:
drivers/usb/misc/sisusbvga/sisusb.c: In function `sisusb_send_packet':
drivers/usb/misc/sisusbvga/sisusb.c:583: warning: passing arg 7 of
`sisusb_send_bulk_msg' from incompatible pointer type
drivers/usb/misc/sisusbvga/sisusb.c:591:
Fix gcc printk arg type warnings:
drivers/usb/media/pwc/pwc-if.c:325: warning: int format, different type arg
(arg 2)
drivers/usb/media/pwc/pwc-if.c:1182: warning: int format, different type arg
(arg 4)
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
diffstat:=
drivers/usb/media/pwc/pwc-if.c |
Alan Stern wrote:
On Mon, 14 Mar 2005, Brian Murphy wrote:
This was nice in theory and partially fixes the problem (no more crash)
unfortunately
the module removal hangs if the data interface is attempted to be
removed first.
This seems to be because usb_driver_claim_interface is not the
In come to my attention that the later SuSE kernel has
change the /proc/bus/usb/devices to
/proc/bus/usb/devices_please-use-sysfs-instead.
Of course, that breaks the VMWare and I add some option
to use this wired file name.
I am wondering how to get the devices change event from
sysfs in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Randy.Dunlap wrote:
| Fix gcc printk arg type and other function parameter warnings:
|
| drivers/usb/misc/sisusbvga/sisusb.c: In function `sisusb_send_packet':
| drivers/usb/misc/sisusbvga/sisusb.c:583: warning: passing arg 7 of
`sisusb_send_bulk_msg'
Has anyone hacked up PictBridge gadget-side support so that a device without
a host controller can speak to a printer?
Ciao,
-ch
ch--at--murgatroid.com
ch--at--hpl.hp.com
---
SF email is sponsored by - The IT Product Guide
Read honest
Hello
I have implements usb-mass storage support on Intel pxa271. My backing
file is DiskOnChip(/dev/tffsa,/dev/tffsa1). Most of the time, it works
normal, but there still has a few questions:
First. when I use usb storage,I use hotplug script to umount /truefs1,
and when plug off usb
On Monday 14 March 2005 5:42 pm, Christopher Hoover wrote:
Has anyone hacked up PictBridge gadget-side support so that a device without
a host controller can speak to a printer?
http://www.cipa.jp/english/pictbridge/
Suggests that it'd only be _some_ printers, namely ones that
embed a USB
Hi Pete,
I am following Rubini's Linux Device Driver book. I am working on 2.4.18,
and I am wondering, why you said you cannot get anything working!! Atleast
the block drivers implemented using CURRENT are working with 2.4.18 (as you
mentioned, the floppy.c).
P.S. I can't migrate to 2.6 since
mohanlal jangir wrote:
Don't copy from floppy.c, it's one of the most convoluted block drivers.
No wonder you cannot get anything working. CURRENT is retarded, don't
use it. Migrate to kernel 2.6 and copy from ub.c.
-- Pete
Really? Last I heard, UCLA's OS class had a project that was to write a
25 matches
Mail list logo
