Message ID | 20221201002719.2596558-5-ira.weiny@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp1229244wrr; Wed, 30 Nov 2022 16:32:45 -0800 (PST) X-Google-Smtp-Source: AA0mqf6wj/kwf/lSA0Qtv6f0JbrozvbEkVPjxFLJ4Sca70NhjQKNNcJaP8ZkVvn7kNytiOACR3xo X-Received: by 2002:a17:906:7f96:b0:7b2:b782:73 with SMTP id f22-20020a1709067f9600b007b2b7820073mr38131673ejr.641.1669854765609; Wed, 30 Nov 2022 16:32:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669854765; cv=none; d=google.com; s=arc-20160816; b=v4wxHs/FI1JnLeaeN4fGLlYcD00n+N6j5wbjAnr7cSEcoN5Q7yxpaJpvd/WByGWWGp noUDwPowSg9dBdfsr/ZkYiRa2CLT/i1qZOQvPzOa/H89ztfIDA0XAL+F0FfNic9e8nT0 8plY0ABNf6wTHLbfPrVjhPZG+H2L+3U9t2O7f6YE9Epgl0v4HxKVUlE3MUj+k+mL8Cpj umcGEvxYWFg8bmckWf4ok4my6U8R58isK7OJci9wpuofi/3VnBRd6JH7abmNtubCqoZr DDRapLUHAY6mBYdkmpFJGSxTqkG3EnTEBQyFYTxWRFwMq18SuiPsYVhzQkXfKFGUcQNI KKgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=DOaCj2tyDu/Sqdu1sMDLCWxgo2wk4zuBJK0npUFkNhc=; b=WEXfiy7uQcKnW9psCbK06ngN3pfugL3RmHIcJD9NIPs2vbT2ZSEeArXM0a1+3srslS H/kYrr8gZZsu3jBwYV+xzZZAAvhaKggcItLz2jh4ocfw/5hLDc6KmyDfa3VNenrQuNIr BwNdutIt8gVCcmHlMkjRaMYlUuFWmcjCATze2qoKM4vFyI3vYFtx7m3lAVA77VxsxBiN 8xgCfHSg7LQn9PNdfIsI6oudl+Hgnf9R0fQG8Ksn93rvy9GKMcVIibft6qafvfZJlFTr eYuJYTj0RPQpSN0Q0sGYowHc9Q85z9FC0zjAQeZjJfYlw3eauLsiWi7OFq0iLh/uV9nK ox+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=VuK1lyfd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qf20-20020a1709077f1400b007ae2299a195si2645900ejc.815.2022.11.30.16.32.21; Wed, 30 Nov 2022 16:32:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=VuK1lyfd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229792AbiLAA1r (ORCPT <rfc822;heyuhang3455@gmail.com> + 99 others); Wed, 30 Nov 2022 19:27:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229712AbiLAA1e (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 30 Nov 2022 19:27:34 -0500 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 431B310E; Wed, 30 Nov 2022 16:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669854453; x=1701390453; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=QN0FHISioResjhVj/Pv6zoPf18aJjWgu/WCgU6BoeF8=; b=VuK1lyfd5Oyi95mckUYMTyXVe0S1B13uOib6ISqUtlYlMfF0hlKa3Ptt zTXFYyJ78rhdWPry35qHicC+iual+biCa570CHXkB1wPUl+9IiuBeGEdj 7c7nvJMx2AyLWWC+bPBVz2iDObQ58wo8dYDMPrai4qlzDLNeh3dii4uUm UKFpG5YhoSaFkv5hX/NtrlEDbapWPn2SP5NFHGTm0zLQBKHbzp2aDw7cK rFTTnztGW4y9Ed3CDAxFKIDQkfnHbiSi9XK+HP4+F47eFEgSCL7fVZWim p8odTSIggQkJXTifb/zSFr9IagdcTeamcibIukEmu/UA+1ZMdNUgdHsMm g==; X-IronPort-AV: E=McAfee;i="6500,9779,10547"; a="317400853" X-IronPort-AV: E=Sophos;i="5.96,207,1665471600"; d="scan'208";a="317400853" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Nov 2022 16:27:31 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10547"; a="622085225" X-IronPort-AV: E=Sophos;i="5.96,207,1665471600"; d="scan'208";a="622085225" Received: from iweiny-mobl.amr.corp.intel.com (HELO localhost) ([10.251.1.240]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Nov 2022 16:27:29 -0800 From: ira.weiny@intel.com To: Dan Williams <dan.j.williams@intel.com> Cc: Ira Weiny <ira.weiny@intel.com>, Jonathan Cameron <Jonathan.Cameron@huawei.com>, Dave Jiang <dave.jiang@intel.com>, Alison Schofield <alison.schofield@intel.com>, Vishal Verma <vishal.l.verma@intel.com>, Ben Widawsky <bwidawsk@kernel.org>, Steven Rostedt <rostedt@goodmis.org>, Davidlohr Bueso <dave@stgolabs.net>, linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org Subject: [PATCH V2 04/11] cxl/mem: Clear events on driver load Date: Wed, 30 Nov 2022 16:27:12 -0800 Message-Id: <20221201002719.2596558-5-ira.weiny@intel.com> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20221201002719.2596558-1-ira.weiny@intel.com> References: <20221201002719.2596558-1-ira.weiny@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750969630879068737?= X-GMAIL-MSGID: =?utf-8?q?1750969630879068737?= |
Series |
CXL: Process event logs
|
|
Commit Message
Ira Weiny
Dec. 1, 2022, 12:27 a.m. UTC
From: Ira Weiny <ira.weiny@intel.com> The information contained in the events prior to the driver loading can be queried at any time through other mailbox commands. Ensure a clean slate of events by reading and clearing the events. The events are sent to the trace buffer but it is not anticipated to have anyone listening to it at driver load time. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Ira Weiny <ira.weiny@intel.com> --- drivers/cxl/pci.c | 2 ++ tools/testing/cxl/test/mem.c | 2 ++ 2 files changed, 4 insertions(+)
Comments
On Wed, 30 Nov 2022 16:27:12 -0800 ira.weiny@intel.com wrote: > From: Ira Weiny <ira.weiny@intel.com> > > The information contained in the events prior to the driver loading can > be queried at any time through other mailbox commands. > > Ensure a clean slate of events by reading and clearing the events. The > events are sent to the trace buffer but it is not anticipated to have > anyone listening to it at driver load time. > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > Reviewed-by: Dave Jiang <dave.jiang@intel.com> > Signed-off-by: Ira Weiny <ira.weiny@intel.com> Probably not worth addressing but there is a corner case where this might fail if some broken software already messed with reading out the events. Imagine it read the first mailbox sized chunk, but didn't clear them... If that happens, then we'd end up seeing the whole list, but in non temporal order and hence trying to clear them out of order with predictable fails. Maybe this is the category of things we 'fix' if we ever hear of it actually happening. So with that caveat called out so I can say 'I told you so' :), fine to keep my tag on this. Thanks, Jonathan > --- > drivers/cxl/pci.c | 2 ++ > tools/testing/cxl/test/mem.c | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c > index 8f86f85d89c7..11e95a95195a 100644 > --- a/drivers/cxl/pci.c > +++ b/drivers/cxl/pci.c > @@ -521,6 +521,8 @@ static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) > if (IS_ERR(cxlmd)) > return PTR_ERR(cxlmd); > > + cxl_mem_get_event_records(cxlds); > + > if (resource_size(&cxlds->pmem_res) && IS_ENABLED(CONFIG_CXL_PMEM)) > rc = devm_cxl_add_nvdimm(&pdev->dev, cxlmd); > > diff --git a/tools/testing/cxl/test/mem.c b/tools/testing/cxl/test/mem.c > index aa2df3a15051..e2f5445d24ff 100644 > --- a/tools/testing/cxl/test/mem.c > +++ b/tools/testing/cxl/test/mem.c > @@ -285,6 +285,8 @@ static int cxl_mock_mem_probe(struct platform_device *pdev) > if (IS_ERR(cxlmd)) > return PTR_ERR(cxlmd); > > + cxl_mem_get_event_records(cxlds); > + > if (resource_size(&cxlds->pmem_res) && IS_ENABLED(CONFIG_CXL_PMEM)) > rc = devm_cxl_add_nvdimm(dev, cxlmd); >
On Thu, Dec 01, 2022 at 01:30:33PM +0000, Jonathan Cameron wrote: > On Wed, 30 Nov 2022 16:27:12 -0800 > ira.weiny@intel.com wrote: > > > From: Ira Weiny <ira.weiny@intel.com> > > > > The information contained in the events prior to the driver loading can > > be queried at any time through other mailbox commands. > > > > Ensure a clean slate of events by reading and clearing the events. The > > events are sent to the trace buffer but it is not anticipated to have > > anyone listening to it at driver load time. > > > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > Reviewed-by: Dave Jiang <dave.jiang@intel.com> > > Signed-off-by: Ira Weiny <ira.weiny@intel.com> > > Probably not worth addressing but there is a corner case where this might fail > if some broken software already messed with reading out the events. Yea they can keep the pieces if they have done that. > > Imagine it read the first mailbox sized chunk, but didn't clear them... > > If that happens, then we'd end up seeing the whole list, but in non > temporal order and hence trying to clear them out of order with predictable > fails. > > Maybe this is the category of things we 'fix' if we ever hear of it actually > happening. > > So with that caveat called out so I can say 'I told you so' :), fine to keep my tag on this. Sure! We probably owe you this T-Shirt already! https://www.amazon.com/Big-Bang-Theory-Informed-Thusly/dp/B06XYCSQRF :-D Ira > > Thanks, > > Jonathan > > > > --- > > drivers/cxl/pci.c | 2 ++ > > tools/testing/cxl/test/mem.c | 2 ++ > > 2 files changed, 4 insertions(+) > > > > diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c > > index 8f86f85d89c7..11e95a95195a 100644 > > --- a/drivers/cxl/pci.c > > +++ b/drivers/cxl/pci.c > > @@ -521,6 +521,8 @@ static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) > > if (IS_ERR(cxlmd)) > > return PTR_ERR(cxlmd); > > > > + cxl_mem_get_event_records(cxlds); > > + > > if (resource_size(&cxlds->pmem_res) && IS_ENABLED(CONFIG_CXL_PMEM)) > > rc = devm_cxl_add_nvdimm(&pdev->dev, cxlmd); > > > > diff --git a/tools/testing/cxl/test/mem.c b/tools/testing/cxl/test/mem.c > > index aa2df3a15051..e2f5445d24ff 100644 > > --- a/tools/testing/cxl/test/mem.c > > +++ b/tools/testing/cxl/test/mem.c > > @@ -285,6 +285,8 @@ static int cxl_mock_mem_probe(struct platform_device *pdev) > > if (IS_ERR(cxlmd)) > > return PTR_ERR(cxlmd); > > > > + cxl_mem_get_event_records(cxlds); > > + > > if (resource_size(&cxlds->pmem_res) && IS_ENABLED(CONFIG_CXL_PMEM)) > > rc = devm_cxl_add_nvdimm(dev, cxlmd); > > >
cxl/mem is cxl_mem.ko, This is cxl/pci. ira.weiny@ wrote: > From: Ira Weiny <ira.weiny@intel.com> > > The information contained in the events prior to the driver loading can > be queried at any time through other mailbox commands. > > Ensure a clean slate of events by reading and clearing the events. The > events are sent to the trace buffer but it is not anticipated to have > anyone listening to it at driver load time. This is easy to guarantee with modprobe policy, so I am not sure it is worth stating. This breakdown feels odd. I would split the trace event definitions into its own lead in patch since that is a pile of definitions that can be merged on their own. Then squash get, clear, and this patch into one patch as they don't have much reason to go in separately. > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > Reviewed-by: Dave Jiang <dave.jiang@intel.com> > Signed-off-by: Ira Weiny <ira.weiny@intel.com> > --- > drivers/cxl/pci.c | 2 ++ > tools/testing/cxl/test/mem.c | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c > index 8f86f85d89c7..11e95a95195a 100644 > --- a/drivers/cxl/pci.c > +++ b/drivers/cxl/pci.c > @@ -521,6 +521,8 @@ static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) > if (IS_ERR(cxlmd)) > return PTR_ERR(cxlmd); > > + cxl_mem_get_event_records(cxlds); > + > if (resource_size(&cxlds->pmem_res) && IS_ENABLED(CONFIG_CXL_PMEM)) > rc = devm_cxl_add_nvdimm(&pdev->dev, cxlmd); > > diff --git a/tools/testing/cxl/test/mem.c b/tools/testing/cxl/test/mem.c > index aa2df3a15051..e2f5445d24ff 100644 > --- a/tools/testing/cxl/test/mem.c > +++ b/tools/testing/cxl/test/mem.c > @@ -285,6 +285,8 @@ static int cxl_mock_mem_probe(struct platform_device *pdev) > if (IS_ERR(cxlmd)) > return PTR_ERR(cxlmd); > > + cxl_mem_get_event_records(cxlds); > + This hunk likely goes with the first patch that actually implements some mocked events. > if (resource_size(&cxlds->pmem_res) && IS_ENABLED(CONFIG_CXL_PMEM)) > rc = devm_cxl_add_nvdimm(dev, cxlmd); > > -- > 2.37.2 >
On Thu, Dec 01, 2022 at 06:48:12PM -0800, Dan Williams wrote: > cxl/mem is cxl_mem.ko, This is cxl/pci. > > ira.weiny@ wrote: > > From: Ira Weiny <ira.weiny@intel.com> > > > > The information contained in the events prior to the driver loading can > > be queried at any time through other mailbox commands. > > > > Ensure a clean slate of events by reading and clearing the events. The > > events are sent to the trace buffer but it is not anticipated to have > > anyone listening to it at driver load time. > > This is easy to guarantee with modprobe policy, so I am not sure it is > worth stating. Fair enough. But there was some discussion early on regarding why reading and clearing on startup was a good thing. This showed that we chose to do that and why we don't care. I'll remove it. > > This breakdown feels odd. I would split the trace event definitions into > its own lead in patch since that is a pile of definitions that can be > merged on their own. Then squash get, clear, and this patch into one > patch as they don't have much reason to go in separately. I agree that splitting the Get/Clear/and this patch was odd. However, splitting Get/Clear made the discussion on those operations easier IMO. As a result this did not really belong in either of those patches on their own. It is also very clearly a do one thing per patch situation. > > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > Reviewed-by: Dave Jiang <dave.jiang@intel.com> > > Signed-off-by: Ira Weiny <ira.weiny@intel.com> > > --- > > drivers/cxl/pci.c | 2 ++ > > tools/testing/cxl/test/mem.c | 2 ++ > > 2 files changed, 4 insertions(+) > > > > diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c > > index 8f86f85d89c7..11e95a95195a 100644 > > --- a/drivers/cxl/pci.c > > +++ b/drivers/cxl/pci.c > > @@ -521,6 +521,8 @@ static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) > > if (IS_ERR(cxlmd)) > > return PTR_ERR(cxlmd); > > > > + cxl_mem_get_event_records(cxlds); > > + > > if (resource_size(&cxlds->pmem_res) && IS_ENABLED(CONFIG_CXL_PMEM)) > > rc = devm_cxl_add_nvdimm(&pdev->dev, cxlmd); > > > > diff --git a/tools/testing/cxl/test/mem.c b/tools/testing/cxl/test/mem.c > > index aa2df3a15051..e2f5445d24ff 100644 > > --- a/tools/testing/cxl/test/mem.c > > +++ b/tools/testing/cxl/test/mem.c > > @@ -285,6 +285,8 @@ static int cxl_mock_mem_probe(struct platform_device *pdev) > > if (IS_ERR(cxlmd)) > > return PTR_ERR(cxlmd); > > > > + cxl_mem_get_event_records(cxlds); > > + > > This hunk likely goes with the first patch that actually implements some > mocked events. If this patch was squashed into the other patches yes. But as a patch which does exactly 1 thing "Clear events on driver load" it works IMO. I could just have well put this patch at the very end. Now that the Get/Clear operations are more settled I'll split this out and squash it as you suggest. Jonathan suggested squashing Get/Clear too but again I really prefer the 1 thing/patch and each of those operations seemed like a good breakdown. Ira > > > if (resource_size(&cxlds->pmem_res) && IS_ENABLED(CONFIG_CXL_PMEM)) > > rc = devm_cxl_add_nvdimm(dev, cxlmd); > > > > -- > > 2.37.2 > > > >
Ira Weiny wrote: > On Thu, Dec 01, 2022 at 06:48:12PM -0800, Dan Williams wrote: > > cxl/mem is cxl_mem.ko, This is cxl/pci. > > > > ira.weiny@ wrote: > > > From: Ira Weiny <ira.weiny@intel.com> > > > > > > The information contained in the events prior to the driver loading can > > > be queried at any time through other mailbox commands. > > > > > > Ensure a clean slate of events by reading and clearing the events. The > > > events are sent to the trace buffer but it is not anticipated to have > > > anyone listening to it at driver load time. > > > > This is easy to guarantee with modprobe policy, so I am not sure it is > > worth stating. > > Fair enough. But there was some discussion early on regarding why reading and > clearing on startup was a good thing. This showed that we chose to do that and > why we don't care. I'll remove it. > > > > > This breakdown feels odd. I would split the trace event definitions into > > its own lead in patch since that is a pile of definitions that can be > > merged on their own. Then squash get, clear, and this patch into one > > patch as they don't have much reason to go in separately. > > I agree that splitting the Get/Clear/and this patch was odd. However, > splitting Get/Clear made the discussion on those operations easier IMO. > > As a result this did not really belong in either of those patches on their own. > > It is also very clearly a do one thing per patch situation. > > > > > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > Reviewed-by: Dave Jiang <dave.jiang@intel.com> > > > Signed-off-by: Ira Weiny <ira.weiny@intel.com> > > > --- > > > drivers/cxl/pci.c | 2 ++ > > > tools/testing/cxl/test/mem.c | 2 ++ > > > 2 files changed, 4 insertions(+) > > > > > > diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c > > > index 8f86f85d89c7..11e95a95195a 100644 > > > --- a/drivers/cxl/pci.c > > > +++ b/drivers/cxl/pci.c > > > @@ -521,6 +521,8 @@ static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) > > > if (IS_ERR(cxlmd)) > > > return PTR_ERR(cxlmd); > > > > > > + cxl_mem_get_event_records(cxlds); > > > + > > > if (resource_size(&cxlds->pmem_res) && IS_ENABLED(CONFIG_CXL_PMEM)) > > > rc = devm_cxl_add_nvdimm(&pdev->dev, cxlmd); > > > > > > diff --git a/tools/testing/cxl/test/mem.c b/tools/testing/cxl/test/mem.c > > > index aa2df3a15051..e2f5445d24ff 100644 > > > --- a/tools/testing/cxl/test/mem.c > > > +++ b/tools/testing/cxl/test/mem.c > > > @@ -285,6 +285,8 @@ static int cxl_mock_mem_probe(struct platform_device *pdev) > > > if (IS_ERR(cxlmd)) > > > return PTR_ERR(cxlmd); > > > > > > + cxl_mem_get_event_records(cxlds); > > > + > > > > This hunk likely goes with the first patch that actually implements some > > mocked events. > > If this patch was squashed into the other patches yes. But as a patch which > does exactly 1 thing "Clear events on driver load" it works IMO. I could just > have well put this patch at the very end. > > Now that the Get/Clear operations are more settled I'll split this out and > squash it as you suggest. Jonathan suggested squashing Get/Clear too but again > I really prefer the 1 thing/patch and each of those operations seemed like a > good breakdown. > I'll preface this by saying if you ask 3 kernel developers how to split a patch series you'll get 5 answers. For me though, a patch should be a bisectable full-thought. That at each step of a series the kernel is incrementally better in a way that makes sense. The kernel that gets Get Events likely needs to clear them too to complete 1 full thought about enbling Event handling. Otherwise a kernel that just retrieves some events until they overflow feels like a POC.
On Fri, Dec 02, 2022 at 03:34:20PM -0800, Dan Williams wrote: > Ira Weiny wrote: > > On Thu, Dec 01, 2022 at 06:48:12PM -0800, Dan Williams wrote: > > > cxl/mem is cxl_mem.ko, This is cxl/pci. [snip] > > > > + cxl_mem_get_event_records(cxlds); > > > > + > > > > > > This hunk likely goes with the first patch that actually implements some > > > mocked events. > > > > If this patch was squashed into the other patches yes. But as a patch which > > does exactly 1 thing "Clear events on driver load" it works IMO. I could just > > have well put this patch at the very end. > > > > Now that the Get/Clear operations are more settled I'll split this out and > > squash it as you suggest. Jonathan suggested squashing Get/Clear too but again > > I really prefer the 1 thing/patch and each of those operations seemed like a > > good breakdown. > > > > I'll preface this by saying if you ask 3 kernel developers how to split > a patch series you'll get 5 answers. Indeed. > For me though, a patch should be a > bisectable full-thought. That at each step of a series the kernel is > incrementally better in a way that makes sense. The kernel that gets Get > Events likely needs to clear them too to complete 1 full thought about > enbling Event handling. Otherwise a kernel that just retrieves some > events until they overflow feels like a POC. I've squashed it. Ira
diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c index 8f86f85d89c7..11e95a95195a 100644 --- a/drivers/cxl/pci.c +++ b/drivers/cxl/pci.c @@ -521,6 +521,8 @@ static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) if (IS_ERR(cxlmd)) return PTR_ERR(cxlmd); + cxl_mem_get_event_records(cxlds); + if (resource_size(&cxlds->pmem_res) && IS_ENABLED(CONFIG_CXL_PMEM)) rc = devm_cxl_add_nvdimm(&pdev->dev, cxlmd); diff --git a/tools/testing/cxl/test/mem.c b/tools/testing/cxl/test/mem.c index aa2df3a15051..e2f5445d24ff 100644 --- a/tools/testing/cxl/test/mem.c +++ b/tools/testing/cxl/test/mem.c @@ -285,6 +285,8 @@ static int cxl_mock_mem_probe(struct platform_device *pdev) if (IS_ERR(cxlmd)) return PTR_ERR(cxlmd); + cxl_mem_get_event_records(cxlds); + if (resource_size(&cxlds->pmem_res) && IS_ENABLED(CONFIG_CXL_PMEM)) rc = devm_cxl_add_nvdimm(dev, cxlmd);