linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andre Hedrick <andre@linux-ide.org>, Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: <linux-kernel@vger.kernel.org>
Subject: IDE janitoring comments
Date: Sat, 24 Aug 2002 17:15:58 +0200	[thread overview]
Message-ID: <20020824151558.26134@192.168.4.1> (raw)

A few notes taken while adapting the ide-pmac (MMIO) code
to the new layer in -ac:

 - Do we really want to keep all those _P versions around ?
A quick grep showed _only_ by the non-portable x86 specific
recovery timer stuff that taps ISA timers (well, I think ports
0x40 and 0x43 and an ISA timer). I would strongly suggest to
get rid of those functions from the hwif, and use directly
the appropriate PIO functon i that timer routine. Also make
sure that timer stuff don't get compiled on anything but
legacy harware where we know those ports mean something.

 - In ide-iops, the insw, insl, outsw, outsl functions are
broken for big endian. They should not do byteswap on these,
however, implemeting them with a loop of IN/OUT_BYTE/WORD
will cause byteswapped access on archs like PPC.
The problem is that the macros IN/OUT_BYTE/WORD don't define
non-swapping equivalents that would allow us to correctly
implement the "s" versions.

After much thinking about the above, I came to the conslusion
we probably want to just kill all the IN_BYTE, OUT_BYTE, etc...
macros and use directly inb/outb/etc... in the default PIO
ops defined in ide-iops.c. We would then use the normal arch
provided insw/insl/outsw/outsl functions here as well.

I already added a set of ops for MMIO in there using the normal
readb/writeb/... and for the "multiple" versions, I did loops
using the __raw versions (no byteswap) and a manual io_barrier().

I grep'ed in 2.4, the only archs that use custom IN/OUT_BYTE
macros for IDE are m68k and cris. I'm pretty sure m68k is wrong
and should do like PPC :) In anyway, both should be fixed the
new 'clean' way which is to define a set of access functions
to be stuffed in the HWIF structure. The goal of ide-iops is
to provide defaults for PIO (and MMIO soon as those can be made
fairly generic too).

Also, getting rid of the _P version would make things a lot
easier as well here too.

Any comments ?

Ben.



             reply	other threads:[~2002-08-24 14:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-24 15:15 Benjamin Herrenschmidt [this message]
2002-08-24 20:14 ` IDE janitoring comments Alan Cox
2002-08-24 21:01   ` Andre Hedrick
2002-08-24 22:28   ` Benjamin Herrenschmidt
2002-08-24 20:56     ` Andre Hedrick
  -- strict thread matches above, loose matches on Subject: below --
2002-08-24 15:09 Benjamin Herrenschmidt
2002-09-23 22:01 ` Richard Zidlicky
2002-09-23  7:29   ` Benjamin Herrenschmidt
2002-09-24  0:28   ` Andre Hedrick
2002-09-24  9:27     ` Richard Zidlicky
2002-09-24 11:35       ` Benjamin Herrenschmidt
2002-09-24 12:41         ` Benjamin Herrenschmidt
2002-09-25  3:57       ` Andre Hedrick

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=20020824151558.26134@192.168.4.1 \
    --to=benh@kernel.crashing.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andre@linux-ide.org \
    --cc=linux-kernel@vger.kernel.org \
    /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).