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: <200703161120.46123.bjorn.helgaas@hp.com>
Date:	Fri, 16 Mar 2007 11:20:44 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Jesse Barnes <jesse.barnes@...el.com>
Cc:	eiichiro.oiwa.nm@...achi.com, akpm@...l.org, tony.luck@...el.com,
	greg@...ah.com, "Alan Cox" <alan@...rguk.ukuu.org.uk>,
	linux-ia64@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.18] PCI: Turn pci_fixup_video into generic for embedded VGA

On Thursday 28 September 2006 10:36, Jesse Barnes wrote:
> On Wednesday, September 27, 2006 9:55 pm, eiichiro.oiwa.nm@...achi.com 
> wrote:
> > pci_fixup_video turns into generic code because there are many platforms
> > need this fixup for embedded VGA as well as x86. The Video BIOS
> > integrates into System BIOS on a machine has embedded VGA although
> > embedded VGA generally don't have PCI ROM. As a result, embedded VGA
> > need the way that the sysfs rom points to the Video BIOS of System RAM
> > (0xC0000). PCI-to-PCI Bridge Architecture specification describes the
> > condition whether or not PCI ROM forwards VGA compatible memory address.
> > fixup_video suits this specification. Although the Video ROM generally
> > implements in x86 code regardless of platform, some application such as
> > X Window System can run this code by dosemu86. Therefore,
> > pci_fixup_video should turn into generic code.
> ... 
> Thanks a lot, Eiichiro, this patch has been needed for awhile.

Are there really ia64 machines where we need to use the option ROM
copy at 0xC0000?  If so, is this documented somewhere?  I couldn't
find any mention in DIG64, EFI, or internal HP architecture specs.

If we do need to use it, ia64 has a bit of a problem because on some
boxes, the 0xC0000 memory supports only cacheable access, the VGA
frame buffer at 0xA0000 supports only uncacheable access, and the
usual ia64 ioremap mapping is a 16MB page that covers both.

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