All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joachim Foerster <JOFT@gmx.de>
To: linuxppc-dev@lists.ozlabs.org
Subject: _extending_ platform support options?
Date: Wed, 01 Dec 2010 14:25:43 +0100	[thread overview]
Message-ID: <4CF64CD7.2060802@gmx.de> (raw)

Hi all,

currently I'm wondering what the preferred/recommend way of _extending_ an existing 
"Platform support" option is?

We are working with custom design/boards based on Virtex4/5. So we are primarily using the 
  CONFIG_XILINX_VIRTEX*_GENERIC_BOARD options. In our case we have some special needs, 
like custom ppc_md.restart(), ppc_md.power_off() or ppc_md.show_cpuinfo().

Till now, we just duplicated arch/powerpc/platforms/4?x/virtex.c and added our special 
stuff. Properly renaming everything, etc ...

An alternative could be to add a virtex_my.c which extends virtex.c, like this
(also like virtex_ml510.c extends virtex.c):

static void virtex_my_show_cpuinfo(struct seq_file *m)
{
	seq_printf(m, something);
}

static int __init virtex_mle_init(void)
{
	ppc_md.show_cpuinfo = virtex_my_show_cpuinfo;
	return 0;
}
machine_core_initcall(virtex, virtex_my_init);

Though, to me, it does not seem really OK to assign ppc_md members that way. The original 
struct machdep for "virtex" (which is defined in virtex.c with define_machine()) is not 
adjusted either. Ok, we could modify that one, too.
Especially I'm not sure if it is OK to use machine_core_initcall() for such modifications.

So my question is: Is there any recommended way for doing such "extensions"? Or is it OK 
to just duplicate virtex.c (which does not seem really OK, too)?

Thanks,
  Joachim

             reply	other threads:[~2010-12-01 13:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-01 13:25 Joachim Foerster [this message]
2010-12-01 13:47 ` _extending_ platform support options? Josh Boyer
2010-12-01 20:57   ` Benjamin Herrenschmidt

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=4CF64CD7.2060802@gmx.de \
    --to=joft@gmx.de \
    --cc=linuxppc-dev@lists.ozlabs.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.