On Wed, Nov 18, 2020 at 4:26 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > 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. I agree with above, but the degree of potential code sharing and refactoring for CXL is nowhere near approaching the x86_64 situation. There's also the counter example in ext3 and ext4 where a split is maintained for good reason. All I'm saying is that let's judge patches and not theory when it comes to refactoring CXL, my expectation is that those opportunities will be few and far between. CXL is a superset of PCIE functionality so it should not put much pressure on common core PCIE code to change vs incremental CXL extensions.
