From: "Luck, Tony" <tony.luck@intel.com>
To: Jean Delvare <jdelvare@suse.de>, DuanZhenzhong <zhenzhong.duan@oracle.com>
CC: Andrew Morton <akpm@linux-foundation.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        "Yu, Fenghua" <fenghua.yu@intel.com>
Subject: RE: memcpy_fromio in dmi_scan.c
Thread-Topic: memcpy_fromio in dmi_scan.c
Thread-Index: AQHOP/RwacaplR9CdEKkq9gPksW/N5jkWgQA
Date: Tue, 23 Apr 2013 22:00:05 +0000
Message-ID: <3908561D78D1C84285E8C5FCA982C28F1EA52ED3@ORSMSX104.amr.corp.intel.com>
References: <1366636689.4503.35.camel@chaos.site>
	 <5175FF0F.9050206@oracle.com> <1366702122.4667.11.camel@chaos.site>
In-Reply-To: <1366702122.4667.11.camel@chaos.site>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Transfer-Encoding: 8bit
Content-Length: 1062
Lines: 18

> I don't have much knowledge about IA64 either. All I see is that while
> x86 implements memcpy_fromio() with memcpy [1], ia64 implements it with
> readb [2]. There must be a reason for that, and I can only suppose that
> memcpy on __iomem pointers doesn't work on IA64. If memcpy doesn't work
> then I can't see memcmp working.

On most platforms readb() just ends up doing a regular dereference of the
address ... so I'd expect that memcmp would work just fine.  The exception
is the old SGI sn2 which end up calling ___sn_readb() ... which does something
weird with sn_dma_flush() after doing the dereference of *addr.  I don't
really understand what is going on here - but I assume that it is for real
PCI iomapped memory, as opposed to random bits of BIOS reserved memory
that we used ioremap() to get a virtual handle on.

Not sure how to test ... what would I run to exercise this code?

-Tony
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?