linux-kernel - Re: [PATCH 3/4] Fix remaining big endian issue of hfcmulti

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:	Tue, 5 Aug 2008 11:42:56 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Karsten Keil <kkeil@...e.de>
cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	linux-kernel@...r.kernel.org, isdn4linux@...tserv.isdn4linux.de,
	"Andreas.Eversberg" <Andreas.Eversberg@...satel.de>
Subject: Re: [PATCH 3/4] Fix remaining big endian issue of hfcmulti

On Tue, 5 Aug 2008, Karsten Keil wrote:
> 
> Maybe we can use the trick from lib/iomap.c to detect which
> kind of IO is needed, but unfortunately PIO_OFFSET, PIO_MASK and
> PIO_RESERVED are not exported so it would need to copy the defines, which
> isn't a really clean solution.

Even if they were exported, you couldn't.

lib/iomap.c is _not_ generic code. It's a library function for 
architectures that don't do it some other way. But various architectures 
can choose to not use lib/iomap.c at all - for example, they may have MMIO 
and PIO in the same address space, so they don't need the conditionals at 
all (because all the work was done at mapping time, not at runtime).

So if you actually have different models of operation for PIO and MMIO, 
then yes, you need to handle that in the driver itself.

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