From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: linux-ide@vger.kernel.org, Adrian Bunk <bunk@kernel.org>,
linux-pcmcia@lists.infradead.org, Sam Ravnborg <sam@ravnborg.org>,
linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] PCMCIA mustn't select HAVE_IDE
Date: Wed, 16 Apr 2008 01:26:10 +0200 [thread overview]
Message-ID: <200804160126.11116.bzolnier@gmail.com> (raw)
In-Reply-To: <20080415223928.GH5676@flint.arm.linux.org.uk>
On Wednesday 16 April 2008, Russell King wrote:
> On Wed, Apr 16, 2008 at 01:10:02AM +0300, Adrian Bunk wrote:
> > On Tue, Apr 15, 2008 at 11:03:45PM +0100, Russell King wrote:
> > > On Wed, Apr 16, 2008 at 12:52:23AM +0300, Adrian Bunk wrote:
> > >...
> > > So this is a only impacting ARM wrt. PCMCIA, and given that ARM supplies
> > > an asm/ide.h, it's _entirely_ reasonable that if a platform has PCMCIA
> > > then it supports IDE.
> > >
> > > > We could simply always select HAVE_IDE on arm instead of manually
> > > > setting which platforms could possibly get IDE support (e.g. are there
> > > > any boards with PCI slots for which HAVE_IDE is currently not
> > > > selected?).
> > >
> > > You could, if there was a demand for it. As no one has added that,
> > > I conclude that its less common for people to stick an IDE controller
> > > into a PCI backplane.
> >
> > People can always enable code for stuff they don't use.
> >
> > But instead of having 14 ARM platforms plus PCMCIA (which is offered
> > unconditionally on all ARM platforms...) select HAVE_IDE it's simpler
> > to select it once for all ARM platforms.
Please send me a patch doing this, it should be safe for current IDE tree.
> That would seem logical, but Bart objects to that idea.
I don't remember the background but I think it was needed because of badly
perplexed ide_init_hwif_ports() and friends in <asm/ide.h> vs <linux/ide.h>
(almost all this stuff is gone in IDE tree for 2.6.26)...
Ok, I found the patch:
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=4b3b8ee5db374b76608537e061f2efd90e21179d
[ tglx's history tree since it is from May 2004. ]
> However, consider that we're gradually transitioning over to being
> exclusively libata only.
>
> > > In fact, there are only three classes of ARM platforms which have PCI
> > > selected but not HAVE_IDE - IOP13xx, IXP2000, and Orion. I suspect
> > > the only reason they don't select it because they now use the ATA code
> > > rather than the old IDE code - that's certainly true of Orion.
> >
> > The libata options are offered unconditionally on all platforms...
>
> It wasn't *my* choice to restrict IDE on ARM. See Bart for that
> decision.
It could be that I did the poor job of explaining things back then
but I also didn't like the fact that I needed to restrict the IDE
choice on ARM - the change in question was _necessary_ to start
converting IDE drivers to become real, independent, modular host
drivers and as a preparation for adding proper warm-plug support.
Thanks,
Bart
WARNING: multiple messages have this Message-ID (diff)
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Adrian Bunk <bunk@kernel.org>, Sam Ravnborg <sam@ravnborg.org>,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pcmcia@lists.infradead.org
Subject: Re: [2.6 patch] PCMCIA mustn't select HAVE_IDE
Date: Wed, 16 Apr 2008 01:26:10 +0200 [thread overview]
Message-ID: <200804160126.11116.bzolnier@gmail.com> (raw)
In-Reply-To: <20080415223928.GH5676@flint.arm.linux.org.uk>
On Wednesday 16 April 2008, Russell King wrote:
> On Wed, Apr 16, 2008 at 01:10:02AM +0300, Adrian Bunk wrote:
> > On Tue, Apr 15, 2008 at 11:03:45PM +0100, Russell King wrote:
> > > On Wed, Apr 16, 2008 at 12:52:23AM +0300, Adrian Bunk wrote:
> > >...
> > > So this is a only impacting ARM wrt. PCMCIA, and given that ARM supplies
> > > an asm/ide.h, it's _entirely_ reasonable that if a platform has PCMCIA
> > > then it supports IDE.
> > >
> > > > We could simply always select HAVE_IDE on arm instead of manually
> > > > setting which platforms could possibly get IDE support (e.g. are there
> > > > any boards with PCI slots for which HAVE_IDE is currently not
> > > > selected?).
> > >
> > > You could, if there was a demand for it. As no one has added that,
> > > I conclude that its less common for people to stick an IDE controller
> > > into a PCI backplane.
> >
> > People can always enable code for stuff they don't use.
> >
> > But instead of having 14 ARM platforms plus PCMCIA (which is offered
> > unconditionally on all ARM platforms...) select HAVE_IDE it's simpler
> > to select it once for all ARM platforms.
Please send me a patch doing this, it should be safe for current IDE tree.
> That would seem logical, but Bart objects to that idea.
I don't remember the background but I think it was needed because of badly
perplexed ide_init_hwif_ports() and friends in <asm/ide.h> vs <linux/ide.h>
(almost all this stuff is gone in IDE tree for 2.6.26)...
Ok, I found the patch:
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=4b3b8ee5db374b76608537e061f2efd90e21179d
[ tglx's history tree since it is from May 2004. ]
> However, consider that we're gradually transitioning over to being
> exclusively libata only.
>
> > > In fact, there are only three classes of ARM platforms which have PCI
> > > selected but not HAVE_IDE - IOP13xx, IXP2000, and Orion. I suspect
> > > the only reason they don't select it because they now use the ATA code
> > > rather than the old IDE code - that's certainly true of Orion.
> >
> > The libata options are offered unconditionally on all platforms...
>
> It wasn't *my* choice to restrict IDE on ARM. See Bart for that
> decision.
It could be that I did the poor job of explaining things back then
but I also didn't like the fact that I needed to restrict the IDE
choice on ARM - the change in question was _necessary_ to start
converting IDE drivers to become real, independent, modular host
drivers and as a preparation for adding proper warm-plug support.
Thanks,
Bart
next prev parent reply other threads:[~2008-04-15 23:26 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-14 14:16 [2.6 patch] PCMCIA mustn't select HAVE_IDE Adrian Bunk
2008-04-14 14:16 ` Adrian Bunk
2008-04-14 17:53 ` Sam Ravnborg
2008-04-15 20:15 ` Bartlomiej Zolnierkiewicz
2008-04-15 21:23 ` Adrian Bunk
2008-04-15 21:28 ` Russell King
2008-04-15 21:42 ` Russell King
2008-04-15 21:42 ` Russell King
2008-04-15 21:52 ` Adrian Bunk
2008-04-15 22:03 ` Russell King
2008-04-15 22:10 ` Adrian Bunk
2008-04-15 22:39 ` Russell King
2008-04-15 23:26 ` Bartlomiej Zolnierkiewicz [this message]
2008-04-15 23:26 ` Bartlomiej Zolnierkiewicz
2008-04-17 9:37 ` [2.6 patch] ARM: always " Adrian Bunk
2008-04-17 9:59 ` Russell King
2008-04-17 10:48 ` Adrian Bunk
2008-04-17 11:00 ` Russell King
2008-04-17 13:25 ` Adrian Bunk
2008-04-19 11:33 ` Russell King
2008-04-27 18:32 ` Bartlomiej Zolnierkiewicz
2008-04-27 20:29 ` Sam Ravnborg
2008-04-27 21:06 ` Bartlomiej Zolnierkiewicz
2008-04-17 12:38 ` Matthew Wilcox
2008-04-27 17:53 ` Bartlomiej Zolnierkiewicz
2008-04-15 21:26 ` [2.6 patch] PCMCIA mustn't " Russell King
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=200804160126.11116.bzolnier@gmail.com \
--to=bzolnier@gmail.com \
--cc=bunk@kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pcmcia@lists.infradead.org \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=sam@ravnborg.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.