The problem with reimplementing the usb_register_dev() is the non
existing external access to the "static struct file_operations
*usb_minors[MAX_USB_MINORS]".
The FPGA board itself has only iso endpoints, the rest of the system is
controlled via control messages. One could in principle implement
[CC: list pared down]
On Sun, 28 Aug 2005, Daniel Ritz wrote:
> > I was going to fix things by passing the driver as an explicit argument to
> > device_bind_driver and device_release_driver. That way the subroutines
> > can test the current value of dev->driver while holding the semaphore,
>
Alan
It looks to me more like a timing problem with initialization of the
external high-speed hub. Try this patch:
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=112439094723976&w=2
Thank you very much: the patch seems indeed to fix the problem.
However, I didn't boot more than twice wit
> > Currently I've made a preliminary firmware for implementing the
> > CDC-ACM interface, however as Pavel kindly pointed out for me,
> > currently only 64Kbyte/sec is achieveable with this driver. I've read
> > the archives and from the discussions, I suspect that this is
> > connected to th
> From: "Andy Chuo" <[EMAIL PROTECTED]>
> Date: Mon, 29 Aug 2005 09:47:32 +0800
>
> ...
>
> The development platform is running Linux 2.4.21-rmk2 and as far as I
> understand this version (not till 2.4.23) doesn't support USB Gadget driver.
That is, it doesn't bundle support for that framework.
Greg Lee wrote:
Currently I've made a preliminary firmware for implementing the
CDC-ACM interface, however as Pavel kindly pointed out for me,
currently only 64Kbyte/sec is achieveable with this driver. I've read
the archives and from the discussions, I suspect that this is
connected to the
> I wrote my own user space driver which has achieved write
> speeds of 900k/s.
900 K bits/sec or 900 K bytes/sec?
Greg
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Dev
Greg Lee wrote:
I wrote my own user space driver which has achieved write
speeds of 900k/s.
900 K bits/sec or 900 K bytes/sec?
Greg
That would be bytes :)
/Brian
---
SF.Net email is Sponsored by the Better Software Confer
On Mon, 29 Aug 2005, Brian Murphy wrote:
> It seems that the acm driver sets the maximum transfer size to
> the wMaxPacketSize field of the relevant endpoint descriptor,
> this is maximum 64 bytes for a bulk high speed endpoint.
> From my experiments this does not just restrict bulk packets to
>
> >900 K bits/sec or 900 K bytes/sec?
> >
> >Greg
> >
> That would be bytes :)
>
> /Brian
Thanks. 900 K bits/sec === bad, 900 K bytes/sec === good!
Greg
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22
Hi,
I trying to track down a usb failure on several late 2.4 kernels (2.4.18
and 2.4.21) with usb flash disks.
Some usb flash disks work and some disks don't. The ones that fail seem
to give odd "READ CAPACITY failed" messages.
I just sending this in case anyone else has seen it and has an ins
On Monday 29 August 2005 17.09, Alan Stern wrote:
> [CC: list pared down]
>
> On Sun, 28 Aug 2005, Daniel Ritz wrote:
>
> > > I was going to fix things by passing the driver as an explicit argument
> > > to
> > > device_bind_driver and device_release_driver. That way the subroutines
> > > can
> From: Daniel Ritz <[EMAIL PROTECTED]>
> Date: Tue, 30 Aug 2005 00:39:36 +0200
>
> ...
>
> if i didn't miss anything usb's check for knode_bus is also stupid workaround
> to avoid a double device_bind_driver()...
USB is one of very few subsystems that really _needs_ to be using the
two phase ini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
HI Alan et al,
Alan Stern wrote:
>
> At least you've ruled out the operating system version as the source of
> the problem.
Well, that's not yet clear to me. The two systems have significantly
different hardware configurations.
>
>>I've tried pl
Pete Zaitcev wrote:
> The stick replies to the door lock commands with a check condition
> (e.g. FAIL status in a normal bulk CSW), but the subsequent REQUEST SENSE
> returns all-zero sense. The situation is documented in our Bugzilla,
> including usbmon traces.
> https://bugzilla.redhat.com/bugzi
This patch is originally from Sebastian Kapfer, with a few tests and a
rediff from me. This keeps the NEC USB floppy from reporting 8 identical
luns.
Reported-by: Sebastian Kapfer <[EMAIL PROTECTED]>
Signed-off-by: Phil Dibowitz <[EMAIL PROTECTED]>
--
Phil Dibowitz [E
Phil Dibowitz wrote:
> This patch is originally from Sebastian Kapfer, with a few tests and a
> rediff from me. This keeps the NEC USB floppy from reporting 8 identical
> luns.
>
> Reported-by: Sebastian Kapfer <[EMAIL PROTECTED]>
> Signed-off-by: Phil Dibowitz <[EMAIL PROTECTED]>
Erm. Greg, don'
Greg,
This patch adds entries for several USB floppies that need
the US_FL_SINGLE_LUN flag. These were reported by
Sebastian Kapfer <[EMAIL PROTECTED]> and Olaf Hering
<[EMAIL PROTECTED]>, with rediffing and cleaning from me.
NOTE: This is a re-do of the previous pd32 patch which should be discar
Hello Greg,
I'm using usbserial driver to communicate with USB Mobile phones. It was
started with 2.4 kernel and now we are using Red Hat Enterprise Linux
Edition 4 with kernel version 2.6.9-5, driver functionalities are
working fine.
Now we have to upgrade to update 1 from Red Hat. We tried wi
19 matches
Mail list logo
