| Message ID | 20230202135508.447109-1-dan.scally@ideasonboard.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add XU support to UVC Gadget | expand |
On Thu, Feb 02, 2023 at 01:54:57PM +0000, Daniel Scally wrote: > Hello all > > This series adds support for the definition of extension units in configfs for > the UVC Gadget. The XUs are modelled as config_items within a new "extensions" > group under control, which seemed like an appropriate place to put them. > > To allow the XU's to be inserted in the function graph, the bSourceID attribute > for the default output terminal is made writeable - users will need to configure > it with the bUnitID of the XU that they want to use as the OT's source. This does > mean that the XUs can _only_ be placed immediately preceding the OT, but I think > that that's fine for now. > > The XUs configured through this series have been tested via uvc-gadget, uvcvideo > and uvcdynctrl. > > This version is almost identical to v3 but rebased onto usb-testing, with minor > changes to 6/11 and 7/11. > > v2 of the series here: https://lore.kernel.org/linux-usb/0ae65812-c937-d071-455b-7c1d6418b080@ideasonboard.com/ This series conflicts with the previous patch series you sent, how did you create this? Again, can you rebase and resubmit? thanks, greg k-h
Hi Greg On 06/02/2023 10:02, Greg KH wrote: > On Thu, Feb 02, 2023 at 01:54:57PM +0000, Daniel Scally wrote: >> Hello all >> >> This series adds support for the definition of extension units in configfs for >> the UVC Gadget. The XUs are modelled as config_items within a new "extensions" >> group under control, which seemed like an appropriate place to put them. >> >> To allow the XU's to be inserted in the function graph, the bSourceID attribute >> for the default output terminal is made writeable - users will need to configure >> it with the bUnitID of the XU that they want to use as the OT's source. This does >> mean that the XUs can _only_ be placed immediately preceding the OT, but I think >> that that's fine for now. >> >> The XUs configured through this series have been tested via uvc-gadget, uvcvideo >> and uvcdynctrl. >> >> This version is almost identical to v3 but rebased onto usb-testing, with minor >> changes to 6/11 and 7/11. >> >> v2 of the series here: https://lore.kernel.org/linux-usb/0ae65812-c937-d071-455b-7c1d6418b080@ideasonboard.com/ > This series conflicts with the previous patch series you sent, how did > you create this? Do you mean conflicts with the previous version of this series, or with the "UVC Gadget: Extend color matching support" series? If the latter I rebased them separately onto usb-testing, so neither series knew about the other. > > Again, can you rebase and resubmit? Sure, sorry about the hassle this morning! > > thanks, > > greg k-h
On Mon, Feb 06, 2023 at 10:24:03AM +0000, Dan Scally wrote: > Hi Greg > > On 06/02/2023 10:02, Greg KH wrote: > > On Thu, Feb 02, 2023 at 01:54:57PM +0000, Daniel Scally wrote: > > > Hello all > > > > > > This series adds support for the definition of extension units in configfs for > > > the UVC Gadget. The XUs are modelled as config_items within a new "extensions" > > > group under control, which seemed like an appropriate place to put them. > > > > > > To allow the XU's to be inserted in the function graph, the bSourceID attribute > > > for the default output terminal is made writeable - users will need to configure > > > it with the bUnitID of the XU that they want to use as the OT's source. This does > > > mean that the XUs can _only_ be placed immediately preceding the OT, but I think > > > that that's fine for now. > > > > > > The XUs configured through this series have been tested via uvc-gadget, uvcvideo > > > and uvcdynctrl. > > > > > > This version is almost identical to v3 but rebased onto usb-testing, with minor > > > changes to 6/11 and 7/11. > > > > > > v2 of the series here: https://lore.kernel.org/linux-usb/0ae65812-c937-d071-455b-7c1d6418b080@ideasonboard.com/ > > This series conflicts with the previous patch series you sent, how did > > you create this? > > > Do you mean conflicts with the previous version of this series, or with the > "UVC Gadget: Extend color matching support" series? If the latter I rebased > them separately onto usb-testing, so neither series knew about the other. The latter. And if they know nothing about each other, how is anyone supposed to be able to apply both of them? Please please please make my life easy to take your changes, not difficult, as this just makes me want to ignore your patches as I will inherently assume they are going to cause me problems... What would you do if you were in my place here? thanks, greg k-h
On 06/02/2023 10:29, Greg KH wrote: > On Mon, Feb 06, 2023 at 10:24:03AM +0000, Dan Scally wrote: >> Hi Greg >> >> On 06/02/2023 10:02, Greg KH wrote: >>> On Thu, Feb 02, 2023 at 01:54:57PM +0000, Daniel Scally wrote: >>>> Hello all >>>> >>>> This series adds support for the definition of extension units in configfs for >>>> the UVC Gadget. The XUs are modelled as config_items within a new "extensions" >>>> group under control, which seemed like an appropriate place to put them. >>>> >>>> To allow the XU's to be inserted in the function graph, the bSourceID attribute >>>> for the default output terminal is made writeable - users will need to configure >>>> it with the bUnitID of the XU that they want to use as the OT's source. This does >>>> mean that the XUs can _only_ be placed immediately preceding the OT, but I think >>>> that that's fine for now. >>>> >>>> The XUs configured through this series have been tested via uvc-gadget, uvcvideo >>>> and uvcdynctrl. >>>> >>>> This version is almost identical to v3 but rebased onto usb-testing, with minor >>>> changes to 6/11 and 7/11. >>>> >>>> v2 of the series here: https://lore.kernel.org/linux-usb/0ae65812-c937-d071-455b-7c1d6418b080@ideasonboard.com/ >>> This series conflicts with the previous patch series you sent, how did >>> you create this? >> >> Do you mean conflicts with the previous version of this series, or with the >> "UVC Gadget: Extend color matching support" series? If the latter I rebased >> them separately onto usb-testing, so neither series knew about the other. > The latter. And if they know nothing about each other, how is anyone > supposed to be able to apply both of them? I had not really anticipated that they would be taken at the same time, so I was expecting to be rebasing one or the other at some point anyway...in that situation it seemed better to submit them both "clean" since neither inherently relies on the other. > > Please please please make my life easy to take your changes, not > difficult, as this just makes me want to ignore your patches as I will > inherently assume they are going to cause me problems... Ack; I apologise - it's absolutely not my intention to make work for you. > > What would you do if you were in my place here? I don't really know enough about the processes and deadlines you manage to make a judgement on that. > > thanks, > > greg k-h