linux-kernel - Re: [PATCH] restore libata build on frv

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]

Date:	Mon, 25 Sep 2006 16:45:38 +0100
From:	David Howells <dhowells@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Al Viro <viro@....linux.org.uk>,
	David Howells <dhowells@...hat.com>,
	Linus Torvalds <torvalds@...l.org>,
	Jeff Garzik <jgarzik@...ox.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] restore libata build on frv 

Alan Cox <alan@...rguk.ukuu.org.uk> wrote:

> > Fine by me.  In that case we need to add
> > 	depends on !FRV || BROKEN
> > to drivers/ata/Kconfig and be done with that.  BTW, empty libata-portmap.h
> > is equivalent to absent one - it still won't build.
> 
> From every public piece of info I can find and from looking at the FRV
> tree your changes are correct for the ports Al. I can't find any info on
> how legacy IRQ routing is done on FRV systems but if it is not then set
> the IRQ values to zero and maybe Dave will stop complaining.

Sigh.

On FRV, inX() and outX() take fully qualified memory-space addresses, exactly
as readX() and writeX() (in/out just wrap readX/writeX).  This is because:

 (1) The FRV has a limited number of static mappings, and these have to specify
     _all_ access windows to I/O, RAM, ROM, etc.  The FRV arch uses a single
     mapping to handle *all* I/O (which happens to be through the region from
     0xE0000000 to 0xFFFFFFFF) thus allowing it to use the remaining mappings
     for other purposes.

 (2) inX() and outX() would have to adjust the addresses to otherwise make
     them appear PC compatible.  Making in() and out() just pass the addresses
     straight through means I don't have to do any calculation on the address
     in order to use it.

inb(0x1F0) will, for example, oops because there's no mapping for the bottom
virtual megabyte to anywhere, otherwise NULL pointer detection would not be
possible.

Don't forget, also, that things like FRV systems generally _won't_ have
pluggable PCI buses, and so any devices attached to it will be known in
advance, and generalisations can be waived.

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