On Tue, Apr 19, 2022 at 03:28:26PM -0700, Dan Williams wrote: > On Tue, Apr 19, 2022 at 11:09 AM Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > > > On Tue, Apr 19, 2022 at 9:48 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Tue, Apr 19, 2022 at 09:38:51AM -0700, Tony Luck wrote: > > > > The initial implementation of IFS is model specific. Enumeration is > > > > via a combination of family-model-stepping and a check for a bit in the > > > > CORE_CAPABILITIES MSR. > > > > > > > > Linux has handled this lack of enumeration before with a code stub to > > > > create a device. See arch/x86/kernel/pmem.c. Use the same approach > > > > here. > > > > > > Ick, why? Why not just create a simple virtual device and use that? Do > > > you really want to bind a driver to this? Or do you already "know" the > > > only driver that you have will bind to this? > > > > With the realization that there may be multiple instances of an > > IFS-like capability going forward, and that ideally those capabilities > > would move away from a CPU capability bit to an ACPI description, then > > it seemed to me that a simulated platform_device for this is a > > reasonable fit. I.e. when / if an ACPI _HID is assigned for this > > capability the same platform_driver can be reused for those instances. > > Turns out the ACPI enumeration for this may not materialize, so this > can indeed move to a simple / driver-less device. Hey, see, doing extra work now was not a good idea :)
