On Sun, 2007-06-03 at 08:40 -0400, Justin Piszcz wrote: > On Sun, 3 Jun 2007, Kay Sievers wrote: > > > On 6/3/07, Justin Piszcz <[EMAIL PROTECTED]> wrote: > >> On Sun, 3 Jun 2007, Jiri Kosina wrote: > >> > >> > On Sun, 3 Jun 2007, Justin Piszcz wrote: > >> > > >> >>> Thanks. Does by any chance reverting the commit > >> >>> 9f8b17e643fe6aa505629658445849397bda4e4f improve the situation? > >> >> I have not played around with git/etc enough to back it out, if you > >> >> have > >> a > >> >> patch that applies on top of 2.6.22-rc3 that backs it out I can give it > >> a try. > >> > > >> > Please try this > >> > >> [[ .. snip .. ]] > >> > >> The patch was successful and now my USB device is working again! > > > > Please set: > > CONFIG_USB_DEVICE_CLASS=y > > there should be no patch needed. The option already defaults to yes in > > the latest kernel.
> USB device class-devices (DEPRECATED) (USB_DEVICE_CLASS) [N/y/?] (NEW) y > > Why is it deprecated if (nut/usb/etc fails) when its not used? Does nut > or udev have to play catch-up to adhere to the new kernel changes? The usb_device class was created to replace the /proc usbfs device nodes which can't handle access-control-lists for logged-in users. The device nodes worked fine, but plugging into the device events to trigger userspace device handling created a bunch of problems with the event timing. We have several open bugs, that can't be fixed properly with using the usb_device-devices. We changed the driver core to allow us to export device nodes directly by bus-devices, instead of forcing us to create artificial devices like the usb_device-class, just to export device nodes to userspace. If systems set CONFIG_USB_DEVICE_CLASS=n (which defaults to yes now), one new udev rule is needed, to replace the functionality of the usb_device-class devices. Also the next version of HAL (which is where nut receives the events from) will depend on the new device nodes, and will not longer use usb_device devices. No changes to nut should be needed. Thanks, Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
