Re: [PATCH V2 04/11] cxl/mem: Clear events on driver load

Dan Williams
2022-12-02T23:35:14Z

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.