> -----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). > > > > 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. > > > > Possible values are supported: > > > > > > - == =========================================== > > > + == =================================================== > > > + 0 The device will be de-authorized (only supported if > > > + deauthorization attribute under domain contains 1) > > > 1 The device will be authorized and connected > > > - == =========================================== > > > + == =================================================== > > > > > > When key attribute contains 32 byte hex string the > possible > > > values are: > > > > As 0 is available for 'secure' security level too, you may want to reflect > it in > > the documentation here somehow. > > OK. > > > > +static int disapprove_switch(struct device *dev, void *data) > > > > Maybe it's better to mark `data` as `__maybe_unused`? > > Or rename `data` as `unused`? I think in ACPI side we are doing that > but sure, I'll change it.
