From: Greg KH <greg@kroah.com>
To: linux-usb-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] USB and Driver Core patches for 2.6.10
Date: Fri, 7 Jan 2005 21:47:42 -0800 [thread overview]
Message-ID: <11051632624000@kroah.com> (raw)
In-Reply-To: <11051632623844@kroah.com>
ChangeSet 1.1938.444.27, 2004/12/21 12:12:05-08:00, jbarnes@engr.sgi.com
[PATCH] PCI: export PCI resources in sysfs
This patch exports PCI resources to userspace in the corresponding sysfs
device directory. It depends on the platform HAVE_PCI_MMAP code, and is
#ifdef'd accordingly. I've also added documentation describing the sysfs PCI
device file layout.
Signed-off-by: Jesse Barnes <jbarnes@sgi.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Documentation/filesystems/sysfs-pci.txt | 64 ++++++++++++++++++++++
drivers/pci/pci-sysfs.c | 92 ++++++++++++++++++++++++++++++++
include/linux/pci.h | 1
3 files changed, 157 insertions(+)
diff -Nru a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/Documentation/filesystems/sysfs-pci.txt 2005-01-07 15:40:39 -08:00
@@ -0,0 +1,64 @@
+Accessing PCI device resources through sysfs
+
+sysfs, usually mounted at /sys, provides access to PCI resources on platforms
+that support it. For example, a given bus might look like this:
+
+ pci0000:17
+ |-- 0000:17:00.0
+ | |-- class
+ | |-- config
+ | |-- detach_state
+ | |-- device
+ | |-- irq
+ | |-- local_cpus
+ | |-- resource
+ | |-- resource0
+ | |-- resource1
+ | |-- resource2
+ | |-- rom
+ | |-- subsystem_device
+ | |-- subsystem_vendor
+ | `-- vendor
+ `-- detach_state
+
+The topmost element describes the PCI domain and bus number. In this case,
+the domain number is 0000 and the bus number is 17 (both values are in hex).
+This bus contains a single function device in slot 0. The domain and bus
+numbers are reproduced for convenience. Under the device directory are several
+files, each with their own function.
+
+ file function
+ ---- --------
+ class PCI class (ascii, ro)
+ config PCI config space (binary, rw)
+ detach_state connection status (bool, rw)
+ device PCI device (ascii, ro)
+ irq IRQ number (ascii, ro)
+ local_cpus nearby CPU mask (cpumask, ro)
+ resource PCI resource host addresses (ascii, ro)
+ resource0..N PCI resource N, if present (binary, mmap)
+ rom PCI ROM resource, if present (binary, ro)
+ subsystem_device PCI subsystem device (ascii, ro)
+ subsystem_vendor PCI subsystem vendor (ascii, ro)
+ vendor PCI vendor (ascii, ro)
+
+ ro - read only file
+ rw - file is readable and writable
+ mmap - file is mmapable
+ ascii - file contains ascii text
+ binary - file contains binary data
+ cpumask - file contains a cpumask type
+
+The read only files are informational, writes to them will be ignored.
+Writable files can be used to perform actions on the device (e.g. changing
+config space, detaching a device). mmapable files are available via an
+mmap of the file at offset 0 and can be used to do actual device programming
+from userspace. Note that some platforms don't support mmapping of certain
+resources, so be sure to check the return value from any attempted mmap.
+
+Supporting PCI access on new platforms
+
+In order to support PCI resource mapping as described above, Linux platform
+code must define HAVE_PCI_MMAP and provide a pci_mmap_page_range function.
+Platforms are free to only support subsets of the mmap functionality, but
+useful return codes should be provided.
diff -Nru a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
--- a/drivers/pci/pci-sysfs.c 2005-01-07 15:40:39 -08:00
+++ b/drivers/pci/pci-sysfs.c 2005-01-07 15:40:39 -08:00
@@ -20,6 +20,7 @@
#include <linux/pci.h>
#include <linux/stat.h>
#include <linux/topology.h>
+#include <linux/mm.h>
#include "pci.h"
@@ -178,6 +179,93 @@
return count;
}
+#ifdef HAVE_PCI_MMAP
+/**
+ * pci_mmap_resource - map a PCI resource into user memory space
+ * @kobj: kobject for mapping
+ * @attr: struct bin_attribute for the file being mapped
+ * @vma: struct vm_area_struct passed into the mmap
+ *
+ * Use the regular PCI mapping routines to map a PCI resource into userspace.
+ * FIXME: write combining? maybe automatic for prefetchable regions?
+ */
+static int
+pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr,
+ struct vm_area_struct *vma)
+{
+ struct pci_dev *pdev = to_pci_dev(container_of(kobj,
+ struct device, kobj));
+ struct resource *res = (struct resource *)attr->private;
+ enum pci_mmap_state mmap_type;
+
+ vma->vm_pgoff += res->start >> PAGE_SHIFT;
+ mmap_type = res->flags & IORESOURCE_MEM ? pci_mmap_mem : pci_mmap_io;
+
+ return pci_mmap_page_range(pdev, vma, mmap_type, 0);
+}
+
+/**
+ * pci_create_resource_files - create resource files in sysfs for @dev
+ * @dev: dev in question
+ *
+ * Walk the resources in @dev creating files for each resource available.
+ */
+static void
+pci_create_resource_files(struct pci_dev *pdev)
+{
+ int i;
+
+ /* Expose the PCI resources from this device as files */
+ for (i = 0; i < PCI_ROM_RESOURCE; i++) {
+ struct bin_attribute *res_attr;
+
+ /* skip empty resources */
+ if (!pci_resource_len(pdev, i))
+ continue;
+
+ res_attr = kmalloc(sizeof(*res_attr) + 10, GFP_ATOMIC);
+ if (res_attr) {
+ pdev->res_attr[i] = res_attr;
+ /* Allocated above after the res_attr struct */
+ res_attr->attr.name = (char *)(res_attr + 1);
+ sprintf(res_attr->attr.name, "resource%d", i);
+ res_attr->size = pci_resource_len(pdev, i);
+ res_attr->attr.mode = S_IRUSR | S_IWUSR;
+ res_attr->attr.owner = THIS_MODULE;
+ res_attr->mmap = pci_mmap_resource;
+ res_attr->private = &pdev->resource[i];
+ sysfs_create_bin_file(&pdev->dev.kobj, res_attr);
+ }
+ }
+}
+
+/**
+ * pci_remove_resource_files - cleanup resource files
+ * @dev: dev to cleanup
+ *
+ * If we created resource files for @dev, remove them from sysfs and
+ * free their resources.
+ */
+static void
+pci_remove_resource_files(struct pci_dev *pdev)
+{
+ int i;
+
+ for (i = 0; i < PCI_ROM_RESOURCE; i++) {
+ struct bin_attribute *res_attr;
+
+ res_attr = pdev->res_attr[i];
+ if (res_attr) {
+ sysfs_remove_bin_file(&pdev->dev.kobj, res_attr);
+ kfree(res_attr);
+ }
+ }
+}
+#else /* !HAVE_PCI_MMAP */
+static inline void pci_create_resource_files(struct pci_dev *dev) { return; }
+static inline void pci_remove_resource_files(struct pci_dev *dev) { return; }
+#endif /* HAVE_PCI_MMAP */
+
/**
* pci_write_rom - used to enable access to the PCI ROM display
* @kobj: kernel object handle
@@ -269,6 +357,8 @@
else
sysfs_create_bin_file(&pdev->dev.kobj, &pcie_config_attr);
+ pci_create_resource_files(pdev);
+
/* If the device has a ROM, try to expose it in sysfs. */
if (pci_resource_len(pdev, PCI_ROM_RESOURCE)) {
struct bin_attribute *rom_attr;
@@ -303,6 +393,8 @@
sysfs_remove_bin_file(&pdev->dev.kobj, &pci_config_attr);
else
sysfs_remove_bin_file(&pdev->dev.kobj, &pcie_config_attr);
+
+ pci_remove_resource_files(pdev);
if (pci_resource_len(pdev, PCI_ROM_RESOURCE)) {
if (pdev->rom_attr) {
diff -Nru a/include/linux/pci.h b/include/linux/pci.h
--- a/include/linux/pci.h 2005-01-07 15:40:39 -08:00
+++ b/include/linux/pci.h 2005-01-07 15:40:39 -08:00
@@ -539,6 +539,7 @@
u32 saved_config_space[16]; /* config space saved at suspend time */
struct bin_attribute *rom_attr; /* attribute descriptor for sysfs ROM entry */
int rom_attr_enabled; /* has display of the rom attribute been enabled? */
+ struct bin_attribute *res_attr[DEVICE_COUNT_RESOURCE]; /* sysfs file for resources */
#ifdef CONFIG_PCI_NAMES
#define PCI_NAME_SIZE 96
#define PCI_NAME_HALF __stringify(43) /* less than half to handle slop */
next prev parent reply other threads:[~2005-01-08 7:58 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-08 5:46 [BK PATCH] USB and Driver Core patches for 2.6.10 Greg KH
2005-01-08 5:47 ` [PATCH] " Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH [this message]
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 5:47 ` Greg KH
2005-01-08 12:08 ` Christoph Hellwig
2005-01-08 22:42 ` Greg KH
2005-01-08 23:33 ` Alessandro Suardi
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=11051632624000@kroah.com \
--to=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.