Messages in this thread | | | Date | Fri, 2 Dec 2022 15:34:20 -0800 | From | Dan Williams <> | Subject | Re: [PATCH V2 04/11] cxl/mem: Clear events on driver load |
| |
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.
| |