> -----Original Message----- > From: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> > Sent: Tuesday, January 5, 2021 11:06 > To: Limonciello, Mario > Cc: Yehezkel Bernat; linux-usb@xxxxxxxxxxxxxxx; Michael Jamet; Lukas Wunner; > Andreas Noever; Christian Kellner > Subject: Re: [PATCH 2/2] thunderbolt: Add support for de-authorizing devices > > > [EXTERNAL EMAIL] > > 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. In that case I think you're right to leave it as deauthorization. If there is a strong enough use case to detect connection manager at userspace (IE it will actually do something differently from that information) that attribute can always be exported later. > > > > > 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.
