All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH]: Prevent sn2 ptc code from executing on all ia64 subarches
Date: Tue, 13 Dec 2005 17:14:58 +0000	[thread overview]
Message-ID: <200512131014.58643.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <20051121180016.24224.2378.sendpatchset@prarit.boston.redhat.com>

On Tuesday 13 December 2005 8:42 am, Prarit Bhargava wrote:
> I spent the past day or so looking at a couple of solutions to this problem and 
> the only solution that appears viable is to (as stated previously) create new 
> initcalls of the form
> 
> platform_calltype_initcall(fn,platform)
> 
> ex)
> 	platform_device_initcall(sn_prarit_driver, "sn2");
> 
> which would check the platform type prior to loading a kernel.

I think this is too complicated.  Initcall ordering is fragile as it
is.  I don't think there are enough users of this sort of functionality
to justify complicating it even more with a platform identifier.

> Suggestions/comments?  Anyone think this is too much bother for the original 
> issue of avoiding
> 
> 	if (!ia64_platform_is("sn2"))
> 		return -ENOSYS;

But I still think it is important to keep these ia64_platform_is()
checks out of generic init functions.  There's just too much chance
of inadvertently breaking non-SN platforms.

Can you use the existing machine vector infrastructure to solve this
problem?  For example, what if you added a "platform_device_setup()"
hook that is a no-op on most platforms, but maps to sn_device_setup()
in the SN2 machine vector?  platform_device_setup() would itself be
called as a device_initcall().

  parent reply	other threads:[~2005-12-13 17:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-21 18:00 [PATCH]: Prevent sn2 ptc code from executing on all ia64 subarches Prarit Bhargava
2005-12-09 17:11 ` Robin Holt
2005-12-09 17:46 ` Bjorn Helgaas
2005-12-09 17:54 ` Luck, Tony
2005-12-09 18:22 ` Prarit Bhargava
2005-12-09 18:31 ` Prarit Bhargava
2005-12-09 18:38 ` Luck, Tony
2005-12-09 19:41 ` Andreas Schwab
2005-12-13 14:06 ` Prarit Bhargava
2005-12-13 15:10 ` Andreas Schwab
2005-12-13 15:42 ` Prarit Bhargava
2005-12-13 15:43 ` Prarit Bhargava
2005-12-13 16:03 ` Prarit Bhargava
2005-12-13 17:02 ` Christoph Hellwig
2005-12-13 17:14 ` Bjorn Helgaas [this message]
2005-12-13 17:24 ` Luck, Tony
2005-12-13 17:47 ` Bjorn Helgaas
2005-12-13 17:57 ` Luck, Tony
2005-12-13 18:26 ` Prarit Bhargava
2005-12-13 20:27 ` Bjorn Helgaas
2005-12-14 13:17 ` Prarit Bhargava
2005-12-15 14:33 ` Prarit Bhargava
2005-12-15 15:51 ` Bjorn Helgaas
2005-12-15 20:56 ` Prarit Bhargava
2005-12-15 21:08 ` Luck, Tony

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=200512131014.58643.bjorn.helgaas@hp.com \
    --to=bjorn.helgaas@hp.com \
    --cc=linux-ia64@vger.kernel.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.