From: Martin Mares <mj@ucw.cz>
To: Jon Smirl <jonsmirl@yahoo.com>
Cc: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
Greg KH <greg@kroah.com>, Jesse Barnes <jbarnes@engr.sgi.com>,
linux-pci@atrey.karlin.mff.cuni.cz,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Petr Vandrovec <VANDROVE@vc.cvut.cz>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH] add PCI ROMs to sysfs
Date: Fri, 13 Aug 2004 20:17:25 +0200 [thread overview]
Message-ID: <20040813181725.GD5685@ucw.cz> (raw)
In-Reply-To: <20040812022229.23100.qmail@web14929.mail.yahoo.com>
Hello!
Just a couple of notes about your patch:
+unsigned char *
+pci_map_rom(struct pci_dev *dev, size_t *size) {
+ struct resource *res = &dev->resource[PCI_ROM_RESOURCE];
+ loff_t start;
+ unsigned char *rom;
+
+ if (res->flags & PCI_ROM_SHADOW) { /* PCI_ROM_SHADOW only set on x86 */
+ start = (loff_t)0xC0000; /* primary video rom always starts here */
+ *size = 0x20000; /* cover C000:0 through E000:0 */
Shouldn't we do this only if we find that the device has a ROM resource?
+ } else if (res->flags & PCI_ROM_COPY) {
+ *size = pci_resource_len(dev, PCI_ROM_RESOURCE);
+ return (unsigned char *)pci_resource_start(dev, PCI_ROM_RESOURCE);
+ } else {
+ start = pci_resource_start(dev, PCI_ROM_RESOURCE);
+ *size = pci_resource_len(dev, PCI_ROM_RESOURCE);
+ if (*size == 0)
+ return NULL;
+
+ /* Enable ROM space decodes */
+ pci_enable_rom(dev);
+ }
This seems to be wrong -- before enabling a resource, you must call
request_resource() on it and make sure that the ROM (1) has an address
allocated, and (2) the address is not used by anything else.
+ /* If the device has a ROM, try to expose it in sysfs. */
+ if (pci_resource_len(pdev, PCI_ROM_RESOURCE)) {
+ unsigned char *rom;
+ struct bin_attribute *rom_attr;
+
+ pdev->rom_attr = NULL;
+ rom_attr = kmalloc(sizeof(*rom_attr), GFP_ATOMIC);
+ if (rom_attr) {
+ /* set default size */
+ rom_attr->size = pci_resource_len(pdev, PCI_ROM_RESOURCE);
+ /* get true size if possible */
+ rom = pci_map_rom(pdev, &rom_attr->size);
As we can never be sure about the decoder sharing, it is very wise not to
touch the ROM BAR until somebody accesses the sysfs file. Using size according
to the PCI config space (i.e., the resource) does not harm anybody.
+ if (dev->hdr_type == PCI_HEADER_TYPE_NORMAL) {
+ res = &dev->resource[PCI_ROM_RESOURCE];
+ if (res->flags & PCI_ROM_COPY) {
+ kfree((void*)res->start);
+ res->flags &= !PCI_ROM_COPY;
~, not !
+ res->start = 0;
+ res->end = 0;
+ }
+ }
This should better be handled in a separate function in the same source
file as the rest of the ROM handling code.
Also, what about ROMs in the other header types? Wouldn't it be better to
scan all resources for the COPY flag instead?
#define PCI_SUBSYSTEM_ID 0x2e
#define PCI_ROM_ADDRESS 0x30 /* Bits 31..11 are address, 10..1 reserved */
#define PCI_ROM_ADDRESS_ENABLE 0x01
+#define PCI_ROM_SHADOW 0x02 /* resource flag, ROM is copy at C000:0 */
+#define PCI_ROM_COPY 0x04 /* resource flag, ROM is alloc'd copy */
#define PCI_ROM_ADDRESS_MASK (~0x7ffUL)
This does not belong here! This part of pci.h describes the configuration
space, not stuff internal to the kernel. Better introduce a new resource
flag in <linux/ioport.h>.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"Oh no, not again!" -- The bowl of petunias
next prev parent reply other threads:[~2004-08-13 18:17 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-11 23:27 [PATCH] add PCI ROMs to sysfs Pallipadi, Venkatesh
2004-08-12 0:22 ` Jon Smirl
2004-08-12 2:22 ` Jon Smirl
2004-08-13 18:17 ` Martin Mares [this message]
2004-08-14 5:34 ` Jon Smirl
2004-08-14 9:47 ` Martin Mares
2004-08-14 14:17 ` Jon Smirl
2004-08-14 22:10 ` Martin Mares
2004-08-14 23:39 ` Jon Smirl
2004-08-18 18:13 ` Jon Smirl
2004-08-18 18:37 ` Jesse Barnes
2004-08-23 22:51 ` Greg KH
2004-08-25 17:32 ` Jon Smirl
2004-08-25 17:42 ` Greg KH
2004-08-25 18:06 ` Jon Smirl
2004-08-25 18:19 ` Greg KH
2004-08-25 18:45 ` Jon Smirl
2004-08-25 18:55 ` Greg KH
2004-08-25 20:06 ` Jon Smirl
2004-08-26 13:13 ` Matthew Wilcox
2004-08-26 15:40 ` Jon Smirl
2004-08-26 15:58 ` Matthew Wilcox
2004-08-26 19:54 ` Jon Smirl
2004-08-28 16:15 ` Matthew Wilcox
2004-08-28 17:33 ` Jon Smirl
2004-08-28 17:38 ` Jon Smirl
2004-08-27 16:43 ` Matthew Wilcox
2004-08-27 22:29 ` Jon Smirl
2004-08-28 16:35 ` Matthew Wilcox
2004-08-28 21:53 ` Grant Grundler
2004-08-25 18:29 ` Matthew Wilcox
2004-08-19 12:51 ` Alan Cox
2004-08-19 23:00 ` Jon Smirl
2004-08-19 14:01 ` Martin Mares
2004-08-19 23:11 ` Jon Smirl
2004-08-20 10:26 ` Martin Mares
2004-08-25 15:36 ` Matthew Wilcox
2004-08-25 15:50 ` Jon Smirl
-- strict thread matches above, loose matches on Subject: below --
2004-09-08 3:15 Jon Smirl
2004-09-08 6:07 ` Greg KH
2004-09-08 23:50 ` Greg KH
2004-10-08 2:20 ` Jon Smirl
2004-11-05 23:06 ` Greg KH
2004-09-03 1:40 Jon Smirl
2004-09-03 17:27 ` Jesse Barnes
2004-09-03 17:45 ` Jesse Barnes
2004-09-03 18:06 ` Jesse Barnes
2004-08-29 4:58 Jon Smirl
2004-08-12 8:39 Thomas Winischhofer
2004-08-04 15:57 Petr Vandrovec
2004-08-04 17:06 ` Jesse Barnes
2004-08-05 1:38 ` Jon Smirl
2004-07-30 21:09 Jesse Barnes
2004-07-30 21:29 ` Greg KH
2004-07-30 21:34 ` Jesse Barnes
2004-07-30 21:39 ` Greg KH
2004-07-30 21:48 ` Jesse Barnes
2004-07-30 22:15 ` Jon Smirl
2004-07-31 15:59 ` Jesse Barnes
2004-08-02 17:02 ` Jesse Barnes
2004-08-02 17:29 ` Jon Smirl
2004-08-02 21:00 ` Jon Smirl
2004-08-02 21:05 ` Jesse Barnes
2004-08-02 23:32 ` Alan Cox
2004-08-02 23:30 ` Alan Cox
2004-08-03 2:03 ` Jesse Barnes
2004-08-03 2:32 ` Jon Smirl
2004-08-03 17:07 ` Jesse Barnes
2004-08-03 21:19 ` Jon Smirl
2004-08-03 21:28 ` Jesse Barnes
2004-08-03 21:30 ` Jesse Barnes
2004-08-03 21:31 ` Martin Mares
2004-08-03 21:36 ` Jon Smirl
2004-08-03 21:39 ` Martin Mares
2004-08-05 5:05 ` Jon Smirl
2004-08-05 5:41 ` Benjamin Herrenschmidt
2004-08-05 11:53 ` Jon Smirl
2004-08-05 15:54 ` Jesse Barnes
2004-08-05 16:25 ` Jesse Barnes
2004-08-05 20:45 ` Jon Smirl
2004-08-05 21:12 ` Jesse Barnes
2004-08-06 21:14 ` Jon Smirl
2004-08-06 22:33 ` Jesse Barnes
2004-08-11 17:04 ` Jesse Barnes
2004-08-11 17:28 ` Greg KH
2004-08-11 18:02 ` Jesse Barnes
2004-08-11 18:12 ` Greg KH
2004-08-12 1:28 ` Marcelo Tosatti
2004-08-12 14:38 ` Jesse Barnes
2004-08-12 17:29 ` Greg KH
2004-08-12 2:25 ` Miles Bader
2004-08-12 4:38 ` Greg KH
2004-08-12 9:18 ` Geert Uytterhoeven
2004-08-12 22:01 ` Matthew Wilcox
2004-08-11 19:24 ` Jon Smirl
2004-08-11 19:44 ` Jesse Barnes
2004-08-11 20:11 ` Alan Cox
2004-08-11 23:31 ` Jon Smirl
2004-08-12 11:51 ` Alan Cox
2004-08-12 20:28 ` Jon Smirl
2004-08-12 0:45 ` Jon Smirl
2004-08-12 4:37 ` Greg KH
2004-08-04 6:08 ` Jon Smirl
2004-08-04 15:56 ` Jesse Barnes
2004-07-30 21:53 ` Jon Smirl
2004-07-31 10:03 ` Vojtech Pavlik
2004-07-31 13:28 ` Jon Smirl
2004-07-31 15:42 ` Greg KH
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=20040813181725.GD5685@ucw.cz \
--to=mj@ucw.cz \
--cc=VANDROVE@vc.cvut.cz \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=benh@kernel.crashing.org \
--cc=greg@kroah.com \
--cc=jbarnes@engr.sgi.com \
--cc=jonsmirl@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=venkatesh.pallipadi@intel.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