Re: [RFC PATCH 2/9] cxl/acpi: add OSC support

[Rafael J. Wysocki]

On Tue, Nov 17, 2020 at 12:26 AM Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
>
> On Mon, Nov 16, 2020 at 10:00 AM Jonathan Cameron
> <Jonathan.Cameron@xxxxxxxxxx> wrote:
> >
> > On Tue, 10 Nov 2020 21:43:49 -0800
> > Ben Widawsky <ben.widawsky@xxxxxxxxx> wrote:
> >
> > > From: Vishal Verma <vishal.l.verma@xxxxxxxxx>
> > >
> > > Add support to advertise OS capabilities, and request OS control for CXL
> > > features using the ACPI _OSC mechanism. Advertise support for all
> > > possible CXL features, and attempt to request control too for all
> > > possible features.
> > >
> > > Based on a patch by Sean Kelley.
> > >
> > > Signed-off-by: Vishal Verma <vishal.l.verma@xxxxxxxxx>
> > > Signed-off-by: Ben Widawsky <ben.widawsky@xxxxxxxxx>
> >
> > I guess unsurprisingly a lot of this is cut and paste from PCIe
> > so can we share some of the code?
> >
>
> I do not see a refactoring effort for these bit being all that
> fruitful.

Well, that depends on how much code duplication could be avoided this way.

> The backport pressure for this driver stack I expect will be
> higher than most, so I'm sensitive to avoiding unnecessary core
> entanglements.

If two pieces of code are based on the same underlying common code, it
is immediately clear to the reader how similar to each other they are.
Otherwise, they need to be carefully compared with each other to find
out what the differences are and whether or not they are arbitrary or
vitally important.  That is essential both from the revirem
perspective today and to anyone wanting to understand the given code
in the future (possibly in order to modify it without breaking it).
It outweighs the convenience by far IMV, with all due respect.

Recall how much effort it took to combine x86 with x86_64 and why it
turned out to be necessary to do that work, for one example.