Messages in this thread | | | Date | Tue, 4 Apr 2023 12:17:01 -0700 | From | Dan Williams <> | Subject | RE: [PATCH v4 3/5] cxl/pci: Find and register CXL PMU devices |
| |
Jonathan Cameron wrote: > CXL PMU devices can be found from entries in the Register > Locator DVSEC. > > In order to register the minimum number of IRQ vectors necessary > to support all CPMUs found, separate the registration into two > steps. First find the devices, and query the IRQs used and then > register the devices. Between these two steps, request the > IRQ vectors necessary and enable bus master support.
It's not clear why this patch is talking about irq vectors and bus mastering when there is no irq query/setup logic in this patch?
> Future IRQ users for CXL type 3 devices (e.g. DOEs) will need to > follow a similar pattern the number of vectors necessary is known > before any parts of the driver stack rely on their availability.
With the new pci_msix_alloc_irq_at() it's not clear that this 2 step approach is required, right?
> Reviewed-by: Dave Jiang <dave.jiang@intel.com> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > --- > v4: > - No change. > --- > drivers/cxl/core/Makefile | 1 + > drivers/cxl/core/core.h | 1 + > drivers/cxl/core/cpmu.c | 72 +++++++++++++++++++++++++++++++++++++++
A quibble with the naming, I prefer:
drivers/cxl/core/pmu.c
...since "cxl" is in the directory path. Also, usages of cpmu already have a cxl in their symbol names, so just s/cpmu/pmu/ throught. The usage of CPMU_ for register macros would seem be more clear, or at least more consistent, as CXL_PMU_ like the other register offset definitions in cxlpci.h.
> drivers/cxl/core/port.c | 2 ++ > drivers/cxl/core/regs.c | 16 +++++++++ > drivers/cxl/cpmu.h | 56 ++++++++++++++++++++++++++++++
drivers/cxl/pmu.h
> drivers/cxl/cxl.h | 14 ++++++++ > drivers/cxl/cxlpci.h | 1 + > drivers/cxl/pci.c | 25 +++++++++++++- > 9 files changed, 187 insertions(+), 1 deletion(-)
Other than those minor issues above, this looks good to me, with those fixed up.
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
| |