On Tue, Jan 05, 2021 at 04:48:23PM +0000, Limonciello, Mario wrote: > > -----Original Message----- > > From: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> > > Sent: Tuesday, January 5, 2021 10:36 > > To: Yehezkel Bernat > > Cc: linux-usb@xxxxxxxxxxxxxxx; Michael Jamet; Lukas Wunner; Andreas Noever; > > Christian Kellner; Limonciello, Mario > > Subject: Re: [PATCH 2/2] thunderbolt: Add support for de-authorizing devices > > > > > > [EXTERNAL EMAIL] > > > > Hi, > > > > On Tue, Jan 05, 2021 at 03:53:33PM +0200, Yehezkel Bernat wrote: > > > On Tue, Jan 5, 2021 at 11:28 AM Mika Westerberg > > > <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > > > > > > > In some cases it is useful to be able de-authorize devices. For example > > > > if user logs out the userspace can have a policy that disconnects PCIe > > > > devices until logged in again. This is only possible for software based > > > > connection manager as it directly controls the tunnels. > > > > > > > > For this reason make the authorized attribute accept writing 0 which > > > > makes the software connection manager to tear down the corresponding > > > > PCIe tunnel. Userspace can check if this is supported by reading a new > > > > domain attribute deauthorization, that holds 1 in that case. > > Just another idea, rather than the value of a new "deauthorize" attribute indicating > whether this is supported how about instead a "connection_manager" attribute? > > My thought being userspace can potentially make a judgement call from the information > on how tunnels are going to behave (particularly in long chains from the suspend/resume > cycle coming back differently). I went for "deauthorization" because that kind of allows this to work on systems with firmware based connection manager too (yes, Intel Maple Ridge is using FW CM even if it is USB4 :( ). However, at the moment the FW CM does not support any if this but nobody knows if something like this will be implemented there. That said, I'm fine to change this to whatever you guys think is the best :) If "connection_manager=sw/fw" or so is better then no problem changing that. > > > What a great feature! Thanks for implementing it. > > I agree, this sounds like a great idea. > > > > > > > BTW, is there any general way to disable the device operations before such a > > > disconnection? The user has a way to stop removable disks, for example, but > > > maybe other devices need additional precaution from the user (eGPU?). > > > > There are ways but it depends on the driver, I guess. For instance eGPUS > > at the moment (the ones I've tested) simply crash as their driver does > > not support hot-remove ;-) > > > > What ends up happening is essentially PCIe hot-remove so drivers that > > are prepared for that should be fine. Of course if you had mounted > > filesystem behind the PCIe link that was torn down you end up losing > > your data, so the user interface should make sure the user is aware of > > that. > > I think it's also worth mentioning this risk in the thunderbolt.rst documentation > directly. Sure, I'll add there mention about this.
