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=-13.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 849A0C28B5B for ; Mon, 13 Sep 2021 23:19:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7020A60FDA for ; Mon, 13 Sep 2021 23:19:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241821AbhIMXVA (ORCPT ); Mon, 13 Sep 2021 19:21:00 -0400 Received: from mga17.intel.com ([192.55.52.151]:16266 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245301AbhIMXUl (ORCPT ); Mon, 13 Sep 2021 19:20:41 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10106"; a="201992179" X-IronPort-AV: E=Sophos;i="5.85,291,1624345200"; d="scan'208";a="201992179" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2021 16:19:23 -0700 X-IronPort-AV: E=Sophos;i="5.85,291,1624345200"; d="scan'208";a="582590158" Received: from lwilson9-mobl1.amr.corp.intel.com (HELO intel.com) ([10.252.130.153]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2021 16:19:22 -0700 Date: Mon, 13 Sep 2021 16:19:21 -0700 From: Ben Widawsky To: Dan Williams Cc: linux-cxl@vger.kernel.org, Alison Schofield , Ira Weiny , Jonathan Cameron , Vishal Verma Subject: Re: [PATCH 04/13] cxl: Introduce endpoint decoders Message-ID: <20210913231921.w2rujefmewgraopi@intel.com> References: <20210902195017.2516472-1-ben.widawsky@intel.com> <20210902195017.2516472-5-ben.widawsky@intel.com> <20210913161149.ggbd5jmro2davaq5@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-cxl@vger.kernel.org On 21-09-13 15:07:44, Dan Williams wrote: > On Mon, Sep 13, 2021 at 9:11 AM Ben Widawsky wrote: > > > > On 21-09-10 12:19:24, Dan Williams wrote: > > > On Thu, Sep 2, 2021 at 12:50 PM Ben Widawsky wrote: > > > > > > > > Endpoints have decoders too. It is useful to share the same > > > > infrastructure from cxl_core. Endpoints do not have dports (downstream > > > > targets), only the underlying physical medium. As a result, some special > > > > casing is needed. > > > > > > > > There is no functional change introduced yet as endpoints don't actually > > > > enumerate decoders yet. > > > > > > > > Signed-off-by: Ben Widawsky > > > > --- > > > > drivers/cxl/core/bus.c | 29 +++++++++++++++++++++++++---- > > > > 1 file changed, 25 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/drivers/cxl/core/bus.c b/drivers/cxl/core/bus.c > > > > index 8d5061b0794d..6202ce5a5ac2 100644 > > > > --- a/drivers/cxl/core/bus.c > > > > +++ b/drivers/cxl/core/bus.c > > > > @@ -175,6 +175,12 @@ static const struct attribute_group *cxl_decoder_switch_attribute_groups[] = { > > > > NULL, > > > > }; > > > > > > > > +static const struct attribute_group *cxl_decoder_endpoint_attribute_groups[] = { > > > > + &cxl_decoder_base_attribute_group, > > > > + &cxl_base_attribute_group, > > > > + NULL, > > > > +}; > > > > + > > > > static void cxl_decoder_release(struct device *dev) > > > > { > > > > struct cxl_decoder *cxld = to_cxl_decoder(dev); > > > > @@ -184,6 +190,12 @@ static void cxl_decoder_release(struct device *dev) > > > > kfree(cxld); > > > > } > > > > > > > > +static const struct device_type cxl_decoder_endpoint_type = { > > > > + .name = "cxl_decoder_endpoint", > > > > + .release = cxl_decoder_release, > > > > + .groups = cxl_decoder_endpoint_attribute_groups, > > > > +}; > > > > + > > > > static const struct device_type cxl_decoder_switch_type = { > > > > .name = "cxl_decoder_switch", > > > > .release = cxl_decoder_release, > > > > @@ -196,6 +208,11 @@ static const struct device_type cxl_decoder_root_type = { > > > > .groups = cxl_decoder_root_attribute_groups, > > > > }; > > > > > > > > +static bool is_endpoint_decoder(struct device *dev) > > > > +{ > > > > + return dev->type == &cxl_decoder_endpoint_type; > > > > +} > > > > + > > > > bool is_root_decoder(struct device *dev) > > > > { > > > > return dev->type == &cxl_decoder_root_type; > > > > @@ -472,7 +489,7 @@ struct cxl_decoder *cxl_decoder_alloc(struct cxl_port *port, int nr_targets) > > > > struct device *dev; > > > > int rc = 0; > > > > > > > > - if (nr_targets > CXL_DECODER_MAX_INTERLEAVE || nr_targets < 1) > > > > + if (nr_targets > CXL_DECODER_MAX_INTERLEAVE) > > > > return ERR_PTR(-EINVAL); > > > > > > > > cxld = kzalloc(struct_size(cxld, target, nr_targets), GFP_KERNEL); > > > > @@ -491,8 +508,11 @@ struct cxl_decoder *cxl_decoder_alloc(struct cxl_port *port, int nr_targets) > > > > dev->parent = &port->dev; > > > > dev->bus = &cxl_bus_type; > > > > > > > > + /* Endpoints don't have a target list */ > > > > + if (nr_targets == 0) > > > > + dev->type = &cxl_decoder_endpoint_type; > > > > > > Do you also plan to introduce the concept of endpoint ports, and if > > > yes should that come before this patch? That would seem to be more > > > robust than, for example, allowing a switch port to carry an endpoint > > > decoder object as this allows. > > > > I didn't see a need as of yet to differentiate between endpoint ports and other > > ports. I don't entirely understand what you mean by "allowing a switch port to > > carry an endpoint decoder" means. Can you please elaborate? > > If endpoint ports were an explicit type then this check could make > sure that someone did not pass nr_targets set to 0 where the @port > argument is referring to a switch where the target_list must be > specified. > > Either that, or a comment in kernel-doc for this routine about the > special meaning of nr_targets == 0 and expected usage. Well, since Jonathan also brought up a concern here perhaps I should entertain other ideas. I suppose future versions of the spec could break things, but as it stands today the only CXL component that implements decoders that can have a 0 value for this are endpoint devices (T2 or T3, or LD). I think it's fine to wait until we have a second reason to make an endpoint port type and update kdocs for now, but maybe it will also be a natural fit with a proper port driver.