| Message ID | 20191016093933.693-1-hadess@hadess.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add Apple MFi fastcharge USB device driver | expand |
Hey, Any updates on getting this into the USB tree? Alan acked the patchset more than a month ago. On Wed, 2019-10-16 at 11:39 +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()
Hey, On Thu, 2019-11-21 at 16:20 +0100, Bastien Nocera wrote: > Hey, > > Any updates on getting this into the USB tree? > > Alan acked the patchset more than a month ago. Thought I'd ask again, the 6 patches were acked by Alan, and tested by me. Is there any chance they could be considered for merging, or reviewed? Cheers > On Wed, 2019-10-16 at 11:39 +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() > >
On Tue, Jan 07, 2020 at 09:46:50AM +0100, Bastien Nocera wrote: > Hey, > > On Thu, 2019-11-21 at 16:20 +0100, Bastien Nocera wrote: > > Hey, > > > > Any updates on getting this into the USB tree? > > > > Alan acked the patchset more than a month ago. > > Thought I'd ask again, the 6 patches were acked by Alan, and tested by > me. Is there any chance they could be considered for merging, or > reviewed? Ugh, sorry, these fell through the cracks. They are still in my "to-review" queue, I'll try to get to them by the end of the week. thanks, greg k-h
On Tue, 2020-01-07 at 10:35 +0100, Greg Kroah-Hartman wrote: > On Tue, Jan 07, 2020 at 09:46:50AM +0100, Bastien Nocera wrote: > > Hey, > > > > On Thu, 2019-11-21 at 16:20 +0100, Bastien Nocera wrote: > > > Hey, > > > > > > Any updates on getting this into the USB tree? > > > > > > Alan acked the patchset more than a month ago. > > > > Thought I'd ask again, the 6 patches were acked by Alan, and tested > > by > > me. Is there any chance they could be considered for merging, or > > reviewed? > > Ugh, sorry, these fell through the cracks. They are still in my > "to-review" queue, I'll try to get to them by the end of the week. No worries, looking forward to the review.
On Tue, 2020-01-07 at 10:35 +0100, Greg Kroah-Hartman wrote: > On Tue, Jan 07, 2020 at 09:46:50AM +0100, Bastien Nocera wrote: > > Hey, > > > > On Thu, 2019-11-21 at 16:20 +0100, Bastien Nocera wrote: > > > Hey, > > > > > > Any updates on getting this into the USB tree? > > > > > > Alan acked the patchset more than a month ago. > > > > Thought I'd ask again, the 6 patches were acked by Alan, and tested > > by > > me. Is there any chance they could be considered for merging, or > > reviewed? > > Ugh, sorry, these fell through the cracks. They are still in my > "to-review" queue, I'll try to get to them by the end of the week. Hey, It's been a month, and it missed the last merge window. Is there anything else I should be doing? Cheers
On Tue, Feb 11, 2020 at 01:21:15AM +0100, Bastien Nocera wrote: > On Tue, 2020-01-07 at 10:35 +0100, Greg Kroah-Hartman wrote: > > On Tue, Jan 07, 2020 at 09:46:50AM +0100, Bastien Nocera wrote: > > > Hey, > > > > > > On Thu, 2019-11-21 at 16:20 +0100, Bastien Nocera wrote: > > > > Hey, > > > > > > > > Any updates on getting this into the USB tree? > > > > > > > > Alan acked the patchset more than a month ago. > > > > > > Thought I'd ask again, the 6 patches were acked by Alan, and tested > > > by > > > me. Is there any chance they could be considered for merging, or > > > reviewed? > > > > Ugh, sorry, these fell through the cracks. They are still in my > > "to-review" queue, I'll try to get to them by the end of the week. > > Hey, > > It's been a month, and it missed the last merge window. Is there > anything else I should be doing? {sigh} my fault, will look at this today, sorry...
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. So all now queued up, let's see what breaks in linux-next with it! :) One note, your patches had to be applied with "-p0" to git, normally we do it with "-p1", I don't know how you generated your patches at 0 depth. thanks, greg k-h
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. > So all now queued up, let's see what breaks in linux-next with it! :) And I sure hope I won't be break anything! > One note, your patches had to be applied with "-p0" to git, normally > we > do it with "-p1", I don't know how you generated your patches at 0 > depth. My fault. I tried to use the "noprefix" git diff option to make it easier to visualise changes, but that leaked into generated patches as well. I've disabled it since. 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. Cheers
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? > 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. greg k-h
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.