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. > > What a great feature! Thanks for implementing it. > > 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. > > 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.
