RE: [linux-usb-devel] Kernel unable to read partition table on US B Memory Key

2005-07-05 Thread Roberts-Thomson, James
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

[linux-usb-devel] Re: Input Device Key Mapping (driver authoring advice?)

2005-07-05 Thread Micah F. Galizia
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", b

RE: [linux-usb-devel] Kernel unable to read partition table on US B Memory Key

2005-07-05 Thread Alan Stern
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 looki

RE: [linux-usb-devel] Kernel unable to read partition table on US B Memory Key

2005-07-05 Thread Roberts-Thomson, James
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 blo

Re: [linux-usb-devel] Kernel panic after build of 2.6.12-rc6-mm1 (reproducable)

2005-07-05 Thread Alan Stern
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

RE: [linux-usb-devel] Developing a Gadget driver on 2.6.x kernel

2005-07-05 Thread Alan Stern
On Tue, 5 Jul 2005, Conio sandiago wrote: > 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, Yes. It manages the USB device controller hardware.

Re: [linux-usb-devel] Developing a Gadget driver on 2.6.x kernel

2005-07-05 Thread Greg KH
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.N

Re: [linux-usb-devel] VID & PID based fixed minor numbers - How ?

2005-07-05 Thread Greg KH
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 simp

Re: [linux-usb-devel] VID & PID based fixed minor numbers - How ?

2005-07-05 Thread Jayaprakash Shanmugam
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 (My

[linux-usb-devel] Kernel panic after build of 2.6.12-rc6-mm1 (reproducable)

2005-07-05 Thread Roel kluin
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

RE: [linux-usb-devel] Developing a Gadget driver on 2.6.x kernel

2005-07-05 Thread Conio sandiago
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

Re: [linux-usb-devel] Kernel unable to read partition table on USB Memory Key

2005-07-05 Thread Alan Stern
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 b

[linux-usb-devel] Re: Developing a Gadget driver on 2.6.x kernel

2005-07-05 Thread Conio sandiago
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 k

Re: [linux-usb-devel] Developing a Gadget driver on 2.6.x kernel

2005-07-05 Thread Alan Stern
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

[linux-usb-devel] Re: [PATCH] Avoid to use kmalloc in usb/core/message.c

2005-07-05 Thread Duncan Sands
> > > 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 i

[linux-usb-devel] Re: [PATCH] Avoid to use kmalloc in usb/core/message.c

2005-07-05 Thread Arjan van de Ven
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 -

[linux-usb-devel] Re: [PATCH] Avoid to use kmalloc in usb/core/message.c

2005-07-05 Thread Duncan Sands
> I wonder why the invocations of kmalloc are needed in these functions. Because some architectures can't do DMA to/from the stack. All the best, Duncan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Fin

[linux-usb-devel] [PATCH] Avoid to use kmalloc in usb/core/message.c

2005-07-05 Thread Masatake YAMATO
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 kma

[linux-usb-devel] Re: Kernel unable to read partition table on USB Memory Key

2005-07-05 Thread Stefano Rivoir
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 creat

[linux-usb-devel] Re: Input Device Key Mapping (driver authoring advice?)

2005-07-05 Thread Vojtech Pavlik
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 se