From: "Benjamin Herrenschmidt" <benh@kernel.crashing.org>
To: "Pete Zaitcev" <zaitcev@redhat.com>
Cc: <andre@linux-ide.org>, <linux-kernel@vger.kernel.org>,
<axboe@suse.de>, <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] fix ide-iops for big endian archs
Date: Thu, 26 Sep 2002 00:48:39 +0200 [thread overview]
Message-ID: <20020925224839.24517@192.168.4.1> (raw)
In-Reply-To: <20020925141946.A14230@devserv.devel.redhat.com>
>> Curently in 2.5 (afaik in -ac too), the ide-iops "s" routines used
>> to transfer datas in/out the data port are incorrect for big endian
>> machines. They are implemented with a loop of inw/outw which are
>> byteswapping, but a fifo transfer like that mustn't be swapped.
>
>Dunno about ppc, but sparc works just fine as it is in 2.4.
>When was the last time you examined include/asm-sparc/ide.h?
I'm talking about 2.4-ac with the new IDE code, not Marcelo
2.4.
>IDE uses ide_insw instead of plain insw specifically to
>resolve this kind of issue, and you are trying to defeat
>the mechanism designed to help you. I smell a fish here.
Again, I'm talking about the new layer. In this, the iops
functions are no longer macros defined by include/asm*/ide.h,
but are now function pointers inside the hwif structure
(so we can now deal with real MMIO or CPU register based IDE
without playing macro tricks in asm*/ide.h).
The problem resides in the default implementation of those
iops in the new ide-iops.c file, which currently re-implements
insw as a loop of IN_WORD, which usually translates to inw,
and thus would cause incorrect endianness.
My patch fixes that. Ultimately, we want to completely get
rid of the uppercase {IN,OUT}{BYTE,WORD,LONG} macros though.
The principle is that ide-iops.c will provide reasonable
"default" ops for PIO (and MMIO if my next patch gets in),
any "different" interface can provide it's own ops, and you
keep the ability to mix different kind of interfaces on the
same machine (like an embeded CPU-register based interface
_and_ a PCI based interface using different iops).
Ben.
next prev parent reply other threads:[~2002-09-26 9:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1032957359.10217.linux-kernel2news@redhat.com>
2002-09-25 18:19 ` [PATCH] fix ide-iops for big endian archs Pete Zaitcev
2002-09-25 19:57 ` David S. Miller
2002-09-25 22:49 ` Benjamin Herrenschmidt
2002-09-25 22:48 ` Benjamin Herrenschmidt [this message]
2002-09-25 12:32 Benjamin Herrenschmidt
2002-09-25 18:22 ` Linus Torvalds
2002-09-25 22:44 ` Benjamin Herrenschmidt
2002-09-26 15:11 ` Alan Cox
2002-09-26 15:16 ` Benjamin Herrenschmidt
2002-09-26 16:04 ` Benjamin Herrenschmidt
2002-09-26 15:09 ` Alan Cox
2002-09-26 15:14 ` Benjamin Herrenschmidt
2002-09-26 20:58 ` Richard Zidlicky
2002-09-26 21:03 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020925224839.24517@192.168.4.1 \
--to=benh@kernel.crashing.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andre@linux-ide.org \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=zaitcev@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).