Re: [linux-usb-devel] VID PID based fixed minor numbers - How ?
On Mon, Jul 04, 2005 at 06:19:14PM +0530, Jayaprakash Shanmugam wrote:
Hello All,
I have a USB driver that talks to four devices differentiated by their
minor numbers (fixed minor numbers for everyone of the devices)
In 2.4 Kernel - Probe () function :
I used devfs_register() for all the devices as follows:
for (i =0; i = 4;i++)
{
devfs_register(usb_devfs_handle, MyDriver,DEVFS_FL_DEFAULT,USB_MAJOR,
USBH_MINOR_BASE+i,S_IFCHR | S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP, Fops,
NULL);
}
I have this code working and planning to migrate to 2.6 kernel.
In 2.6 kernel :
When I looked into the usb-skeleton.c, it is suggested to use the
usb_register_dev() function. My problem here is this function
allocates minor numbers automatically starting from the base and I
dont have control over it ? For eg., If I plug in card 1 and then card
2, I will have minors as 64 for Card 1 and 65 for card 2. If I plug
in card 2 and then card 1, I will have minors as 64 for card 2 and 65
for card 1.
That is correct. If you are using the USB Major, there is no other way
(and if you are, you need to reserve your minor number range with the
usb kernel maintainer to make sure you don't conflict with anyone else.)
If you use your own major, you can do whatever you want to.
Could you please help me to fix a minor number based on the vendor ID
and product ID of a card ?
I would not recommend doing this. What happens if you plug in 2 devices
with the same vendor/product ids.
good luck,
greg k-h
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=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] providing sysfs/udev support
On Sat, Jul 02, 2005 at 12:51:39AM +0200, Tilman Schmidt wrote: For a driver for a USB ISDN device I help maintaining (http://gigaset307x.sourceforge.net - not yet submitted for inclusion in the kernel, for the obvious reasons), I have received a problem report that on Ubuntu with kernel 2.6.10, the setup is lost on every reboot. (Details at https://sourceforge.net/forum/forum.php?thread_id=1274719forum_id=75814) One contributor to the discussion stated that this was for lack of sysfs support in our driver as required by udev. Unfortunately I cannot find any information on what is actually required from a USB driver in order to work correctly with udev. We do register a character device with tty_register_device(), and it does appear as (for example) /sys/class/tty/ttyGB0/dev, but apparently that isn't enough. That is all that is needed for udev support. Unless you have other char devices than the tty node? thanks, greg k-h --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ 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: Input Device Key Mapping (driver authoring advice?)
On Mon, Jul 04, 2005 at 04:08:09PM -0400, Micah F. Galizia wrote: On Mon, 2005-04-07 at 13:01 +0200, Vojtech Pavlik wrote: The assignment of HID usages to Linux input events is done in the hid-input.c file. Change the #undef DEBUG in there to a #define DEBUG, and take a look at (or send me) the resulting 'dmesg' output. There you'll see which HID usages it didn't understand and how it assigned the others. Hello again. The output is at the bottom of the message. The offending device is listed as the Logitech USB Receiver. Another thing I just noticed is that the first physical device, which is standard keys (numbers, letters, etc), is claiming to have keys and buttons that it does not (or evtest is anyways). In any case, I'm game to fix this, so I guess I'm looking for recommendations on where to go from here. Oh, and sorry for all of the extra junk included in the dmesg output: Mapping: Keyboard.008c --- Key.KPJpComma Mapping: Keyboard.008d --- Key.Unknown Mapping: Keyboard.008e --- Key.Unknown Mapping: Keyboard.008f --- Key.Unknown Mapping: Keyboard.0090 --- Key.Hanguel Mapping: Keyboard.0091 --- Key.Hanja Mapping: Keyboard.0092 --- Key.Katakana Mapping: Keyboard.0093 --- Key.HIRAGANA Mapping: Keyboard.0094 --- Key.Zenkaku/Hankaku Mapping: Keyboard.0095 --- Key.Unknown Mapping: Keyboard.0096 --- Key.Unknown Mapping: Keyboard.0097 --- Key.Unknown Mapping: Keyboard.0098 --- Key.Unknown Mapping: LED.NumLock --- LED.NumLock Mapping: LED.CapsLock --- LED.CapsLock Mapping: LED.ScrollLock --- LED.ScrollLock input: USB HID v1.10 Keyboard [Logitech USB Receiver] on usb-:00:10.3-2 The above seems to be a truncated output from the keyboard part of the USB receiver. Apart from claiming to have keys that it doesn't, which is rather common, I don't see any problems there. Mapping: Consumer.00b5 --- Key.NextSong Mapping: Consumer.00b6 --- Key.PreviousSong Mapping: Consumer.0045 --- Key.Btn0 Mapping: Consumer.00cd --- Key.PlayPause Mapping: Consumer.00e2 --- Key.Mute Mapping: Consumer.00e9 --- Key.VolumeUp Mapping: Consumer.00ea --- Key.VolumeDown Mapping: Consumer.00b2 --- Key.Record Mapping: Consumer.009c --- Key.Btn1 Mapping: Consumer.009d --- Key.Btn2 Mapping: Consumer.0224 --- Key.Back Mapping: Consumer.0225 --- Key.Forward Mapping: Consumer.00b7 --- Key.StopCD Mapping: Consumer.0227 --- Key.Refresh Mapping: Consumer.022a --- Key.Bookmarks Mapping: Consumer.0192 --- Key.Calc Mapping: Consumer.0194 --- Key.File Mapping: Consumer.0209 --- Key.Btn3 Mapping: Consumer.00b4 --- Key.Rewind Mapping: Consumer.00b3 --- Key.Fast Forward Mapping: Consumer.0223 --- Key.HomePage Mapping: Consumer.008d --- Key.Btn4 Mapping: Consumer.00b0 --- Key.Play Mapping: Consumer.00b1 --- Key.Pause Mapping: ffbc.000d --- Key.Btn5 Mapping: ffbc.0025 --- Key.Btn6 Mapping: ffbc.0024 --- Key.Btn7 Mapping: ffbc.0047 --- Key.Btn8 Mapping: ffbc.0049 --- Key.Btn9 Mapping: ffbc.004a --- Key.? Mapping: ffbc.0046 --- Key.? Mapping: ffbc.0048 --- Key.? Mapping: ffbc.004b --- Key.? Mapping: ffbc.004c --- Key.? Mapping: ffbc.0026 --- Key.? Mapping: ffbc.004d --- Key.LeftBtn Mapping: ffbc.0031 --- Key.RightBtn Mapping: ffbc.0032 --- Key.MiddleBtn Mapping: ffbc.0033 --- Key.SideBtn Mapping: ffbc.0004 --- Key.ExtraBtn Mapping: ffbc.0051 --- Key.ForwardBtn Mapping: ffbc.0052 --- Key.BackBtn input,hiddev96: USB HID v1.10 Device [Logitech USB Receiver] on usb-:00:10.3-2 Here we have the multimedia part of the thingy, most likely some kind of a remote. And this is where the hid-input module gets quite confused. First by usages from the Consumer page it doesn't understand (0045, 009c, 009d, 0209, 008d). Second, by Logitech vendor usages (ffbc.*). This will be a bit harder, and will need your cooperation. Please enable DEBUG in hid-core.c, too, and check what usages from the ffbc page appear in your syslog/dmesg when you press keys on the device. Let's take a look in the specs (USB HID HUT 1.11): 0045: MenuRight 009c: NextChannel 009d: PrevChannel 0209: ApplicationControlProperties 008d: MediaSelectProgramGuide I guess I'll need your help again to find out what these keys are supposed to do and how they're marked on the device. usb 1-1: new low speed USB device using uhci_hcd and address 4 Mapping: Button.0001 --- Key.LeftBtn Mapping: Button.0002 --- Key.RightBtn Mapping: Button.0003 --- Key.MiddleBtn Mapping: Button.0004 --- Key.SideBtn Mapping: Button.0005 --- Key.ExtraBtn Mapping: Button.0006 --- Key.ForwardBtn Mapping: Button.0007 --- Key.BackBtn Mapping: Button.0008 --- Key.TaskBtn Mapping: GenericDesktop.X --- Relative.X Mapping: GenericDesktop.Y --- Relative.Y Mapping: GenericDesktop.Wheel --- Relative.Wheel Mapping: LED.004b --- IGNORED Mapping: LED.004b --- IGNORED Mapping: LED.004b --- IGNORED Mapping: LED.004b --- IGNORED Mapping: LED.004b --- IGNORED Mapping: LED.004b --- IGNORED Mapping: LED.004b --- IGNORED Mapping:
[linux-usb-devel] Re: Kernel unable to read partition table on USB Memory Key
Roberts-Thomson, James wrote: Hi, I'm trying to diagnose an issue with a USB Memory Key (128Mb Flash drive) on my workstation (i386 Linux 2.6.12 kernel, using udev 058). When connecting the key, the kernel fails to read the partition table, and therefore the block device /dev/sda1 isn't created, so I can't mount the volume. Calling fdisk manually, however, makes it all work. Bus 001 Device 004: ID 0ea0:2168 Ours Technology, Inc. Transcend JetFlash 2.0 Hi all, Just a vote for this: same USB key, same symptoms, same inability to use the key: I can create the fs and use it, but once unmounted it won't be mounted anymore. Bye -- Stefano RIVOIR --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ 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] [PATCH] Avoid to use kmalloc in usb/core/message.c
In some functions in drivers/usb/core/message.c kmalloc is used to
allocate fix size of memory chunks; and the chunks is freed at the end
of each functions. The sizes are not so large: 8(struct
usb_ctrlrequest), 18(struct usb_device_descriptor), and 2(u16) bytes.
I wonder why the invocations of kmalloc are needed in these functions.
Following patch is for avoiding invocations of kmalloc. Instead stacks
are used.
The patch is generated by co-diff against
rsync://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Signed-off-by: Masatake YAMATO [EMAIL PROTECTED]
Index: drivers/usb/core/message.c
===
--- 6f51e67e4a433ee0ff866a6ac18a4bce798fe0c7/drivers/usb/core/message.c
(mode:100644)
+++ uncommitted/drivers/usb/core/message.c (mode:100644)
@@ -142,11 +142,9 @@
int usb_control_msg(struct usb_device *dev, unsigned int pipe, __u8 request,
__u8 requesttype,
__u16 value, __u16 index, void *data, __u16 size, int
timeout)
{
- struct usb_ctrlrequest *dr = kmalloc(sizeof(struct usb_ctrlrequest),
GFP_NOIO);
+ struct usb_ctrlrequest dr_rec;
+ struct usb_ctrlrequest *dr = dr_rec;
int ret;
-
- if (!dr)
- return -ENOMEM;
dr-bRequestType= requesttype;
dr-bRequest = request;
@@ -158,7 +156,6 @@
ret = usb_internal_control_msg(dev, pipe, dr, data, size, timeout);
- kfree(dr);
return ret;
}
@@ -794,19 +791,17 @@
*/
int usb_get_device_descriptor(struct usb_device *dev, unsigned int size)
{
+ struct usb_device_descriptor desc_rec;
struct usb_device_descriptor *desc;
int ret;
if (size sizeof(*desc))
return -EINVAL;
- desc = kmalloc(sizeof(*desc), GFP_NOIO);
- if (!desc)
- return -ENOMEM;
+ desc = desc_rec;
ret = usb_get_descriptor(dev, USB_DT_DEVICE, 0, desc, size);
if (ret = 0)
memcpy(dev-descriptor, desc, size);
- kfree(desc);
return ret;
}
@@ -835,17 +830,13 @@
int usb_get_status(struct usb_device *dev, int type, int target, void *data)
{
int ret;
- u16 *status = kmalloc(sizeof(*status), GFP_KERNEL);
-
- if (!status)
- return -ENOMEM;
+ u16 status;
ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
- USB_REQ_GET_STATUS, USB_DIR_IN | type, 0, target, status,
- sizeof(*status), USB_CTRL_GET_TIMEOUT);
+ USB_REQ_GET_STATUS, USB_DIR_IN | type, 0, target, status,
+ sizeof(status), USB_CTRL_GET_TIMEOUT);
- *(u16 *)data = *status;
- kfree(status);
+ *(u16 *)data = status;
return ret;
}
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
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: [PATCH] Avoid to use kmalloc in usb/core/message.c
On Tue, 2005-07-05 at 12:36 +0200, Duncan Sands wrote: I wonder why the invocations of kmalloc are needed in these functions. Because some architectures can't do DMA to/from the stack. doing dma to/from kmalloc also isn't too nice... should be using dma_alloc_*() API I guess --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ 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: [PATCH] Avoid to use kmalloc in usb/core/message.c
I wonder why the invocations of kmalloc are needed in these functions. Because some architectures can't do DMA to/from the stack. doing dma to/from kmalloc also isn't too nice... should be using dma_alloc_*() API I guess The USB core applies dma_map_single to the buffer, so its OK. Ciao, Duncan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=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] Developing a Gadget driver on 2.6.x kernel
On Tue, 5 Jul 2005, Conio sandiago wrote: Hello All, I am a newbie in this domain and i want to develop a USB gadget driver on Linux kernel 2.6.x, I want to know 'how to start of with project, i have read the USB Spec 2.0. Can anyone please guide Look at http://www.linux-usb.org/gadget. Alan Stern --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ 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: Developing a Gadget driver on 2.6.x kernel
Hello All This is the only source from which i can expect soem kind of help/support Please reply to my earlier mail as follows Thanks in advance On 7/5/05, Conio sandiago [EMAIL PROTECTED] wrote: Hello All, I am a newbie in this domain and i want to develop a USB gadget driver on Linux kernel 2.6.x, I want to know 'how to start of with project, i have read the USB Spec 2.0. Can anyone please guide Regards conio --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=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] Kernel unable to read partition table on USB Memory Key
On Tue, 5 Jul 2005, Roberts-Thomson, James wrote: Hi, I'm trying to diagnose an issue with a USB Memory Key (128Mb Flash drive) on my workstation (i386 Linux 2.6.12 kernel, using udev 058). When connecting the key, the kernel fails to read the partition table, and therefore the block device /dev/sda1 isn't created, so I can't mount the volume. Calling fdisk manually, however, makes it all work. You don't even have to call fdisk. Probably touch /dev/sda would be enough. When I plug the device into the USB port, the kernel prints the following: Jul 5 16:18:38 pc196344 kernel: usb 1-6: new high speed USB device using ehci_hcd and address 3 Jul 5 16:18:39 pc196344 kernel: Initializing USB Mass Storage driver... Jul 5 16:18:39 pc196344 kernel: scsi2 : SCSI emulation for USB Mass Storage devices Jul 5 16:18:39 pc196344 kernel: usbcore: registered new driver usb-storage Jul 5 16:18:39 pc196344 kernel: USB Mass Storage support registered. Jul 5 16:18:39 pc196344 kernel: usb-storage: device found at 3 Jul 5 16:18:39 pc196344 kernel: usb-storage: waiting for device to settle before scanning Jul 5 16:18:44 pc196344 kernel: Vendor: OTi Model: Flash Disk Rev: 2.00 Jul 5 16:18:44 pc196344 kernel: Type: Direct-Access ANSI SCSI revision: 02 Jul 5 16:18:44 pc196344 kernel: Attached scsi generic sg1 at scsi2, channel 0, id 0, lun 0, type 0 Jul 5 16:18:44 pc196344 kernel: usb-storage: device scan complete Jul 5 16:18:44 pc196344 scsi.agent[12708]: disk at /devices/pci:00/:00:1d.7/usb1/1-6/1-6:1.0/host2/target2:0:0/2:0:0:0 Jul 5 16:18:44 pc196344 kernel: sda: Unit Not Ready, sense: Jul 5 16:18:44 pc196344 kernel: : Current: sense key: Unit Attention Jul 5 16:18:44 pc196344 kernel: Additional sense: Not ready to ready change, medium may have changed Jul 5 16:18:44 pc196344 kernel: sda : READ CAPACITY failed. Jul 5 16:18:44 pc196344 kernel: sda : status=1, message=00, host=0, driver=08 Jul 5 16:18:44 pc196344 kernel: sd: Current: sense key: Unit Attention Jul 5 16:18:44 pc196344 kernel: Additional sense: Not ready to ready change, medium may have changed snip Clearly, something isn't right here, and the kernel is unable to read block 0 (the parition table). I've tried using the delay_use parameter to the usb-storage module to increase the delay time to 10 seconds, but still no difference. The device is not supposed to send the Unit Attention, Not ready to ready change message more than once. It's violating the SCSI protocol by doing so. (In fact it's not supposed to send that message at all; it's supposed to send Power on or reset.) If I run fdisk /dev/sda however, then the kernel realises there is a partition table and it all just works, thus: For some reason, the device stopped sending that error code and started working. In the case above, I'd not done anything inside fdisk apart from q to exit. However, I have tried reparitioning the device; using dd if=/dev/zero of=/dev/sda bs=512 count=1 to zero the partition table and recreate; returning the device to the vendor and getting another one - no difference at all. What's stored in the partition table won't matter because the kernel isn't able to read it in the first place. Replacing the device won't help, because the device is behaving as designed and the design is broken. The key itself is a NZ vendor own-name rebadge, made in Taiwan. According to the vendor's (Dick Smith Electronics, if anyone is interested) website, http://www.dse.co.nz/cgi-bin/dse.storefront/42ca0f440021d23e273fc0a87f9906a 8/Product/View/XH8250 the product is based on an OTi-2168 USB2.0 mass storage class controller. My previous USB-Key (an IBM 32Mb device which developed a memory hole and died) worked fine. This new key also fails to work in a colleagues Fedora Core 2 2.4.x kernel machine which much the same issue. It just works when used in Windows XP. Any help highly valued at this point, and a direct cc on any reply would also be appreciated. What might help would be a direct comparison of the commands being sent by Linux and by Windows. If you turn on USB Mass Storage verbose debugging (CONFIG_USB_STORAGE_DEBUG) in the kernel configuration then the system debugging log will contain the commands sent by usb-storage. You can use a USB sniffer program like USB Snoop (available from Sourceforge) to record the commands sent by Windows. Perhaps looking over the two logs will reveal what magic command the device is waiting for. Alan Stern --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ linux-usb-devel@lists.sourceforge.net To
RE: [linux-usb-devel] Developing a Gadget driver on 2.6.x kernel
Thanks Alan, I have read the artice that u sent, it was very helpfull Just to clear about my understanding - 1) Peripheral driver - This will basically act as a Hardware abstraction layer, it will depend upon the USB IP that i will be using 2) Gadget Drivers - This is the core of USB , this part will implement the command that Master requests from the client 3) Upper layers - not clear I want to know is there any good existing example gadget driver present in kernel Please clarify Regards Conio -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan Stern Sent: Tuesday, July 05, 2005 7:02 PM To: Conio sandiago Cc: linux-usb-devel@lists.sourceforge.net Subject: Re: [linux-usb-devel] Developing a Gadget driver on 2.6.x kernel On Tue, 5 Jul 2005, Conio sandiago wrote: Hello All, I am a newbie in this domain and i want to develop a USB gadget driver on Linux kernel 2.6.x, I want to know 'how to start of with project, i have read the USB Spec 2.0. Can anyone please guide Look at http://www.linux-usb.org/gadget. Alan Stern --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=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] VID PID based fixed minor numbers - How ?
On Tue, Jul 05, 2005 at 07:39:49PM +0530, Jayaprakash Shanmugam wrote:
Thanks for your reply. I just wanted to give some more information on
my requirement.
1) In my driver (working in 2.4), I have fixed minor numbers for the
USB cards (custom devices). While reading or writing, I simply do the
following:
MyCard = MINOR (pstFilp-f_dentry-d_inode-i_rdev);
if (MyCard == 64)
{
MyDevice = usb_find_device(MyCardVID, MyCardPID);
usb_control_msg();
}
else if ()
..
But if I use usb_register_dev(), it assigns the minors dynamically and
no way ( as far as I know ) I can get which device ( I have four
devices and I am sure that they will not have PIDs in common ) the
read / write is operating on.
You can check the minor number when you register the device. It is
returned in the structure after usb_register_dev() is called.
2) For your reply:
It is our own control system - both the host and devices. These are
the only devices that can go and plug into the host's USB port.
There cannot be two boards with same VID / PID pair.
3) Can I use devfs_register in 2.6 kernel ? The /proc/kallsyms doesnt
display this symbol. I tried using devfs_mk_cdev() in probe. But I
got No Such Device while opening.
devfs is gone in the latest 2.6 kernel, so no, you can't use it.
Good luck,
greg k-h
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=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] Developing a Gadget driver on 2.6.x kernel
On Tue, Jul 05, 2005 at 07:14:16PM +0530, Conio sandiago wrote: I want to know is there any good existing example gadget driver present in kernel Have you looked? What is wrong with the existing drivers as an example? greg k-h --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=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] Kernel panic after build of 2.6.12-rc6-mm1 (reproducable)
On Tue, 5 Jul 2005, Roel kluin wrote: A while ago I had a kernel panic using kernel 2.6.12-rc6-mm1. 2.6.12-rc6 works fine. I sent an oops report to Andrew Morton and he told me to forward this to usb-devel however since the screenshot was too large, it was returned and somehow landed in my trashbox before I read it. So here it is again. I captured a screenshot of the panic in 2.6.12-rc6-mm1, used OCR and corrected it. If there is still an error, Mail me to get the screenshot. I tried again in 2.6.12-mm1 and I got a panic there too. I don't have a screenshot of that yet, but I can make one too. I haven't tried the 2.6.13-rc1-mm1 yet. You probably need some more information about my system as well so I have pasted an oops report behind the panic. Please reply if enything else is needed. And maybe you could send me an email if this leeds to a patch? Well anyway, good luck. It looks like your panic occurred when a USB mass storage device was probed. To get more information about this, it will help if you turn on the USB Mass Storage verbose debugging option (CONFIG_USB_STORAGE_DEBUG) in the kernel configuration. Make sure all your USB storage devices are unplugged when you boot, and then see what appears in the log when you connect them. Alan Stern --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=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] Kernel unable to read partition table on US B Memory Key
Alan, Thanks very much for the input. I'm trying to diagnose an issue with a USB Memory Key (128Mb Flash drive) on my workstation (i386 Linux 2.6.12 kernel, using udev 058). When connecting the key, the kernel fails to read the partition table, and therefore the block device /dev/sda1 isn't created, so I can't mount the volume. Calling fdisk manually, however, makes it all work. You don't even have to call fdisk. Probably touch /dev/sda would be enough. Yes, indeed that does make it work. The device is not supposed to send the Unit Attention, Not ready to ready change message more than once. It's violating the SCSI protocol by doing so. (In fact it's not supposed to send that message at all; it's supposed to send Power on or reset.) Oh well, so much for the Linux Compatible markings on the box... :-) Replacing the device won't help, because the device is behaving as designed and the design is broken. Yes, I'd imagine so, but I just wanted to make sure that it wasn't a bad chip etc - generally speaking QA isn't what it used to be for most products on the market these days. What might help would be a direct comparison of the commands being sent by Linux and by Windows. If you turn on USB Mass Storage verbose debugging (CONFIG_USB_STORAGE_DEBUG) in the kernel configuration then the system debugging log will contain the commands sent by usb-storage. You can use a USB sniffer program like USB Snoop (available from Sourceforge) to record the commands sent by Windows. Perhaps looking over the two logs will reveal what magic command the device is waiting for. OK, I'll try and do that today, and if I get anything meaningful, I'll send it to the list(s). One more additional note is that the key came with some s/w that allows you to partition the key into private and public areas, where the private area is accessed by a password. Naturally, this s/w (Ustorage) is Windows only; but looking at how it works under Windows it would appear that the key has some firmware inside that is controlling access etc - could it be that this firmware hasn't finished initialising by the time Linux tries to read block 0, which is why the messages occur? If this is the case, then a subtle delay somewhere in the initialisation chain may help. I'm not a Kernel Guru by any stretch, but I imagine the sequence is something like this: key insert usb subsystem identifies device usb-storage driver takes device control (existing specifiable delay in here, via delay_use) usb-storage drivers creates /dev/sdX (via some form of udev interaction, I guess...) sd_mod informed that new SCSI disk exists * sd_mod tries to read partition table etc sd_mod creates /dev/sdXn entries (also via udev) ...etc Perhaps the ability to create an additional settle delay at the * above may help - presumably, I'd need to hack the sd_mod driver, so I'll have a look there, too. Thanks, James Roberts-Thomson -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. Mailing list Readers: Please ignore the following disclaimer - this email is explicitly declared to be non confidential and does not contain privileged information. This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=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] Kernel unable to read partition table on US B Memory Key
On Wed, 6 Jul 2005, Roberts-Thomson, James wrote: One more additional note is that the key came with some s/w that allows you to partition the key into private and public areas, where the private area is accessed by a password. Naturally, this s/w (Ustorage) is Windows only; but looking at how it works under Windows it would appear that the key has some firmware inside that is controlling access etc - could it be that this firmware hasn't finished initialising by the time Linux tries to read block 0, which is why the messages occur? That's certainly possible. The question is, at what time does that firmware start initializing and how long does it take? You mentioned before that setting delay_use to 30 seconds didn't make any difference. If this is the case, then a subtle delay somewhere in the initialisation chain may help. I'm not a Kernel Guru by any stretch, but I imagine the sequence is something like this: key insert usb subsystem identifies device usb-storage driver takes device control (existing specifiable delay in here, via delay_use) usb-storage drivers creates /dev/sdX (via some form of udev interaction, I guess...) sd_mod informed that new SCSI disk exists * sd_mod tries to read partition table etc sd_mod creates /dev/sdXn entries (also via udev) ...etc That's not quite right. It really goes like this: key insert usb subsystem identifies device usb-storage driver takes device control (existing specifiable delay in here, via delay_use) sd_mod informed that new SCSI disk exists sd_mod gets total disk capacity, write-protection setting, and other stuff sd_mod registers /dev/sdX as a disk and udev learns about it the general disk driver tries to read partition table etc gendisk creates /dev/sdXn entries (also via udev) ...etc It's not clear how any of this affects the device's internal state. Perhaps the ability to create an additional settle delay at the * above may help - presumably, I'd need to hack the sd_mod driver, so I'll have a look there, too. Try putting delays at various spots in sd_revalidate_disk: the beginning, the middle, and the end. Alan Stern --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ 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: Input Device Key Mapping (driver authoring advice?)
Hello,
I've attached the patch that makes all keys on the Logitech UltraX Media
Remote work nicely. I will verify that the previous patch correctly
assigns the channel keys in the consumer page, however, I cannot give
props to the mapping of props (sorry). 0x209 on this remote says
Info/EPG, but it has been assigned to KEY_PROPS. Maybe I'm just not
understanding the meaning of props. This patch does reassign KEY_INFO
to 0x209 in the consumer page; it that was the wrong thing to do, I'll
resubmit.
I used my best judgement when assigning keys, since the text on the
device does not always match up with a key defined in input.h. Here is
a list of the potentially ambiguous or incorrect mappings:
Start-KEY_RED
Pictures-KEY_MEDIA
DVD Menu-KEY_MENU
SAP-KEY_AUDIO
Repeat-KEY_AGAIN
CC/Teletext-KEY_SUBTITLE
Music-KEY_MP3
Allow me to justify the silly ones. The start key is big and red,
Google told me SAP stands for Secondary Audio Program, and there is no
key close to pictures/graphics/image.
On Tue, 2005-05-07 at 11:04 +0200, Vojtech Pavlik wrote:
[really big snip]
Please try with this patch:
[another snip]
The patch failed on account of HID_UP_LOGIVENDOR not being defined. I
fixed two hunks manually, so it should work fine with your tree,
Vojtech.
Thanks again for all your help. Please keep me posted if something is
wrong.
--
Micah F. Galizia
[EMAIL PROTECTED]
The mark of an immature man is that he wants to die
nobly for a cause, while the mark of the mature man is
that he wants to live humbly for one. --W. Stekel
--- gitandhidpatches/drivers/usb/input/hid-input.c 2005-07-05 18:29:32.726219000 -0400
+++ micah/drivers/usb/input/hid-input.c 2005-07-05 18:42:15.489888750 -0400
@@ -237,6 +237,7 @@
case 0x000: goto ignore;
case 0x034: map_key_clear(KEY_SLEEP); break;
case 0x036: map_key_clear(BTN_MISC); break;
+case 0x045: map_key_clear(KEY_RADIO); break;
case 0x08a: map_key_clear(KEY_WWW); break;
case 0x08d: map_key_clear(KEY_PROGRAM); break;
case 0x095: map_key_clear(KEY_HELP); break;
@@ -265,7 +266,7 @@
case 0x201: map_key_clear(KEY_NEW); break;
case 0x207: map_key_clear(KEY_SAVE); break;
case 0x208: map_key_clear(KEY_PRINT); break;
-case 0x209: map_key_clear(KEY_PROPS); break;
+case 0x209: map_key_clear(KEY_INFO); break;
case 0x21a: map_key_clear(KEY_UNDO); break;
case 0x21b: map_key_clear(KEY_COPY); break;
case 0x21c: map_key_clear(KEY_CUT); break;
@@ -309,9 +310,27 @@
case HID_UP_MSVENDOR:
case HID_UP_LOGIVENDOR:
case HID_UP_LOGIVENDOR2:
-
- goto ignore;
-
+ switch(usage-hid HID_USAGE) {
+ case 0x004: map_key_clear(KEY_AGAIN); break;
+ case 0x00d: map_key_clear(KEY_HOME); break;
+ case 0x024: map_key_clear(KEY_SHUFFLE); break;
+ case 0x025: map_key_clear(KEY_TV); break;
+ case 0x026: map_key_clear(KEY_MENU); break;
+ case 0x031: map_key_clear(KEY_AUDIO); break;
+ case 0x032: map_key_clear(KEY_SUBTITLE); break;
+ case 0x033: map_key_clear(KEY_LAST); break;
+ case 0x047: map_key_clear(KEY_MP3); break;
+ case 0x048: map_key_clear(KEY_DVD); break;
+ case 0x049: map_key_clear(KEY_MEDIA); break;
+ case 0x04a: map_key_clear(KEY_VIDEO); break;
+ case 0x04b: map_key_clear(KEY_ANGLE); break;
+ case 0x04c: map_key_clear(KEY_LANGUAGE); break;
+ case 0x04d: map_key_clear(KEY_SUBTITLE); break;
+ case 0x051: map_key_clear(KEY_RED); break;
+ case 0x052: map_key_clear(KEY_CLOSE); break;
+ default:goto ignore;
+ }
+ break;
case HID_UP_PID:
set_bit(EV_FF, input-evbit);
signature.asc
Description: This is a digitally signed message part
RE: [linux-usb-devel] Kernel unable to read partition table on US B Memory Key
Alan, Try putting delays at various spots in sd_revalidate_disk: the beginning, the middle, and the end. OK, the attached patch works for me when sd_mod was loaded with delay_use=1. Now I'm quite prepared to be told that this is a really horrible and inapproprate hack (given that I am not a kernel developer, I don't really know the correct way to solve this problem); and I'll cheerfully admit that it doesn't really solve the problem cleanly as can be seen below: Jul 6 14:44:50 pc196344 kernel: usb 1-6: new high speed USB device using ehci_hcd and address 6 Jul 6 14:44:50 pc196344 kernel: Initializing USB Mass Storage driver... Jul 6 14:44:50 pc196344 kernel: scsi5 : SCSI emulation for USB Mass Storage devices Jul 6 14:44:50 pc196344 kernel: usbcore: registered new driver usb-storage Jul 6 14:44:50 pc196344 kernel: USB Mass Storage support registered. Jul 6 14:44:50 pc196344 kernel: usb-storage: device found at 6 Jul 6 14:44:50 pc196344 kernel: usb-storage: waiting for device to settle before scanning Jul 6 14:44:52 pc196344 kernel: Vendor: OTi Model: Flash Disk Rev: 2.00 Jul 6 14:44:52 pc196344 kernel: Type: Direct-Access ANSI SCSI revision: 02 Jul 6 14:44:52 pc196344 kernel: Attached scsi generic sg1 at scsi5, channel 0, id 0, lun 0, type 0 Jul 6 14:44:52 pc196344 kernel: usb-storage: device scan complete Jul 6 14:44:52 pc196344 scsi.agent[27245]: disk at /devices/pci:00/:00:1d.7/usb1/1-6/1-6:1.0/host5/target5:0:0/5:0:0:0 Jul 6 14:44:52 pc196344 kernel: sd: waiting for device to get ready. Jul 6 14:44:53 pc196344 kernel: sda: Unit Not Ready, sense: Jul 6 14:44:53 pc196344 kernel: : Current: sense key: Unit Attention Jul 6 14:44:53 pc196344 kernel: Additional sense: Not ready to ready change, medium may have changed Jul 6 14:44:53 pc196344 kernel: sda : READ CAPACITY failed. Jul 6 14:44:53 pc196344 kernel: sda : status=1, message=00, host=0, driver=08 Jul 6 14:44:53 pc196344 kernel: sd: Current: sense key: Unit Attention Jul 6 14:44:53 pc196344 kernel: Additional sense: Not ready to ready change, medium may have changed Jul 6 14:44:53 pc196344 kernel: sda: test WP failed, assume Write Enabled Jul 6 14:44:53 pc196344 kernel: sda: assuming drive cache: write through Jul 6 14:44:53 pc196344 kernel: sd: waiting for device to get ready. Jul 6 14:44:54 pc196344 kernel: sda: Unit Not Ready, sense: Jul 6 14:44:54 pc196344 kernel: : Current: sense key: Unit Attention Jul 6 14:44:54 pc196344 kernel: Additional sense: Not ready to ready change, medium may have changed Jul 6 14:44:54 pc196344 kernel: sda : READ CAPACITY failed. Jul 6 14:44:54 pc196344 kernel: sda : status=1, message=00, host=0, driver=08 Jul 6 14:44:54 pc196344 kernel: sd: Current: sense key: Unit Attention Jul 6 14:44:54 pc196344 kernel: Additional sense: Not ready to ready change, medium may have changed Jul 6 14:44:54 pc196344 kernel: sda: test WP failed, assume Write Enabled Jul 6 14:44:54 pc196344 kernel: sda: assuming drive cache: write through Jul 6 14:44:54 pc196344 kernel: sd: waiting for device to get ready. Jul 6 14:44:55 pc196344 kernel: SCSI device sda: 255488 512-byte hdwr sectors (131 MB) Jul 6 14:44:55 pc196344 kernel: sda: Write Protect is off Jul 6 14:44:55 pc196344 kernel: sda: Mode Sense: 03 00 00 00 Jul 6 14:44:55 pc196344 kernel: sda: assuming drive cache: write through Jul 6 14:44:55 pc196344 kernel: /dev/scsi/host5/bus0/target0/lun0: p1 Jul 6 14:44:55 pc196344 kernel: Attached scsi removable disk sda at scsi5, channel 0, id 0, lun 0 There are three delays from my patch in the above list, and increasing the delay to 3 seconds didn't help, as I got three one-second delays. However, if someone with the appropriate knowledge could transform my kludge into a proper fix, then I would be very happy. Alan, thanks very much for your help - I really appreciate the quick responses you have given me. Note that I now have the output from the USB Snoop tool under Windows if anyone wants it - please ask if needed to help solve the issue correctly. James Roberts-Thomson -- Hardware: The parts of a computer system that can be kicked. Mailing list Readers: Please ignore the following disclaimer - this email is explicitly declared to be non confidential and does not contain privileged information. This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. oti-usb-key.patch Description: Binary data
