On Wed, 2020-02-12 at 15:17 -0800, Greg Kroah-Hartman wrote: > On Thu, Feb 13, 2020 at 12:05:13AM +0100, Bastien Nocera wrote: > > On Wed, 2020-02-12 at 11:06 -0800, Greg Kroah-Hartman wrote: > > > On Wed, Oct 16, 2019 at 11:39:27AM +0200, Bastien Nocera wrote: > > > > This is version 3 of the patch set. > > > > > > > > Changes in v3: > > > > - Add Alan's ack > > > > - don't export usb_device_match_id() > > > > > > > > Changes in v2: > > > > - checkpatch.pl is now quiet > > > > - fallback to the generic driver when driver ->probe() fails > > > > > > Sorry for the long response to this, my fault. > > > > > > At first, I really don't like the idea of using the usb device > > > driver > > > interface, but I don't think there's a better way. And, you did > > > the > > > work to make it so that it works cleanly, which is always > > > appreciated. > > > > I'm hoping that a few user-space drivers end up upstream in the > > kernel > > for hardware that needs it. > > And here I am wanting to move more USB drivers to userspace :) > > What ones do you see that are currently in userspace that should be > in > the kernel? The power control one here makes sense, are there others > like this? Well, I don't know yet. I would expect them to be of similar ilk, and fit in with the type of devices the kernel already handles but would use interfaces for on other devices. As I mentioned at the beginning of the discussion, I'm not trying to bring in user-space drivers that don't fit in an existing subsystem, but rather those that are badly designed ;) > > I plan on making some more changes to the USB subsystem in the > > (near) > > future, so it's to get my feet wet with this. > > That was a serious modification to "start" with, nice work. I think what I want to work on, revoke support for USB devices, might be more complicated/racy/full of security problems.
