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;
Date:   Fri, 2 Dec 2022 15:34:20 -0800
From:   Dan Williams <dan.j.williams@intel.com>
To:     Ira Weiny <ira.weiny@intel.com>,
        Dan Williams <dan.j.williams@intel.com>
CC:     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: Re: [PATCH V2 04/11] cxl/mem: Clear events on driver load
Message-ID: <638a8b7c97ceb_18fe029410@dwillia2-mobl3.amr.corp.intel.com.notmuch>
References: <20221201002719.2596558-1-ira.weiny@intel.com>
 <20221201002719.2596558-5-ira.weiny@intel.com>
 <6389676c60d39_3cbe029487@dwillia2-xfh.jf.intel.com.notmuch>
 <Y4oo+rxYAyBoHexo@iweiny-desk3>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Y4oo+rxYAyBoHexo@iweiny-desk3>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?HQmbhoAnB4PLUcUHIDLsCoB5Y0KOQkgfkFCSbXry7BmyDnrVYU+xY0rdkLIa?=
 =?us-ascii?Q?wjRwoX7fD8bgej+tNkFbJVq5dxHCtoNXEimsFAk9mb6HtilSxwLqOuDMC8X2?=
 =?us-ascii?Q?VoiLvfOUpIpSiFioyWNJRQlr5xa1QRZXIYPP0EQW586AZ68Vtcg23EdrHYd3?=
 =?us-ascii?Q?z4jFZLcMcrJobnvPToq2S4+dkMrP3qSNtNrAFmJ3dRiSWvGsq4anGwtKFg58?=
 =?us-ascii?Q?UZJSx9vFq1c2CNdgcttbUNH+qpO0+D5OslskrZI7DDHXMxyicWT4sr3gBiZl?=
 =?us-ascii?Q?qBGSSrEE2IuaRqYnMcCz47ciaMC85/YMAGAAMSnZLA3Zx4gL4/q9SeftPMRm?=
 =?us-ascii?Q?V21GWMQ7KzEA3j2xAv+EldewAkVut3Q6DzmSHICmN+X53AA60bdAVxQAGVaN?=
 =?us-ascii?Q?ywZ3+NmDLjNHTI4gsbUj/QMuruC8UKkJEPlCeFdgbU+8kFS2ocF8aV2HiZsP?=
 =?us-ascii?Q?5HAhTO6ui1qh35fINHdNBI4/kqpnEInjeZW+eFmHmVvs1YFEGxgInfRFHQqU?=
 =?us-ascii?Q?6Q115GWABH79nTacoG+i87IhnfuRF2VDDfI1zAdvqif0Vczbio76SYPXBATA?=
 =?us-ascii?Q?KSNBw/+pIuRmmtaLxyrEN/cwE29u31u4mv0XcGOhuMMfaHvH1jMigYZXe/Up?=
 =?us-ascii?Q?ZF8E8NLdPRlOpAIIEoab/hJqKz2q8FjWkq84FlhgXctgL3JLiEuw97+28XxC?=
 =?us-ascii?Q?TlvRabRRKqoWcUN7LxJBSkEG+mZTlLoSMkBl6VUSh70cPBT+wZiQ+FhFySTo?=
 =?us-ascii?Q?37Wv8bIVZmNmdjkKtBXpiPOoQGeJCRPy8UDl3bh38xpDUoh37sLKBZlasinQ?=
 =?us-ascii?Q?Jd073D3P+clIE1f1RUveOPAJIRgWJ/UGohkujklsLLOErrlEGZbK6fjb0Ins?=
 =?us-ascii?Q?cFWaZOILWmH0/jhAeyGUz+ym7oVrwC1aM1frowgQoCGJD5JrTQZFTkppU3DO?=
 =?us-ascii?Q?0vfIeT+HA8EZumcHR89suiCEV4uX6PB/mo8HzLBZc+nz7l0KzNOrmhBt35Do?=
 =?us-ascii?Q?t3NtLtEFakAJEorivuzIh4amRjIzB2x20/okGM7HqwPvdTV1fNpEegbgRyMP?=
 =?us-ascii?Q?twWjXN9qxGqU7Z/arzevMSPtRFqvot5EBRhnxImcIvw5EEf8qv/mShsbSE9b?=
 =?us-ascii?Q?5wu8meEnWP5ad4XEYto0A9eTqhg2TuH+blongjdF+m9M+TFTA+8bvj9tdSOm?=
 =?us-ascii?Q?2Wv5lkuNrO7FGL8u1F64MRSfdWnzUqF8PjrJCrkVxJObqzJXPgVa5MzmX6pu?=
 =?us-ascii?Q?O5OcevPnJSG2qMVOTI7vOyMMAVIR+IMbn3zokjgt488cvBfqtEcGFirIaC9K?=
 =?us-ascii?Q?DmLS0H+F20BW42UMwXBlTaEPsvmrAirovQai1/hrmHbHFdTDS7GhL2fJm4mo?=
 =?us-ascii?Q?PxAHBElk8pK1Lb1aq0L5EVoD1yEuTN2Ltli54gbz944pl85bsIlF7VxotLNL?=
 =?us-ascii?Q?Q8YI72w4G3eMFPs+o/rDvZDhIU/TohNHQzMqqDiY/FRJZk3jIoYAy6/JSuHa?=
 =?us-ascii?Q?vWBIQ2iOlOyWAdHoyK6LCiGlvm4vvU/uYIE/3toTuVLdooDB/IvLWlTGimN7?=
 =?us-ascii?Q?Sxszaq6vRfXWd23aNMZ1J6W2+tJfEgEgWYkLpvq1G4gPB3XPNP3ig4qxgvJG?=
 =?us-ascii?Q?bQ=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 2519ab18-6194-4196-8fb4-08dad4bdbe22
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1101MB2126.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2022 23:34:23.3002
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ZORTdUcT01BTj8+KnGGP0GJLIx1BmaP4KnlKNrvB+S09nat5tLLpltoeVwKrAeILYQw2sll1REv4LnRd8Gor/4DMvtYvZUxoM6FOuAnx0wI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5381
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,
        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

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.