On Mon, Aug 1, 2016 at 1:57 PM, Linda Knippers <linda.knippers(a)hpe.com> wrote:
> What's missing in here is a) the glue code to
drivers/acpi/nfit.c and b) the
> implementations of HPE1 DSMs.
> Once I have these two I'll post a RFC patch series to the ML, but in the
> meanwhile I'm already open to comments.
> The glue code to nfit will be a bus so we have all the nice and shiny .probe()
> .remove() .uevent() and what not.
There are some things I like about this approach. What I like most is
that it add modularity. I think that when the ACPI tables for NVDIMM
devices were designed, the idea was that you could have different types
of NVDIMMs with different capabilities and management requirements, and
have generic as well as device-specific software. Section 9.20.5
describes the different fields that might be used to distinguish the
hardware and load device or vendor-specific drivers. We don't have
flexibility in the current code. Perhaps it makes sense to evolve our
current code base to one where the root functions are in the Generic NVDIMM
management driver and we have vendor-specific management drivers for the
non-root device DSMs. I don't know if we need that for the other driver
types but management is becoming more complicated without them.
I don't think that is quite what Johannes is proposing. This isn't a
management model per-vendor, this is a scheme to have the kernel
present unified management model across vendors and minimize the
surface area of the userspace ABI as much as possible.