From: Bjorn Helgaas <helgaas@kernel.org>
To: "Kobayashi,Daisuke" <kobayashi.da-06@fujitsu.com>
Cc: kobayashi.da-06@jp.fujitsu.com, linux-cxl@vger.kernel.org,
y-goto@fujitsu.com, linux-pci@vger.kernel.org, mj@ucw.cz,
dan.j.williams@intel.com
Subject: Re: [PATCH v3 1/3] Add sysfs attribute for CXL 1.1 device link status
Date: Tue, 9 Apr 2024 09:59:33 -0500 [thread overview]
Message-ID: <20240409145933.GA2074336@bhelgaas> (raw)
In-Reply-To: <20240312080559.14904-2-kobayashi.da-06@fujitsu.com>
On Tue, Mar 12, 2024 at 05:05:57PM +0900, Kobayashi,Daisuke wrote:
> This patch implements a process to output the link status information
> of the CXL1.1 device to sysfs. The values of the registers related to
> the link status are outputted into three separate files.
>
> In CXL1.1, the link status of the device is included in the RCRB mapped to
> the memory mapped register area. This function accesses the address where
> the device's RCRB is mapped.
>
>
Spurious blank line in the commit log.
Perhaps include the names of the sysfs files? And a hint of what they
mean?
I think it's also conventional for the patch to add entries to
Documentation/ABI/... to show how to use the new files.
> +static u8 cxl_rcrb_get_pcie_cap_offset(void __iomem *addr){
Opening brace would typically be on the next line.
> + u8 offset;
> + u32 cap_hdr;
> +
> + offset = readb(addr + PCI_CAPABILITY_LIST);
> + cap_hdr = readl(addr + offset);
> + while ((cap_hdr & 0x000000ff) != PCI_CAP_ID_EXP) {
> + offset = (cap_hdr >> 8) & 0x000000ff;
> + if (offset == 0) // End of capability list
> + return 0;
> + cap_hdr = readl(addr + offset);
> + }
> + return offset;
Possibly mimic the name and structure of pci_find_capability(), in
particular, the loop structure of __pci_find_next_cap_ttl().
> +
Spurious blank line.
> +}
> +
> +static u32 cxl_rcrb_to_linkcap(struct device *dev, resource_size_t rcrb)
> +{
> + void __iomem *addr;
> + u8 offset;
> + u32 linkcap;
> +
> + if (WARN_ON_ONCE(rcrb == CXL_RESOURCE_NONE))
> + return 0;
> +
> + if (!request_mem_region(rcrb, SZ_4K, dev_name(dev)))
> + return 0;
> +
> + addr = ioremap(rcrb, SZ_4K);
> + if (!addr)
> + goto out;
> +
> + offset = cxl_rcrb_get_pcie_cap_offset(addr);
> + if (offset)
> + dev_dbg(dev, "found PCIe capability (0x%x)\n", offset);
> + else
> + goto out;
> +
> + linkcap = readl(addr + offset + PCI_EXP_LNKCAP);
> + iounmap(addr);
> +out:
> + release_mem_region(rcrb, SZ_4K);
> +
> + return linkcap;
> +}
> +static u16 cxl_rcrb_to_linkctr(struct device *dev, resource_size_t rcrb)
Why name this "linkctr" when other references here use "linkctrl"?
> +{
> + void __iomem *addr;
> + u8 offset;
> + u16 linkctrl;
> +
> + if (WARN_ON_ONCE(rcrb == CXL_RESOURCE_NONE))
> + return 0;
> +
> + if (!request_mem_region(rcrb, SZ_4K, dev_name(dev)))
> + return 0;
> +
> + addr = ioremap(rcrb, SZ_4K);
> + if (!addr)
> + goto out;
> +
> + offset = cxl_rcrb_get_pcie_cap_offset(addr);
> + if (offset)
> + dev_dbg(dev, "found PCIe capability (0x%x)\n", offset);
> + else
> + goto out;
> +
> + linkctrl = readw(addr + offset + PCI_EXP_LNKCTL);
> + iounmap(addr);
> +out:
> + release_mem_region(rcrb, SZ_4K);
> +
> + return linkctrl;
There's a lot of duplicated boilerplate here between
cxl_rcrb_to_linkcap(), cxl_rcrb_to_linkctr(),
cxl_rcrb_to_linkstatus().
It also seems like a lot of repeated work to search for the PCIe Cap,
ioremap, tear down, etc., for each file, every time it is read. I
assume most readers will be interested in all three items at the same
time.
> +static umode_t cxl_rcd_visible(struct kobject *kobj,
> + struct attribute *a, int n)
> +{
> + struct device *dev = kobj_to_dev(kobj);
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + if (is_cxl_restricted(pdev))
Not related to *this* patch, but I can't connect the dots between the
"is_cxl_restricted()" name, the meaning of "restricted", and the "CXL
memory expander class code" mentioned in the is_cxl_restricted()
function comment. It doesn't check the "class code". It's not
obvious why this applies to RCiEPs but not other endpoints. No doubt
all obvious to the CXL-initiated, which I am not.
Bjorn
next prev parent reply other threads:[~2024-04-09 14:59 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-12 8:05 [PATCH v3 0/3] Display cxl1.1 device link status Kobayashi,Daisuke
2024-03-12 8:05 ` [PATCH v3 1/3] Add sysfs attribute for CXL 1.1 " Kobayashi,Daisuke
2024-03-26 19:51 ` Dan Williams
2024-03-28 1:47 ` Daisuke Kobayashi (Fujitsu)
2024-04-03 9:40 ` Daisuke Kobayashi (Fujitsu)
2024-04-05 8:31 ` Daisuke Kobayashi (Fujitsu)
2024-04-08 21:43 ` Dan Williams
2024-04-09 4:55 ` Daisuke Kobayashi (Fujitsu)
2024-04-05 17:25 ` Jonathan Cameron
2024-04-08 21:32 ` Dan Williams
2024-04-09 14:59 ` Bjorn Helgaas [this message]
2024-04-09 15:00 ` Bjorn Helgaas
2024-03-12 8:05 ` [PATCH v3 2/3] Remove conditional branch that is not suitable for cxl1.1 devices Kobayashi,Daisuke
2024-03-26 20:00 ` Dan Williams
2024-03-27 8:26 ` Daisuke Kobayashi (Fujitsu)
2024-03-12 8:05 ` [PATCH v3 3/3] Add function to display cxl1.1 device link status Kobayashi,Daisuke
2024-03-26 20:05 ` Dan Williams
2024-03-27 8:27 ` Daisuke Kobayashi (Fujitsu)
2024-03-29 22:23 ` Martin Mareš
2024-03-30 1:15 ` Dan Williams
2024-03-31 1:03 ` Martin Mareš
2024-04-01 17:47 ` Dan Williams
2024-04-02 7:09 ` Daisuke Kobayashi (Fujitsu)
2024-03-25 4:49 ` [PATCH v3 0/3] Display " Daisuke Kobayashi (Fujitsu)
2024-03-26 19:15 ` Dan Williams
2024-03-27 8:24 ` Daisuke Kobayashi (Fujitsu)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240409145933.GA2074336@bhelgaas \
--to=helgaas@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=kobayashi.da-06@fujitsu.com \
--cc=kobayashi.da-06@jp.fujitsu.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mj@ucw.cz \
--cc=y-goto@fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox