Re: [linux-usb-devel] [PATCH] USB: Spelling fixes for drivers/usb.
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 listing cancellation (two ll) as an option. It'd be nice to do that ... fixes should really not change things that started out correct! At work a few years ago we actually did some research on this issue and, as a result of finding that the ll usage was not very widely accepted (in several dictionaries and quite a few CS research papers), we switched everything to use the single l usage. Which is why USB has so far been consistent about that form. Funny. I would have used -ll-. Let me see. - My Webster has -ll- and does not recognize -l-. - Cambridge Advanced Learner's dictionary has only -ll- - Merriam-Webster online says that -l- is a variant of -ll- - American Heritage says the same - Encarta says -l-: see -ll- - Webster 1828 has only -l- This quick test seems to show a strong preference for -ll- Let us ask Google. -ll-: about 22,100,000 -l-: about 205,000 and the question did you mean cancellation? (And what about the technical USB context? Again Google: -ll- + usb: about 251,000 -l- + usb: about 667.) So, I will not contradict your statement that cancelation is correct, but it certainly looks like cancellation is preferred, and that is also what the USB specs talk about. Andries --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB memory-stick Mandrake 10.1
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 conversation does not contain information. The memory-stick IS formatted, but in FAT32 Yes, it is being recognized. It appears to get attached to /dev/sda but not be formated. You have not shown any kernel messages yet. Have you tried formatting it with 'fdisk /dev/sda' ? Not so drastic. As soon as the thing can be addressed, most problems have been solved already. Such memory sticks sometimes contain a partition table, and sometimes not. A command like dd if=/dev/sda bs=512 count=1 | od -tx1 would show the contents. If there is no partition table fdisk would list garbage only, but if there is, then fdisk -l /dev/sda would tell you what it looks like. Andries --- 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. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] write protection handling on usb-storage devices
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 their kernels from elsewhere and are unable to compile. to select whether or not the driver should allow checking for write-protection on new devices. The majority of devices support this check with no difficulty, but there are a few that choke on it. (That's part of the reason we made it configurable -- the other part is that earlier versions of Linux performed the check in a slightly different way which was much more likely to cause problems.) Now there's a proposal to make this be a module parameter rather than a config option, so that it can be changed on-the-fly via sysfs without having to rebuild usb-storage. A big improvement. The bad aspect of doing this is that it would also eliminate the nice explanatory help message in the Kconfig file, so the background information wouldn't be so easily available to users any more. Kernel configuration time is not the time to feed users with information. There are thousands of parameters. A parameter is a sign of weakness: I have no idea how to make this work, please figure it out for yourself. Suggested actions are: Move the explanation into the FAQ on www.linux-usb.org (a good idea in any case). Not least of the advantages is that it would then be findable by Google. Yes. Change the setting to a module parameter, and _keep_ the config option -- but make the config option control only the initial default value of the parameter. No. The config option is bad. You yourself have to determine the initial default value. Imagine a distribution. They have to do something for thousands of users, many of whom are unable to compile kernels. If it regularly happens that RW investigation leads to a hang, and there is a great variety of devices where this happens, then do not investigate RW. If only two devices are known that are bad, mark them in unusual_devs.h and make the default to determine RW, with a module parameter to override for new unknown bad cases. Nobody is in a better position to determine the default than you are. Go ahead and do the complete changeover now (or as soon as the FAQ is updated). Yes. P.S.: This raises the issue of documenting a bunch of module parameters added to the USB subsystem fairly recently. What's the best way to do this? Add entries to Documentation/kernel-parameters.txt? Put descriptions on the linux-usb FAQ? Both? Both. kernel-parameters.txt is obligatory, all other places are nice. Andries --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: usb-storage since at least 2.6.3: destroys partitions on hdd
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.6.3 partititons on usb-devices (HDD'S with USB-Adapter or USB-Sticks) get destroyed when writing to them. Steps to reproduce: mkfs.ext3 /dev/sda1 (happens with any filesystem ext3, ext2, fat) mount /dev/sda1 /mnt/usbdisk cp -Rp linux-2.6.9-rc3 /mnt/usbdisk cd /mnt/usbdisk make mrproper make menuconfig or copy .config make or just write a lot of files and delete and write ... you will get IO-Errors. On ext3 you get an aborted journal -- I asked: You report that you get I/O errors with Linux kernels 2.6.3-2.6.9. Are there kernels that work? Thomas replied: Yes it works fine with all 2.4 kernels but I'm not sure if it did ever with a 2.6 kernel. I have this problem with any usb-storage device (digital camera, memorysticks, usb2ide adapter). I've tested with my Laptop and with my normal Pc I've also tried with usb1.1 and usb2. If you need more info or if I should test something, feel free to ask me. I found this entry because I looked for problems with the partition code. However, this is better labeled I/O errors with usb-storage. Let me forward this to the usb-storage list. Andries --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Partition and removable devices
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 of windows formatted media.. [this is not an usb question] Windows can handle removable usb devices with and without partition table. It is quite common for Compact flash and Smart Media cards to have a partition table. Linux is rather eager in trying to recognize a partition table even when none is present. However, I seem to recall that I submitted a patch to improve this behaviour a little. Remains the question: (i) what kernel are you using? (ii) what is the contents of the first 512 bytes of your device? Andries [EMAIL PROTECTED] --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: RFC: [2.6 patch] let BLK_DEV_UB depend on EMBEDDED
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 don't know what. Is it that bad, really? Honestly, I could not imagine users can be so dumb. The option defaults to off. There is a warning in the Kconfig. And yet they first enable it and then complain about it. I don't know what to do about it, either. I see config BLK_DEV_UB tristate Low Performance USB Block driver depends on USB help This driver supports certain USB attached storage devices such as flash keys. Warning: Enabling this cripples the usb-storage driver. If unsure, say N. You might think this is a strong warning already. But if I have a flash key, I might conclude that I need it. Especially if the very first attempt to make it work with usb-storage failed. So, if it is true that lots of people complain, one might consider writing This driver attempts to support the same devices that usb-storage supports, but without going through the SCSI layer. It doesnt know about the special quirks of many devices. Probably you should say N here and Y for usb-storage. Having both does not work very well. Andries --- 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. Start reading now. http://productguide.itmanagersjournal.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [usb-storage] Re: PATCH: (as226e) Blacklist device flags changes
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 = drivers/usb/storage/Kconfig 1.12 vs edited = --- 1.12/drivers/usb/storage/Kconfig Wed Mar 17 11:16:51 2004 +++ edited/drivers/usb/storage/KconfigSun Jun 13 10:13:41 2004 @@ -23,6 +23,25 @@ Say Y here in order to have the USB Mass Storage code generate verbose debugging messages. +config USB_STORAGE_RW_DETECT + bool USB Mass Storage Write-Protect Media Detection (EXPERIMENTAL) + depends on USB_STORAGE EXPERIMENTAL + help + Say Y here in order to have the USB Mass Storage code indicate to + the SCSI layers that using MODE SENSE(6) and MODE SENSE(10) to + determine if the media is write-protected is a good thing to do. + + Many devices have historically had trouble with these commands, + hence the default 2.6.x behavior has been to supress their use. + 2.4.x used this commands with (at best) mixed results, often + crashing the firmware of the device. + + Recent changes to the SCSI layer now make use of these commands + in a manor which is more consistent with other popular OSes, in + an attempt to improve compatibility. Typos: manor - manner, supress - suppress General comment: It is a really bad idea to introduce such configuration options. For many reasons: First of all, introducing options is always bad. We do not need ten thousand configuration options. Secondly, introducing options is always bad. The user has no idea what to answer. She doesn't know anything about usb-storage or SCSI, and certainly nothing about how her memory stick reader will react to MODE SENSE(6) commands. Thus, she will try one choice, and if it fails the other choice. In case of N binary options the user will try blindly and without understanding 2^N combinations to see whether one works. Bad. Thirdly, introducing options is bad. The distribution provider does not know anything about the user's devices. How must he choose the options? Fourthly, introducing options is bad. The user may have several devices, where these devices need different answers to this question. We need code that works, and if we are unable to write such code, code that can be made to work by using dynamic settings. Andries --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Logitech USB Multimedia keyboards sending mouse events
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 when using them in PS/2 mode, but in USB mode, a few of their keys send mouse events, which seems very bizarre to me. Can you give the scancodes involved? --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [patch] datafab fix and unusual devices
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 sectors but the last sector.
Applied, thanks.
Hi guys,
We also probably need this for 2.4 ?
Yes. I planned to send you one, but have no time.
Now that you ask, here is the patch, not compiled, not tested.
Andries
--- datafab.c~ 2003-06-13 16:51:37.0 +0200
+++ datafab.c 2004-04-05 14:41:24.0 +0200
@@ -695,20 +695,24 @@
}
if (srb-cmnd[0] == READ_CAPACITY) {
+ unsigned int max_sector;
+
info-ssize = 0x200; // hard coded 512 byte sectors as per ATA spec
rc = datafab_id_device(us, info);
if (rc != USB_STOR_TRANSPORT_GOOD)
return rc;
- US_DEBUGP(datafab_transport: READ_CAPACITY: %ld sectors, %ld bytes
per sector\n,
+ US_DEBUGP(datafab_transport: READ_CAPACITY:
+ %ld sectors, %ld bytes per sector\n,
info-sectors, info-ssize);
// build the reply
//
- ptr[0] = (info-sectors 24) 0xFF;
- ptr[1] = (info-sectors 16) 0xFF;
- ptr[2] = (info-sectors 8) 0xFF;
- ptr[3] = (info-sectors) 0xFF;
+ max_sector = info-sectors - 1;
+ ptr[0] = (max_sector 24) 0xFF;
+ ptr[1] = (max_sector 16) 0xFF;
+ ptr[2] = (max_sector 8) 0xFF;
+ ptr[3] = (max_sector) 0xFF;
ptr[4] = (info-ssize 24) 0xFF;
ptr[5] = (info-ssize 16) 0xFF;
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [patch] datafab fix and unusual devices
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 (which fixes this bug) certainly looks good to me for 2.6 -- we need to check that 2.4 doesn't also have the problem. The second part of your patch I don't like (it seems to violate the 'principal of least suprise' to me) but I'm also ready and willing to consider a beter alternative. What do you suggest? Well, the entire patch should be applied. Nothing wrong with it. That will enable people to use (0x0c0b,0xa109) to read CF, or to read SM, but not both. (Without the patch the device does not work at all.) The situation is precisely the same as that for (0x07c4,0xa109). To do something better we need infrastructure that does not exist today, at least not in the vanilla kernel. That is why I call for discussion. The points are ordinary use and error recovery. For ordinary use the main point seems to be the us-extra pointer to private data. Since each driver needs private data, a single pointer does not suffice. Andries --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [usb-storage] SDDR-09 CIS Revisited
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
*
* This writes at the indicated address. Don't know how it differs
* from E9. Maybe it does not erase? However, it will also write to
* the CIS.
*
* When two such commands on the same page follow each other directly,
* the second one is not done.
*/
static int
sddr09_writeCIS(struct us_data *us, int nr_of_pages, unsigned char *buf) {
struct sm_card_info *info = us-extra;
unsigned char command[12] = {
0xee, LUNBITS, 0, 0, 0x20, 0, 0, 0, 0, 0, 0, 0x01
};
unsigned char ecc[3];
unsigned char *bptr, *cptr;
int pagelen, bulklen, result, i;
command[4] = (1 info-blockshift);
command[11] = nr_of_pages;
result = sddr09_send_scsi_command(us, command, sizeof(command));
...
etc. I deleted the rest, the details in the present kernel are
a bit different, but this command is what one needs.
Andries
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [usb-storage] PATCH: fix mode-sense handling for 10-byte commands
| 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 all to know such things.
| Yes, knowing such things is directly harmful.
I can only see this if you don't do hardware interface programming
or if you do but it's all on one $ARCH.
There are places (like USB host controller drivers) that using
endian swapping is necessary.
As indeed was necessary here. And the code that was there did the
job fine. And did not need the concept of endianness or swapping.
It just did what was to be done.
Let me give another example.
When reading DOS-type partition tables, one encounters four bytes
that give the start of a partition. Least significant byte first.
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.
But smart people write
start = *(int *) p;
And it fails on big-endian architectures.
Then even smarter people write
start = le32_to_cpu(*(int *) p);
And it fails on a DEC Alpha because the alignment is wrong.
The current kernel writes
#include asm/unaligned.h
#define START_SECT(p) ({ __typeof__(p-start_sect) __a = \
get_unaligned(p-start_sect); \
le32_to_cpu(__a); \
})
Look what progress!
We need an additional include file, an additional define,
compiler magic, lots of ugliness.
No, never use a cast and just magically the code will work.
If you ever notice that using a cast produces better code
then most likely the compiler must be improved.
Andries
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [usb-storage] PATCH: fix mode-sense handling for 10-byte commands
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 this: start = get_be32(p); ? I have been arguing that casts are bad. If get_le32(p) does not involve a cast but is just an abbreviation of what I wrote above, then of course I do not object. Andries [did you write be32 by mistake?] --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [usb-storage] PATCH: fix mode-sense handling for 10-byte commands
Hmm. I am not precisely happy with improvements like - ptr[4] = MSB_of(info-pagesize16); - ptr[5] = LSB_of(info-pagesize16); - ptr[6] = MSB_of(info-pagesize0x); - ptr[7] = LSB_of(info-pagesize0x); + ((u32 *) ptr)[1] = cpu_to_be32(info-pagesize); A good compiler generates the same code, and for a human like me the above four statements show much more clearly that values are assigned to ptr[4..7] than the ugly cast below. And + ((u16*)ptr)[0] = sizeof(mode_page_01) - 2; looks like a bug. This (u16*) will work or not, depending on whether the machine is big or little-endian. No obfuscation please. Andries --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: modified datafab storage driver
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 decide which lun is available by means of checking the media presence flag which is reported from the datafab_id_device function. Now the driver works with _my_ datafab device. Yes, but I think you broke some other devices. 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 different srb-device-lun. If probing has shown that srb-device-lun == 0 belongs to the SM half, with a different driver, then datafab.c will be called only for srb-device-lun == 1, but still it may need info-lun = 0. 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. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: modified datafab storage driver
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. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: datafab.c
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 count, xx: sector, 28 bits, little endian) * * Write:00 nn xx xx xx ex 30 02 * (idem; returns 2-byte status reply) * * Note that EC, 20, 30 are the ATA commands * IDENTIFY DRIVE, READ SECTORS, WRITE SECTORS. */ The device I played with recently is an Apacer CF+SM, where this datafab.c is used for the CF part, which is lun 0 of the device, and I use lun 0 of the datafab part. (There are various concepts of lun here. In the below I do not mean scsi or usb lun, but info-lun, the datafab lun.) From you I understand that you have a single-use device and both lun 0 and lun 1 work - is that true? That is, does your device work both with info-lun = 0 and with info-lun = 1? I have a more fundamental question: Why do we need lun detection? You wrote info-lun = srb-device-lun; and maybe that would work. These are two very different animals in principle, but maybe it is true that if the datafab is used for two devices the usb 0,1 are mapped this way, randomly, to the datafab 0,1. While if the datafab is used for one device maybe it does not matter which lun is used. That last sentence expresses my uncertainty: it is conceivable that datafab.c is called with srb-device-lun == 1 while only datafab lun 0 works. That would be a case where we need detection. Let me try to ask the original author why detection was needed for him and cc Jimmie Mayfield. 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. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: datafab.c
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 media. And a related variant: what if one of the cards is CF and the other is SM, or what if both cards are the same type? There is no choice what to insert where, SM cards are much thinner than CF cards. 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. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: datafab.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 issued when doing modprobe sd-mod with usb-storage already loaded. First I thought the insmod whill never return, but after 25 minutes (!) insmod was ready. Yes. On the one hand, I have never seen SCSI error recovery do something useful. On the other hand, in this case, it is mostly our fault. If we return errors with the meaning don't retry, that is meaningless that would stop the SCSI layer from doing its nonsense. I tried your suggestion - insmod without CF card inserted and found that it took 13 minutes in my case. Then polished the error returns a bit and got it down to 2 seconds instead. Now you want to see the improved code, but just a moment ago my ethernet hub broke down - never had that happen before - so my development machine is out of reach for the moment. The changes are easy to describe. In the routine *determine_lun() there are three possible results: *GOOD / *FAILED / *ERROR. The two cases where a lun is discovered were and remain *GOOD. The cases where we cannot send a command at all (the write fails) were and remain *ERROR. The remaining cases (we do not try because of beenhere, or we try but do not find a lun) return *FAILED. When FAILED is returned, the sense code for Unit Attention, No Media is set. Clear the beenhere when we return *FAILED after trying in vain, so that we can try later. (In fact I made beenhere the condition info-lun == -2, and changed all tests elsewhere from if (info-lun == -1) to if (info-lun 0).) The result of this change was the following: After a fresh reboot, insmod with CF card already inserted works. Also, insmod without CF card inserted works (after two-second delay), and if the card is inserted later, a blockdev --rereadpt causes the lun to be determined later, and again access is fine. So, all is well so far. However, rmmod followed by a second insmod does not work here. Was just wondering what initialization insmod usb-storage did to disturb the peace of this device when this hub broke. 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. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: datafab.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-device-lun (and enabling CONFIG_SCSI_MULTI_LUN)? This is puzzling me. This Apacer device is a CF+SM reader. The CF part works with datafab.c. The SM part works with sddr55.c. The vanilla kernel has no support for the situation where two luns require two different drivers. Somewhere in the archives I have two solutions, one rather general, and mdharm did not like it because it would add code for everybody and in his experience multiple lun was the exception, and then I wrote a small twoluns.c precisely for this situation (I have lots of devices, N-in-1 readers, with two luns, very few with more.) Must dig this up again one of these days. 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. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: datafab.c
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 come up with the right lun?) What is the lun in your case? I trust you are aware that using static variables Yes, my old code had such stuff in the info struct. It is a pity I didnt push that code more forcefully at that time. Now I see lots of broken stuff that was fixed long ago. Am slowly coming back to this. 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. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] datafab.c
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 the device.
The ATA convention is to return the capacity.
The SCSI convention is to return the highest block number,
one less than the capacity.
So, the driver misses a -1.
Another problem causing hangs was that the SCSI code does
TEST_UNIT_READY, and datafab.c first wants to determine
which lun it is using, and tries to find out, but the attempt
fails and causes scsi error-recovery, but that does TEST_UNIT_READY
and we have a recursion.
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.
In the good old days I showed versions that just worked, but the
vanilla kernel does not yet handle multi-lun devices.
Andries
--
--- /linux/2.6/linux-2.6.0-test11/linux/drivers/usb/storage/datafab.c Wed Nov 26
21:45:53 2003
+++ ./datafab.c Thu Dec 4 23:35:58 2003
@@ -294,11 +294,12 @@
// There might be a better way of doing this?
static unsigned char scommand[8] = { 0, 1, 0, 0, 0, 0xa0, 0xec, 1 };
+ static int beenhere = 0;/* protect against recursive calls */
unsigned char *command = us-iobuf;
unsigned char *buf;
int count = 0, rc;
- if (!us || !info)
+ if (!us || !info || beenhere)
return USB_STOR_TRANSPORT_ERROR;
memcpy(command, scommand, 8);
@@ -306,6 +307,8 @@
if (!buf)
return USB_STOR_TRANSPORT_ERROR;
+ beenhere = 1;
+
US_DEBUGP(datafab_determine_lun: locating...\n);
// we'll try 3 times before giving up...
@@ -387,7 +390,7 @@
// we'll go ahead and extract the media capacity while we're here...
//
- rc = datafab_bulk_read(us, reply, sizeof(reply));
+ rc = datafab_bulk_read(us, reply, 512);
if (rc == USB_STOR_XFER_GOOD) {
// capacity is at word offset 57-58
//
@@ -574,20 +577,26 @@
}
if (srb-cmnd[0] == READ_CAPACITY) {
- info-ssize = 0x200; // hard coded 512 byte sectors as per ATA spec
- rc = datafab_id_device(us, info);
+ unsigned long size_minus1;
+
+ info-ssize = 0x200; // 512 byte sectors as per ATA spec
+
+ rc = datafab_id_device(us, info); // reads capacity
if (rc != USB_STOR_TRANSPORT_GOOD)
return rc;
- US_DEBUGP(datafab_transport: READ_CAPACITY: %ld sectors, %ld bytes
per sector\n,
+ US_DEBUGP(datafab_transport: READ_CAPACITY:
+ %ld sectors, %ld bytes per sector\n,
info-sectors, info-ssize);
// build the reply
- //
- ptr[0] = (info-sectors 24) 0xFF;
- ptr[1] = (info-sectors 16) 0xFF;
- ptr[2] = (info-sectors 8) 0xFF;
- ptr[3] = (info-sectors) 0xFF;
+ // convert ATA to SCSI convention
+ size_minus1 = info-sectors - 1;
+
+ ptr[0] = (size_minus1 24) 0xFF;
+ ptr[1] = (size_minus1 16) 0xFF;
+ ptr[2] = (size_minus1 8) 0xFF;
+ ptr[3] = (size_minus1) 0xFF;
ptr[4] = (info-ssize 24) 0xFF;
ptr[5] = (info-ssize 16) 0xFF;
---
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.
Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] sddr09.c
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/linux/drivers/usb/storage/sddr09.c Mon Sep 8
23:45:15 2003
+++ ./sddr09.c Thu Nov 20 23:25:19 2003
@@ -66,7 +66,7 @@
* NAND Flash Manufacturer ID Codes
*/
#define NAND_MFR_AMD 0x01
-#define NAND_MFR_NS0x8f
+#define NAND_MFR_NATSEMI 0x8f
#define NAND_MFR_TOSHIBA 0x98
#define NAND_MFR_SAMSUNG 0xec
@@ -74,8 +74,8 @@
switch(manuf_id) {
case NAND_MFR_AMD:
return AMD;
- case NAND_MFR_NS:
- return NS;
+ case NAND_MFR_NATSEMI:
+ return NATSEMI;
case NAND_MFR_TOSHIBA:
return Toshiba;
case NAND_MFR_SAMSUNG:
@@ -302,8 +302,7 @@
if (result != USB_STOR_XFER_GOOD) {
US_DEBUGP(request sense bulk in failed\n);
return USB_STOR_TRANSPORT_ERROR;
- }
- else {
+ } else {
US_DEBUGP(request sense worked\n);
return USB_STOR_TRANSPORT_GOOD;
}
@@ -469,6 +468,8 @@
unsigned char *command = us-iobuf;
int result;
+ US_DEBUGP(sddr09_erase: erase address %lu\n, Eaddress);
+
memset(command, 0, 12);
command[0] = 0xEA;
command[1] = LUNBITS;
@@ -757,17 +758,27 @@
return result;
}
-/* we never free blocks, so lastpba can only increase */
static unsigned int
-sddr09_find_unused_pba(struct sddr09_card_info *info) {
+sddr09_find_unused_pba(struct sddr09_card_info *info, unsigned int lba) {
static unsigned int lastpba = 1;
- int numblocks = info-capacity (info-blockshift + info-pageshift);
- int i;
+ int zonestart, end, i;
- for (i = lastpba+1; i numblocks; i++) {
- if (info-pba_to_lba[i] == UNDEF) {
+ zonestart = (lba/1000) 10;
+ end = info-capacity (info-blockshift + info-pageshift);
+ end -= zonestart;
+ if (end 1024)
+ end = 1024;
+
+ for (i = lastpba+1; i end; i++) {
+ if (info-pba_to_lba[zonestart+i] == UNDEF) {
+ lastpba = i;
+ return zonestart+i;
+ }
+ }
+ for (i = 0; i = lastpba; i++) {
+ if (info-pba_to_lba[zonestart+i] == UNDEF) {
lastpba = i;
- return i;
+ return zonestart+i;
}
}
return 0;
@@ -784,21 +795,23 @@
unsigned int pagelen, blocklen;
unsigned char *blockbuffer, *bptr, *cptr, *xptr;
unsigned char ecc[3];
- int i, result;
+ int i, result, isnew;
- lbap = ((lba 0x3ff) 1) | 0x1000;
+ lbap = ((lba % 1000) 1) | 0x1000;
if (parity[MSB_of(lbap) ^ LSB_of(lbap)])
lbap ^= 1;
pba = info-lba_to_pba[lba];
+ isnew = 0;
if (pba == UNDEF) {
- pba = sddr09_find_unused_pba(info);
+ pba = sddr09_find_unused_pba(info, lba);
if (!pba) {
printk(sddr09_write_lba: Out of unused blocks\n);
return USB_STOR_TRANSPORT_ERROR;
}
info-pba_to_lba[pba] = lba;
info-lba_to_pba[lba] = pba;
+ isnew = 1;
}
if (pba == 1) {
@@ -823,8 +836,8 @@
if (result != USB_STOR_TRANSPORT_GOOD)
goto err;
- /* check old contents */
- for (i = 0; i info-blockshift; i++) {
+ /* check old contents and fill lba */
+ for (i = 0; i info-blocksize; i++) {
bptr = blockbuffer + i*pagelen;
cptr = bptr + info-pagesize;
nand_compute_ecc(bptr, ecc);
@@ -839,6 +852,8 @@
i, pba);
nand_store_ecc(cptr+8, ecc);
}
+ cptr[6] = cptr[11] = MSB_of(lbap);
+ cptr[7] = cptr[12] = LSB_of(lbap);
}
/* copy in new stuff and compute ECC */
@@ -852,8 +867,6 @@
nand_store_ecc(cptr+13, ecc);
nand_compute_ecc(bptr+(info-pagesize / 2), ecc);
nand_store_ecc(cptr+8, ecc);
- cptr[6] = cptr[11] = MSB_of(lbap);
- cptr[7] = cptr[12] = LSB_of(lbap);
}
US_DEBUGP(Rewrite PBA %d (LBA %d)\n, pba, lba);
@@ -947,10 +960,11 @@
unsigned char *content,
int use_sg) {
- US_DEBUGP(Read control address %08lX blocks %04X\n,
+ US_DEBUGP(Read control address %lu, blocks %d\n,
address, blocks);
- return sddr09_read21(us, address, blocks, CONTROL_SHIFT, content, use_sg);
+ return
Re: [linux-usb-devel] usb-storage and Sony Handycam
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 : 12 01 00 01 00 00 00 08 4c 05 2e 00 00 03 01 02 0010: 00 01 The meaning is decoded below. bLength: 0x12 (18) bDescriptorType: 0x01 (1) bcdUSB : 0x0100 (256) bDeviceClass : 0x00 (0) bDeviceSubClass: 0x00 (0) bDeviceProtocol: 0x00 (0) bMaxPacketSize0: 0x08 (8) idVendor : 0x054c (1356) idProduct : 0x002e (46) bcdDevice : 0x0300 (768) iManufacturer : 0x01 (1) iProduct : 0x02 (2) iSerialNumber : 0x00 (0) bNumConfigurations : 0x01 (1) It is the device that reports that it is 054c:002e a Sony HandyCam MemoryStick Reader. --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB keycodes Logitech Cordless Desktop Optical: (Was USB Multimedia Keyboards. Some keys do not produce keyevents)
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-255. --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB keycodes Logitech Cordless Desktop Optical: (Was USB Multimedia Keyboards. Some keys do not produce keyevents)
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 not work, we have two situations. Either the kernel does not even see the key, i.e. nothing gets returned by either the kernel (in the form of an error written to the messages file), showkey -s, or xev. Or the kernel returns a Can't emulate rawmode for keycode message and neither X nor showkey -s see any output. You do not mention kernel version. These things are very sensitive to kernel version. If the kernel does not see the key at all, there is nothing the keyboard driver can do. The cases where the kernel complains Can't emulate rawmode for keycode ... while X and scancode -s do not see anything are for keycodes above 255. So far, keycodes have been 7-bit objects, and going to 8-bit is straightforward, but going past 8-bit requires updates to quite a lot of software. So, life is easier if one does not use large keycodes. The remaining codes are all OK. You have a keyboard and pressing a key produces some code. Use setkeycodes and loadkeys to assign some symbol or string. Or use some version of funkey or so to assign some action. --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: USB storage problems on OHCI..
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 for mode page 8 then we achieve the same effect in a positive way. I disagree on this one. hot-pluggable sounds like it should be set for ever hotplug device (currently that would include firewire, which may be iffy, and Fibre Channel, which has our highest level of SCSI compliance and would definitely be wrong). Why would it be wrong? The design goal is that this flag makes sd assume as little SCSI standards compliance as it can get away with while still operating the device. No, the design goal of hot-pluggable is that it indicates that the device can disappear any moment. Nothing at all about SCSI compliance. Pulling out a device while it is actively reading or writing will probably break something. But if a device is hot-pluggable it should be OK to pull it out when it has been inactive for a second or so. But if that is really true, then it should not be necessary to send the device any synchronise cache commands when we shut down. And if no such commands will be sent anyway, then we need not ask the device about its type of cache. And if we do not ask, then we need not worry whether the device is sufficiently compliant to answer such a question. Andries --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: USB storage problems on OHCI..
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 seen this for keyboards: keypresses work, modifier key
releases work, and as soon as one assumes anything more there turn
out to be keyboards that fail.
Similarly, USB storage devices tend to fail whatever one tries,
and only systematically work if one does precisely what Windows
does. For SCSI disks things are not nearly as bad - there are
only a few manufacturers and they mostly produce quality stuff.
This means that carefully reading the SCSI standard is a useful
activity if one writes for SCSI disks. But for USB storage it
is more productive to trace the commands the various flavours
of Windows send.
(Yes, I am willing to collect whatever people send me, and put up
a web page describing the Windows way of addressing USB storage.)
So, I agree with Linus (and with myself :-)) - in the absence of
precise knowledge about the device and about its Windows drivers
all that is left is being as conservative as possible.
And I agree with Alan - even though being careful is a very good idea,
it does not help in all cases.
There are some general things we can do - for CF cards and the like
we probably do not want to read the cache type - USB is hot pluggable,
so it should not be necessary to send a flush cache command at shutdown.
Today I see
if (sdkp-media_present) {
sd_read_capacity(sdkp, disk-disk_name, sreq, buffer);
if (sdp-removable)
sd_read_write_protect_flag(sdkp, disk-disk_name,
sreq, buffer);
sd_read_cache_type(sdkp, disk-disk_name, sreq, buffer);
}
and I suppose we could skip sd_read_cache_type() in the
hot-pluggable case - a flag that USB storage could set.
Andries
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: USB storage problems on OHCI..
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)
sd_read_write_protect_flag(sdkp, disk-disk_name,
sreq, buffer);
sd_read_cache_type(sdkp, disk-disk_name, sreq, buffer);
}
and I suppose we could skip sd_read_cache_type() in the
hot-pluggable case - a flag that USB storage could set.
what about just having a conservative mode for sd? This could still
internally be a set of flags, just one single way of clearing them all
from slave configure. For the most conservative setting, we could
probably dump spin up, read write protect, and read cache type.
Maybe.
[By the way - reading Write Protect is meaningful and works,
for my Smart Media card readers.]
I have seen proposals around here for flags that are far too specific
(like do not ask for mode page 8). If we go to that level of detail
then we'll soon have fifty flags.
Black lists, and flags that describe various ways of being broken
are a bad idea in my opinion. I will not deny that they may be needed
in some cases, but they are never the preferred solution.
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
for mode page 8 then we achieve the same effect in a positive way.
There is another comment here.
A scsi device declares its level of scsi compliance.
Most USB storage devices are not very scsi compliant at all,
and report 0 there.
To everybody's surprise USB storage does
US_DEBUGP(Fixing INQUIRY data to show SCSI rev 2 - was %d\n,
data_ptr[2] 7);
/* Change the SCSI revision number */
data_ptr[2] = (data_ptr[2] ~7) | 2;
It claims that the device is SCSI-2 compliant, even when the
device itself does not make that claim at all.
Suppose that we stop changing this compliance level.
Then getting SCSI-1 or no compliance level could be a
conservative mode flag.
[Of course this was done for a reason - USB storage was written
assuming the SCSI layer given. If we stop changing the SCSI level
that may require changes in the SCSI code. Probably Matt remembers
what the problems were.]
Andries
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB sniffer under linux
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 working under linux? A USB sniffer under Linux doesn't make much sense. Think about why you need a sniffer... greg k-h I think a USB sniffer under Linux makes excellent sense. I have on several occasions used tcpdump and similar programs to study the ethernet traffic between two Linux machines. Of course one can fix bugs in the kernel code by reading all kernel code, but often it is quicker to have an independent and more direct window on what is happening. Andries --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb-storage: WIN_SECURITY_UNLOCK
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 that is related to the ATAPI security features. I think the general answer will be No. A similar question is whether ide-floppy is superfluous and one can do everything via ide-scsi. Again I think the answer will be No. Indeed, ide-scsi uses the Packet command A0 of ATAPI to send SCSI command packets to the ATAPI device. But there is no reason to expect that all ATAPI commands are covered this way. The first example is already A1: IDENTIFY PACKET DEVICE. SCSI has INQUIRY, but that is not the same. I have some ancient patches to ide-floppy.c that allow one to switch an Iomega ZIP drive between large floppy and removable disk. I do not know of a way to send these same commands via ide-scsi. Andries --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] oops in sd_shutdown
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 observe this race between sd_probe and sd_shutdown.
(Of course sd_probe hangs in sd_revalidate disk.)
Perhaps the obvious test is a good idea.
Locking seems meaningless - sd_probe will never finish.
Andries
[Probably the init of usb_storage should start probing the devices in separate
threads, in parallel, and return immediately.]
The obvious patch (with whitespace damage)
diff -u --recursive --new-file -X /linux/dontdiff a/drivers/scsi/sd.c
b/drivers/scsi/sd.c
--- a/drivers/scsi/sd.c Mon Jul 28 05:39:31 2003
+++ b/drivers/scsi/sd.c Tue Aug 12 01:24:51 2003
@@ -1351,10 +1351,14 @@
static void sd_shutdown(struct device *dev)
{
struct scsi_device *sdp = to_scsi_device(dev);
- struct scsi_disk *sdkp = dev_get_drvdata(dev);
+ struct scsi_disk *sdkp;
struct scsi_request *sreq;
int retries, res;
+ sdkp = dev_get_drvdata(dev);
+ if (!sdkp)
+ return; /* this can happen */
+
if (!sdp-online || !sdkp-WCE)
return;
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [retry] deadlock (and mailer error)
(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-subsys.rwsem); and then later usb/core/hub.c:usb_reset_device() downs down_read(gdev-bus-subsys.rwsem); This is the same semaphore, and we have a deadlock. --- (2) Mailer error but vger didnt like this letter (?) and confusingly answered --- The following addresses had permanent fatal errors [EMAIL PROTECTED] ... while talking to vger.kernel.org.: MAIL From:[EMAIL PROTECTED] SIZE=463 501-5.1.7 For input: [EMAIL PROTECTED] SIZE=463 501 5.1.7 Path data: Spurious dot (.) at the end of the domain name 501 [EMAIL PROTECTED]... Data format error [EMAIL PROTECTED]... Deferred: Connection refused by hera.cwi.nl. --- Andries --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH] oops in sd_shutdown
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 purpose, when no object is present or no action (other than the default) needs to be performed. But that general idea is broken by container_of(), which just subtracts a constant. So, one should check before subtracting that the pointer is non-NULL. Checking afterwards is meaningless. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Apacer SM/CF combo reader driver
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 read-only driver; hope to add the writing part soon. Andries Does your driver work well ? Yes, it reads and writes without problems, both CF and SM, assuming the surrounding kernel works. Is it in the stock kernel now ? If not, is it possible to get it? Now the question arises what you mean by stock kernel. 2.6.0-test3 is still in a sorry state. I cannot insmod usb-storage.o for a vanilla 2.6.0-test3. It hangs. (Have not checked yet whether this is a permanent hang or one of these scsi_eh_X that spend hours resetting the bus and trying again. I booted 33 min ago and it still hangs.) I have not tried 2.4 recently, but that is supposedly stable. If you need the CF half, you need no help from me, you must just find some kernel where usb-storage and usb and scsi all work. Maybe a recent 2.4 would do. If you need the SM half, ask me again. Andries [Long ago I made some general common infrastructure for SM readers. In May 2002 someone asked me for this stuff and I put something at ftp://ftp.kernel.org/pub/linux/kernel/people/aeb/usb-storage.tar.gz Don't recall precisely what this is, or to what kernel it belonged, in view of the date it may have been 2.5.13 or 2.5.14. But I see there is an apacer.c, and the source looks healthy at first sight.] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] add LP_ABORTOPEN ioctl in usblp.c [2.5.70]
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.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Usb-storage doesn't find a valid part. table for the Nike player
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 storage device, but it doesn't recognize the partition table? Windows sees the player as a usb mass storage device and I can read the mp3 files. Also strange under Windows the player has a size of 127MB and under Linux 134MB This is not strange: 127MiB is 134 MB. Vendor: Philips Model: MassStorage Disc Rev: Type: Direct-Access ANSI SCSI revision: 02 Inquiry succeeded USB Mass Storage device found at 2 USB Mass Storage support registered. Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0 usb-storage: Command READ_CAPACITY (10 bytes) SCSI device sda: 131072 1024-byte hdwr sectors (134 MB) Read capacity succeeded. sda: Write Protect is off sda:7usb-storage: queuecommand() called usb-storage: *** thread awakened. usb-storage: Command READ_10 (10 bytes) usb-storage: 28 00 00 00 00 00 00 00 04 00 8c c7 usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096 Successfully read 4096 bytes. unknown partition table But the contents do not look familiar. Altogether a rather encouraging start. What is the contents of the first sector? You could for example try # dd if=/dev/sda bs=512 count=1 | od -tx1 Andries --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RE: A different look at block device hotswap in the Linux kernel
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 when I unplugged it. You may want your device to reattach as totally new. You may, on the other hand, want your device to resume where you left off. I can see valid reasons for wanting either behaviour (but it can't/shouldn't be deduced by the OS). The kernel does not remember this device once it is gone. If user space thinks it recognizes it, it must have a means to tell the kernel what it should do. What kind of info? The only thing that I can think of right now is the name. User space may tell the kernel under what name a device should be accessible. [Today user space can tell the kernel the numbering of the partitions.] More generally, the question of what same device means depends on the application. Is /dev/fd0 the same device as /dev/fd0 also when the floppy is different? Yes, the name is the same. The contents not. In all cases user space does not tell the kernel it is the same as ... since the kernel does not remember anyway. User space just instructs the kernel to do certain definite things. Andries --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] sd_read_cache_type
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 later. For now a question: this call does a MODE_SENSE with the DBD (disable block descriptors) bit set. Is there a reason for that? Wouldn't the same code work in the same way without that bit? And the reason I ask is that we already have sd_do_mode_sense6(), so part of sd_read_cache_type() can be simply replaced by a call of sd_do_mode_sense6(), but the latter needs an extra parameter if DBD is really needed. And a second question: sd_read_cache_type() is called also when no medium is present. Objections against only calling when media are present? Andries --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: IDs
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. How do you plan to use this? Is it already in use somewhere? The sysfs tree does not contain device nodes. Do you plan a user space utility that figures out that the ID SHP CD-Writer+ 8200 [ belongs to /dev/hdd which also is /dev/sr0? The id is not suitable as a user space name. Moreover, it is a heuristic only, and user space needs unambiguous names. What user space names do you want to use? Andries --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: inquiry in scsi_scan.c
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 case where 8 blacks or NULs is padding, from the case where these 8 blanks or NULs is the actual vendor name, but this distinction does not matter at all for our purposes. Andries --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: IDs
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 will not be on the white list. Our perceptions differ, I think. My impression is that chaos is the norm, and well-behaved devices are the exception. I find very good behaviour in fixed hard disks. Stuff by Maxtor, Seagate, IBM, etc - a very small collection of very experienced manufacturers with high quality products. SCSI CDROM drives or tape drives or scanners are messier. USB storage devices are much messier - very basic parts of the protocol are regularly broken. So to me the approach of an id together with a blacklist seems unworkable. As you say - we can make a best effort and get a string that with some luck identifies the device uniquely. But no guarantees given. Maybe that again means that the S/Z distinction can be dropped. Andries --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: inquiry in scsi_scan.c
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 additional length field (thus reports length 37). This second device, when asked for 37 bytes, still only returns 36. Andries --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] IDs
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 INQUIRY response; maybe unnecessarily - all details are well understood, and patches fixing all problems have been posted, but in any case it is best to separate both threads.] Maybe I should ask you to explain more in detail what purpose you have in mind. If I read your code and hear you talking it sounds like you would like to have a string identifying the device. But in many cases no such string exists. Moreover, what precisely is the device? If I have a Compact Flash card reader and read CF cards, is the device the reader? Or the card? Or the combination? If I have an Imation FlashGo! reader, and insert a SmartMedia adapter, and read a SmartMedia card, is the device the reader, the reader plus adapter, the card? If the device is the reader, then it will have a different size, partitioning and contents each time we see it. If the device is the card, then we need a different driver each time we see it. What do you want to recognize with this ID, and why? Andries --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: IDs
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. (And this is not because of truncation.) I can see your intentions, but view these names/ids more like heuristics than like reliable data. More or less like mount, which will usually figure out the filesystem type for you, but no guarantees are given. And where we have heuristics only, it cannot be wrong to truncate at 50 positions or so. The heuristic does not become appreciably weaker. (And, in case of heuristics, I like 98% heuristics better than 99.98% heuristics. They keep you honest. No important things will depend upon them. With 99.98% one may forget that it is a heuristic.) Andries --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: inquiry in scsi_scan.c
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 have all the data... We don't do a second request. Actually, we ask for 36 and get 36, but the field in the response which is supposed to tell us how much there is total is zeroed out, instead of having a real value. Right. All we need to do is recognize when that field indicates less than 36 bytes, and then stop asking for anything else. Either (a) the device is lying, in which case our original INQUIRY is fine, or (b) the device really has less than 36 bytes, which means that we already have all the data. I think you misunderstand the problems. We do not ask for anything else. There are two problems: a SCSI and a USB problem. In the SCSI code a length of 5 is legal. Now the code allocates space for these 5 bytes but subsequently uses pointers to vendor etc that point past the end of the allocated area. If ever anything is written via these pointers random memory is corrupted. And cat /proc/scsi/scsi shows randow junk. A bug that has to be fixed, independently of USB. 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 bytes were transferred and the additional length byte is 0, indicating a length of 5, then the USB code can fix the response and change the additional length byte to 31, indicating a length of 36. That way the SCSI code knows that not 5 but 36 bytes are valid, and it gets actual vendor and model strings. Andries [the code I showed does the right things; will submit actual diffs sooner or later] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: inquiry in scsi_scan.c
[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 bytes were transferred and the additional length byte is 0, indicating a length of 5, then the USB code can fix the response and change the additional length byte to 31, indicating a length of 36. And what if the transport is *not* USB? Or they used a similar firmware of their device server in another product which used another transport? I suggest that this device is blacklisted in that SCSI Core would know that the ADDITIONAL LENGTH field in the INQURY response is incorrectly set (to 0). I.e. leave it to the interpreter. A transport is *not* supposed to peek and poke in the data it transfers! There are at least four replies: The factual: It seems you are unaware of the present USB storage code. For many devices the INQUIRY response is entirely fabricated. The vicious circle: The SCSI blacklist works by attaching quirks to vendor and model data. This fails when the quirk is precisely that vendor and model data are not reported. The theoretical: USB-storage is the SCSI host - it is responsible for presenting the SCSI layer with a device that complies with the SCSI standard. If any blacklisting is to be done it must be blacklisting in the USB storage code, not in the SCSI code. (And that blacklist exists, of course - it is called unusual_devs.h.) The practical: USB devices are notoriously bad as far as standard compliance is concerned. If it works with Windows that is good enough. That standard, too expensive to implement it all, or, after implementing, to test it all. Your philosophy leads to blacklisting almost every USB storage device (I possess a dozen or so, not a single one without quirks). Of course that is a possibility: describe for every device on the market in what ways it fails. But it is counterproductive. When people buy a new device it would be nice if it worked with Linux immediately, not first after adding its quirks to some list. Indeed, several times a week I read someone reporting add this to unusual_devs.h to make this device work. No doubt thousands of people just decide that their device does not work with Linux. In cases where it is possible to automatically detect and correct faulty data no list of quirks is required, and more devices will work with Linux out-of-the-box. Andries --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: inquiry in scsi_scan.c
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/scsi_scan.c
--- a/drivers/scsi/scsi_scan.c Wed Jan 1 23:54:23 2003
+++ b/drivers/scsi/scsi_scan.c Sun Jan 5 14:22:21 2003
@@ -544,32 +544,6 @@
}
/**
- * scsi_check_id_size - check if size fits in the driverfs name
- * @sdev: Scsi_Device to use for error message
- * @size: the length of the id we want to store
- *
- * Description:
- * Use a function for this since the same code is used in various
- * places, and we only create one string and call to printk.
- *
- * Return:
- * 0 - fits
- * 1 - size too large
- **/
-static int scsi_check_id_size(Scsi_Device *sdev, int size)
-{
- if (size DEVICE_NAME_SIZE) {
- printk(KERN_WARNING scsi scan: host %d channel %d id %d lun %d
- identifier too long, length %d, max %d. Device might
- be improperly identified.\n, sdev-host-host_no,
- sdev-channel, sdev-id, sdev-lun, size,
- DEVICE_NAME_SIZE);
- return 1;
- } else
- return 0;
-}
-
-/**
* scsi_get_evpd_page - get a list of supported vpd pages
* @sdev: Scsi_Device to send an INQUIRY VPD
* @sreq: Scsi_Request associated with @sdev
@@ -715,17 +689,16 @@
* scsi_check_fill_deviceid - check the id and if OK fill it
* @sdev: device to use for error messages
* @id_page: id descriptor for INQUIRY VPD DEVICE ID, page 0x83
- * @name: store the id in name
+ * @name: store the id in name (of size DEVICE_NAME_SIZE 26)
* @id_search: store if the id_page matches these values
*
* Description:
* Check if @id_page matches the @id_search, if so store an id (uid)
- * into name.
+ * into name, that is all zero on entrance.
*
* Return:
* 0: Success
* 1: No match
- * 2: Failure due to size constraints
**/
static int scsi_check_fill_deviceid(Scsi_Device *sdev, char *id_page,
char *name, const struct scsi_id_search_values *id_search)
@@ -755,70 +728,41 @@
if ((id_page[0] 0x0f) != id_search-code_set)
return 1;
- name[0] = hex_str[id_search-id_type];
+ /*
+* All OK - store ID
+*/
+ name[0] = hex_str[id_search-id_type];
+
+ /*
+* Prepend the vendor and model before the id, since the id
+* might not be unique across all vendors and models.
+* The same code is used below, with a different size.
+*/
+ if (id_search-id_type == SCSI_ID_VENDOR_SPECIFIC) {
+ strncat(name, sdev-vendor, 8);
+ strncat(name, sdev-model, 16);
+ }
+
+ i = 4;
+ j = strlen(name);
if ((id_page[0] 0x0f) == SCSI_ID_ASCII) {
/*
* ASCII descriptor.
*/
- if (id_search-id_type == SCSI_ID_VENDOR_SPECIFIC) {
- /*
-* Prepend the vendor and model before the id,
-* since the id might not be unique across all
-* vendors and models. The same code is used
-* below, with a differnt size.
-*
-* Need 1 byte for the idtype, 1 for trailing
-* '\0', 8 for vendor, 16 for model total 26, plus
-* the name descriptor length.
-*/
- if (scsi_check_id_size(sdev, 26 + id_page[3]))
- return 2;
- else {
- strncat(name, sdev-vendor, 8);
- strncat(name, sdev-model, 16);
- }
- } else if (scsi_check_id_size (sdev, (2 + id_page[3])))
- /*
-* Need 1 byte for the idtype, 1 byte for
-* the trailing '\0', plus the descriptor length.
-*/
- return 2;
- memcpy(name[strlen(name)], id_page[4], id_page[3]);
- return 0;
- } else if ((id_page[0] 0x0f) == SCSI_ID_BINARY) {
- if (id_search-id_type == SCSI_ID_VENDOR_SPECIFIC) {
- /*
-* Prepend the vendor and model before the id.
-*/
- if (scsi_check_id_size(sdev, 26 + (id_page[3] * 2)))
- return 2;
- else {
- strncat(name, sdev-vendor, 8);
- strncat(name, sdev-model, 16);
- }
- } else if
[linux-usb-devel] Re: inquiry in scsi_scan.c
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-minimal.
That's an error in the INQUIRY data/
The minimum (by spec) is 36 bytes.
No. Quoting:
The INQUIRY data (Table 7-9) contains a five byte header,
followed by the vendor unique parameters, if any.
(SCSI-1 standard)
So, as long as we are willing to support SCSI-1 devices,
we must accept that the INQUIRY data can be as short as this.
And in fact all our other code is careful - look at
print_inquiry() how before looking at a byte we check
whether it really there.
On the other hand, my case was not an ancient SCSI-1 device,
it was a brand new USB device. So, I have the SCSI host in hand.
Looking at what happens:
usb-storage: usb_stor_bulk_transfer_buf(): xfer 36 bytes
00 80 00 00 00 00 00 00 4F 45 49 2D 55 53 42 20
53 6D 61 72 74 4D 65 64 69 61 20 20 20 20 20 20
32 2E 30 35
usb-storage: Status code 0; transferred 36/36
usb-storage: Fixing INQUIRY data to show SCSI rev 2 - was 0
usb-storage: Fixing INQUIRY data to show length 36 - was 0
and all is fine.
Instead of the old garbage I now see:
% cat /proc/scsi/scsi
...
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: OEI-USB Model: SmartMedia Rev: 2.05
Type: Direct-AccessANSI SCSI revision: 02
...
Conclusion:
(i) scsi_scan.c has to be careful about INQUIRY lengths,
and some patch is required for devices that return a short length.
(ii) usb-storage knows the transport length, and can fix it
in case it is (5+)0. For example, in protocol.c:fix_inquiry_data():
static void fix_inquiry_data(Scsi_Cmnd *srb)
{
unsigned char *data_ptr;
/* verify that it's an INQUIRY command */
if (srb-cmnd[0] != INQUIRY)
return;
data_ptr = find_data_location(srb);
if ((data_ptr[2] 7) != 2) {
US_DEBUGP(Fixing INQUIRY data to show SCSI rev 2 - was %d\n,
data_ptr[2] 7);
/* Change the SCSI revision number */
data_ptr[2] = (data_ptr[2] ~7) | 2;
}
if (data_ptr[4] == 0) {
US_DEBUGP(Fixing INQUIRY data to show length 36 - was 0\n);
data_ptr[4] = 36 - 5;
}
}
Andries
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: inquiry in scsi_scan.c
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; transferred 36/37 usb-storage: -- short transfer In other words, we asked for 36, got 36 but the 0x20 indicated that the full length is 37. So we ask a second time, but learn that only 36 bytes are available. An off-by-one, as happens more often. Fortunately this device does not hang, so is not yet a reason to introduce additional patch code. Andries --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [usb-storage] Re: PATCH: change function signatures and cleanup debug msgs
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 * behave better for casts though? Quite the contrary. Saying void * means: compiler, don't check. If you have a buffer and declare it char *, then it cannot be confused with a struct urb *urb. But a void * can. Therefore it is generally a bad idea to use void * pointers. Andries --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: usb storage sddr09
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, 4096 MB Oct 17 21:37:07 oscar kernel: sda : unsupported sector size 1. Oct 17 21:37:07 oscar kernel: SCSI device sda: 0 1-byte hdwr sectors (0 MB) Yes. Reverting the 2.5.43 patch on usb/storage fixes this. Also attempting to rmmod usb-storage gets: Oct 17 21:53:12 oscar kernel: kernel BUG at drivers/base/core.c:269! Yes. I have seen the patch several times on this list. See http://marc.theaimsgroup.com/?l=linux-kernelm=103479992624108w=2 Andries --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] USB stories
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
were on was not recognized. It looks like the reason is that
drivers/base/core.c:found_match() returns nonzero now
while it returned 0 earlier (before 2.5.39).
Phenomenon:
An attempt to match 1-1:0 with usbscanner would return an
error, and then an attempt to match it with hub would
succeed. In the present code the first error causes
the loops in bus_for_each_dev and bus_for_each_drv to abort.
So, maybe found_match() must return the opposite of the
present return code, to continue scanning if something is
wrong, and to stop when the right match has been found.
diff -u --recursive --new-file -X /linux/dontdiff a/drivers/base/core.c
b/drivers/base/core.c
--- a/drivers/base/core.c Sat Oct 12 19:28:37 2002
+++ b/drivers/base/core.c Mon Oct 14 22:59:45 2002
@@ -54,7 +54,7 @@
*/
static int found_match(struct device * dev, struct device_driver * drv)
{
- int error = 0;
+ int error;
if (!(error = probe(dev,get_driver(drv {
pr_debug(bound device '%s' to driver '%s'\n,
@@ -64,7 +64,7 @@
put_driver(drv);
dev-driver = NULL;
}
- return error;
+ return !error;
}
/**
With such a change the USB devices were found, and I got photographs
off the first CF card. Then exchanged cards and wanted to use the second
one, of a different capacity.
But /proc/partitions continued to show the old capacity, also after a dd
and also after a mount. And also after a BLKRRPART ioctl.
Not only is media_change broken, also partition rereading is.
Repairing the ioctl is easy:
diff -u --recursive --new-file -X /linux/dontdiff a/fs/block_dev.c b/fs/block_dev.c
--- a/fs/block_dev.cTue Oct 8 21:57:34 2002
+++ b/fs/block_dev.cMon Oct 14 23:13:52 2002
@@ -808,6 +808,10 @@
return -EACCES;
if (down_trylock(bdev-bd_sem))
return -EBUSY;
+
+ /* make sure rescan_partitions will actually do something */
+ bdev-bd_invalidated = 1;
+
res = rescan_partitions(disk, bdev);
up(bdev-bd_sem);
return res;
Indeed, when bdev-bd_invalidated is zero, rescan_partitions() doesnt
do anything, so that is why the ioctl failed.
But why was media change broken? I looked at check_scsidisk_media_change.
It contains some silly code that has been there since 0.99, and recently
got the comment what is this for??. It can be deleted.
diff -u --recursive --new-file -X /linux/dontdiff a/drivers/scsi/sd.c
b/drivers/scsi/sd.c
--- a/drivers/scsi/sd.c Sat Oct 12 19:28:46 2002
+++ b/drivers/scsi/sd.c Mon Oct 14 23:18:36 2002
@@ -337,7 +337,9 @@
* quietly refuse to do anything to a changed disc until
* the changed bit has been reset
*/
- /* printk(SCSI disk has been changed. Prohibiting further I/O.\n); */
+#if 0
+ printk(SCSI disk has been changed. Prohibiting further I/O.\n);
+#endif
return 0;
}
SCSI_LOG_HLQUEUE(2, sd_dskname(dsk_nr, nbuff));
@@ -717,7 +719,6 @@
static int check_scsidisk_media_change(kdev_t full_dev)
{
int retval;
- int flag = 0; /* what is this for?? */
Scsi_Disk * sdkp;
Scsi_Device * sdp;
int dsk_nr = DEVICE_NR(full_dev);
@@ -775,8 +776,7 @@
sdkp-media_present = 1;
retval = sdp-changed;
- if (!flag)
- sdp-changed = 0;
+ sdp-changed = 0;
return retval;
}
Concerning the media change:
US_FL_START_STOP no longer does anything in usb-storage.
The START_STOP command from sd.c is changed into a TEST_UNIT_READY
in usb.c, and the device reports that it is ready.
No media change is seen.
I removed the USB device and inserted it elsewhere.
It was recognized as the same device (it would be, also
if it had been a different one: only vendor+productid is checked,
the thing has no serial number, and the CF card inside does not
influence this GUID either.
[Thus, recognizing a device after removal+insertion is broken
and cannot be repaired, there is not enough information.]
Then I tried to force a detection of media change by removing
the device and doing a BLKRRPART. That caused a kernel crash.
BUG at drivers/base/core:251. (BUG_ON(dev-present)).
Another funny effect was caused by the fact that disk sizes
are now stored both in bdev-bd_inode-i_size and in gendisk.
During a partition table reread on a changed disk the value
in bdev-bd_inode-i_size was used, causing lots of I/O errors
since the new disk was smaller than the old one. Amusing
error messages:
end_request: I/O error, dev 08:10, sector 63480
Buffer I/O error on device sd(8,16), logical block 7935
as if the
[linux-usb-devel] Re: [usb-storage] problem clearing halts
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_halt() manages to work. So far, I haven't seen such a thing happen. And I've seen _lots_ of STALL conditions. A grep in some old logs: Aug 7 21:11:28: usb-storage: usb_stor_transfer_partial(): xfer 255 bytes Aug 7 21:11:28: usb-storage: usb_stor_bulk_msg() returned -32 xferred 0/255 Aug 7 21:11:28: usb-storage: clearing endpoint halt for pipe 0xc0010380 Aug 7 21:11:28: usb-storage: usb_stor_clear_halt: result=0 Aug 7 21:11:28: usb-storage: usb_stor_transfer_partial(): unknown error Aug 8 00:25:11: usb-storage: Call to usb_stor_control_msg() returned -32 Aug 8 00:25:11: usb-storage: -- Stall on control pipe. Clearing Aug 8 00:25:11: usb-storage: usb_stor_clear_halt: result=0 Sep 1 16:28:26: usb-storage: usb_stor_bulk_msg() returned 0 xferred 56/255 Sep 1 16:28:26: usb-storage: Bulk data transfer result 0x1 Sep 1 16:28:26: usb-storage: Attempting to get CSW... Sep 1 16:28:26: usb-storage: clearing endpoint halt for pipe 0xc0008680 Sep 1 16:28:26: usb-storage: usb_stor_clear_halt: result=-32 Sep 1 16:28:26: usb-storage: Attempting to get CSW (2nd try)... Sep 1 16:28:26: usb-storage: clearing halt for pipe 0xc0008680 Sep 1 16:28:26: usb-storage: usb_stor_clear_halt: result=-32 Both 0 and -EPIPE occur. I have not seen -EPIPE in the month of August. Andries --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [usb-storage] Re: Mass storage driver and changing RAM card sizes...
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 is very confusing for the user to see the systems behaviour change in mysterious, unpredictable ways. Moreover, I often use floppies or CF cards etc as transport medium between machines. Even when a serial number allows one to conclude that this really is the same floppy, one cannot conclude that the contents is still the same. No, media change is media change. Trying to recognize media that we saw earlier is a bad idea. Andries --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] card reader brings down 2.4.18
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 under Win98SE. Sounds like something I have. It says: ACOMdATA 0c0b:a109 for the CF+SM part, and 0c0b:a10c for the SD+MS part. If I recall correctly, I made this work under 2.5 two months ago or so, at least the CF+SM part. Do you have the same vendor:product id? --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCHlet] 2.5.23 usb, ide
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, applying diff -r -u linux-2.5.23/linux/drivers/usb/core/hcd-pci.c linux-2.5.23a/linux/drivers/usb/core/hcd-pci.c --- linux-2.5.23/linux/drivers/usb/core/hcd-pci.c Mon Jun 17 19:35:40 2002 +++ linux-2.5.23a/linux/drivers/usb/core/hcd-pci.c Thu Jun 20 17:48:09 2002 @@ -209,13 +209,16 @@ if (in_interrupt ()) BUG (); + if (!hcd-driver) BUG (); + hub = hcd-self.root_hub; hcd-state = USB_STATE_QUIESCING; dbg (%s: roothub graceful disconnect, hcd-self.bus_name); usb_disconnect (hub); - hcd-driver-stop (hcd); + if (hcd-driver-stop) + hcd-driver-stop (hcd); hcd-state = USB_STATE_HALT; free_irq (hcd-irq, hcd); @@ -232,7 +235,8 @@ if (atomic_read (hcd-self.refcnt) != 1) err (usb_hcd_pci_remove %s, count != 1, hcd-self.bus_name); - hcd-driver-hcd_free (hcd); + if (hcd-driver-hcd_free) + hcd-driver-hcd_free (hcd); } EXPORT_SYMBOL (usb_hcd_pci_remove); stops the oops. USB people may worry whether hcd-driver-stop should have been non-NULL. Andries with a somewhat working 2.5 --- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCHlet] 2.5.23 usb, ide
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-driver-stop should have been non-NULL. Not supposed to be possible. All those hc_driver structures are declared static const, with non-null stop(). Looks like something was zeroing some driver's readonly data segment while it was still in use. (And who knows that else!) Now wild pointers happen, and it took me some effort a few weeks ago to catch one. But at first one should look at simpler explanations. Now that you tell me that these things are set at initialization and never changed, the initialization must be wrong. And indeed, it says __devexit_p(uhci_stop) and this yields NULL. So, my previous stopoops patch can be replaced by diff -r linux-2.5.23/linux/drivers/usb/host/uhci-hcd.c linux-2.5.23a/linux/drivers/usb/host/uhci-hcd.c 2431c2431 static void __devexit uhci_stop(struct usb_hcd *hcd) --- static void uhci_stop(struct usb_hcd *hcd) 2512c2512 stop: __devexit_p(uhci_stop), --- stop: uhci_stop, (pasted from another window). Andries --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: /proc/scsi/map
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:/raid5/Kernel/src $ cat /proc/scsi/map # C,B,T,U Typeonl sg_nm sg_dev nm dev(hex) 0,0,00,00 0x051 sg0 c:15:00 sr0 b:0b:00 [...] Great, this was really missing badly. But how about adding another column: GUID. Most usb-storage and (all?) FireWire devices have such a unique identitiy. In contrast to native SCSI devices, these emulated SCSI devices on hot-plugging busses will change their LUNs/IDs. Therefor the GUID is really a must to be able to create stable names (laptop suspend, etc.). Both usb-storage and iee1394-sbp2 know the GUID. It only needs to be communicated.. The usb-storage GUID is just one random item of information. One might wish for much more. And: this information is already somewhere: % cat /proc/scsi/sg/host_strs SCSI host adapter emulation for IDE ATAPI devices Iomega VPI2 (imm) interface SCSI emulation for USB Mass Storage devices SCSI emulation for USB Mass Storage devices % This tells me that host 0 will be in ide-scsi, host 1 in imm, host 2 in usb-storage-0, host 3 in usb-storage-1. And % cat /proc/scsi/ide-scsi/0 SCSI host adapter emulation for IDE ATAPI devices % cat /proc/scsi/imm/1 Version : 2.05 (for Linux 2.4.0) Parport : parport0 Mode: SPP % cat /proc/scsi/usb-storage-0/2 Host scsi2: usb-storage Vendor: DataFab Systems Inc. Product: USB CF+SM Serial Number: 5DC69477C6 Protocol: Transparent SCSI Transport: Datafab Bulk-Only GUID: 07c4a109005dc69477c6 Attached: Yes % cat /proc/scsi/usb-storage-1/3 Host scsi3: usb-storage Vendor: SCM Microsystems Inc. Product: eUSB SmartMedia / CompactFlash Serial Number: None Protocol: Transparent SCSI Transport: Control/Bulk-EUSB/SDDR09 GUID: 04e60005 Attached: Yes % A small utility that looks around in /proc is able to find the GUID. Of course it would be better when fewer heuristics were required. Finally, the GUIDs you see here do not determine the LUN. So, there is no well-defined line in /proc/scsi/map where they would belong. Andries ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb-storage
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 the 1-symbol fix that I sent to the list yesterday. --- /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 +00:32:48 2002 @@ -430,7 +430,7 @@ /* fill the URB */ FILL_CONTROL_URB(us-current_urb, us-pusb_dev, pipe, -(unsigned char*) dr, data, size, +(unsigned char*) dr, data, size, usb_stor_blocking_completion, NULL); /* submit the URB */ Andries ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Multiple Control URBs
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 locking problem; plan to look at it further soon] Andries ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb-storage
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 +00:32:48 2002 @@ -430,7 +430,7 @@ /* fill the URB */ FILL_CONTROL_URB(us-current_urb, us-pusb_dev, pipe, -(unsigned char*) dr, data, size, +(unsigned char*) dr, data, size, usb_stor_blocking_completion, NULL); /* submit the URB */ (pasted from another window, just to show; hope to send real patches later) Andries ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Multiple Control URBs
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 is so vague. In the IDE code there are things meant for certain types of RLL disks, very obsolete, but without comments it is difficult to judge for others whether something applied twelve years ago or yesterday, and whether it applies to lots of devices or just to a single broken model. Probably at some point in the future people will want to clean up some stuff in the usb code and will want to know why these customized things are required. Andries ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb-storage
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-2.5.17.tar.gz
% cp -a linux-2.5.17 linux
% patch -p0 -s /linux/2.5/linux-2.5.17a/2.5.16-us-patch
% diff -urb linux-2.5.17 linux odifmd
% rm -rf linux-2.5.17 linux
Am not sure why you couldn't do the similar thing.
Anyway, below a diff for your viewing pleasure.
This exercise also shows that it still applies against 2.5.17.
Andries
diff -urb linux-2.5.17/drivers/usb/storage/Makefile linux/drivers/usb/storage/Makefile
--- linux-2.5.17/drivers/usb/storage/Makefile Tue May 21 07:07:41 2002
+++ linux/drivers/usb/storage/Makefile Tue May 21 12:02:48 2002
@@ -11,14 +11,14 @@
obj-$(CONFIG_USB_STORAGE) += usb-storage.o
usb-storage-obj-$(CONFIG_USB_STORAGE_DEBUG)+= debug.o
-usb-storage-obj-$(CONFIG_USB_STORAGE_HP8200e) += shuttle_usbat.o
-usb-storage-obj-$(CONFIG_USB_STORAGE_SDDR09) += sddr09.o
-usb-storage-obj-$(CONFIG_USB_STORAGE_SDDR55) += sddr55.o
+usb-storage-obj-$(CONFIG_USB_STORAGE_HP8200e) += shuttle_usbat.o raw_bulk.o
+usb-storage-obj-$(CONFIG_USB_STORAGE_SDDR09) += sddr09.o raw_bulk.o
+usb-storage-obj-$(CONFIG_USB_STORAGE_SDDR55) += sddr55.o raw_bulk.o
usb-storage-obj-$(CONFIG_USB_STORAGE_FREECOM) += freecom.o
usb-storage-obj-$(CONFIG_USB_STORAGE_DPCM) += dpcm.o
usb-storage-obj-$(CONFIG_USB_STORAGE_ISD200) += isd200.o
-usb-storage-obj-$(CONFIG_USB_STORAGE_DATAFAB) += datafab.o
-usb-storage-obj-$(CONFIG_USB_STORAGE_JUMPSHOT) += jumpshot.o
+usb-storage-obj-$(CONFIG_USB_STORAGE_DATAFAB) += datafab.o raw_bulk.o
+usb-storage-obj-$(CONFIG_USB_STORAGE_JUMPSHOT) += jumpshot.o raw_bulk.o
usb-storage-objs :=scsiglue.o protocol.o transport.o usb.o \
initializers.o $(usb-storage-obj-y)
diff -urb linux-2.5.17/drivers/usb/storage/datafab.c
linux/drivers/usb/storage/datafab.c
--- linux-2.5.17/drivers/usb/storage/datafab.c Tue May 21 07:07:43 2002
+++ linux/drivers/usb/storage/datafab.c Tue May 21 12:02:48 2002
@@ -51,6 +51,7 @@
*/
#include transport.h
+#include raw_bulk.h
#include protocol.h
#include usb.h
#include debug.h
@@ -60,113 +61,31 @@
#include linux/errno.h
#include linux/slab.h
-extern int usb_stor_bulk_msg(struct us_data *us, void *data, int pipe,
-unsigned int len, unsigned int *act_len);
-
-static int datafab_determine_lun(struct us_data *us, struct datafab_info *info);
-
-
-static void datafab_dump_data(unsigned char *data, int len)
-{
- unsigned char buf[80];
- int sofar = 0;
-
- if (!data)
- return;
-
- memset(buf, 0, sizeof(buf));
-
- for (sofar = 0; sofar len; sofar++) {
- sprintf(buf + strlen(buf), %02x ,
- ((unsigned int) data[sofar]) 0xFF);
-
- if (sofar % 16 == 15) {
- US_DEBUGP(datafab: %s\n, buf);
- memset(buf, 0, sizeof(buf));
- }
- }
-
- if (strlen(buf) != 0)
- US_DEBUGP(datafab: %s\n, buf);
-}
-
-
-static int datafab_raw_bulk(int direction,
- struct us_data *us,
- unsigned char *data,
- unsigned int len)
-{
- int result;
- int act_len;
- int pipe;
-
- if (direction == SCSI_DATA_READ)
- pipe = usb_rcvbulkpipe(us-pusb_dev, us-ep_in);
- else
- pipe = usb_sndbulkpipe(us-pusb_dev, us-ep_out);
-
- result = usb_stor_bulk_msg(us, data, pipe, len, act_len);
-
- // if we stall, we need to clear it before we go on
- if (result == -EPIPE) {
- US_DEBUGP(datafab_raw_bulk: EPIPE. clearing endpoint halt for
- pipe 0x%x, stalled at %d bytes\n, pipe, act_len);
- usb_stor_clear_halt(us, pipe);
- }
-
- if (result) {
- // NAK - that means we've retried a few times already
- if (result == -ETIMEDOUT) {
- US_DEBUGP(datafab_raw_bulk: device NAKed\n);
- return US_BULK_TRANSFER_FAILED;
- }
-
- // -ENOENT -- we canceled this transfer
- if (result == -ENOENT) {
- US_DEBUGP(datafab_raw_bulk: transfer aborted\n);
- return US_BULK_TRANSFER_ABORTED;
- }
-
- if (result == -EPIPE) {
- US_DEBUGP(datafab_raw_bulk: output pipe stalled\n);
- return USB_STOR_TRANSPORT_FAILED;
- }
+static int datafab_determine_lun(struct us_data *us,
+struct datafab_info *info);
- // the catch-all case
- US_DEBUGP(datafab_raw_bulk: unknown
Re: [linux-usb-devel] [PATCH] usb-storage
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(
struct us_data *us, int pipe,
unsigned char request, unsigned char requesttype,
unsigned int value, unsigned int index,
unsigned char *xfer_data, unsigned int xfer_len);
extern int usb_storage_raw_bulk(
struct us_data *us, int direction,
unsigned char *data, unsigned int len, unsigned int *act_len);
extern int usb_storage_bulk_transport(
struct us_data *us, int direction,
unsigned char *data, unsigned int len, int use_sg);
/* scatter-gather */
extern unsigned char *us_copy_from_sgbuf(
unsigned char *content, int buflen,
int *index, int *offset, int use_sg);
extern unsigned char *us_copy_from_sgbuf_all(
unsigned char *content, int len, int use_sg);
extern void us_copy_to_sgbuf(
unsigned char *buffer, int buflen,
void *content, int *index, int *offset, int use_sg);
extern void us_copy_to_sgbuf_all(
unsigned char *buffer, int buflen,
void *content, int use_sg);
#endif
raw_bulk.c
/*
* Common routines for a handful of drivers.
* Unrelated to CF/SM - just USB stuff.
*
* This is mostly a thin layer on top of transport.c.
* It converts routines that return values like -ENOENT and -EPIPE
* into routines that return USB_STOR_TRANSPORT_ABORTED etc.
*
* There is also some debug printing here.
*/
#include debug.h
#include transport.h
#include raw_bulk.h
#ifdef CONFIG_USB_STORAGE_DEBUG
#define DEBUG_PRCT 12
#else
#define DEBUG_PRCT 0
#endif
/*
* Send a control message and wait for the response.
*
* us - the pointer to the us_data structure for the device to use
*
* request - the URB Setup Packet's first 6 bytes. The first byte always
* corresponds to the request type, and the second byte always corresponds
* to the request. The other 4 bytes do not correspond to value and index,
* since they are used in a custom way by the SCM protocol.
*
* xfer_data - a buffer from which to get, or to which to store, any data
* that gets send or received, respectively, with the URB. Even though
* it looks like we allocate a buffer in this code for the data, xfer_data
* must contain enough allocated space.
*
* xfer_len - the number of bytes to send or receive with the URB.
*
*/
int
usb_storage_send_control(struct us_data *us,
int pipe,
unsigned char request,
unsigned char requesttype,
unsigned int value,
unsigned int index,
unsigned char *xfer_data,
unsigned int xfer_len) {
int result;
// Send the URB to the device and wait for a response.
printk(usb_storage_send_control\n);
/* Why are request and request type reversed in this call? */
result = usb_stor_control_msg(us, pipe,
request, requesttype, value, index,
xfer_data, xfer_len);
printk(usb_stor_control_msg returns %d\n, result);
// Check the return code for the command.
if (result 0) {
/* if the command was aborted, indicate that */
if (result == -ENOENT)
return USB_STOR_TRANSPORT_ABORTED;
/* a stall is a fatal condition from the device */
if (result == -EPIPE) {
US_DEBUGP(-- Stall on control pipe. Clearing\n);
result = usb_clear_halt(us-pusb_dev, pipe);
US_DEBUGP(-- usb_clear_halt() returns %d\n,
result);
return USB_STOR_TRANSPORT_FAILED;
}
/* Uh oh... serious problem here */
return USB_STOR_TRANSPORT_ERROR;
}
return USB_STOR_TRANSPORT_GOOD;
}
int
usb_storage_raw_bulk(struct us_data *us, int direction, unsigned char *data,
unsigned int len, unsigned int *act_len) {
int result;
int pipe;
if (direction == SCSI_DATA_READ)
pipe = usb_rcvbulkpipe(us-pusb_dev, us-ep_in);
else
pipe = usb_sndbulkpipe(us-pusb_dev, us-ep_out);
result = usb_stor_bulk_msg(us, data, pipe, len, act_len);
/* if we stall, we need to clear it before we go on */
if (result == -EPIPE) {
US_DEBUGP(EPIPE: clearing endpoint halt for
pipe 0x%x, stalled at %d bytes\n,
pipe, *act_len);
usb_clear_halt(us-pusb_dev, pipe);
/* return US_BULK_TRANSFER_SHORT; */
}
if (result) {
[linux-usb-devel] HID and usb-uhci-hcd.c (was: usb-storage)
: 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 device is T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 D: Ver= 1.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=05e3 ProdID=000a Rev= 0.00 C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr= 48mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=hid E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=8ms I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=(none) E: Ad=83(I) Atr=03(Int.) MxPS= 2 Ivl=8ms I: If#= 2 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=(none) E: Ad=82(I) Atr=03(Int.) MxPS= 3 Ivl=8ms A USB keyboard that again connects to a (non-USB!) mouse. The routine drivers/usb/input/hid-core.c:hid_init_reports() submits a control usb via hid_submit_report(). Then, a few lines down, it submits a control usb via usb_control_msg(). It is this couple that usb-uhci-hcd.c:uhci_urb_enqueue() complains about saying propably device driver bug (Or, rather, there are many such couples, but this is the first occurrence.) The keyboard works fine. Andries ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] HID and usb-uhci-hcd.c (was: usb-storage)
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.sprintpcs.com/adp/index.cfm ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb-storage
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 have very small drivers. In usb-storage the drivers are many times larger. The reason is that everyone who writes a driver starts by taking a copy of a previous driver. Consequently much code duplication occurs. This is bad in itself, but as people discover small flaws in the code, these flaws get corrected in one driver, and live on in other drivers. Also this divergence is bad. Your question sounds as if I invent functions. But I do not claim such originality. Everywhere I saw five copies of a function, I made a single copy and made these five places use the single copy. For example, datafab_raw_bulk() and jumpshot_raw_bulk() and sddr09_raw_bulk() and sddr55_raw_bulk() and usbat_raw_bulk() now become usb_storage_raw_bulk(). You ask: what silly code - why write things that way? I agree entirely. But this silly code occurred five times, and after the patch it occurs once. That is a much better starting point if one wants to improve this code. And this raw_bulk business is an uninteresting part. The knowledge about smartmedia now also lies embedded many places. Some drivers have more details than others. And this knowledge is needed not only by a handful of drivers in usb/storage.c but also by mtd. So, the next patch, or a next patch, is the extraction of all smartmedia stuff and the creation of smartmedia.c. You have already seen it, or at least, I already send some version last week. Probably there also is some version at ftp.kernel.org. Both changes are changes that do no touch USB or SCSI. A third change does touch the SCSI part of things, namely the patch that makes all drivers return correct or at least reasonable sense codes. Hope that you see what I am doing. And that although it seems as if most of usb-storage is changed, in reality almost nowhere the usb side of things is touched. Andries ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb-storage
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 easy to find the typo and correct it. With large patches this continuity is lost. My patch removed 5% of the code in usb-storage. That suffices for a first step. I'd also like to know that he _really_ intends to take the next few steps. I outlined a few steps to come. Showed you the code for some. Every step is an improvement. Why don't I do more? Well, you are welcome to work yourself on the things you consider most urgent. Other than that, the patch looks fine. But I'd really hate to introduce a couple of new files only to have them removed later... so we should think about where this is all going to end up _ahead_of_time_. Ah, this is going to end up in a beautiful USB subsystem, where all devices I possess really work, and nothing crashes if one inserts and removes a few devices a few times. Andries ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb-storage
== 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 130kB or so. Split the patch in separate subpatches. After applying 90kB of those things still work. Must look a bit better at the last part. Unfortunately not before Friday. Maybe the hang is because of the replacement of semaphores by spinlocks? [Can the author of that code (try to) check that the locking stuff is OK?] In the above works may involve an Oops at boot time that goes away after a power cycle. Something that doesnt cause a failure, but is very ugly: Why was status_byte(srb-result) == GOOD replaced by srb-result == GOOD 1 ? Andries ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb-storage
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. With earlier kernel versions I often saw a stalled pipe, but that was never fatal. But now it was. Once I caused a kernel reboot by disconnecting a USB device. I tried a USB keyboard, and it was fine. The problems were only with usb-storage. First I blamed my patch, but a vanilla 2.5.16 exhibits identical behaviour. More precisely, I tried three UHCI drivers, and two showed the same behaviour, and the third did not compile. So, if nobody else immediately recognizes the problem I must wait until there is some time and then go slowly through the changes between 2.5.14, that works, and 2.5.16, that doesn't work. Maybe this evening. More likely, next weekend. Andries Is it documented someplace what requirements a driver should obey? It feels as if several usb-storage things are not in a perfect shape. But I know so little about the surroundings. ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb-storage
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 changes in debugging printout. With earlier 2.5 kernels I would get a kernel crash with 10 retries, while the kernel survived with 3. As I said in a previous letter, usb-storage is not in a perfect shape yet. But apart from this practical fact, there is also a theoretical reason. Very often the first attempt fails, for various reasons. Perhaps there is still a Unit Attention to react to. Usually the second attempt succeeds. Just to be sure, try three times. Of course, in a perfect world, it would not matter how often one tried. As it is, with our rather fragile USB system, I find that things crash when unexpected interrupts arrive. Sometimes a warm reboot does not clear this situation, and the kernel crashes immediately at the next reboot. A cold reboot, an actual power cycle, is required to make things work again. The more often one retries, the more certain it is that the kernel is not at the same place in a conversation as the device. Andries ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb-storage
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 removes a lot of code. [Greg, no reason not to apply the previous patch - the next one will just remove some more code.] Matt, you asked for a diff -b. But can't you make that yourself? (Apply the patch to some tree, and say diff -r -u -b or so.) But if you are short on disk space, I'll send one. Matt, concerning the s/10/3/ - if that really worries you I'll do s/3/10/ again. [Personally I think that anybody who writes a driver and lets it retry ten times is a bad programmer. Retrying is almost always the wrong thing to do. In this particular case it also happened to crash the kernel. But of course the USB code will improve, and some day it will no longer crash the kernel. That day I will still think that retrying ten times is a bug.] Andries ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb-storage
== 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 the file devices should exist, but might of course be empty. [create_special_files is called by usbfs_add_bus(), so never happens if usbfs_add_bus() never happens] The reason that usbfs_add_bus never happens turns out to be that nothing in the host directory is compiled. Maybe --- Makefile~ Sat May 18 16:25:54 2002 +++ MakefileTue May 21 04:33:03 2002 @@ -14,6 +14,7 @@ subdir-$(CONFIG_USB_OHCI) += host subdir-$(CONFIG_USB_UHCI_ALT) += host subdir-$(CONFIG_USB_UHCI) += host +subdir-$(CONFIG_USB_UHCI_HCD) += host subdir-$(CONFIG_USB_ACM) += class subdir-$(CONFIG_USB_AUDIO) += class is needed in linux/drivers/usb? After doing this, and with only a keyboard connected, I see Initializing USB Mass Storage driver... usb.c: registered new driver usb-storage usb-uhci-hcd.c: ENXIO (Control) 8400, flags 0, urb ce1b9120, burb ce1b90c0, propably device driver bug... input: USB HID v1.00 Device [05e3:000a] on usb-00:07.2-1.1 usb-uhci-hcd.c: ENXIO (Control) 8480, flags 0, urb ce1b9180, burb ce1b90c0, propably device driver bug... USB Mass Storage support registered. Certainly propably is a typo. Did not look further - am not sure whether things are supposed to work with only CONFIG_USB_UHCI_HCD selected. Andries ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb-storage
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 looked at them, always work relative to the latest official kernel. As far as I can see that is a reasonable point of view: Greg does frequent syncs. Concerning Bitkeeper, for the time being I have decided against using it. Jeff Dike was happy last week or so that UML is self-hosting. I would be unhappy if it turns out that open source software is not self-hosting. Concerning 2.5.16: IDE and USB were broken for me. The IDE part turned out to be easy to fix. Have not yet looked at the USB part. Andries BTW - Now that I write anyway, a question: One of the things I did was replacing half a dozen identical copies of some scatter-gather code by a single copy. But is it really necessary to have even this single copy? It is not clear to me why these CF and SM drivers should replace sg buffers by a single big contiguous buffer. ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [patch] 2.4.19-pre8 uhci.c invalid pipe size
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 the usb_submit_urb() call, not force it
to be duplicated in all host drivers. So how about the patch below?
int usb_submit_urb(struct urb *urb, int mem_flags)
{
-if (urb urb-dev urb-dev-bus urb-dev-bus-op)
+
+if (urb urb-dev urb-dev-bus urb-dev-bus-op) {
+if (usb_maxpacket(urb-dev, urb-pipe, usb_pipeout(urb-pipe)) = 0) {
+err(%s: pipe %x has invalid size (= 0), __FUNCTION__, urb-pipe);
+return -EMSGSIZE;
+}
return urb-dev-bus-op-submit_urb(urb, mem_flags);
-else
-return -ENODEV;
+}
+return -ENODEV;
}
Hmm. So arbitrary. Why only this single test?
uhci_submit_urb() starts with several sanity checks.
And why precisely is it necessary?
Why does the kernel die? Does it hang in a spinlock with
disabled interrupts? Inspection of the code without this
stopgap might reveal other bugs.
Andries
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [patch] 2.4.19-pre8 uhci.c invalid pipe size
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 a long time.
Similar code occurs in uhci_submit_control().
Andries
[I would prefer testing at the place this maxsze is actually
used. Maybe that is less code and more readable source.]
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [patch] 2.4.19-pre8 uhci.c invalid pipe size
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-epmaxpacketin/out that is zero. So, the bug is perhaps more in kernel code than in the device. Must read some more code to see who is responsible for setting dev-epmaxpacketin/out. T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 P: Vendor=07cc ProdID=0003 Rev= 0.00 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=usb-storage I: If#= 0 Alt= 1 #EPs=13 Cls=ff(vend.) Sub=ff Prot=ff Driver=usb-storage E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=10ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=88(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=08(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=89(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=09(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=8a(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=0a(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms I: If#= 0 Alt= 2 #EPs=13 Cls=ff(vend.) Sub=ff Prot=ff Driver=usb-storage E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=10ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=88(I) Atr=01(Isoc) MxPS= 256 Ivl=1ms E: Ad=08(O) Atr=01(Isoc) MxPS= 256 Ivl=1ms E: Ad=89(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=09(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=8a(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=0a(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms Also, your patch on 2.5 would cause urbs to leak if that if () call was ever true. How so? You made the return follow /* increment the reference count of the urb */ urb = usb_get_urb(urb); without decrementing. Andries ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [patch] 2.4.19-pre8 uhci.c invalid pipe size
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 can see. More precisely, the value for endpoint 0 is set in usb_new_device(). Values for other endpoints only in usb_set_maxpacket() [which has the comment hub-only!!]. And usb_set_maxpacket() is called only by hub.c:usb_reset_device() and core/usb.c:usb_set_interface() and usb_set_configuration(). From the comments it looks like usb_set_interface() and usb_set_configuration() are called only in non-default situations. In any case, usb_set_interface() is not called in usb-storage, and usb_set_configuration() only in some very ugly, kludgy #ifdef CONFIG_USB_STORAGE_SDDR09 - part of storage/usb.c. So, at least in usb-storage, it seems that epmaxpacket* will be valid only by accident. It also looks like storage/usb.c picks an essentially random endpoint to use, ignoring all others. Let me cc Matt so that he can comment. Andries ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [patch] 2.4.19-pre8 uhci.c invalid pipe size
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 pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [patch] 2.4.19-pre8 uhci.c invalid pipe size
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
not calling that function.
I do not know enough yet to change these things, so I am only
muttering about the things I don't like or don't understand,
and about the things that cause the kernel to malfunction.
Ugly part number one is the special ad-hoc
CONFIG_USB_STORAGE_SDDR09 code in storage/usb.c:storage_probe().
USB storage must do general things, and if special device things
are required there should be a flag for that special action in
the unusual device table.
Question number two is the code that selects the endpoint:
for (i = 0; i altsetting-bNumEndpoints; i++) {
/* is it an BULK endpoint? */
if ((altsetting-endpoint[i].bmAttributes
USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_BULK) {
/* BULK in or out? */
if (altsetting-endpoint[i].bEndpointAddress
USB_DIR_IN)
ep_in = altsetting-endpoint[i];
else
ep_out = altsetting-endpoint[i];
}
/* is it an interrupt endpoint? */
if ((altsetting-endpoint[i].bmAttributes
USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT) {
ep_int = altsetting-endpoint[i];
}
}
Thus, among all endpoints, one will get the last endpoints that are
bulk-in, bulk-out and interrupt, respectively.
To me that sounds fairly random.
But maybe there is some ordering among the endpoints, so that it
is appropriate to take the last ones in the list?
Problem number three is that the above code in storage_probe()
is called in a loop over all interfaces (in scsiglue.c I suppose)
but that usb_set_configuration() is not called, so that the endpoint
sizes will be undefined if the interface is not interface 0.
Probably there should be an unconditional call to usb_set_configuration()
in storage_probe().
Andries
P.S. Let me repeat the /proc/bus/usb/devices output for the device
that prompted this discussion.
T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1
P: Vendor=07cc ProdID=0003 Rev= 0.00
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=usb-storage
I: If#= 0 Alt= 1 #EPs=13 Cls=ff(vend.) Sub=ff Prot=ff Driver=usb-storage
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=10ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=88(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms
E: Ad=08(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms
E: Ad=89(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms
E: Ad=09(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms
E: Ad=8a(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms
E: Ad=0a(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms
I: If#= 0 Alt= 2 #EPs=13 Cls=ff(vend.) Sub=ff Prot=ff Driver=usb-storage
E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=10ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=88(I) Atr=01(Isoc) MxPS= 256 Ivl=1ms
E: Ad=08(O) Atr=01(Isoc) MxPS= 256 Ivl=1ms
E: Ad=89(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms
E: Ad=09(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms
E: Ad=8a(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms
E: Ad=0a(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [patch] 2.4.19-pre8 uhci.c invalid pipe size
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, Memory Stick, Secure Digital, etc. device. This chip has been used in many devices with a varying amount of physical buildup around it. Some of these are readers for one kind of card, some are dual readers, some are multiple readers. The device I actually have here only reads SmartMedia, so does not need all these endpoints. A single pair suffices. Why on earth is usb-storage even trying to claim this device? Because, unless I am much mistaken, this device will work fine under Linux within a few days. But unlike earlier devices I wrote a driver for, this one forces me to learn more about the surrounding USB code. Andries ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [patch] 2.4.19-pre8 uhci.c invalid pipe size
: 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 the data sheet of the Anchor AN2131, and the resemblance is too large to be a coincidence. Four of the bulk endpoints are used (one for reading, one for writing / downloading firmware, one for getting a 2-byte status, one for sending commands). So, indeed, the usb-storage model where only two bulk endpoints are used, fails. Is there already support for this animal elsewhere? That is, would it suffice to give the firmware? Andries ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] bug in alt-uhci
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 message is preferable above a dead system, this must be regarded as a bug in alt-uhci. This is 2.5.14. Andries ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] usb-storage / smartmedia
Recently I have written three drivers for USB SmartMedia readers.
One reached 2.5.13. One is visible on ftp.XX.kernel.org.
The third was this evening.
Such drivers share a lot of code, and instead of having N copies
of the code (as is already today visible in usb/storage) I separated
out all that was common. Let me show you here some fragments of code.
Note, Matt, Greg: this is not a code submission, it is just a request
for comments. This may not even compile. Sooner or later I'll submit
some version of this.
The first fragment is smartmedia.c.
It knows about the structure of a smartmedia card, but not about the
commands the various drivers use to read and write.
- smartmedia.h -
#ifndef _SMARTMEDIA_H_
#define _SMARTMEDIA_H_
#include usb.h
extern unsigned char nand_parity[256];
extern void nand_compute_ecc(unsigned char *data, unsigned char *ecc);
extern void nand_store_ecc (unsigned char *data, unsigned char *ecc);
extern int nand_compare_ecc(unsigned char *data, unsigned char *ecc);
struct sm_card_info {
unsigned long capacity; /* Size of card in bytes */
int pagesize; /* Size of page in bytes */
int pageshift; /* log2 of pagesize */
int blocksize; /* Size of block in pages */
int blockshift; /* log2 of blocksize */
int blockmask; /* 2^blockshift - 1 */
int *lba_to_pba;/* logical to physical map */
int *pba_to_lba;/* physical to logical map */
int controlshift; /* log2 of extra bytes/page */
int lbact; /* number of available pages */
int flags;
#define SMARTMEDIA_WP 1 /* write protected */
#define SMARTMEDIA_RO 2 /* set to read-only */
};
struct sm_ops {
int (*sm_init)(struct us_data *us);
int (*sm_read_deviceID)(struct us_data *us, unsigned char *id4);
int (*sm_read_map)(struct us_data *us);
int (*sm_read_control)(struct us_data *us,
unsigned long address, unsigned int sectorct,
unsigned char *buf, int use_sg);
int (*sm_read_data)(struct us_data *us,
unsigned long address, unsigned int sectorct,
unsigned char *buf, int use_sg);
int (*sm_write_lba)(struct us_data *us, unsigned int lba,
unsigned int page, unsigned int pagect,
unsigned char *buf);
int (*sm_test_unit_ready)(struct us_data *us,
Scsi_Cmnd *srb, int cmdlen);
int (*sm_request_sense)(struct us_data *us,
Scsi_Cmnd *srb, int cmdlen);
};
extern int smartmedia_raw;
extern int
smartmedia_transport(Scsi_Cmnd *srb, struct us_data *us, struct sm_ops *sm);
extern int
smartmedia_allocate_map(struct sm_card_info *info);
extern unsigned int
smartmedia_find_unused_pba(struct sm_card_info *info, unsigned int lba);
/*
* LBA and PBA are unsigned ints. Special values.
*/
#define UNDEF0x
#define SPARE0xfffe
#define UNUSABLE 0xfffd
#endif
- smartmedia.c -
/*
* SmartMedia driver, aeb, koninginnedag 2002
*
* (c) 2000, 2001 Robert Baruch ([EMAIL PROTECTED])
* (c) 2002 Andries Brouwer ([EMAIL PROTECTED])
*/
#include linux/config.h
#include linux/module.h
#include transport.h
#include smartmedia.h
#include debug.h
/* #define US_DEBUGPprintk */
#define short_pack(lsb,msb) (((u16)(lsb)) | (((u16)(msb))8))
#define LSB_of(s) ((s)0xFF)
#define MSB_of(s) ((s)8)
/*
* The below two parameters are meant for debugging use only.
* They work globally, not per device.
*/
/* direct access to card */
int smartmedia_raw = 0;
MODULE_PARM(smartmedia_raw, i);
MODULE_PARM_DESC(smartmedia_raw, make PBA=LBA);
/* each 512-byte sector has 64 bytes control */
/* the control is given in PBA order */
static int smartmedia_control = 0;
MODULE_PARM(smartmedia_control, i);
MODULE_PARM_DESC(smartmedia_control, read control);
/*
* First some stuff that does not belong here:
* data on SmartMedia and other cards, unrelated to USB.
* Similar stuff occurs in linux/mtd/nand_ids.h.
*/
struct nand_flash_dev {
int model_id;
int chipshift; /* 1cs bytes total capacity */
char pageshift; /* 1ps bytes in a page */
char blockshift;/* 1bs pages in an erase block */
char zoneshift; /* 1zs blocks in a zone */
/* # of logical blocks is 125/128 of this */
char pageadrlen;/* length of an address in bytes - 1 */
};
/*
* NAND Flash Manufacturer ID Codes
*/
#define NAND_MFR_AMD0x01
#define NAND_MFR_TOSHIBA0x98
#define NAND_MFR_SAMSUNG0xec
static inline char *
nand_flash_manufacturer(int manuf_id
Re: [linux-usb-devel] Re: usb-storage
How did you find out about the 128bit SSFDC ID ? Toshiba gives a few details. Andries ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: usb-storage
From: Sancho Dauskardt [EMAIL PROTECTED] Forget datafab.c for this, as the protocoll is a little different. Hm. I used datafab.c successfully for the CF side. What precisely is different? It's a while ago, but if I remember correctly, the ACOMdATA (actually OnSpec Inc.) chip has two short bulk data packets waiting to be read after a read/write, and datafab.c only requested one, which got the device quite confused after some time - and especially so after media change. Also datafab.c is useless for lun != 0 (for the ACOMdATA drive that is). Note: reseting the ACOMdATA via the usb hub (usb_reset_device()) only work for the CF/SM part, but not for the MS/SD. Check older postings about other quirks. Last Tuesday (Queens Birthday - a holiday in Holland) I did the reading part, and this evening the writing part for this animal. I see that you also did reading, more or less in the same way, but you did not have writing code? Let me document the present state of knowledge. /* * Commands: 8 bytes * Five commands are known: * * Identify: 0 0 0 0 0 b0 0 80 * * Read DeviceID: 0 0 0 0 0 b0 0 84 * * Read: 0 P P P 0 b0 N 85 * here N is the number of 256-byte chunks, * the high order bits of PPP are the PBA, the low order bits * the sector within an erase block. * * Write: L1 P P P eN b0 L2 86 * here e is the bit no evacuation needed (bit 6), and * N is the number of 512-byte sectors (bits 5-0), * and PPP is as for Read, and L1,L2 are the low and high order * parts of LBA. * * The write is not done at the indicated address, but elsewhere, * and after the 2-byte OK status, four more bytes are returned * to indicate where. The address PPP is big-endian, the returned * address little-endian. * * Read map: 0 0 0 0 0 b0 L 8a * here L is the number of 256-byte chunks. * The map in 2 bytes (little endian) per block. * * (The CF part uses Identify: 00 01 00 00 00 a0 ec 01.) */ (more details in the code). I changed quite a lot in the usb-storage directory, mostly to avoid code duplication. If anyone is interested, the current version lives on ftp.XX.kernel.org in kernel/people/aeb/usb-storage*wip Unfortunately I cannot finish this second driver this evening, since I destroyed my SmartMedia card. Wrote something bad to it, and this reader doesnt want to look at it anymore. Andries ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: usb-storage
Ah, that beast ! Check http://www.dauskardt.de/leftovers.html. Done. Forget datafab.c for this, as the protocoll is a little different. Hm. I used datafab.c successfully for the CF side. What precisely is different? Also your code resembles datafab.c very much; my first impression is that you added media_change and reset stuff and left all the rest unchanged. Did I overlook something? Andries ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: usb-storage
From: Matthew Dharm [EMAIL PROTECTED] If it provides multiple LUNs, then it must be using the 'standard' interfaces. If that's the case, none of the 'standard' class drivers use the us-extra pointer. I'm confused. I have several devices here that read smart media. All of them need a PBA-LBA translation table. All of them use more than one lun, for example because they also read compact flash cards. So, I don't know about your 'standard', but the us-extra pointer is really needed. Also elsewhere us-extra is needed. For example, it is quite usual to fake a reply to certain SCSI commands. A later REQUEST_SENSE must then not go to the device, even when the device can handle the REQUEST_SENSE command, but must give the reply suitable for the earlier fake command reply. Failure to do so produces stalls. Where does one keep the fake sense codes to return in case someone asks for them? Really the info struct at us-extra is the only reasonable place. Andries ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: usb-storage
i.e. you want to use datafab.c for lun #0, but you own driver
for lun #1..3 ?
My own driver for lun 1, yes.
And in another device precisely the reverse, datafab.c for lun #1
and my own driver for lun #0.
[The thing I mentioned is two USB devices with two luns each,
not one device with four luns.]
Such considerations bring me to the desire to have something like
info = ((struct per_lun_data *) us-extra)[lun].data;
kill = ((struct per_lun_data *) us-extra)[lun].destructor;
for all drivers in usb-storage.
Yes and no. There are other drives that have totally different commands
for each 'lun', but still share status media change bits.
In this case you'd have problems distributing the media change information
over the different luns.
Ha, media change - I still do not know how to detect that,
understood from Matt that this info is unavailable. But it is?
As your case is a fairly uncommon one, i'd suggest:
struct big_6in1_reader_extra_data {
struct something_for_cf cf_data;
struct something_for_sm sm_data;
...
}
and then, do all the lun -- xxx_data handling in your transport routine
(ie. then swap the us-extra is you really want to use other code this way).
That does not work, since both cf and sm can be active simultaneously.
But us-extra can only hold a single value.
p.s. got a cat /proc/bus/usb/devices of the reader for us ?
...
T: Bus=01 Lev=03 Prnt=03 Port=03 Cnt=02 Dev#= 20 Spd=12 MxCh= 4
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0451 ProdID=2046 Rev= 1.25
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms
T: Bus=01 Lev=04 Prnt=20 Port=00 Cnt=01 Dev#= 22 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0c0b ProdID=a109 Rev=17.08
S: Manufacturer=ACOMdATA
S: Product=USB CF+SM
S: SerialNumber=64FDEA5EFD
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms
T: Bus=01 Lev=04 Prnt=20 Port=01 Cnt=02 Dev#= 21 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0c0b ProdID=a10c Rev= 2.00
S: Manufacturer=ACOMdATA
S: Product=USB SD+MS
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms
...
Andries
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: usb-storage
From: Matthew Dharm [EMAIL PROTECTED] But us-extra can only hold a single value. This isn't really true. If you implement them as different LUNs on the same unit, the SCSI layer won't allow them to both have a command active at once. Besides, the control thread for the unit will serialize the commands. OK. Still, such solutions (have a struct with two pointers and two destructor routines in us-extra; have the driver copy this to some local variables and replace us-extra when it calls the subdriver to do the work, and restore things again when the subdriver is done) feel extremely fragile and kludgy. You are not really suggesting the above? Andries ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] BUG()
Devices (now, after a reboot): 1. USB UHCI-alt Root Hub 2. hub 0451:1446 3. hub 0451:1446 4. keyboard / hidmouse 05e3:000a 3a. eUSB SmartMedia / CompactFlash Adapter 04e6:0005 with numbering and indentation showing the topology. [... Both hubs shown are the same device. ...] So you're reporting at least one reproducible bug ... maybe a second (hub shows up twice, see below) ... Nothing is wrong with these hubs. This hub is a little box with seven ports. Internally it is two 4-port hubs, where the second one takes one port of the first one. Andries ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] BUG()
From: David Brownell [EMAIL PROTECTED] So you're reporting at least one reproducible bug (3a sticks), maybe a second (hub shows up twice, see below) and even a third (CONFIG problem) ... and that eventually you see one hard-to-reproduce BUG()? I report a BUG(), and mention in passing that some things are not perfect. Some people tend to connect these minor flaws with the bug. I think they are wrong. Anyway, let me start with the smallest flaw. CONFIG_USB_INPUT is mentioned twice. Reading drivers/usb/input/Config.in we find if [ $CONFIG_USB_HID = y -o $CONFIG_USB_KBD = y -o $CONFIG_USB_MOUSE \ = y ]; then define_bool CONFIG_USB_INPUT y fi if [ $CONFIG_USB_WACOM = y ]; then define_bool CONFIG_USB_INPUT y fi So, I suppose these two rules should be merged, and this tiny flaw is gone. Andries ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] BUG()
I have now seen for the second time a BUG() at usb.h:1074 usb_dec_dev_use() called by uhci_free_qh() called by uhci_free_pending_qhs() called by uhci_interrupt() called by handle_IRQ_event(). Since it is not easily reproducible, I have not attempted to trace what happens. Andries [Versions of the sddr09 driver for 2.4.19pre4 and 2.5.8 are now on ftp.linux.org. Comments are welcome.] ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: IDE / SmartMedia
From [EMAIL PROTECTED] Mon Apr 15 10:05:40 2002 - drive-using_tcq = 1; That helps, I think. The first boot after deleting this line again crashed, but this time with BUG() in linux/usb.h. All usb stuff was compiled in except for usb-storage, which was a module and not loaded. Maybe a race somewhere. The second boot all was fine. Andries ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Dane-Elec PhotoMate Combo
From: Matthew Dharm [EMAIL PROTECTED] (ii) this card needs usb/storage/dpcm.c which is compiled when CONFIG_USB_STORAGE_DPCM is set, but this variable is missing from usb/Config.in. Add it. This config option is considered so immature that it's not ready for the kernel config, even as an EXPERIMENTAL. Use it at your own risk. Of course. But the choice is simple. Without it, one has a non-functional device. With it, one has a device that works beautifully. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Dane-Elec PhotoMate Combo
I just got a Dane-Elec PhotoMate Combo SmartMedia/CompactFlash reader
manufactured by SCM Microsystems. It is a USB device with ID 04e6:0005.
The http://www.qbik.ch/usb/devices/ list of supported devices
calls this thing unsupported, and [EMAIL PROTECTED] writes:
I want this to work ! I'll help testing.
I think the status can be changed to fully supported, at least
it works fine in my first tests.
Changes required:
(i) in sd.c there is a peculiar code fragment that assumes
that a removable disk is write protected in case the status is unknown;
reversing this default allows writing to the flash card.
if (the_result) {
- printk(%s: test WP failed, assume Write Protected\n, nbuff);
- rscsi_disks[i].write_prot = 1;
+ printk(%s: test WP failed, assume Write Enabled\n, nbuff);
} else {
rscsi_disks[i].write_prot = ((buffer[2] 0x80) != 0);
(ii) this card needs usb/storage/dpcm.c which is compiled when
CONFIG_USB_STORAGE_DPCM is set, but this variable is missing
from usb/Config.in. Add it.
(iii) add to unusual_devs.h:
diff -u --recursive --new-file ../linux-2.4.3/linux/drivers/usb/storage/unusual_devs.h
./l\
inux/drivers/usb/storage/unusual_devs.h
--- ../linux-2.4.3/linux/drivers/usb/storage/unusual_devs.h Sun Apr 1 20:44:19
2001
+++ ./linux/drivers/usb/storage/unusual_devs.h Sat Apr 28 14:39:20 2001
@@ -79,6 +79,12 @@
CameraMate (DPCM_USB),
US_SC_SCSI, US_PR_DPCM_USB, NULL,
US_FL_START_STOP ),
+
+UNUSUAL_DEV( 0x04e6, 0x0005, 0x0100, 0x0208,
+ SCM Microsystems Inc,
+ eUSB SmartMedia / CompactFlash Adapter,
+ US_SC_SCSI, US_PR_DPCM_USB, NULL,
+ US_FL_START_STOP ),
#endif
Maybe the device is slow, and I got read errors with a Compact Flash
card in the reader at boot time. A blockdev --rereadpt /dev/sdX worked.
Andries
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
