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
-
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/