Re: [PATCH 01/12] Use mutex instead of semaphore in driver core

2007-12-29 Thread Greg KH
On Sat, Dec 29, 2007 at 03:07:30PM +0800, Dave Young wrote: > On Dec 29, 2007 1:06 PM, Dave Young <[EMAIL PROTECTED]> wrote: > > > > On Dec 29, 2007 12:42 PM, Greg KH <[EMAIL PROTECTED]> wrote: > > > On Sat, Dec 29, 2007 at 10:36:49AM +0800, Dave Young wrote: > > > > > > > > > The full boot dmesg w

[RFC] USB driver for talking to the Microchip PIC18 boot loader

2007-12-29 Thread mgross
I'm playing around with a PIC based project at home (not an Intel activity) and found I needed a usb driver to talk to the boot loader so I can program my USB Bitwhacker with new custom firmware. The following adds the pic18bl driver to the kernel. Its pretty simple and is somewhat based on bits

usblp not waiting for read data

2007-12-29 Thread Martin Mares
Hello, world! I am currently playing with HP LaserJet P2015D connected over USB and I have a slight problem with the usblp driver there. Whenever I try to read from /dev/usb/lp0 and no data are available, it immediately returns reporting EOF (0 bytes read) instead of waiting for the data. Does any

Re: [PATCH 01/12] Use mutex instead of semaphore in driver core

2007-12-29 Thread Alan Stern
On Sat, 29 Dec 2007, Dave Young wrote: > On Dec 29, 2007 1:06 PM, Dave Young <[EMAIL PROTECTED]> wrote: > > > > On Dec 29, 2007 12:42 PM, Greg KH <[EMAIL PROTECTED]> wrote: > > > On Sat, Dec 29, 2007 at 10:36:49AM +0800, Dave Young wrote: > > > > > > > > > The full boot dmesg with lockdep output i

Re: [RFC] USB driver for talking to the Microchip PIC18 boot loader

2007-12-29 Thread Alan Stern
On Sat, 29 Dec 2007, mgross wrote: > I'm playing around with a PIC based project at home (not an Intel > activity) and found I needed a usb driver to talk to the boot loader > so I can program my USB Bitwhacker with new custom firmware. The > following adds the pic18bl driver to the kernel. Its

Re: [RFC] USB driver for talking to the Microchip PIC18 boot loader

2007-12-29 Thread Xiaofan Chen
On Dec 30, 2007 6:15 AM, Alan Stern <[EMAIL PROTECTED]> wrote: > On Sat, 29 Dec 2007, mgross wrote: > > > I'm playing around with a PIC based project at home (not an Intel > > activity) and found I needed a usb driver to talk to the boot loader > > so I can program my USB Bitwhacker with new custom

Re: [RFC] USB driver for talking to the Microchip PIC18 boot loader

2007-12-29 Thread mgross
On Sat, Dec 29, 2007 at 05:15:30PM -0500, Alan Stern wrote: > On Sat, 29 Dec 2007, mgross wrote: > > > I'm playing around with a PIC based project at home (not an Intel > > activity) and found I needed a usb driver to talk to the boot loader > > so I can program my USB Bitwhacker with new custom f

Re: [RFC] USB driver for talking to the Microchip PIC18 boot loader

2007-12-29 Thread mgross
On Sun, Dec 30, 2007 at 10:40:45AM +0800, Xiaofan Chen wrote: > On Dec 30, 2007 6:15 AM, Alan Stern <[EMAIL PROTECTED]> wrote: > > On Sat, 29 Dec 2007, mgross wrote: > > > > > I'm playing around with a PIC based project at home (not an Intel > > > activity) and found I needed a usb driver to talk t

Re: [RFC] USB driver for talking to the Microchip PIC18 boot loader

2007-12-29 Thread Xiaofan Chen
On Dec 30, 2007 12:29 PM, mgross <[EMAIL PROTECTED]> wrote: > The device ID's are different 0x000C in ldusb.c vrs 0x000b in the > driver I just posted. I know that. 000b is for the demo application. 000c is for the bootloader application. I am not a progammer myself but I think the USB communicat

Re: [RFC] USB driver for talking to the Microchip PIC18 boot loader

2007-12-29 Thread Xiaofan Chen
On Dec 30, 2007 11:53 AM, mgross <[EMAIL PROTECTED]> wrote: > Yeah, it has been done from user space using a libusb based > application. (that didn't work with a usb-hub in the loop) and had > code that was just too nasty for words, so I made a kernel driver that > looks nicer to me and enables a

Re: [PATCH 01/12] Use mutex instead of semaphore in driver core

2007-12-29 Thread David Brownell
On Saturday 29 December 2007, Alan Stern wrote: > lockdep warns whenever a task acquires a mutex while holding another > mutex of the same kind (that is, the same member in another structure > of the same type).  But there are lots of places where the kernel needs > to acquire dev->sem for one devi