Thread (77 messages) 77 messages, 8 authors, 2023-05-29

Re: [PATCH v1 2/3] drivers/perf: add DesignWare PCIe PMU driver

From: Shuai Xue <xueshuai@linux.alibaba.com>
Date: 2022-09-27 06:01:35
Also in: linux-pci, lkml


在 2022/9/24 AM2:51, Bjorn Helgaas 写道:
On Fri, Sep 23, 2022 at 10:46:09PM +0800, Shuai Xue wrote:
quoted
在 2022/9/23 AM1:36, Bjorn Helgaas 写道:
quoted
On Sat, Sep 17, 2022 at 08:10:35PM +0800, Shuai Xue wrote:
quoted
quoted
quoted
+static struct device_attribute dwc_pcie_pmu_cpumask_attr =
+__ATTR(cpumask, 0444, dwc_pcie_pmu_cpumask_show, NULL);
DEVICE_ATTR_RO()?
quoted
DEVICE_ATTR_RO may a good choice. But does it fit the code style to use
DEVICE_ATTR_RO in drivers/perf? As far as know, CCN, CCI, SMMU,
qcom_l2_pmu use "struct device_attribute" directly.
DEVICE_ATTR_RO is just newer, and I think CCN, CCI, SMMU, etc. would
be using it if they were written today.  Of course, the drivers/perf
maintainers may have a different opinion :)
Well, you are right, I will use DEVICE_ATTR_RO instead :)
quoted
quoted
I think every caller of dwc_pcie_pmu_read_dword() makes the same check
and prints the same message; maybe the message should be moved inside
dwc_pcie_pmu_read_dword()?

Same with dwc_pcie_pmu_write_dword(); moving the message there would
simplify all callers.
I would like to wrap dwc_pcie_pmu_{write}_dword out, use
pci_{read}_config_dword and drop the snaity check of return value as
Jonathan suggests.  How did you like it?
Sounds good.  Not sure the error checking is worthwhile since
pci_read_config_dword() really doesn't return meaningful errors
anyway.
quoted
quoted
quoted
+static struct dwc_pcie_info_table *pmu_to_pcie_info(struct pmu *pmu)
+{
+	struct dwc_pcie_info_table *pcie_info;
+	struct dwc_pcie_pmu *pcie_pmu = to_pcie_pmu(pmu);
+
+	pcie_info = container_of(pcie_pmu, struct dwc_pcie_info_table, pcie_pmu);
+	if (pcie_info == NULL)
+		pci_err(pcie_info->pdev, "Can't get pcie info\n");
It shouldn't be possible to get here for a pmu with no pcie_info, and
callers don't check for a NULL pointer return value before
dereferencing it, so I guess all this adds is an error message before
a NULL pointer oops?  Not sure the code clutter is worth it.
Do you mean to drop the snaity check of container_of?
Yes.  I'm suggesting that the NULL pointer oops itself has enough
information to debug this problem, even without the pci_err().
I will drop the snaity check in next version.


Thank you for you valuable comments.

Best Regards,
Shuai

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help