All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@engr.sgi.com>
To: linux-pci@atrey.karlin.mff.cuni.cz
Cc: Matthew Wilcox <willy@debian.org>,
	Christoph Hellwig <hch@infradead.org>,
	Jon Smirl <jonsmirl@yahoo.com>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: Exposing ROM's though sysfs
Date: Fri, 30 Jul 2004 11:49:39 -0700	[thread overview]
Message-ID: <200407301149.39256.jbarnes@engr.sgi.com> (raw)
In-Reply-To: <200407301112.10361.jbarnes@engr.sgi.com>

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

On Friday, July 30, 2004 11:12 am, Jesse Barnes wrote:
> On Friday, July 30, 2004 11:12 am, Matthew Wilcox wrote:
> > How about reading the contents of the ROM at pci_scan_bus() time?  It'd
> > waste a bunch of memory, but hey, people love sysfs.
>
> That might be a good solution, actually.  Then it would be cached for
> devices that don't want you to look at it after they've been POSTed too.

Here's a version that actually works, but without the caching (i.e. don't 
access it after a driver starts using the card).  If we go that route, should 
we hang a copy of the ROM off of the pci_dev in a pointer or somewhere else?

Thanks,
Jesse

[-- Attachment #2: pci-sysfs-rom-3.patch --]
[-- Type: text/plain, Size: 2222 bytes --]

===== drivers/pci/pci-sysfs.c 1.10 vs edited =====
--- 1.10/drivers/pci/pci-sysfs.c	2004-06-04 06:23:04 -07:00
+++ edited/drivers/pci/pci-sysfs.c	2004-07-30 11:47:26 -07:00
@@ -164,6 +164,60 @@
 	return count;
 }
 
+static void
+pci_enable_rom(struct pci_dev *dev)
+{
+	u32 rom_addr;
+
+	pci_read_config_dword(dev, PCI_ROM_ADDRESS, &rom_addr);
+	rom_addr |= PCI_ROM_ADDRESS_ENABLE;
+	pci_write_config_dword(dev, PCI_ROM_ADDRESS, rom_addr);
+}
+
+static void
+pci_disable_rom(struct pci_dev *dev)
+{
+	u32 rom_addr;
+
+	pci_read_config_dword(dev, PCI_ROM_ADDRESS, &rom_addr);
+	rom_addr &= ~PCI_ROM_ADDRESS_ENABLE;
+	pci_write_config_dword(dev, PCI_ROM_ADDRESS, rom_addr);
+}
+
+static ssize_t
+pci_read_rom(struct kobject *kobj, char *buf, loff_t off, size_t count)
+{
+	struct pci_dev *dev = to_pci_dev(container_of(kobj,struct device,kobj));
+	loff_t init_off = off;
+	unsigned long start = pci_resource_start(dev, PCI_ROM_RESOURCE);
+	int size = pci_resource_len(dev, PCI_ROM_RESOURCE);
+
+	if (off > size)
+		return 0;
+	if (off + count > size) {
+		size -= off;
+		count = size;
+	} else {
+		size = count;
+	}
+
+	/* Enable ROM space decodes and do the reads */
+	pci_enable_rom(dev);
+
+	while (size > 0) {
+		unsigned char val;
+		val = readb(start + off);
+		buf[off - init_off] = val;
+		off++;
+		--size;
+	}
+
+	/* Disable again before continuing */
+	pci_disable_rom(dev);
+
+	return count;
+}
+
 static struct bin_attribute pci_config_attr = {
 	.attr =	{
 		.name = "config",
@@ -186,12 +240,27 @@
 	.write = pci_write_config,
 };
 
+static struct bin_attribute pci_rom_attr = {
+	.attr =	{
+		.name = "rom",
+		.mode = S_IRUSR,
+		.owner = THIS_MODULE,
+	},
+	.read = pci_read_rom,
+};
+
 void pci_create_sysfs_dev_files (struct pci_dev *pdev)
 {
 	if (pdev->cfg_size < 4096)
 		sysfs_create_bin_file(&pdev->dev.kobj, &pci_config_attr);
 	else
 		sysfs_create_bin_file(&pdev->dev.kobj, &pcie_config_attr);
+
+	/* If the device has a ROM, map it */
+	if (pci_resource_len(pdev, PCI_ROM_RESOURCE)) {
+		pci_rom_attr.size = pci_resource_len(pdev, PCI_ROM_RESOURCE);
+		sysfs_create_bin_file(&pdev->dev.kobj, &pci_rom_attr);
+	}
 
 	/* add platform-specific attributes */
 	pcibios_add_platform_entries(pdev);

  parent reply	other threads:[~2004-07-30 18:55 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-30 16:53 Exposing ROM's though sysfs Jon Smirl
2004-07-30 17:10 ` Jesse Barnes
2004-07-30 17:19   ` Jesse Barnes
2004-07-30 17:24   ` Christoph Hellwig
2004-07-30 17:57     ` Jesse Barnes
2004-07-30 18:06       ` Jesse Barnes
2004-07-30 18:12       ` Matthew Wilcox
2004-07-30 18:12         ` Jesse Barnes
2004-07-30 18:20           ` Martin Mares
2004-07-30 18:49           ` Jesse Barnes [this message]
2004-07-30 19:55             ` Greg KH
2004-07-30 20:05               ` Jon Smirl
2004-07-30 20:16               ` Jesse Barnes
2004-07-30 20:29                 ` Greg KH
2004-07-30 18:59         ` Jon Smirl
2004-07-30 19:04           ` Matthew Wilcox
2004-07-30 19:30             ` Jon Smirl
2004-07-30 19:35               ` Martin Mares
2004-07-30 19:39                 ` Jon Smirl
2004-07-30 19:46                   ` Martin Mares
2004-07-30 20:03                     ` Jon Smirl
2004-07-30 20:10                       ` Martin Mares
2004-07-30 20:13                         ` Martin Mares
2004-07-30 20:25                           ` Jesse Barnes
2004-07-30 20:32                         ` Jon Smirl
2004-07-30 20:41                           ` Martin Mares
2004-07-30 20:49                             ` Jesse Barnes
2004-07-30 20:54                               ` Martin Mares
2004-07-30 21:00                                 ` Jesse Barnes
2004-07-30 21:07                               ` Jon Smirl
2004-07-30 21:12                                 ` Jesse Barnes
2004-07-30 19:47               ` Vojtech Pavlik
2004-07-30 22:18             ` Thomas Bogendoerfer
2004-07-30 22:39         ` Alan Cox
2004-07-30 19:25   ` Jon Smirl
2004-07-30 19:35     ` Vojtech Pavlik
2004-07-30 19:41       ` Jon Smirl
2004-07-30 19:48         ` Vojtech Pavlik
2004-07-30 20:20           ` Jesse Barnes
2004-07-30 22:41             ` Alan Cox
     [not found] <1091207136.2762.181.camel@rohan.arnor.net>
2004-07-30 17:24 ` Jon Smirl
2004-07-30 19:14   ` Vojtech Pavlik
2004-07-30 20:26     ` Jesse Barnes
2004-07-30 22:36       ` Alan Cox
2004-08-03 21:41         ` Benjamin Herrenschmidt
2004-08-04  0:55           ` Jesse Barnes
2004-08-04  0:59             ` Benjamin Herrenschmidt
2004-08-04  1:37               ` Jon Smirl
2004-08-04  1:57                 ` Benjamin Herrenschmidt
2004-08-04  2:16                   ` Jesse Barnes

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=200407301149.39256.jbarnes@engr.sgi.com \
    --to=jbarnes@engr.sgi.com \
    --cc=hch@infradead.org \
    --cc=jonsmirl@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=willy@debian.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 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.