All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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 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.