From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1075C64E69 for ; Wed, 18 Nov 2020 17:58:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 43B9A2463B for ; Wed, 18 Nov 2020 17:58:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="tvpfEwP+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726340AbgKRR6Y (ORCPT ); Wed, 18 Nov 2020 12:58:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725970AbgKRR6Y (ORCPT ); Wed, 18 Nov 2020 12:58:24 -0500 Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6576C0613D4 for ; Wed, 18 Nov 2020 09:58:23 -0800 (PST) Received: by mail-ej1-x641.google.com with SMTP id a16so4034754ejj.5 for ; Wed, 18 Nov 2020 09:58:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CUfbbHmtoDuKn7TpUZ579udEm3PcirZfq0eQV5TKq9o=; b=tvpfEwP+ZZMkMQ93Mh1f6j5FKNXm5M2Ak6FsBNIIN8BiaV0BTYVl+2KI363P4pPGhk 4XCHCy6c/5qihFsPbRNd1ryg08ayiY0WUlMRJ7tsItKKpdl+0gXny2bzA4Yc7BDDciiF lm0yCD7b8wCqJOooSmMwFcwAUUnlD0g20c5tSUb4HBEO3d+SZUI228DolNZjs7b8A2Gb 2/lhmqWLg3vKRpt8+5DeljAmd22yWaWMCTaw2KqeGnVRMXy3rZs5tI/ni2Qe2EHepKE+ o1al2whOOjuL2T1TY5X7PNOayGhFCs+jfIlZ3vTJ4lgvHtGKFbdbUxJeUDrWuKJFi6l/ S4Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CUfbbHmtoDuKn7TpUZ579udEm3PcirZfq0eQV5TKq9o=; b=FTAvKx9TwElxS0C/rJAxW4vEqILPKAMg4b5rQlAc9C9Q6pkGOJuEuqgjrUsTo1gElA nQa4afYUbi2tXI39xY97DVRE3onzFeHLa+wt252XhmHn1PMAmxgO99upDP6qKVT3zyC8 uGo7voUCs8p40CSW3Ymnw4XrGvixQQx8Apdc9KBK7TQGJa5HBKUcpK8pIhbzD3Lw6398 ZT5UrDNVI/V2nTUbReKPN7mH16B8CMPNDg9a2bRk60Ff8Vj6P2dJlEBuHxYmqZ4V9QYM pTpOjFwnq/nc1mPz9H0or1s1xC2+ZEZRaD8CNJhiMd65BWoBMyG1FPir/ugjLAW4D8Ne 7iCA== X-Gm-Message-State: AOAM531GG6XsiN01FBtMRDgHbqkKn44DMuQO1LWOJ8X4LEsyCWyaoOiE kjGLVXpSlZhGdim9a6veWPVxsQ7FyZWuh6hHvQy2qw== X-Google-Smtp-Source: ABdhPJzAo7X20AwJvG1rn3bcJsj4ua9pJG670rFxHdWk1YJl4d0tkmXpxpdfWZiNhtz2BTcFoV1XlqYQxL6b9QgLA2M= X-Received: by 2002:a17:906:ad8e:: with SMTP id la14mr21620775ejb.264.1605722302429; Wed, 18 Nov 2020 09:58:22 -0800 (PST) MIME-Version: 1.0 References: <20201111054356.793390-1-ben.widawsky@intel.com> <20201111054356.793390-3-ben.widawsky@intel.com> <20201116175909.00007e53@Huawei.com> In-Reply-To: From: Dan Williams Date: Wed, 18 Nov 2020 09:58:11 -0800 Message-ID: Subject: Re: [RFC PATCH 2/9] cxl/acpi: add OSC support To: "Rafael J. Wysocki" Cc: Jonathan Cameron , Ben Widawsky , linux-cxl@vger.kernel.org, Linux Kernel Mailing List , Linux PCI , Linux ACPI , Ira Weiny , Vishal Verma , "Kelley, Sean V" , Bjorn Helgaas , "Rafael J . Wysocki" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 18, 2020 at 4:26 AM Rafael J. Wysocki wrote: > > On Tue, Nov 17, 2020 at 12:26 AM Dan Williams wrote: > > > > On Mon, Nov 16, 2020 at 10:00 AM Jonathan Cameron > > wrote: > > > > > > On Tue, 10 Nov 2020 21:43:49 -0800 > > > Ben Widawsky wrote: > > > > > > > From: Vishal Verma > > > > > > > > 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 > > > > Signed-off-by: Ben Widawsky > > > > > > 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.