Hi, On Sun, Jan 30, 2022 at 03:30:39PM +0100, Rafael J. Wysocki wrote: > > I'm open to doing so if the others also feel the same way. IMHO > > though, the semantics of ACPI "DmaProperty" differ from the semantics > > of the property I'm proposing here. > > > > The current (documented) semantics (of "DmaProperty"): *This device > > (root port) is trusted*, but any devices downstream are not to be > > trusted. > > > > What I need and am proposing (new "UntrustedDevice"): *This device as > > well as any downstream devices* are untrusted. > > > > Note that there may be firmware implementing "DmaProperty" already out > > there (for windows), and if we decide to use it for my purposes, then > > there shall be a discrepancy in how Linux uses that property vs > > Windows. Is that acceptable? > > It may be confusing, so I'd rather not do that. > > The platform firmware will use it with the Windows use case in mind > and if it has side effects in Linux, problems are likely to appear in > the field. > > So the question is rather not about it being acceptable, but about > whether or not this is generally going to work. I was kind of implying that we could perhaps contact Microsoft and ask them if the wording could be changed to cover all the devices, not just PCIe root ports. I think this is something they will also need for things like internal WI-FI controllers. If that's not possible then no objections adding "UntrustedDevice". We just need to deal with the "DmaProperty" anyway and both end up setting pdev->untrusted in the similar manner.
