Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 24 Aug 2002 16:58:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 24 Aug 2002 16:58:28 -0400 Received: from astound-64-85-224-253.ca.astound.net ([64.85.224.253]:32266 "EHLO master.linux-ide.org") by vger.kernel.org with ESMTP id ; Sat, 24 Aug 2002 16:58:27 -0400 Date: Sat, 24 Aug 2002 14:01:30 -0700 (PDT) From: Andre Hedrick To: Alan Cox cc: Benjamin Herrenschmidt , linux-kernel@vger.kernel.org Subject: Re: IDE janitoring comments In-Reply-To: <1030220051.3196.5.camel@irongate.swansea.linux.org.uk> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1199 Lines: 35 Yep, just be careful of how to decouple the hwif->iops from procfs for pci and the general lameness of x86 centric issues. On 24 Aug 2002, Alan Cox wrote: > On Sat, 2002-08-24 at 16:15, 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. > > > 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 ? > 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/