* [PATCH v6 0/5] tools/usbip: Patch set summary @ 2021-11-30 22:22 Lars Gunnarsson 2021-12-03 11:17 ` Greg KH 2021-12-06 20:02 ` Shuah Khan 0 siblings, 2 replies; 7+ messages in thread From: Lars Gunnarsson @ 2021-11-30 22:22 UTC (permalink / raw) To: Valentina Manea, Shuah Khan, linux-usb To forward a remote usb device over usbip the following steps is required: 1. Execute "usbip bind" on remote end. 2. Execute "usbip attach" on local end. These steps must be perfomed in above order and after usb device is plugged in. If the usb device is unplugged on the remote end the steps above needs to be performed again to establish the connection. This patch set implements a feature to persistently forward devices on a given bus. When using flag "-p|--persistent" on remot end, the USB device becomes exported when plugged in. When using flag "-p|--persistent" on local end, the USB device becomes imported when available on remote end. Thus it is only required to run the usbip command once on each end, in any order, to persistently forward usb devices on a given bus. This is sent in five separate patches: tools/usbip: update protocol documentation tools/usbip: update manual pages tools/usbip: add usb event monitor into libusbip tools/usbip: export USB devices on a given bus persistently tools/usbip: import USB devices on a given bus persistently ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v6 0/5] tools/usbip: Patch set summary 2021-11-30 22:22 [PATCH v6 0/5] tools/usbip: Patch set summary Lars Gunnarsson @ 2021-12-03 11:17 ` Greg KH 2021-12-06 20:02 ` Shuah Khan 1 sibling, 0 replies; 7+ messages in thread From: Greg KH @ 2021-12-03 11:17 UTC (permalink / raw) To: Lars Gunnarsson; +Cc: Valentina Manea, Shuah Khan, linux-usb On Tue, Nov 30, 2021 at 11:22:54PM +0100, Lars Gunnarsson wrote: > To forward a remote usb device over usbip the following steps is required: > > 1. Execute "usbip bind" on remote end. > 2. Execute "usbip attach" on local end. > > These steps must be perfomed in above order and after usb device is plugged in. > If the usb device is unplugged on the remote end the steps above needs to be > performed again to establish the connection. This patch set implements a feature > to persistently forward devices on a given bus. When using flag "-p|--persistent" > on remot end, the USB device becomes exported when plugged in. When using flag > "-p|--persistent" on local end, the USB device becomes imported when available > on remote end. Thus it is only required to run the usbip command once on each > end, in any order, to persistently forward usb devices on a given bus. > > This is sent in five separate patches: > tools/usbip: update protocol documentation > tools/usbip: update manual pages > tools/usbip: add usb event monitor into libusbip > tools/usbip: export USB devices on a given bus persistently > tools/usbip: import USB devices on a given bus persistently Oh wow, this patch series subject lines and threading is crazy, there is no way to figure out what is going on here. This is what this series looks like in my mailbox: Nov 30 Lars Gunnarsson ( 479) [PATCH v4 5/5] tools/usbip: import USB devices on a given bus persistentl Nov 30 Lars Gunnarsson ( 206) [PATCH v5 4/5] tools/usbip: export USB devices on a given bus persistentl Nov 30 Lars Gunnarsson ( 292) [PATCH v4 3/5] tools/usbip: add usb event monitor into libusbip Nov 30 Lars Gunnarsson ( 86) [PATCH v2 2/5] tools/usbip: update manual pages Nov 30 Lars Gunnarsson ( 118) [PATCH v3 1/5] tools/usbip: update protocol documentation Nov 30 Lars Gunnarsson ( 20) [PATCH v6 0/5] tools/usbip: Patch set summary You have a mix of "v" levels and nothing is threaded at all, showing what patch is related to what. Look at the lore.kernel.org link for this, which shows none of the patches in the series: https://lore.kernel.org/all/20211130222254.GA16447@dell-precision-T3610/ Please use tools like 'git send-email' and 'git format-patch' to send and create patches if you don't want to do it by hand as they will handle the threading and versioning properly for you automatically. Here's how a patch series looks in my mailbox that was done correctly as contrast: Nov 24 Prashant Malani ( 34) [PATCH 0/4] usb: Use notifier for linking Type C ports. Nov 26 Heikki Krogerus ( 32) ├─> Nov 30 Heikki Krogerus ( 40) │ └─> Nov 30 Prashant Malani ( 57) │ └─> Dec 01 Heikki Krogerus ( 77) │ └─> Nov 24 Prashant Malani ( 109) ├─>[PATCH 1/4] usb: typec: Add port registration notifier Nov 24 Prashant Malani ( 114) │ └─> Nov 24 Prashant Malani ( 199) ├─>[PATCH 2/4] usb: Use notifier to link Type C ports Nov 25 kernel test rob ( 55) │ └─> Nov 24 Prashant Malani ( 92) ├─>[PATCH 4/4] Revert "usb: Iterator for ports" Nov 24 Prashant Malani ( 60) └─>[PATCH 3/4] usb: Link the ports to the connectors they are attached t See how the patches are linked together? That is because the correct "In-Reply-To:" lines are being set. Please fix up and resend as a "v7" patch series for ALL patches (patch versions are for the whole series, not for individual patches, otherwise it is crazy to try to track...) thanks, greg k-h ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v6 0/5] tools/usbip: Patch set summary 2021-11-30 22:22 [PATCH v6 0/5] tools/usbip: Patch set summary Lars Gunnarsson 2021-12-03 11:17 ` Greg KH @ 2021-12-06 20:02 ` Shuah Khan 2021-12-09 21:11 ` Lars Gunnarsson 1 sibling, 1 reply; 7+ messages in thread From: Shuah Khan @ 2021-12-06 20:02 UTC (permalink / raw) To: Lars Gunnarsson, Valentina Manea, Shuah Khan; +Cc: linux-usb, Shuah Khan On 11/30/21 3:22 PM, Lars Gunnarsson wrote: > To forward a remote usb device over usbip the following steps is required: > > 1. Execute "usbip bind" on remote end. > 2. Execute "usbip attach" on local end. > > These steps must be perfomed in above order and after usb device is plugged in. > If the usb device is unplugged on the remote end the steps above needs to be > performed again to establish the connection. This patch set implements a feature > to persistently forward devices on a given bus. When using flag "-p|--persistent" > on remot end, the USB device becomes exported when plugged in. When using flag > "-p|--persistent" on local end, the USB device becomes imported when available > on remote end. Thus it is only required to run the usbip command once on each > end, in any order, to persistently forward usb devices on a given bus. > > This is sent in five separate patches: > tools/usbip: update protocol documentation > tools/usbip: update manual pages > tools/usbip: add usb event monitor into libusbip > tools/usbip: export USB devices on a given bus persistently > tools/usbip: import USB devices on a given bus persistently > When -p is used, the command stays in foreground. This is a very different use model compared to current model. In addition, once persistent flag is set on a bus, all devices even the ones that are inserted in the future get exported. What happens if one of the devices shouldn't be exported? There are several conditions to be thought through: - What happens if if the command that is running on the foreground is killed on either end? - What happens when one or more devices are detached? - What happens when one or more devices are unbound from the server? Let's walk through these scenarios. thanks, -- Shuah ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v6 0/5] tools/usbip: Patch set summary 2021-12-06 20:02 ` Shuah Khan @ 2021-12-09 21:11 ` Lars Gunnarsson 2021-12-14 22:22 ` Shuah Khan 0 siblings, 1 reply; 7+ messages in thread From: Lars Gunnarsson @ 2021-12-09 21:11 UTC (permalink / raw) To: Shuah Khan; +Cc: Valentina Manea, Shuah Khan, linux-usb On Mon, Dec 06, 2021 at 01:02:35PM -0700, Shuah Khan wrote: > On 11/30/21 3:22 PM, Lars Gunnarsson wrote: > > To forward a remote usb device over usbip the following steps is required: > > > > 1. Execute "usbip bind" on remote end. > > 2. Execute "usbip attach" on local end. > > > > These steps must be perfomed in above order and after usb device is plugged in. > > If the usb device is unplugged on the remote end the steps above needs to be > > performed again to establish the connection. This patch set implements a feature > > to persistently forward devices on a given bus. When using flag "-p|--persistent" > > on remot end, the USB device becomes exported when plugged in. When using flag > > "-p|--persistent" on local end, the USB device becomes imported when available > > on remote end. Thus it is only required to run the usbip command once on each > > end, in any order, to persistently forward usb devices on a given bus. > > > > This is sent in five separate patches: > > tools/usbip: update protocol documentation > > tools/usbip: update manual pages > > tools/usbip: add usb event monitor into libusbip > > tools/usbip: export USB devices on a given bus persistently > > tools/usbip: import USB devices on a given bus persistently > > > > When -p is used, the command stays in foreground. This is a very > different use model compared to current model. In addition, once > persistent flag is set on a bus, all devices even the ones that > are inserted in the future get exported. What happens if one of > the devices shouldn't be exported? Yes it's conceptually more like exporting/importing the physical usb port, rather than exporting/importing a device plugged into the usb port. Using flag "-p" on both ends will behave like a "virtual" usb hub, a device plugged in on the server (on a chosen bus) will automatically be available on the client. Using flag "-p" has no dependency on the other end though. Using "-p" on one end doesn't enforce usage on the other end. It is only for exporting and importing devices automatically when they become available. There might be better choices than naming flag to "persistent" for easily communicate this concept. Would "port" be more intuitive? "usbip attach --port 3-3.1" and "usbip bind --port 3-3.1" > > There are several conditions to be thought through: > > - What happens if if the command that is running on the foreground > is killed on either end? If "attach" cmd gets killed (client side) it will stop the foreground monitoring. The device will still remain imported if user exit at imported state. The user then needs to manually unimport the device with "detach". If "bind" cmd gets killed (server side) it will stop the foreground monitoring. The device will still remain exported if exit at exported state. The user then needs to manually unexport the device with "unbind". > - What happens when one or more devices are detached? If user exit from "attach" cmd running in foreground, followed by detaching the device manually, it will work as previously. The device will become available on the server for importing again. If user running "attach" cmd in foreground, while executing "detach" manually from another terminal or similar, the foreground "attach" command will detect the disconnection and re-establish the import. I don't see any use case for this, it's just for explaining. If user running "attach" cmd in foreground, while the remote device becomes unexported (or disconnected) it will start polling the usbipd. When a device becomes exported on the chosen bus it gets imported immediately. > - What happens when one or more devices are unbound from > the server? > > Let's walk through these scenarios. If user exit from "bind" cmd running in foreground, followed by unbind the device manually it will work as previous. The usb device will become available on the server again. If user running "bind" cmd in foreground, while executing "unbind" from another terminal or similar, the foreground "bind" command will detect the unexport and re-establish the export. I don't see any use case for this, it's just for explaining. If user running "bind" cmd in foreground, while the device becomes unexported or disconnected it will restart monitoring the busid. When a device becomes plugged in on the chosen usb port it gets exported immediately. One option to consider is to unexport & unimport the device at exit, but this comes with the cost of creating a source code dependency between bind --> unbind and attach --> detach. Best regards, Lars > > thanks, > -- Shuah > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v6 0/5] tools/usbip: Patch set summary 2021-12-09 21:11 ` Lars Gunnarsson @ 2021-12-14 22:22 ` Shuah Khan 2021-12-16 21:01 ` Lars Gunnarsson 0 siblings, 1 reply; 7+ messages in thread From: Shuah Khan @ 2021-12-14 22:22 UTC (permalink / raw) To: Lars Gunnarsson; +Cc: Valentina Manea, Shuah Khan, linux-usb, Shuah Khan On 12/9/21 2:11 PM, Lars Gunnarsson wrote: > On Mon, Dec 06, 2021 at 01:02:35PM -0700, Shuah Khan wrote: >> On 11/30/21 3:22 PM, Lars Gunnarsson wrote: >>> To forward a remote usb device over usbip the following steps is required: >>> >>> 1. Execute "usbip bind" on remote end. >>> 2. Execute "usbip attach" on local end. >>> >>> These steps must be perfomed in above order and after usb device is plugged in. >>> If the usb device is unplugged on the remote end the steps above needs to be >>> performed again to establish the connection. This patch set implements a feature >>> to persistently forward devices on a given bus. When using flag "-p|--persistent" >>> on remot end, the USB device becomes exported when plugged in. When using flag >>> "-p|--persistent" on local end, the USB device becomes imported when available >>> on remote end. Thus it is only required to run the usbip command once on each >>> end, in any order, to persistently forward usb devices on a given bus. >>> >>> This is sent in five separate patches: >>> tools/usbip: update protocol documentation >>> tools/usbip: update manual pages >>> tools/usbip: add usb event monitor into libusbip >>> tools/usbip: export USB devices on a given bus persistently >>> tools/usbip: import USB devices on a given bus persistently >>> >> >> When -p is used, the command stays in foreground. This is a very >> different use model compared to current model. In addition, once >> persistent flag is set on a bus, all devices even the ones that >> are inserted in the future get exported. What happens if one of >> the devices shouldn't be exported? > > Yes it's conceptually more like exporting/importing the physical usb port, > rather than exporting/importing a device plugged into the usb port. Using flag > "-p" on both ends will behave like a "virtual" usb hub, a device plugged in on > the server (on a chosen bus) will automatically be available on the client. > Using flag "-p" has no dependency on the other end though. Using "-p" on one end > doesn't enforce usage on the other end. It is only for exporting and importing > devices automatically when they become available. > > There might be better choices than naming flag to "persistent" for easily > communicate this concept. Would "port" be more intuitive? > "usbip attach --port 3-3.1" and "usbip bind --port 3-3.1" > Terminology isn't what I am concerned about. My concern is the idea of automatically making devices available for export at bus level. >> >> There are several conditions to be thought through: >> >> - What happens if if the command that is running on the foreground >> is killed on either end? > > If "attach" cmd gets killed (client side) it will stop the foreground > monitoring. The device will still remain imported if user exit at imported state. > The user then needs to manually unimport the device with "detach". > > If "bind" cmd gets killed (server side) it will stop the foreground monitoring. > The device will still remain exported if exit at exported state. The user then > needs to manually unexport the device with "unbind". > My concern is the persistence nature of these exports/imports through reboots. I have to give it some though on how this can be implemented addressing my concerns. >> - What happens when one or more devices are detached? > > If user exit from "attach" cmd running in foreground, followed by detaching the > device manually, it will work as previously. The device will become available on > the server for importing again. > > If user running "attach" cmd in foreground, while executing "detach" manually > from another terminal or similar, the foreground "attach" command will detect > the disconnection and re-establish the import. I don't see any use case for > this, it's just for explaining. > > If user running "attach" cmd in foreground, while the remote device becomes > unexported (or disconnected) it will start polling the usbipd. > When a device becomes exported on the chosen bus it gets imported immediately. > >> - What happens when one or more devices are unbound from >> the server? >> >> Let's walk through these scenarios. > > If user exit from "bind" cmd running in foreground, followed by unbind the > device manually it will work as previous. The usb device will become available > on the server again. > > If user running "bind" cmd in foreground, while executing "unbind" from another > terminal or similar, the foreground "bind" command will detect the unexport > and re-establish the export. I don't see any use case for this, it's just for > explaining. > > If user running "bind" cmd in foreground, while the device becomes unexported > or disconnected it will restart monitoring the busid. When a device becomes > plugged in on the chosen usb port it gets exported immediately. > > One option to consider is to unexport & unimport the device at exit, but this > comes with the cost of creating a source code dependency between > bind --> unbind and attach --> detach. > How does this look like in code? thanks, -- Shuah ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v6 0/5] tools/usbip: Patch set summary 2021-12-14 22:22 ` Shuah Khan @ 2021-12-16 21:01 ` Lars Gunnarsson 2021-12-23 19:22 ` Shuah Khan 0 siblings, 1 reply; 7+ messages in thread From: Lars Gunnarsson @ 2021-12-16 21:01 UTC (permalink / raw) To: Shuah Khan; +Cc: Valentina Manea, Shuah Khan, linux-usb On Tue, Dec 14, 2021 at 03:22:57PM -0700, Shuah Khan wrote: > On 12/9/21 2:11 PM, Lars Gunnarsson wrote: > > On Mon, Dec 06, 2021 at 01:02:35PM -0700, Shuah Khan wrote: > > > On 11/30/21 3:22 PM, Lars Gunnarsson wrote: > > > > To forward a remote usb device over usbip the following steps is required: > > > > > > > > 1. Execute "usbip bind" on remote end. > > > > 2. Execute "usbip attach" on local end. > > > > > > > > These steps must be perfomed in above order and after usb device is plugged in. > > > > If the usb device is unplugged on the remote end the steps above needs to be > > > > performed again to establish the connection. This patch set implements a feature > > > > to persistently forward devices on a given bus. When using flag "-p|--persistent" > > > > on remot end, the USB device becomes exported when plugged in. When using flag > > > > "-p|--persistent" on local end, the USB device becomes imported when available > > > > on remote end. Thus it is only required to run the usbip command once on each > > > > end, in any order, to persistently forward usb devices on a given bus. > > > > > > > > This is sent in five separate patches: > > > > tools/usbip: update protocol documentation > > > > tools/usbip: update manual pages > > > > tools/usbip: add usb event monitor into libusbip > > > > tools/usbip: export USB devices on a given bus persistently > > > > tools/usbip: import USB devices on a given bus persistently > > > > > > > > > > When -p is used, the command stays in foreground. This is a very > > > different use model compared to current model. In addition, once > > > persistent flag is set on a bus, all devices even the ones that > > > are inserted in the future get exported. What happens if one of > > > the devices shouldn't be exported? > > > > Yes it's conceptually more like exporting/importing the physical usb port, > > rather than exporting/importing a device plugged into the usb port. Using flag > > "-p" on both ends will behave like a "virtual" usb hub, a device plugged in on > > the server (on a chosen bus) will automatically be available on the client. > > Using flag "-p" has no dependency on the other end though. Using "-p" on one end > > doesn't enforce usage on the other end. It is only for exporting and importing > > devices automatically when they become available. > > > > There might be better choices than naming flag to "persistent" for easily > > communicate this concept. Would "port" be more intuitive? > > "usbip attach --port 3-3.1" and "usbip bind --port 3-3.1" > > > > Terminology isn't what I am concerned about. My concern is the idea of > automatically making devices available for export at bus level. > > > > > > > There are several conditions to be thought through: > > > > > > - What happens if if the command that is running on the foreground > > > is killed on either end? > > > > If "attach" cmd gets killed (client side) it will stop the foreground > > monitoring. The device will still remain imported if user exit at imported state. > > The user then needs to manually unimport the device with "detach". > > > > If "bind" cmd gets killed (server side) it will stop the foreground monitoring. > > The device will still remain exported if exit at exported state. The user then > > needs to manually unexport the device with "unbind". > > > > My concern is the persistence nature of these exports/imports through > reboots. I have to give it some though on how this can be implemented > addressing my concerns. Can you elaborate on your thoughts about "the persistence nature of these exports/imports through reboots"? reboot as in exit from foreground and run the command again? > > > > - What happens when one or more devices are detached? > > > > If user exit from "attach" cmd running in foreground, followed by detaching the > > device manually, it will work as previously. The device will become available on > > the server for importing again. > > > > If user running "attach" cmd in foreground, while executing "detach" manually > > from another terminal or similar, the foreground "attach" command will detect > > the disconnection and re-establish the import. I don't see any use case for > > this, it's just for explaining. > > > > If user running "attach" cmd in foreground, while the remote device becomes > > unexported (or disconnected) it will start polling the usbipd. > > When a device becomes exported on the chosen bus it gets imported immediately. > > > > > - What happens when one or more devices are unbound from > > > the server? > > > > > > Let's walk through these scenarios. > > > > If user exit from "bind" cmd running in foreground, followed by unbind the > > device manually it will work as previous. The usb device will become available > > on the server again. > > > > If user running "bind" cmd in foreground, while executing "unbind" from another > > terminal or similar, the foreground "bind" command will detect the unexport > > and re-establish the export. I don't see any use case for this, it's just for > > explaining. > > > > If user running "bind" cmd in foreground, while the device becomes unexported > > or disconnected it will restart monitoring the busid. When a device becomes > > plugged in on the chosen usb port it gets exported immediately. > > > > One option to consider is to unexport & unimport the device at exit, but this > > comes with the cost of creating a source code dependency between > > bind --> unbind and attach --> detach. > > > > How does this look like in code? > > thanks, > -- Shuah ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v6 0/5] tools/usbip: Patch set summary 2021-12-16 21:01 ` Lars Gunnarsson @ 2021-12-23 19:22 ` Shuah Khan 0 siblings, 0 replies; 7+ messages in thread From: Shuah Khan @ 2021-12-23 19:22 UTC (permalink / raw) To: Lars Gunnarsson; +Cc: Valentina Manea, Shuah Khan, linux-usb, Shuah Khan On 12/16/21 2:01 PM, Lars Gunnarsson wrote: > On Tue, Dec 14, 2021 at 03:22:57PM -0700, Shuah Khan wrote: >> On 12/9/21 2:11 PM, Lars Gunnarsson wrote: >>> On Mon, Dec 06, 2021 at 01:02:35PM -0700, Shuah Khan wrote: >>>> On 11/30/21 3:22 PM, Lars Gunnarsson wrote: >>>>> To forward a remote usb device over usbip the following steps is required: >>>>> >>>>> 1. Execute "usbip bind" on remote end. >>>>> 2. Execute "usbip attach" on local end. >>>>> >>>>> These steps must be perfomed in above order and after usb device is plugged in. >>>>> If the usb device is unplugged on the remote end the steps above needs to be >>>>> performed again to establish the connection. This patch set implements a feature >>>>> to persistently forward devices on a given bus. When using flag "-p|--persistent" >>>>> on remot end, the USB device becomes exported when plugged in. When using flag >>>>> "-p|--persistent" on local end, the USB device becomes imported when available >>>>> on remote end. Thus it is only required to run the usbip command once on each >>>>> end, in any order, to persistently forward usb devices on a given bus. >>>>> >>>>> This is sent in five separate patches: >>>>> tools/usbip: update protocol documentation >>>>> tools/usbip: update manual pages >>>>> tools/usbip: add usb event monitor into libusbip >>>>> tools/usbip: export USB devices on a given bus persistently >>>>> tools/usbip: import USB devices on a given bus persistently >>>>> >>>> >>>> When -p is used, the command stays in foreground. This is a very >>>> different use model compared to current model. In addition, once >>>> persistent flag is set on a bus, all devices even the ones that >>>> are inserted in the future get exported. What happens if one of >>>> the devices shouldn't be exported? >>> >>> Yes it's conceptually more like exporting/importing the physical usb port, >>> rather than exporting/importing a device plugged into the usb port. Using flag >>> "-p" on both ends will behave like a "virtual" usb hub, a device plugged in on >>> the server (on a chosen bus) will automatically be available on the client. >>> Using flag "-p" has no dependency on the other end though. Using "-p" on one end >>> doesn't enforce usage on the other end. It is only for exporting and importing >>> devices automatically when they become available. >>> >>> There might be better choices than naming flag to "persistent" for easily >>> communicate this concept. Would "port" be more intuitive? >>> "usbip attach --port 3-3.1" and "usbip bind --port 3-3.1" >>> >> >> Terminology isn't what I am concerned about. My concern is the idea of >> automatically making devices available for export at bus level. >> >>>> >>>> There are several conditions to be thought through: >>>> >>>> - What happens if if the command that is running on the foreground >>>> is killed on either end? >>> >>> If "attach" cmd gets killed (client side) it will stop the foreground >>> monitoring. The device will still remain imported if user exit at imported state. >>> The user then needs to manually unimport the device with "detach". >>> >>> If "bind" cmd gets killed (server side) it will stop the foreground monitoring. >>> The device will still remain exported if exit at exported state. The user then >>> needs to manually unexport the device with "unbind". >>> >> >> My concern is the persistence nature of these exports/imports through >> reboots. I have to give it some though on how this can be implemented >> addressing my concerns. > > Can you elaborate on your thoughts about "the persistence nature of these exports/imports through reboots"? > reboot as in exit from foreground and run the command again? > Sorry for the delay in responding. I have been thinking about this more. I am not convinced that supporting these use-cases requires usbip changes. Can we not accomplish the same via scripts/crontab? Monitor if a bound device is removed and rebind. Do the same on the client side? Have you explored if this can be done with existing tools and a shell script and make use of crontab? thanks, -- Shuah ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-12-23 19:22 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-11-30 22:22 [PATCH v6 0/5] tools/usbip: Patch set summary Lars Gunnarsson 2021-12-03 11:17 ` Greg KH 2021-12-06 20:02 ` Shuah Khan 2021-12-09 21:11 ` Lars Gunnarsson 2021-12-14 22:22 ` Shuah Khan 2021-12-16 21:01 ` Lars Gunnarsson 2021-12-23 19:22 ` Shuah Khan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).