On Wed, 14 Sep 2005, Bill Rees wrote:
> Hi All,
> While working on a driver for an in-house built usb board, I found
> that even when the board failed to register the id strings were printed
> out. This ended up confusing me for a short while as I expected the
> strings to only show up if
On Wed, 14 Sep 2005, Greg KH wrote:
> Any objections to me adding this to mainline after 2.6.14 comes out?
> I think we now have all of the information that is in
> /proc/bus/usb/devices in sysfs. Or does anyone know of anything we are
> missing?
>
> And yes, it's a huge pain to dynamically crea
> From: Nishant Kamat <[EMAIL PROTECTED]>
> Date: Mon, 12 Sep 2005 19:24:30 -0500
>
> Hi,
>
> I would like some suggestions for testing a high-speed host controller
> driver which is based on a 2.4 kernel.
Well, http://www.linux-usb.org/usbtest is the best way to test
things, but that's only for
> From: Conio sandiago <[EMAIL PROTECTED]>
> Date: Tue, 13 Sep 2005 10:12:09 +0200
>
> Hi all
> I have a USB host controller on a application board.
> The OS is Linux kernel 2.6.12
> Now i want to test the USB host controller.
> Please explain
Start with http://www.linux-usb.org/usbtest/ and make
> That flag already exists. SG_FLAG_LUN_INHIBIT -- see
> sg.torque.net for
> details.
>
> Matt
Thanks, I somehow missed that. It should solve my problem.
Tim
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's
Hi All,
While working on a driver for an in-house built usb board, I found
that even when the board failed to register the id strings were printed
out. This ended up confusing me for a short while as I expected the
strings to only show up if the device registered successfully.
What abo
On Wed, Sep 14, 2005 at 09:57:59AM +0530, Savita H. Neelannava wrote:
>
> Hi All,
>
> I am wrtting USB scanner driver is 2.6.11 kernel.
The usb scanner driver has been removed from the 2.6 kernel tree a while
ago. Please use usbfs instead for this, you do not need a kernel driver
for it.
thank
On Wed, Sep 14, 2005 at 01:18:52PM -0700, Timothy Thelin wrote:
>
> > It ought to be possible to add a flag that would prevent the
> > SCSI midlayer
> > from overlaying the LUN bits on top of cdb[1]. Then we could
> > still set
> > the revision number to 2 and you would be happy.
>
> Sounds
On Wed, Sep 14, 2005 at 12:19:39PM -0700, Timothy Thelin wrote:
>
> > > Why would a usb-storage device ever report itself as scsi0
> > if it actually
> > > supports scsi3? Is it because the USB/ATA bridge spec
> > doesn't support asking
> > > the device it self, so the usb-subsystem just makes
I haven't been able to understand why the transfers fail under Linux whereas
it works fine under Windows (note that I am using the same Windows driver
in Linux, albeit with ndiswrapper). All URBs exchanged until the failed URB
seem to be identical. The URB that fails is 2400 bytes long bulk IN URB.
Any objections to me adding this to mainline after 2.6.14 comes out?
I think we now have all of the information that is in
/proc/bus/usb/devices in sysfs. Or does anyone know of anything we are
missing?
And yes, it's a huge pain to dynamically create sysfs attributes and
attribute groups on the f
On Wed, 14 Sep 2005, David Brownell wrote:
> > > The parameter isn't needed, or even usable, without the recursion
> > > removed in the previous patch.
> >
> > These patches look great, and I intend to go through them carefully. At
> > first glance, there appears to be a small problem in the pm-
> It ought to be possible to add a flag that would prevent the
> SCSI midlayer
> from overlaying the LUN bits on top of cdb[1]. Then we could
> still set
> the revision number to 2 and you would be happy.
Sounds plausable, but i'm not an expert on the Linux scsi stack
to know where the flag
A regression wrt 2.6.11.
Begin forwarded message:
Date: Wed, 14 Sep 2005 11:04:54 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 5253] New: usb storage disappears after hotplug
http://bugzilla.kernel.org/show_bug.cgi?id=5253
Summary: usb storage disa
On Wed, 14 Sep 2005, Timothy Thelin wrote:
> > SCSI 3 triggers new and exciting behavior from SCSI core.
Note that usb-storage even sets the version number for SCSI-3 devices back
to 2. That's because a lot of them report SCSI-3 and then crash when
asked to carry out a REPORT LUNS command.
It
> > Why would a usb-storage device ever report itself as scsi0
> if it actually
> > supports scsi3? Is it because the USB/ATA bridge spec
> doesn't support asking
> > the device it self, so the usb-subsystem just makes an (un?
> ;)-educated
> > guess? Or is it because it is possible, but the
> On Wed, Sep 14, 2005 at 10:45:37AM -0700, Timothy Thelin wrote:
> >
> > I was curious about the reasoning behind this decision and
> how to fix an
> > issue that came up because of it.
>
> The reasoning goes something like this: There are lots of
> devices which
> report 0, but need the SCS
> On Wednesday 14 September 2005 19:45, Timothy Thelin wrote:
> > I was curious about the reasoning behind this decision and
> how to fix an
> > issue that came up because of it.
> > ...
> > (1) Is easy to do, but is it going to cause other issues?
> I'd imagine any
> > *usb storage* device tha
On Wed, Sep 14, 2005 at 08:29:19PM +0200, Christian Iversen wrote:
> On Wednesday 14 September 2005 19:45, Timothy Thelin wrote:
> > I was curious about the reasoning behind this decision and how to fix an
> > issue that came up because of it.
> > ...
> > (1) Is easy to do, but is it going to cause
On Wed, Sep 14, 2005 at 10:45:37AM -0700, Timothy Thelin wrote:
>
> I was curious about the reasoning behind this decision and how to fix an
> issue that came up because of it.
The reasoning goes something like this: There are lots of devices which
report 0, but need the SCSI-II 10-byte commands
A regression.
Begin forwarded message:
Date: Wed, 14 Sep 2005 07:13:56 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 5250] New: Cannot find USB devices on 2.6.13.1, on
ICH4m chipset
http://bugzilla.kernel.org/show_bug.cgi?id=5250
Summary: Cannot f
On Wednesday 14 September 2005 19:45, Timothy Thelin wrote:
> I was curious about the reasoning behind this decision and how to fix an
> issue that came up because of it.
> ...
> (1) Is easy to do, but is it going to cause other issues? I'd imagine any
> *usb storage* device that reports scsi0 rea
I was curious about the reasoning behind this decision and how to fix an
issue that came up because of it.
Here is the issue found:
1) Some USB storage peripherals identify themselves as following scsi spec 0
(i.e. "we don't follow a spec, we just kinda magically work with some of the
commands fo
Nothing earth-shattering, these came up from people reading
the code not real-world error reports.
- Dave
Three minor sl811-hcd fixes:
- Elminate memory leak on one (rare) disable/shutdown path.
- For periodic transfers that don't need to be scheduled, update
urb->start_frame to represent t
> > The parameter isn't needed, or even usable, without the recursion
> > removed in the previous patch.
>
> These patches look great, and I intend to go through them carefully. At
> first glance, there appears to be a small problem in the pm-usbsusp patch:
Not with that patch ... it's actually
I saw this when compiling the pxa25x_udc driver in the lastest linus git
kernel. I've included a patch below as one way of cleaning this up.
CC drivers/usb/gadget/pxa2xx_udc.o
drivers/usb/gadget/pxa2xx_udc.c: In function `write_ep0_fifo':
drivers/usb/gadget/pxa2xx_udc.c:532: warning: passin
On Tue, 13 Sep 2005, David Brownell wrote:
> The parameter isn't needed, or even usable, without the recursion
> removed in the previous patch.
These patches look great, and I intend to go through them carefully. At
first glance, there appears to be a small problem in the pm-usbsusp patch:
st
27 matches
Mail list logo
