Re: Cannot read using USB Skeleton Driver
With some modification, I have finally made the skel driver work with my device. I think I have some initial theories about the root cause of the problems that I ran into with skel: 1) The condition if (!dev->processed_urb) is always false in the beginning and this induces a wait without any scope for completion, so it has to be removed. 2) A blocking read and blocking write cannot happen simultaneously. This is because in read, we go to sleep after locking a mutex 'iomutex'. Before writing, we try to lock the same mutex, so if we try to write() from one thread (or process) while waiting for read() to complete in another, we will have both threads blocked, waiting indefinitely for each other (the device won't respond until you send data to it). This can be fixed by unlocking the mutex before entering into the wait but then that mutex might be there for a reason and I might be doing the wrong thing. 3) If the buffer associated with your read urb is not big enough to accommodate the packet that arrives over USB, the transfer request will fail with error -75 in the completion callback. We could handle this by either propagating the error back to the user or by issuing transfer requests with big enough buffers and keeping the data buffered until the user asks for it. Then we could give as much data as he asks for and keep the rest buffered. But in the latter case, the user may issue a read() call expecting a transfer to happen, but he might not necessarily see one (in case there is data already buffered). Also the buffer size would be somewhat arbitrarily chosen which is not nice. Does anybody have anything to add or oppose on this or would you guys rather have me send a patch along with my changes? Regards, Felix. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Cannot read using USB Skeleton Driver
> You might be right and the code might be wrong, care to send a patch for > it correcting the issue? Would be glad to do that, if I am able to resolve the issue. Meanwhile, any insights from anybody on this would be welcome! Regards, Felix. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Cannot read using USB Skeleton Driver
Oh I don't think I have customized it to the point of breaking it. I just modified the VID and PID to those of my device. And later, when I noticed where it was getting stuck, I changed the wait_for_completion to wait_for_completion_interruptible (in the code snippet quoted previously) so that I could recover with Ctrl-C instead of a reboot. And my hardware works fine with the usbserial driver you suggested (I can read/write to it from a simple terminal program). But, to develop a full-fledged driver, the skeleton driver seemed like a better starting point, which is I am still trying to get it working. The condition which causes the code to wait for eternity (from the line I quoted in one of my previous mails) seems to be: if (!dev->processed_urb) But I notice that this variable is not true even for the first read. So the code seems to wait for the completion of something that has not yet started. Also, I do not see this variable being explicitly set to false either, anywhere within the driver. I may be on the wrong track, but isn't this variable one that is used only within our driver? If so, what exactly is it used for, considering that it is only set to 1 (never to 0) and is 0 initially? Regards, Felix. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Cannot read using USB Skeleton Driver
> Just do: > modprobe usb_serial vendor=0x product=0x > with the proper vendor and product ids for your device, then plug it in. > > No kernel changes needed at all, just have a pair of bulk in/out > endpoints and all will work automatically for you. Thanks Greg, I had thought that the usbserial driver would only work with proper CDC class virtual COM devices. I compiled it and tried it on my device and it worked fine! I was able to do bidirectional communication. So at least now I can be sure that one end is working. But the same device with the same firmware still doesn't work with the (customized) usb-skeleton. What could be wrong? Regards, Felix. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Cannot read using USB Skeleton Driver
> What type of device is this you are wishing to write a driver for? That > will determine the type of interface you need to use, odds are it is not > going to be a simple char device. The device is a custom USB dongle whose firmware is also under development. We are still in the process of deciding what it should actually show up as on the linux side but right now, we decided to use a character device for simplicity reasons until we have simple two-way communication over USB up and running. Since I am writing the firmware on the device side too, it had indeed been (and still is) my first suspect :). But I checked the code multiple times and now I am reasonably sure that I am in fact, doing all that is required to send out data properly. Besides, data transfer in the other direction works fine. I have registered only one IN and one OUT endpoint apart from endpoint 0 and I try to send my data through the IN end-point. I noticed that after making the wait interruptible, if I hit Ctrl-C while we are hanging on a read, the device side shows transfer complete. So the device, apparently, thinks the data has been sent successfully when we have actually aborted the transfer at the other end! Shouldn't this mean that something happens after coming out of the wait_for_completion that really makes the transfer happen? Regards, Felix. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Cannot read using USB Skeleton Driver
Hi,
I have been trying to communicate with a custom usb device from a
SAM9G20-EK board using the usb-skeleton.c driver example in the linux
source. I modified the driver to add my device's vendor and product
id. The USB device enumerates with two bulk endpoints - one IN and one
OUT. The (modified) skel driver successfully detects my device and I
get a minor number allocated. After creating a device file with that
minor number, I am able to write into the device by typing 'echo "HI"
> /dev/mydevice'. I verified that this data arrives at my device
intact. Next, I started sending data back from the device and tried to
read it back using 'cat /dev/mydevice'. The problem is that read not
only doesn't work, but also makes the app get totally stuck. Ctrl-C
doesn't work and I have to reboot the board.
Some debugging using printk's led me to the following snippet which
seems to be causing the hang. If I change the wait to a
wait_for_completion_interruptible, Ctrl-C starts working, but still no
data is received.
if (!dev->processed_urb) {
/*
* the URB hasn't been processed
* do it now
*/
wait_for_completion(&dev->bulk_in_completion);
dev->bulk_in_copied = 0;
dev->processed_urb = 1;
}
Oh, btw I am using linux kernel 2.6.39.4. Any Ideas anyone??
Regards,
Felix.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Gmail complaining about authenticity of emails sent/received via kernelnewbies
On 29 June 2011 15:18, Mandeep Sandhu wrote: > Hi All, > > I'm using gmail.com for corresponding to this mailing list. > > Recently I have observed that gmail has started complaining about the > authenticity of the sender. > > Eg: I see this message quite often when someone replies to a kernewbies post: > > This message may not have been sent by: x...@gmail.com > > Is anyone else seeing this too? > > I think mailing lists set a "via" (or some such) header in the mail to > indicate that the mail is being sent on behalf of the original sender. > Could that be missing? Yes, I'm seeing this too. Seems like gmail introduced this particular feature(?) recently. The warning is technically correct, isn't it? You did not send this message to me - kernelnewbies did! Maybe they overlooked (or don't care about) the fact that mailing lists broadcast messages on behalf of the original sender. Or maybe something will have to change in the way the kernelnewbies mailing list sends out its messages. Regards, Felix. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to write linux drivers?
Lalit Pratap Singh wrote: > I just wanted to know that, How can i write the smallest driver and test it? Linux Device Drivers 3rd edition (link provided by Rajat above) was what got me started and is still my reference whenever I get stuck. Chapter 2, pg 16 has the do-nothing 'hello world' driver you are looking for. Lalit Pratap Singh wrote: > I want some basic tutorial links also. You can find a decent tutorial at http://www.freesoftwaremagazine.com/articles/drivers_linux?page=0%2C0 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Putting artificial delays in a char driver
Hi, I can't say I have understood your scenario completely. Maybe you could turn your LED on when you want to (say in the ISR) and then start a kernel timer of sufficient duration. In the timer expiry handler, you could switch it off. By adjusting the duration, you could make sure that the LED stays on long enough to be visible. Regards, Felix. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: kernel BUG while reading from SPI into static buffer
On 13 May 2011 20:02, Mulyadi Santosa wrote: > Feel free to try to observer whether this statement is correct or > not... and you should check the address of "buffer" when declared as > static I guess I did, and here's the result: Local Buffer - 0xc3a61edd Static Buffer - 0xbf03eac1 So they indeed seem to be way apart in memory :). On 13 May 2011 20:38, Greg KH wrote: > Don't statically allocate memory for spi, you need to dynamically > allocate it with 'kmalloc'. > > The fact that the first time didn't crash for you was just lucky. I'm guessing you say this because static variables are not in DMA capable memory. But how exactly do we figure out which part of memory is DMA-capable and which isn't? Also, is this a restriction imposed by the kernel or by the hardware? Thanks & Regards, Felix. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
kernel BUG while reading from SPI into static buffer
Hi, I am trying to read some data via SPI on an a modified (custom SPI device attached) AT91SAM9G20-EK board. If I pass a local array buffer, declared as "char buffer[100];" as the rx_buf pointer for the spi transfer, the code works fine. But if I just change the declaration to "static char buffer[100]" instead, I get the following crash: kernel BUG at arch/arm/mm/dma-mapping.c:425! Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 817 [#1] last sysfs file: Modules linked in: testmod [last unloaded: testmod] CPU: 0Not tainted (2.6.37.2 #8) PC is at __bug+0x1c/0x28 LR is at __bug+0x18/0x28 pc : []lr : []psr: 2093 sp : c3a6fea8 ip : 1e7b fp : r10: r9 : r8 : c38ca6a0 r7 : c395e4e8 r6 : c3a6ff28 r5 : 0032 r4 : c3a6ff54 r3 : r2 : 0001 r1 : 6093 r0 : 0033 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: 23a3c000 DAC: 0017 Process tx_thread (pid: 460, stack limit = 0xc3a6e270) Stack: (0xc3a6fea8 to 0xc3a7) fea0: c3a6ff24 c0034344 c0274848 c3a6ff54 bf00c7f8 c0189dd4 fec0: c395e4e8 6013 c3a6ff28 c395e400 c395e400 c0188bf0 fee0: c3a6ff2c 6013 c3a6ff28 c395e400 c38ca6a0 c0188c54 c3a6ff04 c0188e38 ff00: c3a6ff08 c3a6ff08 c3a6ff94 c3a6ff70 c3a6ff28 bf00c7f8 ff20: 0032 bf00a0d4 c3a6ff94 c3a6ff70 c38ca6a0 c0188fdc c3a6ff04 ff40: ff8d bf00c7f8 0032 ff60: c3a6ff28 c3a6ff94 c3a6ff9f c3a6ff9f ff80: 0001 23a6ff9f 23a6ff9f c3a6ff70 c3a6ff28 20a6ff50 ffa0: c3a6ffd4 c39bfdc4 c38ca6a0 bf00a0e0 bf00a168 720a 01a6cafe ffc0: c3a6ffd4 c00556e0 c002f884 c38ca6a0 c3a6ffd8 c3a6ffd8 ffe0: c39bfdc4 c0055660 c002f884 0013 c002f884 0001151c 00d0 [] (__bug+0x1c/0x28) from [] (___dma_single_cpu_to_dev+0x3c/0x68) [] (___dma_single_cpu_to_dev+0x3c/0x68) from [] (atmel_spi_transfer+0xf8/0x1cc) [] (atmel_spi_transfer+0xf8/0x1cc) from [] (__spi_async+0xa0/0xb0) [] (__spi_async+0xa0/0xb0) from [] (spi_async_locked+0x14/0x2c) [] (spi_async_locked+0x14/0x2c) from [] (__spi_sync+0x60/0xa0) [] (__spi_sync+0x60/0xa0) from [] (read_bytes+0xac/0xb8 [testmod]) [] (read_bytes+0xac/0xb8 [testmod]) from [] (tx_thread+0x88/0x110 [testmod]) [] (tx_thread+0x88/0x110 [testmod]) from [] (kthread+0x80/0x88) [] (kthread+0x80/0x88) from [] (kernel_thread_exit+0x0/0x8) Code: e1a01000 e59f000c eb090854 e3a03000 (e5833000) ---[ end trace 0dac538caa941b38 ]--- Does this behaviour make sense to anyone? Is this a bug or is it just me doing the wrong thing? Regards, Felix. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
