Additional issues not fully address are 8-bit transfers.
Lastly if a host can not do 16-bit transfers it is bad and broken and the
OEM needs to be railed for it. Defaulting to 32-bit with legacy hardware
still in the mix will eat somebodies data.
Much of this discussion as to expose a bogus policy of forcing hardware
to 32-bit and causing other problems that are not reported in the proper
light. When people put DOC or ATA-Flash in the onboard host it will mess
things up. Since there are people who think it is okay to set policies in
hardware and have gotten away with it, adding in the default to undo the
bogusity will point that most hardware does not need the is junk and let
it resided with the enduser.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Sat, 13 Apr 2002, Martin Dalecki wrote:
> Russell King wrote:
> > On Fri, Apr 12, 2002 at 10:04:12AM +0200, Martin Dalecki wrote:
> >
> >>3. Make 32 bit PIO transfers the global default.
> >
> >
> > This is fine, as long as you allow some interfaces to say "I really want
> > to be 16-bit PIO only".
> >
> > I *need* 16-bit transfers for many ARM-based IDE stuff. 32-bit is not
> > an option on many, if not all ARM-based PCMCIA stuff.
>
> What I wan't to disable is just the *unconditional* fallback to 16 bit IO
> at some places. This and not more. This doens't even affect the physical setup
> between the host chip and the controller on disc.
> The global "wheee I'm a poor and can't afford 32 bit IO" option will remain
> there of course.
>
> So we have no issue here. OK?
>
> -
> 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/
>
-
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/