From: Momchil Velikov <velco@fadata.bg>
To: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Cc: Paul Mackerras <paulus@linuxcare.com>,
Cort Dougan <cort@fsmlabs.com>,
Benjamin Herrenschmidt <bh40@calva.net>,
Linux/PPC Developer list <linuxppc-dev@lists.linuxppc.org>
Subject: Re: insw/outsw/insl/outsl (was: Re: your mail)
Date: Fri, 18 Feb 2000 14:52:52 +0100 [thread overview]
Message-ID: <38AD4EB4.8870713@fadata.bg> (raw)
In-Reply-To: Pine.GSO.4.10.10002181314290.22332-100000@dandelion.sonytel.be
Geert Uytterhoeven wrote:
>
> On Thu, 17 Feb 2000, Paul Mackerras wrote:
> > Does anyone have any objection if I make insw/outsw/insl/outsl *not*
> > byte-swap the data? The reason is that these functions are mostly used
> > for transferring blocks of data, i.e. arrays of bytes. I haven't found a
> > single instance where they are used for transferring arrays of 16 or
> > 32-bit words.
> >
> > This would mean that we wouldn't need the kludge in the ide stuff where we
> > redefine insw as ide_insw (which doesn't byte-swap). There is currently a
> > bug there because insl does still byte-swap, which means that if you set
> > the -c1 flag with hdparm, you get byte-swapped data. :-(
>
> Hmm... This is indeed ambiguous. Is e.g. insl() used to (a) read n 32-bit words
> from (little endian) ISA I/O space, or (b) used to read n*4 bytes from ISA I/O
> space, using 32-bit accesses?
>
> What about moving this to linux-kernel? It affects all big endian platforms.
How about {ins|outs}_{be|le}{16|32} ?
Regards,
-velco
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-02-18 13:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <00021714275405.25243@argo.linuxcare.com.au>
2000-02-18 12:17 ` insw/outsw/insl/outsl (was: Re: your mail) Geert Uytterhoeven
2000-02-18 13:45 ` Gabriel Paubert
2000-02-18 13:52 ` Momchil Velikov [this message]
[not found] <B0CAE42C9EE0D311AAAD00500422FC6302CD74@iis000.microdata.fr>
2000-02-18 13:48 ` 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=38AD4EB4.8870713@fadata.bg \
--to=velco@fadata.bg \
--cc=Geert.Uytterhoeven@sonycom.com \
--cc=bh40@calva.net \
--cc=cort@fsmlabs.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=paulus@linuxcare.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).