linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andre Hedrick <andre@linux-ide.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: IDE janitoring comments
Date: Sat, 24 Aug 2002 13:56:42 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.10.10208241356310.20141-100000@master.linux-ide.org> (raw)
In-Reply-To: <20020824222830.14052@192.168.4.1>


I have part of cris fixed

On Sun, 25 Aug 2002, Benjamin Herrenschmidt wrote:

> >>  - 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
> >
> >I'd like to keep them around for the moment. They should be using
> >udelay() but thats a general issue with _p inb/outb etc.
> 
> I don't think we need them at all in hwif (see below)
> 
> >> After much thinking about the above, I came to the conslusion
> >> we probably want to just kill all the IN_BYTE, OUT_BYTE, etc.
> >
> >Agreed entirely
> >
> >
> >> Also, getting rid of the _P version would make things a lot
> >> easier as well here too.
> >
> >What currently uses the _P versions ?
> 
> Ok, I looked and found out that those are used by 
> 
>  - some weird stuff in ide.c tapping IO ports at 0x40 and 0x43 that
> I assume is a timer. (Can someone make sure that code don't get used
> on anything but legacy x86 ?).
> 
>  - a couple of interface drivers like cmd640 tapping the PCI config
> IO stuffs for probing.
> 
> In all cases, I firmly beleive those are way outside of the domain
> of application of the hwif-> abstraction. Those are code that knows
> it's tapping legacy stuff on a IO port, and can/should directly use
> the in/out_p function. I don't think those have anything to do in
> hwif. All that should be in hwif is what is needed by the generic
> code to tap the IDE registers themselves.
> 
> Do you agree ? (I'd love to get rid of them :)
> 
> If you agree, I'll send you a patch tomorrow along with the fixing
> of ide-pmac that will do
> 
>  - Remove the _P versions from hwif->iops
>  - slightly change ide-iops to define both sets of iops, one set
>    providing PIO ops using directly in/outx & int/outsx, and one
>    set providing MMIO ops using directly read/writex
> 
> Anybody that need different routines for the generic IDE code to
> tap the taskfile (or eventually DMA) registers (typically cris
> arch) will provide it's own set of routines to hwif. I can probably
> fix cris (though I don't know anything about that arch, but the
> code seem obvious enough), and i'll rely on you to fix m86k :)
> 
> 
> Ben.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
LAD Storage Consulting Group


  reply	other threads:[~2002-08-24 20:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-24 15:15 IDE janitoring comments Benjamin Herrenschmidt
2002-08-24 20:14 ` Alan Cox
2002-08-24 21:01   ` Andre Hedrick
2002-08-24 22:28   ` Benjamin Herrenschmidt
2002-08-24 20:56     ` Andre Hedrick [this message]
  -- 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=Pine.LNX.4.10.10208241356310.20141-100000@master.linux-ide.org \
    --to=andre@linux-ide.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=benh@kernel.crashing.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).