From: Dan Williams <dan.j.williams@intel.com>
To: Alan Cox <alan@linux.intel.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Hans de Goede <hdegoede@redhat.com>
Subject: Why do we probe option roms at 2K boundaries?
Date: Wed, 15 Jul 2009 16:02:45 -0700 [thread overview]
Message-ID: <1247698965.3989.1.camel@dwillia2-linux.ch.intel.com> (raw)
Hi Alan,
I developed support for mdadm to enumerate the capabilities of an
Intel(r) Matrix Storage Technology (software RAID) platform by
interrogating a data structure stored in option-rom memory. My initial
implementation involved blindly scanning from c0000 to f0000 in 512 byte
increments. Neil and others pointed out that this may not be a safe
operation, so I decided to grab the kernel's probe_roms() implementation
under the assumption that it is safe by virtue of its exposure.
Recently Hans has been working to get Fedora up and running on a recent
Intel software RAID platform and noticed that the option-rom is no
longer visible with the 2K aligned scan. I.e. he needed to make the
following changes to the mdadm probe_roms() routine:
diff -up mdadm-3.0/probe_roms.c~ mdadm-3.0/probe_roms.c
--- mdadm-3.0/probe_roms.c~ 2009-06-02 07:48:29.000000000 +0200
+++ mdadm-3.0/probe_roms.c 2009-07-13 16:24:21.000000000 +0200
@@ -220,7 +220,7 @@ void probe_roms(void)
/* video rom */
upper = adapter_rom_resources[0].start;
- for (start = video_rom_resource.start; start < upper; start += 2048) {
+ for (start = video_rom_resource.start; start < upper; start += 512) {
rom = isa_bus_to_virt(start);
if (!romsignature(rom))
continue;
@@ -239,7 +239,7 @@ void probe_roms(void)
break;
}
- start = (video_rom_resource.end + 1 + 2047) & ~2047UL;
+ start = (video_rom_resource.end + 1 + 511) & ~511UL;
if (start < upper)
start = upper;
@@ -255,7 +255,7 @@ void probe_roms(void)
}
/* check for adapter roms on 2k boundaries */
- for (i = 0; i < ARRAY_SIZE(adapter_rom_resources) && start < upper; start += 2048) {
+ for (i = 0; i < ARRAY_SIZE(adapter_rom_resources) && start < upper; start += 512) {
rom = isa_bus_to_virt(start);
if (!romsignature(rom))
continue;
@@ -273,7 +273,7 @@ void probe_roms(void)
adapter_rom_resources[i].start = start;
adapter_rom_resources[i].end = start + length - 1;
- start = adapter_rom_resources[i++].end & ~2047UL;
+ start = adapter_rom_resources[i++].end & ~511UL;
}
}
Is this safe? Should the kernel be updated as well? I am assuming that
you were the one that originally introduced the 2K aligned scan with
this commit from the historical git:
commit 3bcbf341ca4e71b93be52eac6f6f5f698c70f0d9
Author: alan <alan>
Date: Tue Apr 8 16:42:23 2003 +0000
[PATCH] add but do not yet use mach specific definitions for ports etc on PC
BKrev: 3e92fbefFSaWWI1bUJHNKOjfyZlfkQ
It was subsequently updated here but the alignment constraints remained
intact.
commit 8cc489a8f5a7aa83ac370480784af0206f2ce57b
Author: akpm <akpm>
Date: Mon Apr 12 21:57:08 2004 +0000
[PATCH] i386 probe_roms(): fixes
From: Rene Herman <rene.herman@keyaccess.nl>
This patch tries to improve the i386/mach-default probe_roms(). This also
c99ifies the data, adds an IORESOURCE_IO flag for the I/O port resources,
an IORESOURCE_MEM flag for the VRAM resource, IORESOURCE_READONLY |
IORESOURCE_MEM for the ROM resources and adds two additional "adapter ROM
slots" (for a total of 6) since it now also scans the 0xe0000 segment.
BKrev: 407b10b4nrXSAT3lFi4Io1Kpp4Q8Jw
Thanks for the help,
Dan
next reply other threads:[~2009-07-15 23:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-15 23:02 Dan Williams [this message]
2009-07-15 23:10 ` Why do we probe option roms at 2K boundaries? Alan Cox
2009-07-15 23:13 ` Jon Smirl
2009-07-16 0:08 ` Dan Williams
2009-07-16 7:24 ` Hans de Goede
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=1247698965.3989.1.camel@dwillia2-linux.ch.intel.com \
--to=dan.j.williams@intel.com \
--cc=alan@linux.intel.com \
--cc=hdegoede@redhat.com \
--cc=linux-kernel@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