linux-kernel - Re: [PATCH 3/3] x86: drop support for 1995 era EISA based platforms

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] [day] [month] [year] [list]

Date:	Tue, 20 Jan 2015 19:50:45 +0000 (GMT)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	the arch/x86 maintainers <x86@...nel.org>
Subject: Re: [PATCH 3/3] x86: drop support for 1995 era EISA based
 platforms

On Tue, 20 Jan 2015, Linus Torvalds wrote:

> >  Well, I'd like to keep my x86 box up and alive, to support EISA FDDI
> > equipment I maintain if nothing else -- which in particular means the
> > current head version of Linux, not some ancient branch.
> 
> So if we actually have a user, and it works, then no, we're not
> removing EISA support. It's not like it hurts us or is in some way
> fundamentally broken, like the old i386 code was (i386 kernel page
> fault semantics really were broken, and the lack of some instructions
> made it more painful to maintain than needed - not like EISA at all,
> which is just a pure add-on on the side).

 Thanks.  Last version I tried was 3.18.0-rc1-next-20141023 sometime last 
November.  It worked just fine, booted to the multiuser mode with no 
issue.  I'll have to refresh the build sometime.

 It's a plain EISA box, no PCI.  The EISA FDDI board referred works fine 
(it uses our DMA API for bus mastering) as does an ISA 3c509B Ethernet 
adapter configured for the EISA mode.  The card supports it -- it looks 
like a true EISA board to software then, there's no need to poke at random 
port I/O locations anymore to detect it -- as does our driver.

 I have a small patch outstanding to reserve the BIOS area at 0xffff0000 
(used at reset as per the x86 architecture definition) so that systems 
that do not support the 0xe820 call do not attempt to allocate MMIO in 
that range.  It may matter for some old PCI systems as well, I suppose.  
I just need to verify it does not cause a conflict with systems that do 
support that call.

 Other than that it seems maintenance-free to me.

  Maciej
--
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/