From: "Krzysztof Wilczyński" <kw@linux.com>
To: "Kobayashi,Daisuke" <kobayashi.da-06@fujitsu.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [RFC PATCH v1] Export PBEC Data register into sysfs
Date: Wed, 10 Jul 2024 20:05:19 +0900 [thread overview]
Message-ID: <20240710110519.GA3949574@rocinante> (raw)
In-Reply-To: <20240626044330.106658-1-kobayashi.da-06@fujitsu.com>
Hello,
[...]
> PCIe devices can significantly impact the overall power consumption of
> a system. However, obtaining PCIe device power consumption information
> has traditionally been difficult. This is because the 'lspci' command,
> which is a standard tool for displaying information about PCI devices,
> cannot access PBEC information. `lspci` is a standard tool for displaying
> information about PCI devices.
Will you also be making changes to the pciutils project to expose this
using the lspci utility?
That said, we already expose "config" sysfs object, would using it work to
obtain the data you need?
> +static ssize_t pbec_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct pci_dev *pci_dev = to_pci_dev(dev);
> + size_t len = 0;
> + int i, pos;
> + u32 data;
> +
> + if (!pci_is_pcie(pci_dev))
> + return 0;
This is not needed, I believe the "is_visible" callback for this specific
attributes group checks for this already.
> + pos = pci_find_ext_capability(pci_dev, PCI_EXT_CAP_ID_PWR);
> + if (!pos)
> + return 0;
It would be -EINVAL, customarily. I suppose, the -ENOTSUPP or -ENOSYS could
do too, but most of the other PCI sysfs objects returns -EINVAL back to the
userspace to indicate that something is wrong.
> + for (i = 0; i < 0xff; i++) {
Does this 0xff need to be documented? Something specific to the PBEC feature?
> + pci_write_config_byte(pci_dev, pos + PCI_PWR_DSR, (u8)i);
> + pci_read_config_dword(pci_dev, pos + PCI_PWR_DATA, &data);
> + if (!data)
> + break;
We should return an error here, something like -EINVAL perhaps.
> + len += sysfs_emit_at(buf, len, "%04x\n", data);
> + }
> +
> + return len;
How frequently do you think this new sysfs object would be accessed? It's
not uncommon for the PCI configuration space access to be slow for some
devices.
Thank you!
Krzysztof
next prev parent reply other threads:[~2024-07-10 11:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-26 4:43 [RFC PATCH v1] Export PBEC Data register into sysfs Kobayashi,Daisuke
2024-07-10 8:22 ` Daisuke Kobayashi (Fujitsu)
2024-07-10 11:06 ` Krzysztof Wilczyński
2024-07-10 11:05 ` Krzysztof Wilczyński [this message]
2024-07-16 7:04 ` Daisuke Kobayashi (Fujitsu)
2024-08-29 8:03 ` Daisuke Kobayashi (Fujitsu)
2024-09-02 17:28 ` 'Krzysztof Wilczyński'
2024-09-03 7:55 ` Daisuke Kobayashi (Fujitsu)
2024-07-10 12:28 ` Bjorn Helgaas
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=20240710110519.GA3949574@rocinante \
--to=kw@linux.com \
--cc=kobayashi.da-06@fujitsu.com \
--cc=linux-pci@vger.kernel.org \
/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