lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200610190952.22285.jesse.barnes@intel.com>
Date:	Thu, 19 Oct 2006 09:52:21 -0700
From:	Jesse Barnes <jesse.barnes@...el.com>
To:	David Miller <davem@...emloft.net>
Cc:	eiichiro.oiwa.nm@...achi.com, alan@...hat.com, greg@...ah.com,
	linux-kernel@...r.kernel.org
Subject: Re: pci_fixup_video change blows up on sparc64

On Thursday, October 19, 2006 1:37 am, David Miller wrote:
> Also, and more importantly, you cannot use the 0xc0000 address in a
> raw way like this.  There are multiple PCI domains possible in a
> given system, and the 0xc0000 address you wish to use must be
> relative to that PCI domain.
>
> Therefore, in the presence of multiple PCI domains:
>
> 	x = ioremap(0xc0000, ...);
>
> doesn't make any sense, is extremely non-portable, and will crash
> on many non-x86 systems.

Right, I guess we should have been a bit more careful in making this 
code generic.  At least ia64, i386 and x86_64 systems often have video 
BIOSes in system memory at 0xc0000 (note that this isn't in PCI space).  
It sounds like on your system the regular sysfs ROM mapping code should 
be able to see the ROM, and this 0xc0000 mapping/copying shouldn't be 
necessary.

> All of this pci_fixup_video code was perfectly fine when it was only
> used on x86, where assumptions like this happened to work, but it is
> not possible to continue making these assumptions if this code will
> now run on every single architecture.

Maybe we should conditionalize it, making it only available on ia64, 
i386 and x86_64?  Then again, I think there are some embedded platforms 
that could use this code too?

Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ