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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.