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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45D17C433EF for ; Thu, 4 Nov 2021 19:18:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 18F9B611EE for ; Thu, 4 Nov 2021 19:18:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229850AbhKDTUh (ORCPT ); Thu, 4 Nov 2021 15:20:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53698 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229804AbhKDTUh (ORCPT ); Thu, 4 Nov 2021 15:20:37 -0400 Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12A7AC061714 for ; Thu, 4 Nov 2021 12:17:59 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id v20so8884903plo.7 for ; Thu, 04 Nov 2021 12:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pPY32UoBpos6npFjOhP52/H4dbl/A2LxyxAlHKHwlpU=; b=S0RuQhHoB7eZobVST2JmlxI47OSd+OuT9Fs6h4nIxxATCnEtitUicvr59/9avb4gLx 2MuAEleG667ufF/8v3oJXZOEBzr9f+144GIf+Q6Tnx69saSD3rrOlyCjyC2iImuGLLp9 hKavhyGaADQ4rZnpdV+xNFI7vH1qiRqzkrJ2MqTBkF43w+d5sgU6xtRryFVZkcAQ/9zo viBiTM8PzXoTV0F7AfnytCfpRE01rQzK+4MG/5dkaBgXxL7NQSka6Mc7bC+5qdCTZvNp P7csQh4CsZP9VKzsocJUMJNcPCx7Kmt1fv5ugPK0Bv7QyjgdkUBc3Kj9aDnVpiQ+Nhoj KG5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pPY32UoBpos6npFjOhP52/H4dbl/A2LxyxAlHKHwlpU=; b=gIpkf0BbLUFDQCSq1gXUdWRsCinTviI7jkoc3MO4VH/uk7HmaEfxM7z2Cj1HMF+lOr tC7Tmmcrx/MHDGIKeFTp2vbI1x+ure+ogBUTy+9nkZM2fn2AzuxdGWXKf5BVv15tz99r gh1oapBxQVPzaLkJJu9xGGVOerLOo1PLHI4vLYJA0ON5gzQUKaoiYd5tgw3BiKTf73ny yx+jQk3n8j7xWTnq2DozYBFn62eLNcmboZrrQo17TJ1k4+zerdbpi+eamDzGEWsPWUUW ZuBA3xX+CjOg3FRRSX2C5nCAi0xIoKM5GcKzzH2y9hv2o6TY1TJzlc7F+bp8qIzWGyLH W8PQ== X-Gm-Message-State: AOAM532LBsR8E4m9RBXd6mBvOLcKbjHjpwDp9IoENdevFKwnlWVUeNjG EugP9vaaes+vCUosVBnF6VDRhaAbF6jzIRldRe95+g== X-Google-Smtp-Source: ABdhPJzZehSDivbS4m4ekYnTOxMiXl0zDQr7tsfLls46KuTEKfESXuj+IKtmUERKriJwiifERHm90togNTToITNkjYQ= X-Received: by 2002:a17:90b:1e49:: with SMTP id pi9mr1560146pjb.220.1636053478487; Thu, 04 Nov 2021 12:17:58 -0700 (PDT) MIME-Version: 1.0 References: <20211022183709.1199701-1-ben.widawsky@intel.com> <20211022183709.1199701-9-ben.widawsky@intel.com> <20211104163727.ybgenphhwaruqhff@intel.com> In-Reply-To: <20211104163727.ybgenphhwaruqhff@intel.com> From: Dan Williams Date: Thu, 4 Nov 2021 12:17:48 -0700 Message-ID: Subject: Re: [RFC PATCH v2 08/28] cxl/port: Introduce a port driver To: Ben Widawsky Cc: linux-cxl@vger.kernel.org, Chet Douglas , Alison Schofield , Ira Weiny , Jonathan Cameron , Vishal Verma Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-cxl@vger.kernel.org On Thu, Nov 4, 2021 at 9:37 AM Ben Widawsky wrote: > > On 21-10-29 18:37:36, Dan Williams wrote: > > On Fri, Oct 22, 2021 at 11:37 AM Ben Widawsky wrote: > > > > > [snip] > > > > > +void trigger_decoder_autoremove(void *data) > > +{ > > + struct cxl_decoder *cxld = data; > > + struct device *host = get_cxl_topology_host(); > > + > > + /* The topology host driver beat us to the punch */ > > + if (!host) > > + return; > > + > > + devm_remove_action(host, cxld_unregister, &cxld->dev); > > + put_cxl_topology_host(host); > > +} > > + > > +/** > > + * cxl_port_decoder_autoremove - remove decoders discovered by the port driver > > + * @cxld: decoder to remove > > + * > > + * CXL.mem requires an intact port / decoder topology from root level > > + * platform decoders to endpoint decoders. Arrange for decoders > > + * enumerated by the port driver to be removed when either the root is > > + * removed (in which the entire hierarchy is removed), or when an > > + * individual port is disabled, in which case only that port's > > + * sub-section of the hierarchy is removed. > > + */ > > +int cxl_port_decoder_autoremove(struct cxl_decoder *cxld) > > +{ > > + struct cxl_port *port = to_cxl_port(cxld->dev.parent); > > + struct device *host = get_cxl_topology_host(); > > + int rc; > > + > > + if (!host) > > + return -ENODEV; > > + > > + if (!port->dev.driver) { > > + rc = -ENXIO; > > + goto out; > > + } > > + > > + rc = cxl_decoder_autoremove(host, cxld); > > + if (rc) > > + goto out; > > + > > + rc = devm_add_action_or_reset(&port->dev, trigger_decoder_autoremove, > > + cxld); > > +out: > > + put_cxl_topology_host(host); > > + return rc; > > +} > > +EXPORT_SYMBOL_NS_GPL(cxl_port_decoder_autoremove, CXL); > > The only port which has decoders that aren't discovered by the port driver would > be the "root port" because it's platform specific. However, that port still is > treated similarly to the other ports. Therefore I don't see why you need > cxl_decoder_autoremove() anymore. Could you please explain? I think the safety > check in trigger_decoder_autoremove() makes this work for all cases. I don't think it's worth the games to explain why CXL sees fit to register (here comes your favorite argument...) non-idiomatic devm actions on devices that are not associated with the running device + driver. So as long as the port driver auto-unloads its child devices then we're golden. Is your concern that you want to have the CFMWS decoders registers from cxl_port and not cxl_acpi?