From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
Date: Thu, 6 Jan 2011 20:08:21 +0530 [thread overview]
Message-ID: <65442ed447ba6e1fc8dab9f9d944c03a@mail.gmail.com> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930248201A7E@dbde02.ent.ti.com>
> -----Original Message-----
> From: Premi, Sanjeev [mailto:premi at ti.com]
> Sent: Thursday, January 06, 2011 8:03 PM
> To: Shilimkar, Santosh; linux-omap at vger.kernel.org
> Cc: Hilman, Kevin; tony at atomide.com; linux-arm-
> kernel at lists.infradead.org; Shilimkar, Santosh; Paul Walmsley
> Subject: RE: [PATCH v2 2/5] omap2plus: prm: Trvial build break fix
> for undefined reference to 'omap2_prm_read_mod_reg'
>
> > -----Original Message-----
> > From: linux-omap-owner at vger.kernel.org
> > [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of
> > Santosh Shilimkar
> > Sent: Wednesday, January 05, 2011 4:27 PM
> > To: linux-omap at vger.kernel.org
> > Cc: Hilman, Kevin; tony at atomide.com;
> > linux-arm-kernel at lists.infradead.org; Shilimkar, Santosh;
> > Paul Walmsley
> > Subject: [PATCH v2 2/5] omap2plus: prm: Trvial build break
> > fix for undefined reference to 'omap2_prm_read_mod_reg'
>
> [snip]
>
> >
> > #ifndef __ASSEMBLER__
> > -
> > +/*
> > + * Stub omap2xxx/omap3xxx functions so that common files
> > + * continue to build when custom builds are used
> > + */
> > +#if defined(CONFIG_ARCH_OMAP4) &&
> > !(defined(CONFIG_ARCH_OMAP2) || \
> > + defined(CONFIG_ARCH_OMAP3))
> > +static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
> > +{
> > + WARN_ONCE(1, "prm: omap2xxx/omap3xxx specific function and "
> > + "not suppose to be used on omap4\n");
> > + return 0;
> > +}
> Looking forward, the warning of incorrect SOC may be required
> for when kernel is build for one specific SOC.
>
> Wouldn't it be easy/better to have common global function:
>
> void wrong_soc(char* func, int soc_id)
> {
> WARN_ONCE(1, "Function %s cannot be used for %d", func,
> soc_id);
> }
>
> OR we could have soc specific functions e.g.
>
> void omap2xxx_only (char* func)
> {
> WARN_ONCE(1, "Function %s is specific to OMAP2XXX");
> }
> ..etc..
>
> Later these functions can be called from the stubs.
>
> This is prelim idea, will need to be worked upon.
>
Not sure. May appear like over engineering considering it's a
stub.
Paul can comment.
Regards,
Santosh
next prev parent reply other threads:[~2011-01-06 14:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-05 10:57 [PATCH v2 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask Santosh Shilimkar
2011-01-05 10:57 ` [PATCH v2 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg' Santosh Shilimkar
2011-01-06 14:32 ` Premi, Sanjeev
2011-01-06 14:38 ` Santosh Shilimkar [this message]
2011-01-06 18:09 ` Kevin Hilman
2011-01-06 17:58 ` Paul Walmsley
2011-01-07 8:43 ` Santosh Shilimkar
2011-01-07 11:14 ` Santosh Shilimkar
2011-01-07 21:14 ` Kevin Hilman
2011-01-07 21:22 ` Santosh Shilimkar
2011-01-05 10:57 ` [PATCH v2 3/5] omap2plus: voltage: Trivial warning fix 'no return statement' Santosh Shilimkar
2011-01-05 10:57 ` [PATCH v2 4/5] omap2plus: voltage: Trivial linking fix 'undefined reference' Santosh Shilimkar
2011-01-05 10:57 ` [PATCH v2 5/5] omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared Santosh Shilimkar
2011-01-05 11:19 ` Russell King - ARM Linux
2011-01-05 11:36 ` [PATCH v2 5/5] omap2plus: voltage: Trivial linking fix for'EINVAL' undeclared Santosh Shilimkar
2011-01-05 17:43 ` [PATCH v2 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask Kevin Hilman
2011-01-06 18:02 ` Paul Walmsley
2011-01-06 18:28 ` Kevin Hilman
2011-01-07 8:40 ` Rajendra Nayak
2011-01-07 21:05 ` Kevin Hilman
2011-01-10 19:16 ` Paul Walmsley
2011-01-11 1:31 ` Kevin Hilman
2011-01-19 14:20 ` Rajendra Nayak
2011-01-06 17:59 ` Paul Walmsley
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=65442ed447ba6e1fc8dab9f9d944c03a@mail.gmail.com \
--to=santosh.shilimkar@ti.com \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).