All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Al Viro <viro@ftp.linux.org.uk>
Cc: linuxppc-dev@ozlabs.org, torvalds@linux-foundation.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/13] BLK_DEV_IDE_CELLEB dependency fix
Date: Thu, 15 Mar 2007 20:48:42 +0100	[thread overview]
Message-ID: <200703152048.42972.bzolnier@gmail.com> (raw)
In-Reply-To: <20070315084645.GR4095@ftp.linux.org.uk>


On Thursday 15 March 2007, Al Viro wrote:
> On Thu, Mar 15, 2007 at 03:10:20PM +0900, Akira Iguchi wrote:
> > Al wrote:
> > >
> > >Eh...  You still need dependency on IDE=y; otherwise you'll get configs
> > >with IDE=m, BLK_DEV_IDE_CELLEB=y and those won't link.  BLK_DEV_IDEDMA_PCI
> > >is selectable just fine with IDE=m.
> > >
> > >It's the same problem as with ps3 fb.
> > >
> > 
> > I'm sorry I missed this case.
> > Using some configurations, I found BLK_DEV_IDE=y was better.
> > (I failed to link when IDE=y and BLK_DEV_IDE=m.)
> 
> Umm...  Point taken.  After looking at the entire thing... well.
> 
> a) BLK_DEV_IDE_PMAC has bogus dependency on IDE=y.  If anything, that
> should've been BLK_DEV_IDE=y; however, it *does* build with ide modular -
> it doesn't generate a separate module and its initialization is called
> explicitly from ide one.  AFAICS, we can simply drop that dependency.

agreed

> b) BLK_DEV_IDE_PMAC does *not* build without BLK_DEV_IDEDMA_PMAC.  Quoting
> benh, "I don't see any reason to keep that dma thingy optional anyway".

ditto

> c) BLK_DEV_MPC8xx_IDE depends on BLK_DEV_IDE=y *and* IDE=y.  The latter is
> obviously redundant.  The former...  No idea, 8xx is currently b0rken in

ditto

> ARCH=powerpc and I can't be arsed to wade through arch/ppc bitrot.  As it
> is, driver definitely wants ARCH=ppc stuff (__res, for one thing).
> 
> Now, BLK_DEV_IDE_CELLEB looks interesting.  The nature of breakage is not
> the same as usual (non-modular driver depends on stuff that might be built
> modular); what's going on here is funnier.  If you get ide-core modular,
> you'll have BLK_DEV_IDE_CELLEB code *linked* *into* ide-core.ko.  Unlike
> the rest of its ilk, however, it doesn't have its init called directly from
> ide init.  It uses module_init(), which happens to work when it goes into
> the kernel image (ide-core.o has several initcalls, not a problem), but breaks
> when it goes into a modular ide-core.ko; there multiple module_init() are
> fatal.
> 
> So AFAICS the minimal fix for that sucker is dependency on BLK_DEV_IDE=y;
> however, I really wonder if
> 	* it needs to be linked into ide-core (as opposed to being a normal
> module of its own)

AFAICS there are no legacy device ordering issues with scc_pata so it doesn't
need to be linked into ide-core but I'll leave the definitive answer to Akira

> 	* alternatively, its init should be called explicitly.
> 
> Comments?

Care to provide patch for non-scc_pata issues that you've discovered? :-)

Thanks,
Bart

WARNING: multiple messages have this Message-ID (diff)
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Al Viro <viro@ftp.linux.org.uk>
Cc: Akira Iguchi <akira2.iguchi@toshiba.co.jp>,
	torvalds@linux-foundation.org, linuxppc-dev@ozlabs.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/13] BLK_DEV_IDE_CELLEB dependency fix
Date: Thu, 15 Mar 2007 20:48:42 +0100	[thread overview]
Message-ID: <200703152048.42972.bzolnier@gmail.com> (raw)
In-Reply-To: <20070315084645.GR4095@ftp.linux.org.uk>


On Thursday 15 March 2007, Al Viro wrote:
> On Thu, Mar 15, 2007 at 03:10:20PM +0900, Akira Iguchi wrote:
> > Al wrote:
> > >
> > >Eh...  You still need dependency on IDE=y; otherwise you'll get configs
> > >with IDE=m, BLK_DEV_IDE_CELLEB=y and those won't link.  BLK_DEV_IDEDMA_PCI
> > >is selectable just fine with IDE=m.
> > >
> > >It's the same problem as with ps3 fb.
> > >
> > 
> > I'm sorry I missed this case.
> > Using some configurations, I found BLK_DEV_IDE=y was better.
> > (I failed to link when IDE=y and BLK_DEV_IDE=m.)
> 
> Umm...  Point taken.  After looking at the entire thing... well.
> 
> a) BLK_DEV_IDE_PMAC has bogus dependency on IDE=y.  If anything, that
> should've been BLK_DEV_IDE=y; however, it *does* build with ide modular -
> it doesn't generate a separate module and its initialization is called
> explicitly from ide one.  AFAICS, we can simply drop that dependency.

agreed

> b) BLK_DEV_IDE_PMAC does *not* build without BLK_DEV_IDEDMA_PMAC.  Quoting
> benh, "I don't see any reason to keep that dma thingy optional anyway".

ditto

> c) BLK_DEV_MPC8xx_IDE depends on BLK_DEV_IDE=y *and* IDE=y.  The latter is
> obviously redundant.  The former...  No idea, 8xx is currently b0rken in

ditto

> ARCH=powerpc and I can't be arsed to wade through arch/ppc bitrot.  As it
> is, driver definitely wants ARCH=ppc stuff (__res, for one thing).
> 
> Now, BLK_DEV_IDE_CELLEB looks interesting.  The nature of breakage is not
> the same as usual (non-modular driver depends on stuff that might be built
> modular); what's going on here is funnier.  If you get ide-core modular,
> you'll have BLK_DEV_IDE_CELLEB code *linked* *into* ide-core.ko.  Unlike
> the rest of its ilk, however, it doesn't have its init called directly from
> ide init.  It uses module_init(), which happens to work when it goes into
> the kernel image (ide-core.o has several initcalls, not a problem), but breaks
> when it goes into a modular ide-core.ko; there multiple module_init() are
> fatal.
> 
> So AFAICS the minimal fix for that sucker is dependency on BLK_DEV_IDE=y;
> however, I really wonder if
> 	* it needs to be linked into ide-core (as opposed to being a normal
> module of its own)

AFAICS there are no legacy device ordering issues with scc_pata so it doesn't
need to be linked into ide-core but I'll leave the definitive answer to Akira

> 	* alternatively, its init should be called explicitly.
> 
> Comments?

Care to provide patch for non-scc_pata issues that you've discovered? :-)

Thanks,
Bart

  reply	other threads:[~2007-03-15 19:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-14  9:16 [PATCH 10/13] BLK_DEV_IDE_CELLEB dependency fix Al Viro
2007-03-14  9:16 ` Al Viro
2007-03-15  5:25 ` Akira Iguchi
2007-03-15  5:25 ` Akira Iguchi
     [not found] ` <200703150523.l2F5NelE001987@toshiba.co.jp>
2007-03-15  5:36   ` Al Viro
2007-03-15  5:36     ` Al Viro
2007-03-15  6:10     ` Akira Iguchi
2007-03-15  8:46       ` Al Viro
2007-03-15  8:46         ` Al Viro
2007-03-15 19:48         ` Bartlomiej Zolnierkiewicz [this message]
2007-03-15 19:48           ` Bartlomiej Zolnierkiewicz
2007-03-16  1:32           ` Akira Iguchi
2007-03-16  1:32           ` Akira Iguchi
2007-03-15  6:10     ` Akira Iguchi

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=200703152048.42972.bzolnier@gmail.com \
    --to=bzolnier@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ftp.linux.org.uk \
    /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.