On Sat, May 07, 2005 at 01:40:42PM -0700, David Brownell wrote:
> > > > Here are some spelling corrections for drivers/usb.
> > > >
> > > > cancelation -> cancellation
> > >
> > > For the record, "cancelation" (one "l" not two "ll") is
> > > correct, though recently I've found some dictionaries
On Mon, Feb 28, 2005 at 03:34:33AM -0800, Lawrence Porter wrote:
> Sorry Phil, mistake on my part, I'm a newby
Yes. Do not say "it doesnt work", but tell what hardware
you have, what kernel you have, what you do, what happens,
what error messages result.
This list is archived, but so far this con
On Thu, Feb 03, 2005 at 10:56:05AM -0500, Alan Stern wrote:
> Basically the situation is this: There's a config option for usb-storage
USB_STORAGE_RW_DETECT - a bad idea - it must not be necessary to recompile
the kernel (or at least usb-storage) when encountering a bad device.
Many users get t
Thomas Shaefer wrote in kernel bugzilla entry 3505:
--
Distribution: RedHat9
Hardware Environment: HP Omnibook XE 3 GC and others
Software Environment: Redhat 9 partly updated / Aurox 9 / SuSe
Problem Description:
since at least Kernel 2.
On Sun, Jan 09, 2005 at 04:24:00PM +0200, Boris Dinkevich wrote:
> It seems like removable usb devices in windows get formatted without a
> partition table
> (I can't even create partitions on removable devices).
>
> Problem is, Linux seems to expect a partition table, and just reads garbage
>
On Sun, Dec 19, 2004 at 10:37:23PM -0800, Pete Zaitcev wrote:
> On Sun, 19 Dec 2004 22:20:55 -0800, Matthew Dharm <[EMAIL PROTECTED]> wrote:
>
> > I can tell you that this has turned into the single largest source of bug
> > reports/complaints about usb-storage. Something has to be done. I just
On Sun, Jun 13, 2004 at 10:21:49AM -0700, Matthew Dharm wrote:
> Try this version on for size. Lots of help-text changes, but also a key
> change in how the CONFIG option is processed. I think the last version I
> sent was logically inverted from what we described.
>
> Matt
>
>
> = driver
On Fri, Apr 09, 2004 at 11:11:34AM -0700, Brian Thomason wrote:
> I've been toying with LinEAK to preset some default actions for the
> "multimedia" keys on some of the more prominent keyboards used today. I
> have a few different logitech models, and all of their keys function
> properly whe
On Mon, Apr 05, 2004 at 08:39:56AM -0300, Marcelo Tosatti wrote:
> On Tue, Mar 30, 2004 at 01:56:14PM -0800, Greg KH wrote:
> > On Tue, Mar 30, 2004 at 12:44:09AM +0200, [EMAIL PROTECTED] wrote:
> > > datafab.c has an often-seen bug: the SCSI READ_CAPACITY command
> > > does not need the number of
On Mon, Mar 29, 2004 at 03:15:08PM -0800, Matthew Dharm wrote:
> On Tue, Mar 30, 2004 at 12:44:09AM +0200, [EMAIL PROTECTED] wrote:
> > datafab.c has an often-seen bug: the SCSI READ_CAPACITY command
> > does not need the number of sectors but the last sector.
>
> The first part of the patch (whic
People ask how to write the CIS on a SmartMedia card
using an sddr09 reader/writer. The patch below documents
the required command (but does not add the code).
Two years ago or so I used this to fix the CIS on a card
that my camera no longer wanted to accept. A Linux utility
to do this might be us
Aha - I recalled that I had a writeCIS command, but see
that it is not in the current kernel. Should update that driver.
The comment gives the important information:
/*
* Write CIS Command: 12 bytes.
* byte 0: opcode: EE
* bytes 2-5: write address in shorts
* bytes 10-11: sector count
*
* T
> So everybody who does not want to know how integers are represented
> on the current architecture writes
> start = p[0] + (p[1] << 8) + (p[2] << 16) + (p[3] << 24);
> And it just works.
Really, do you think your statement is better, clearer, or less
error-prone than t
| Let me tell you - I have programmed for twenty years without
| knowing the meaning of little-endian and big-endian. Yes,
| they had something to do with the order of bytes in an integer,
| but there are many strange architectures and mixed versions,
| and there is no need at a
From: Alan Stern <[EMAIL PROTECTED]>
> > - ptr[4] = MSB_of(info->pagesize>>16);
> > - ptr[5] = LSB_of(info->pagesize>>16);
> > - ptr[6] = MSB_of(info->pagesize&0x);
> > - ptr[7] = LSB_of(info->pagesize&0x);
> >
Hmm. I am not precisely happy with improvements like
- ptr[4] = MSB_of(info->pagesize>>16);
- ptr[5] = LSB_of(info->pagesize>>16);
- ptr[6] = MSB_of(info->pagesize&0x);
- ptr[7] = LSB_of(info->pagesize&0x);
+ ((u32 *) pt
From: Eduard Hasenleithner <[EMAIL PROTECTED]>
> One can arbitrarily choose info->lun = 0 or, as you do here,
> info->lun = srb->device->lun, but that may be true or not.
>
> A CF+SM reader has a CF part, and it has a srb->device->lun,
> and it has a SM part, with a differ
From: Eduard Hasenleithner <[EMAIL PROTECTED]>
Here is a patch for test11 which modifies the datafab driver according
to my understanding of the datafab device. I completely removed the lun
detection but left this work up to the operating system, namely
sd_mod.ko. sd_mod can
> Comments?
Will look later.
Andries
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
I don't have a card reader and know almost nothing about how they work.
But following this thread has inspired a question: What happens to the lun
mapping when there are two slots in the reader and _both_ slots have a
card inserted?
The mapping does not depend on the presence of m
My own sources have somewhere at the top of datafab.c the comment
/*
* Commands: 8 bytes
* Three commands are known:
*
* Identify: 00 01 00 00 00 a0 ec 01
* (with b0 instead of a0 for LUN 1).
*
* Read: 00 nn xx xx xx ex 20 01
* (with f0 instead of e0 for LUN 1;
* nn: sector c
From [EMAIL PROTECTED] Sun Dec 7 16:04:37 2003
From: Eduard Hasenleithner <[EMAIL PROTECTED]>
The lun detection relies (maybe non-intentional) on the fact that a CF
card is inserted. If no CF is inserted no LUN is detected.
Please find attached only the commands which were
> Does this fix the LUN-selection problem Eduard pointed out?
Eduard, does it?
(That is, if you remove your lun assignment patch, so that the driver
does this silly broken lun detection again, but add my "beenhere" hack
to avoid infinite recursion upon scsi error recovery, does the "detect"
then c
From [EMAIL PROTECTED] Fri Dec 5 07:16:54 2003
> Below a patch fixing both problems. Now my two-lun device works
> for CF and it works for SM but not both - depending on the order
> of the entries in unusual_devices.
Why not? Can't we just use "srb->devic
> Is the size of the card reported correctly, or is it 1 too large?
On an 8 MB CF card:
datafab: SCSI device sdd: 15873 512-byte hdwr sectors (8 MB)
sddr09: SCSI device sdb: 15872 512-byte hdwr sectors (8 MB)
Hmm. Now that I look - it is just that the driver is broken.
Nothing wrong with th
This afternoon I bought a 64MB SmartMedia card to play with.
That was good - several details with the zoning turn out to be
slightly different from what the old driver assumed.
So here is an improved patch. It works for me with 8MB, 16MB and
64MB cards.
Andries
--- /linux/2.6/linux-2.6.0test9/lin
Can someone verify my decoding? (This matches what Dmitri sent earlier
that did not make it to the list, execept it looks like it starts with an
INQUIRY VPD page 0 - get a list of supported VPD pages).
No, that is not a SCSI command.
> TransferBuffer: 0x0012 (18) length
>
On Fri, Oct 17, 2003 at 07:56:45PM -0400, Sheldon Lee-Wen wrote:
> I was under the impression that the kernel would/should at least always see
> the raw scancode (where this is not a value between 0 and 255)
Your impression is incorrect.
The raw scancode is a byte and cannot be a value outside 0
On Fri, Oct 17, 2003 at 03:52:00PM -0400, Sheldon Lee-Wen wrote:
> Pardon my evilness in cross posting this, But I need to get a discussion going
> on how to resolve this problem.
>
> One lineak user went and tested his keyboard. Here is what he got. It does
> appear that for the keys that do n
From [EMAIL PROTECTED] Tue Sep 23 16:05:21 2003
> Also "conservative mode" sounds like a flag that describes some
> way of being broken.
>
> On the other hand "hot-pluggable" describes a positive asset,
> and if we can conclude from that that it is unnecessary to ask
From [EMAIL PROTECTED] Mon Sep 22 21:29:06 2003
On Mon, 2003-09-22 at 13:55, [EMAIL PROTECTED] wrote:
> if (sdkp->media_present) {
> sd_read_capacity(sdkp, disk->disk_name, sreq, buffer);
> if (sdp->removable)
>
> Basically, Andries Brouwer's strategy of making sd.c more conservative has
> been a very successful one in the past. Why not continue on that?
% I would be interested in hearing what Andries has to say. ...
% The variety of ways in which these things fail is truly amazing.
Yes.
We have just se
On Thu, Sep 11, 2003 at 11:41:31AM -0700, Greg KH wrote:
> On Thu, Sep 11, 2003 at 05:33:25PM +0200, Ubaldi Fabio wrote:
> > Hi all,
> >
> > I'm looking for a USB sniffer for linux; but i found in google only sniffer
> > USB for Windows (as usbsnoopy).
> > Does anybody know any USB sniffer sofware
On Mon, Aug 11, 2003 at 06:13:50PM -0700, Jeff Woods wrote:
> Looking only at the above code snippet, I'd suggest something more like:
> + if (!sdp ||
This is not meaningful.
A general kind of convention is that a pointer will be NULL either
by mistake, when it is uninitialized, or on p
On Tue, Aug 12, 2003 at 07:53:53AM +0100, Christoph Hellwig wrote:
> > I see an Oops in the SCSI code, caused by the fact that sdkp is NULL
> > in sd_shutdown. "How can that be?", you will ask - dev->driver_data was set
> > in sd_probe. But in my case sd_probe never finished. An insmod usb-storage
From: Fabien Grumelard <[EMAIL PROTECTED]>
Subject: Re: Apacer SM/CF combo reader driver
> If you need the SM half, ask me again.
yes, this is what I want to use.
About the 07c4:a109 CF+SM Apacer LC1 reader:
I just checked status in 2.4.21.
The CF half words if
(1) Deadlock
A few hours ago I wrote:
---
Now that I mentioned that inserting usb-storage hangs forever
and then causes a SCSI oops, the question arises how the hang
is caused. It turns out to be a semaphore deadlock.
What happens is that base/bus.c:bus_add_driver() downs
down_write(&bus
I see an Oops in the SCSI code, caused by the fact that sdkp is NULL
in sd_shutdown. "How can that be?", you will ask - dev->driver_data was set
in sd_probe. But in my case sd_probe never finished. An insmod usb-storage
hangs forever, or at least for more than six hours, giving ample opportunity
to
On Sat, Aug 09, 2003 at 02:00:06PM +0100, Phoenix wrote:
> Is it possible to send ATAPI commands to usb-storage hard-disks, like
> WIN_SECURITY_UNLOCK, through the scsi inteface?
>
> I have an ALI5621 chipset that supports SCSI transparent command set
> only and I didn't find anything in SCSI-2 t
On Tue, Aug 12, 2003 at 05:24:50PM -0700, Mike Anderson wrote:
> > > Well, this same problem could show upb in any other driver. Could
> > > you instead send a patch to Pat that the driver model never calls
> > > the shutdown method for a driver that hasn't finished ->probe?
> >
> > I think it a
I've got an Apacer SM/CF combo reader too. I found your email :
I just got myself an Apacer SM/CF combo reader, USB 07c4:a109.
The CF part is supported in the stock kernel (by datafab.c),
the SM part is not.
This evening I wrote a
On Thu, Jul 31, 2003 at 06:52:06AM -0400, Wakko Warner wrote:
> What about this one:
> Bus 001 Device 002: ID 0781:0005 SanDisk Corp. SDDR-05b (CF II) ImageMate
> CompactFlash Reader
That is reported to work with the unusual dev patch
+/* glc: Greg Corcoran -- tested with SDDR-05b */
+UNUSUAL_
On Thu, Jun 12, 2003 at 12:10:27AM -0700, Randy.Dunlap wrote:
> I'm trying to use 'tunelp' to test it. The latest version that I can
> find source code for is 1.3, but
tunelp is part of util-linux
tunelp-1.3 is ancient
Andries
---
This SF.N
On Fri, Mar 28, 2003 at 07:13:48PM +0100, [EMAIL PROTECTED] wrote:
> I am trying to get a Nike mp3 player running under Linux.
> I am using linux kernel 2.4.21pre6 and enabled debug in usb-storage.
> Attached is the output after connecting the player on the usb bus. Linux finds a
> usb mass storag
From [EMAIL PROTECTED] Mon Mar 3 20:08:12 2003
The 2.4 support has been available since April of 2002:
http://www.kernel.org/pub/linux/kernel/people/aeb
It was announced on the kernel mailing list, and doesn't seem to have
gotten any negative feedback, but it never became p
On Fri, Jan 24, 2003 at 10:09:32AM -0800, Matthew Jacob wrote:
> > It's like when I pull the power plug because my system is totally hosed and
> > I want to start over. I know I can cause damage by doing that, but I would
> > be upset if the new system booted back to the broken state it was in wh
Last year I wrote half a dozen drivers for various USB card readers.
Some don't work anymore with 2.5.recent.
I just investigated one. The reason it stopped working is the
sd_read_cache_type()
call added in 2.5.41. (With that call removed it works again.)
Will look a bit more at the details late
>> The id is not suitable as a user space name. Moreover,
>> it is a heuristic only, and user space needs unambiguous names.
> If we had a complete white/black list of devices with/without a unique id,
> there would be no ambiguity.
You mean for the devices on the white list.
But most devices wil
> US_FL_DONT_FIX_INQUIRY_LENGTH
Oh, people, please.
There is no problem. So it is a waste of time trying to solve
this non-problem.
If the device transmits 36 bytes, then we have 36 bytes.
What are these bytes used for? To get a vendor name.
A SCSI standard lawyer might wish to distinguish the ca
> But, we don't have to truncate, we should just allocate as many bytes as
> we need, and store the information.
> And, the sysfs name should not store the id.
OK. It seems that we are in total agreement.
Time for the next question.
An id is constructed, that in many cases identifies something.
> We can tell if the id sdev->name should be unique by looking at
> the first byte (it is not unique if the value is 'Z'),
> SCSI_UID_UNKNOWN.
Such things are nontrivial.
% cat /sysfs/devices/ide-scsi/0:0:0:0/0:0:0:0/name
SHP CD-Writer+ 8200 [
Here the serial number consists of the '[' only
> Instead of truncating the id, we need a new scsi_uid field allocated
> to whatever size required.
> And, a descriptive string put in the name, rather than the id, such as:
> scsi disk
[I changed the Subject line "Re: inquiry in scsi_scan.c" since people
are still discussing devices with a buggy
> In the case reported, the problem was
Ha, Alan - it is possible that the two of you are referring
to different things.
I mentioned two devices, both return 36 bytes when asked for
36 bytes, but the first has 0 in the additional length field
(thus reports length 5), the second has 32 in the addi
Zwane Mwaikambo writes:
> This looks related to something i also bumped into
>
> scsi scan: host 2 channel 0 id 0 lun 0 identifier too long
Sounds familiar. Please try the below (on 2.5.54).
Andries
diff -u --recursive --new-file -X /linux/dontdiff a/drivers/scsi/scsi_scan.c
b/drivers/scsi/sc
[EMAIL PROTECTED] wrote:
>
> The SCSI code has no means of knowing the actual length transferred,
> so has no choice but to believe the length byte in the reply.
> But the USB code does the transferring itself, and knows precisely
> how many bytes were transferred. If 36 by
Matthew Dharm writes:
> Instead of fixing this in usb-storage, I think I would rather make
> scsi_scan.c just assume a minimum of 36.
No, because (for SCSI-1) the minimum is 5.
> Or, put another way, if the first request indicates less than 36, why
> should we do a second request? We already ha
By the way - there are other cases where the INQUIRY length is
reported incorrectly. Another device does:
usb_stor_bulk_transfer_buf(): xfer 37 bytes
00 80 02 02 20 00 00 00 65 55 53 42 20 20 20 20
43 6F 6D 70 61 63 74 20 46 6C 61 73 68 20 20 20
00 00 00 00
usb-storage: Status code 0; transferr
Matthew Dharm writes:
> There should probably be a sanity check to never ask for INQUIRY
> less than 36 bytes. I thought there used to be such a thing
As Doug also points out, we ask for 36, but there is no
guarantee that we get what we ask for.
> Actually, 5 isn't minimal... it's sub-minim
On Tue, Nov 19, 2002 at 04:47:58PM -0800, David Brownell wrote:
>
> >>Yeah, looking at struct urb, transfer_buffer is a void *, so nevermind,
> >>I'll take this patch. Sorry for the noise :)
> >
> >It's really a bunch of bytes, right? So u8 * would be a better description?
>
> Doesn't "void *" b
On Thu, Oct 17, 2002 at 09:55:49PM -0400, Ed Tomlinson wrote:
> In the patch fest in the last couple of days usb storage support for sddr09
> has broken. I see the following in the log (2.5.43-mm2):
> Oct 17 21:37:07 oscar kernel: sddr09: Found Flash card, ID = 00 00 00 00: Manuf.
>unknown, 40
I just sent this to linux-kernel.
Maybe I should have cc'ed linux-usb. Here a copy.
-
A moment ago I wanted to get some photographs off some
CF cards. Under 2.5.42 lots of things failed.
First of all, no USB device worked because the hub things
wer
Greg, attached is a patch designed for diagnostic purposes. Please apply
to the 2.5 tree -- yes, we'll be removing this at some point in the future.
It appears that we have a problem clearing halts. This patch causes a very
clear message to be printed whenever a usb_stor_clear_h
I have not looked at this at all, maybe this is nonsense,
but at very first sight, when I see this patch, with code like
result = usb_storage_bulk_transport(us, SCSI_DATA_READ,
buf, bulklen, 0);
- if (result != USB_STOR_TRANSPORT_GOOD)
+
>> Most media doesn't have a serial number or any way to uniquely identify it.
Indeed.
> While I understand that there is no solution that will solve it for all
> devices/media, should we penalize those devices and/or media which do
> make it possible?
Yes we should, because of uniformity.
It i
On Sun, Jul 07, 2002 at 09:15:50PM +0200, Torsten Mohr wrote:
> i just bought a new Device "Multislot CF/SM/SD/MMC/MS USB"
> card reader from company Hama (www.hama.de).
>
> The card reader itself has four connectors for several
> memory devices. It shows up as four "removable hard disks"
> und
From: David Brownell <[EMAIL PROTECTED]>
> Earlier, I reported an oops at shutdown. I just looked at
> what causes the oops and find that the call
> hcd->driver->stop()
> is executed while hcd->driver->stop is NULL.
>
> ...
> USB people may worry whether hcd->
Earlier, I reported that 2.5.22 and 2.5.23 do not boot.
With Marcin's IDE-93 this is corrected, and the system boots.
Earlier, I reported an oops at shutdown. I just looked at
what causes the oops and find that the call
hcd->driver->stop()
is executed while hcd->driver->stop is NULL.
So,
>Life would be easier if the scsi subsystem would just report which SCSI
>device (uniquely identified by the controller,bus,target,unit tuple) belongs
>to which high-level device. The information is available in the kernel.
>
>Attached patch does this:
>garloff@pckurt:/raid
> Named media is one of the standard models for volume management,
Yes, but the names used by usb-storage are sda, sdb, ...
Names that are quite unrelated to the media.
If I put card 1 in reader 1, and then card 2 in reader 1,
and then card 1 in reader 2 what do you want to happen?
No, names sho
> I seem to recall pointing you at usb-storage once already,
> as the only USB driver today which needs to do such stuff.
> It has a notion of device identity, based ISTR on serial
> numbers, and saves that state. UTSL.
You quote this as an example of how to do things.
I am not especially happy w
>>Yes, I must keep coming back until this is cleared up.
...
>>[Can the author of that code (try to) check that the locking stuff is OK?]
> Could you enable the debugging
Problem has been found and fixed. A wild pointer was created,
and what happened afterwards was essentially random. Below
> Some devices are even more delicate than that,
> hence the customized clear_halt code in usb-storage.
Yes. Could you perhaps add a comment in transport.c?
Right now it says something like
"some devices crash their internal firmware
when the status is requested after a halt"
but "some devices"
>> Andries, what kind of USB problems did you have with 2.5.16?
Obscure problems. However, this patch fixes things.
--- /linux/2.5/linux-2.5.18/linux/drivers/usb/storage/transport.c Tue May 21
07:07:37 2002
+++ /linux/2.5/linux-2.5.18a/linux/drivers/usb/storage/transport.c Sun May 26
> There's the much discussed USB storage bulk/control problem
> which is a slightly different, but still related locking issue.
Can you tell me all about it? Or give pointers?
[2.5.18 hangs, 2.5.18 with 2.5.15 usr/storage fails with uhci
but works with alternate uhci; it smells a bit like a lock
== Andries, what kind of USB problems did you have with 2.5.16?
Yes, I must keep coming back until this is cleared up.
2.5.14 works.
2.5.15 works.
2.5.16 hangs upon insmod usb-storage
2.5.16 with the usb/storage directory replaced by that from 2.5.15 works
The patch from 2.5.15 to 2.5.16 is 130
> One minor nit, can you make sure I can
> apply the patch using '-p1'?
Yes - I generate my patches still in Linus-pre-BK style.
Will change.
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Veg
> I don't quite understand your reasoning for not completing
> the code consolidation.
Not so impatient.
The perfect development model is small steps, frequent updates.
If there is a bug in 2.5.N+1 and things work in 2.5.N and the
change between them is a simple and obvious one, then it is very
Okay, now I'm seeing where you are headed...
So why are you creating all these new functions and not just using the
control/bulk messaging functions in transport.c, which do all the
scatter-gather management for you?
Matt
Well, you see, in my own tree I h
> IIRC, hid_submit_report submits an interrupt URB, not control.
Please read 2.5.17:hid-core.c line 1161.
Andries
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintp
: > But this problem is new, AFAIR I only changed the message, not the
: > detection. Thus the HID driver has more than one control URB outstanding...
: > I will look into that...
: Or it could be ...
I missed the original mail, but I have a little bit of information
on the situation.
The devic
Ach, too quick.
> diff -urb
that should have been "diff -urbN". Sorry about that.
Am not going to send the diff once more. Below the new files.
raw_bulk.h
#ifndef _USB_STORAGE_RAW_BULK_H_
#define _USB_STORAGE_RAW_BULK_H_
/* usb bulk */
extern int usb_storage_send_control(
str
>> Matt, you asked for a diff -b. But can't you make that yourself?
> I could, in theory, make a diff -b myself. However, then I would have an
> extra development tree on my machine to keep track of, and that's something
> I like to avoid.
Hmm. I just typed
% cd /tmp
% tar xfz /linux/2.5/linux
== Andries, what kind of USB problems did you have with 2.5.16?
It is a bit late, but I just compiled a kernel.
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_UHCI_HCD=y
etc.
Now usbview doesnt work, even though usbdevfs is mounted.
I consider that a bug in the usbdevfs code.
After the mount th
>> It is not clear to me why these CF and SM drivers should
>> replace sg buffers by a single big contiguous buffer.
> No, they should not be using a single big buffer. They
> should use the scatter-gather list that was given to them by the midlayer.
Good. I hoped you would say that. That again
>> Matt, is this patch ok to apply?
> Yes and no.
> Parts of it look okay, and parts don't.
Can you be more precise? Or is the plural just your single following remark?
> why have retries dropped from 10 to 3 in one place?
Yes, you spotted the only change in behaviour,
apart from possible chan
> Andries, what kind of USB problems did you have with 2.5.16?
I hoped that everybody would have problems, so that the source
of the problems would be immediately obvious to someone who
knows USB and the recent changes better.
I have only vague reports.
Do "insmod usb-storage". The insmod hangs
Is this patch against the latest code (i.e. Greg's super merge)?
Or has that material not yet been released? I saw the patch go out,
but I'm still getting up-to-speed on the Bitkeeper stuff
The patch was against 2.5.16.
I know that CVS repositories exist, but so far have never l
Created the first of a series of usb-storage patches
this afternoon. Please find it below or on ftp.XX.kernel.org
under people/aeb/2.5.16-us-patch .
It removes 5% of the usb-storage code, but should, if I made
no mistake, not affect the behaviour of the code.
(This is the introduction of raw_bulk
> You must be a CompSci guy.
Even worse: a mathematician.
> An EE would have disassembled the device long before now
In fact I opened it. The outside had no markings at all.
Inside there were strings "HT B 94V-O" with fat "HT",
and "190N01417V102". The chip has 44 pins and was
covered by a Qual
: That looks a lot like a Cypress/Anchor Chips device
: that needs firmware downloaded to it before it will work properly.
: Is that what this device needs?
Yes.
= Looks like a Cypress EZUSB or FX (or FX2 maybe), without any firmware
Indeed.
Now that the two of you mention this, I looked at th
> Good lord! What the hell is this!
> This is completely like any usb-storage device I've ever seen
Unlike?
My conjecture about the origin is this:
A company perhaps called PrimeFilm, or perhaps Carry, or perhaps
something else, made the USB chip for a 6-in-1 Compact Flash,
SmartMedia, Memo
The SDDR-09 driver is, well, not one of our finest works. :)
We call usb_set_configuration() to change to a specific alternate
configuration for this device. Is there some sort of problem with
calling that function?
It is almost the opposite, there is some sort of problem with
> usb_new_device -> usb_set_configuration -> usb_set_maxpacket
Yes, for config 0.
> wonder if usb-storage is using a different configuration
> without calling usb_set_configuration?
Yes, that is what happens.
Andries
___
Have big pi
> Are you using an invalid endpoint? You're right, MxPS is not zero in
> any of those, but since it parsed alright, there's no reason why
> dev->exmaxpacketin/out should be 0.
It is not clear at all why dev->epmaxpacketin/out should be
anything but 0. This array is never initialized as far as
I c
> The next step is making this device actually do something.
Well, if you need to talk to that endpoint, then you'll need to kludge
it by hacking the core to ignore the wMaxPacketSize value and hardcoding
it to another value.
It is not wMaxPacketSize that is zero, it is dev->
>> Why does the kernel die?
> The host controller authors can answer this one
Looking at the source we see in uhci.c:uhci_submit_bulk()
the loop
do {
...
len -= maxsze;
...
} while (len > 0);
When maxsze is zero this loop will take
> But, you're absolutely right about an error message being preferable to
> a dead system. The patch is simple enough and I've attached it to the
> bottom of this message.
Well, since 0 is not an illegal value as specified in the USB spec, I
think we should do this check in th
> The patch is simple enough and I've attached it
Good. Now both drivers survive.
The next step is making this device actually do something.
Andries
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the ha
Playing with some strange device with vendor protocol,
I find that alt-uhci crashes the kernel without any messages
or information. (No oops, just dead.)
On the other hand, uhci comes back with an error message
usb-uhci.c: uhci_submit_urb: pipesize for pipe c0030400 is zero
Since an error mes
ffd
#endif
- smartmedia.c -
/*
* SmartMedia driver, aeb, koninginnedag 2002
*
* (c) 2000, 2001 Robert Baruch ([EMAIL PROTECTED])
* (c) 2002 Andries Brouwer ([EMAIL PROTECTED])
*/
#include
#include
#include "transport.h"
#include "smartmedia.h"
#include "debug.h"
1 - 100 of 121 matches
Mail list logo
