Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
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 with lockdep output is out, there's one warnings in > > > > it : > > > > > > Please fix that warning before the next repost of these patches (along > > > with fixing the problem of them not being able to be applied and > > > successfully built at every point in the series...) > > > > > > > Ok, thanks, I will fix them and repost. > > > > Hi, > After digging the code, I feel hard to fix the lockdep warning due to > some misterious relationship with usb. > > Could someone help on this? thanks. My question back to you is why are you doing this conversion? Have you found that it is needed for something? Are there problems in the -rt kernels that this conversion helps with? Or is it just a janitorial "convert semaphore to mutex" type thing. If the latter, I would suggest dropping it, as this area is quite complex and I think the locking chain too deep at times for a simple conversion. good luck, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] USB driver for talking to the Microchip PIC18 boot loader
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 of a libusb driver that does some of
what this driver does.
What do you think?
--mgross
Singed-off-by: Mark Gross <[EMAIL PROTECTED]>
---
Index: linux-2.6.24-rc6/drivers/usb/misc/pic18bl.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.24-rc6/drivers/usb/misc/pic18bl.c 2007-12-29 11:21:14.0
-0800
@@ -0,0 +1,627 @@
+/*
+ * PIC18 usb boot loader driver based on the MicroChip firmware, and a user
+ * mode libusb driver that does some of the same operations only different.
+ * Based on the skeleton driver
+ *
+ * --mgross
+ *
+ * USB Skeleton driver - 2.2
+ *
+ * Copyright (C) 2001-2004 Greg Kroah-Hartman ([EMAIL PROTECTED])
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ *
+ * This driver is based on the 2.6.3 version of drivers/usb/usb-pic18bleton.c
+ * but has been rewritten to be easier to read and use.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Define these values to match your devices */
+#define USB_PIC18BL_VENDOR_ID 0x04d8
+#define USB_PIC18BL_PRODUCT_ID 0x000b
+
+/* table of devices that work with this driver */
+static struct usb_device_id pic18bl_table [] = {
+ { USB_DEVICE(USB_PIC18BL_VENDOR_ID, USB_PIC18BL_PRODUCT_ID) },
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(usb, pic18bl_table);
+
+
+/* Get a minor range for your devices from the usb maintainer */
+#define USB_PIC18BL_MINOR_BASE 192
+
+/* our private defines. if this grows any larger, use your own .h file */
+#define MAX_TRANSFER (PAGE_SIZE - 512)
+/* MAX_TRANSFER is chosen so that the VM is not stressed by
+ allocations > PAGE_SIZE and the number of packets in a page
+ is an integer 512 is the largest possible packet on EHCI */
+#define WRITES_IN_FLIGHT 8
+/* arbitrarily chosen */
+
+/* structs and information based on boot loader firmware */
+#define BOOT_EP_SIZE 64
+#define OVER_HEAD 5 /*Overhead: */
+#define DATA_SIZE (BOOT_EP_SIZE - OVER_HEAD)
+
+#defineREAD_VERSION 0x00
+#defineREAD_FLASH 0x01
+#defineWRITE_FLASH 0x02
+#defineERASE_FLASH 0x03
+#defineREAD_EEDATA 0x04
+#defineWRITE_EEDATA 0x05
+#defineREAD_CONFIG 0x06
+#defineWRITE_CONFIG 0x07
+#defineUPDATE_LED 0x32
+#defineRESET0xFF
+
+struct address {
+ u8 low;
+ u8 high;
+ u8 upper;
+} __attribute__ ((packed));
+
+union boot_data_buffer {
+ u8 buffer[BOOT_EP_SIZE];
+ struct {
+ u8 cmd;
+ u8 len;
+ struct address addr;
+ u8 data[DATA_SIZE];
+ } __attribute__ ((packed)) data;
+ struct {
+ u8 cmd; /* should always == 32 */
+ u8 led_num; /* should only be 3 or 4 */
+ u8 led_status;
+ } __attribute__ ((packed)) led;
+};
+
+
+/* Structure to hold all of our device specific stuff */
+struct usb_pic18bl {
+ struct usb_device *udev;
+ struct usb_interface*interface;
+ struct semaphorelimit_sem;
+ struct usb_anchor submitted;
+ unsigned char *bulk_in_buffer;
+ size_t bulk_in_size;
+ __u8bulk_in_endpointAddr;
+ __u8bulk_out_endpointAddr;
+ int errors;
+ int open_count;
+ spinlock_t err_lock;
+ struct kref kref;
+ struct mutexio_mutex;
+};
+#define to_pic18bl_dev(d) container_of(d, struct usb_pic18bl, kref)
+
+static struct usb_driver pic18bl_driver;
+static void pic18bl_draw_down(struct usb_pic18bl *dev);
+
+static void pic18bl_delete(struct kref *kref)
+{
+ struct usb_pic18bl *dev = to_pic18bl_dev(kref);
+
+ usb_put_dev(dev->udev);
+ kfree(dev->bulk_in_buffer);
+ kfree(dev);
+}
+
+static int pic18bl_open(struct inode *inode, struct file *file)
+{
+ struct usb_pic18bl *dev;
+ struct usb_interface *interface;
+ int subminor;
+ int retval = 0;
+
+ subminor = iminor(inode);
+
+ interface = usb_find_interface(&pic18bl_driver, subminor);
+ if (!interface) {
+ err("%s - error, can't find device for minor %d",
+__FUNCTION__, subminor);
+ retval = -ENODEV;
usblp not waiting for read data
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 anybody know if this is intentional? I am currently experimenting with vanilla kernel 2.6.23.9, but the problem does not seem to be limited to this particular version. lsusb for the printer: | Bus 001 Device 004: ID 03f0:3817 Hewlett-Packard | Device Descriptor: | bLength18 | bDescriptorType 1 | bcdUSB 2.00 | bDeviceClass0 (Defined at Interface level) | bDeviceSubClass 0 | bDeviceProtocol 0 | bMaxPacketSize064 | idVendor 0x03f0 Hewlett-Packard | idProduct 0x3817 | bcdDevice1.00 | iManufacturer 1 Hewlett-Packard | iProduct2 HP LaserJet P2015 Series | iSerial 3 00CNBW74108M | bNumConfigurations 1 | Configuration Descriptor: | bLength 9 | bDescriptorType 2 | wTotalLength 55 | bNumInterfaces 2 | bConfigurationValue 1 | iConfiguration 0 | bmAttributes 0xc0 | Self Powered | MaxPower2mA | Interface Descriptor: | bLength 9 | bDescriptorType 4 | bInterfaceNumber0 | bAlternateSetting 0 | bNumEndpoints 2 | bInterfaceClass 7 Printer | bInterfaceSubClass 1 Printer | bInterfaceProtocol 2 Bidirectional | iInterface 17 Printer | Endpoint Descriptor: | bLength 7 | bDescriptorType 5 | bEndpointAddress 0x01 EP 1 OUT | bmAttributes2 | Transfer TypeBulk | Synch Type None | Usage Type Data | wMaxPacketSize 0x0200 1x 512 bytes | bInterval 255 | Endpoint Descriptor: | bLength 7 | bDescriptorType 5 | bEndpointAddress 0x81 EP 1 IN | bmAttributes2 | Transfer TypeBulk | Synch Type None | Usage Type Data | wMaxPacketSize 0x0200 1x 512 bytes | bInterval 0 | Interface Descriptor: | bLength 9 | bDescriptorType 4 | bInterfaceNumber1 | bAlternateSetting 0 | bNumEndpoints 2 | bInterfaceClass 255 Vendor Specific Class | bInterfaceSubClass 1 | bInterfaceProtocol 1 | iInterface 19 HP EWS | Endpoint Descriptor: | bLength 7 | bDescriptorType 5 | bEndpointAddress 0x0b EP 11 OUT | bmAttributes2 | Transfer TypeBulk | Synch Type None | Usage Type Data | wMaxPacketSize 0x0200 1x 512 bytes | bInterval 255 | Endpoint Descriptor: | bLength 7 | bDescriptorType 5 | bEndpointAddress 0x8b EP 11 IN | bmAttributes2 | Transfer TypeBulk | Synch Type None | Usage Type Data | wMaxPacketSize 0x0200 1x 512 bytes | bInterval 0 | Device Qualifier (for other device speed): | bLength10 | bDescriptorType 6 | bcdUSB 2.00 | bDeviceClass0 (Defined at Interface level) | bDeviceSubClass 0 | bDeviceProtocol 0 | bMaxPacketSize064 | bNumConfigurations 1 | Device Status: 0x0001 | Self Powered Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Immanuel doesn't pun, he Kant. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
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 is out, there's one warnings in > > > > it : > > > > > > Please fix that warning before the next repost of these patches (along > > > with fixing the problem of them not being able to be applied and > > > successfully built at every point in the series...) > > > > > > > Ok, thanks, I will fix them and repost. > > > > Hi, > After digging the code, I feel hard to fix the lockdep warning due to > some misterious relationship with usb. > > Could someone help on this? thanks. > Add usb-devel list as cc The problem isn't specific to USB. And you will not be able to fix it unless you make drastic changes to the lockdep checker. 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 device while already holding dev->parent->sem. There's no way to remove these, which means there's no way to prevent lockdep from issuing a warning. Around a month ago I had a discussion with Peter Zijlstra about the problems in converting the device semaphores to mutexes; you may be able to find it in the LKML archives. Doing the conversion while keeping lockdep happy is a very hard problem and we were not able to solve it. It's possible that you may be able to convert the semaphores in struct class or other structures. But you won't succeed with struct device. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] USB driver for talking to the Microchip PIC18 boot loader
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 pretty simple > and is somewhat based on bits of a libusb driver that does some of > what this driver does. > > What do you think? Not to detract from your driver, but would it be possible to do the whole thing in userspace using libusb? Maybe by extending the driver you mentioned? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] USB driver for talking to the Microchip PIC18 boot loader
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 firmware. The > > following adds the pic18bl driver to the kernel. Its pretty simple > > and is somewhat based on bits of a libusb driver that does some of > > what this driver does. > > > > What do you think? > > Not to detract from your driver, but would it be possible to do the > whole thing in userspace using libusb? Maybe by extending the driver > you mentioned? > The existing libusb based application works fine for PICDEM FS USB or those based on it (like the Bitwhacker the OP is using). Please do not add it to the kernel. There are libusb based application for both the bootloader and the demo application and both are working fine under Linux (along with Windows and I am trying to get FreeBSD working). Last time the demo application has been added to the ldusb and I think it is not a good idea. But since then I've added patches to the existing libusb application. Relevant discussion in thread '[PATCH 70/78] USB: add picdem device to ldusb' http://marc.info/?t=11777007643&r=1&w=2 So please do not do this again. It is not a problem for the libusb based applications after the patches but it is really not necessary. Original libusb based application for the bootloader: http://www.internetking.org/fsusb/ Original libusb based application for the Demo which also includes my patch for libusb-win32. http://www.varxec.net/picdem_fs_usb/ Updated Patches to detach the kernel driver for both the bootloader and Demo application. http://forum.microchip.com/tm.aspx?m=106426 Xiaofan Chen http://mcuee.blogspot.com - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] USB driver for talking to the Microchip PIC18 boot loader
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 firmware. The > > following adds the pic18bl driver to the kernel. Its pretty simple > > and is somewhat based on bits of a libusb driver that does some of > > what this driver does. > > > > What do you think? > > Not to detract from your driver, but would it be possible to do the > whole thing in userspace using libusb? Maybe by extending the driver > you mentioned? > 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 nice python FW loader program to work. What is the linux-usb policies on new drivers that could be implemented in user space? When does a kernel driver make sense over a libusb one? --mgross - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] USB driver for talking to the Microchip PIC18 boot loader
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 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 of a libusb driver that does some of > > > what this driver does. > > > > > > What do you think? > > > > Not to detract from your driver, but would it be possible to do the > > whole thing in userspace using libusb? Maybe by extending the driver > > you mentioned? > > > > The existing libusb based application works fine for PICDEM FS USB > or those based on it (like the Bitwhacker the OP is using). The device ID's are different 0x000C in ldusb.c vrs 0x000b in the driver I just posted. Have you read my patch yet? > > Please do not add it to the kernel. There are libusb based application > for both the bootloader and the demo application and both are working > fine under Linux (along with Windows and I am trying to get FreeBSD > working). The libusb based FW loader http://www.internetking.org/fsusb/ program is nasty and didn't work on one of my systems, so I refactored it into a kernel driver and python program. > > Last time the demo application has been added to the ldusb and > I think it is not a good idea. But since then I've added patches to > the existing libusb application. > > Relevant discussion in thread > '[PATCH 70/78] USB: add picdem device to ldusb' > http://marc.info/?t=11777007643&r=1&w=2 > > So please do not do this again. It is not a problem for the libusb > based applications after the patches but it is really not necessary. Why not? There are a lot of redundant things in the world. Linux is not necessary if you really want to take this argument to its extreme. > > Original libusb based application for the bootloader: > http://www.internetking.org/fsusb/ Yup thats the code. I found it way complex to read and felt a simple kernel driver and simple python program much nicer to my sensibilities. We are getting quickly getting into a fuzzy/ opinion, area on this thread. Is there a technical angle we can discuss? My LOC count of the kernel driver and boot loader is smaller than the fsusb thing. Also, with a kernel driver and a python lib, a GUI based boot loader utility can be had with little effort. > Original libusb based application for the Demo which > also includes my patch for libusb-win32. > http://www.varxec.net/picdem_fs_usb/ > > Updated Patches to detach the kernel driver for both > the bootloader and Demo application. > http://forum.microchip.com/tm.aspx?m=106426 > > Xiaofan Chen > http://mcuee.blogspot.com You blogging about me already? I wont comment on that. --mgross - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] USB driver for talking to the Microchip PIC18 boot loader
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 communication part of both the two libusb based application are fine. I have no comments about the other part of fsusb coce. http://forum.microchip.com/tm.aspx?m=106426 > > Please do not add it to the kernel. There are libusb based application > > for both the bootloader and the demo application and both are working > > fine under Linux (along with Windows and I am trying to get FreeBSD > > working). > > The libusb based FW loader http://www.internetking.org/fsusb/ program > is nasty and didn't work on one of my systems, so I refactored it into > a kernel driver and python program. > If it does not work, read my patches and see if it will work. If you do not like the existing fsusb application, you can rewrite it in python with pyusb (which is based on libusb) but you do not need a kernel driver. pyusb: http://pyusb.berlios.de/ Hex file parsing in pyk by Mark Rages. He is using the Bitpim libusb wrapper which IMHO is not as good as pyusb. http://groups.google.com/group/pickit-devel/msg/35e850832256e890 Xiaofan - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] USB driver for talking to the Microchip PIC18 boot loader
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 nice python FW loader program to work. http://forum.microchip.com/tm.aspx?m=275422&mpage=2 Just a guess why it does not work: this might be due to the auto-suspend. If you update your kernel, it should be ok. The firmware is also to blame. > What is the linux-usb policies on new drivers that could be > implemented in user space? When does a kernel driver make sense over > a libusb one? > That would be interesting to know. Xiaofan - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
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 device while already holding > dev->parent->sem. Not just devices. I've seen the same issue with genirq when enabling or disabling wakeup: while holding irq_desc[354].lock it must also acquire the parent IRQ's irq_desc[37].lock so it can update that parent IRQ's wake flag ... because the wake signal goes from the child up to the parent up to the logic that kicks the clock framework and thence the CPU, and software must enable at least some of those paths by hand. And lockdep says "[ INFO: possible recursive locking detected ]". But the analysis is "ignore that one, it's a false alarm". > There's no way to remove these, which means there's > no way to prevent lockdep from issuing a warning. There may be no *efficient* way to do that. If it tracked every lock individually these false alarms could go away; but that would increase the overhead to create and destroy such locks too. Such tradeoffs are what make it Engineering, not Science. ;) - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
