在 2022/9/24 AM2:51, Bjorn Helgaas 写道: > On Fri, Sep 23, 2022 at 10:46:09PM +0800, Shuai Xue wrote: >> 在 2022/9/23 AM1:36, Bjorn Helgaas 写道: >>> On Sat, Sep 17, 2022 at 08:10:35PM +0800, Shuai Xue wrote: > >>>> +static struct device_attribute dwc_pcie_pmu_cpumask_attr = >>>> +__ATTR(cpumask, 0444, dwc_pcie_pmu_cpumask_show, NULL); >>> >>> DEVICE_ATTR_RO()? > >> 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 :) > >>> 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. > >>>> +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