All of lore.kernel.org
 help / color / mirror / Atom feed
From: pebolle@tiscali.nl (Paul Bolle)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: imx: remove MACH_MXLADS
Date: Sun, 16 Feb 2014 21:35:00 +0100	[thread overview]
Message-ID: <1392582900.28866.85.camel@x220> (raw)
In-Reply-To: <1392578464.996901773@f49.i.mail.ru>

On Sun, 2014-02-16 at 23:21 +0400, Alexander Shiyan wrote:
> ???????????, 16 ??????? 2014, 20:12 +01:00 ?? Paul Bolle <pebolle@tiscali.nl>:
> > On Sun, 2014-02-16 at 23:06 +0400, Alexander Shiyan wrote:
> > > Kconfig selects MACH_MXLADS, this enables machine_arch_type
> > > from include/generated/mach-types.h which used for machine_is_xx() macro,
> > > so if multiple boards is defined in the kernel, this cause to incorrect
> > matching.
> > 
> > But, as I stated in the commit explanation, there are no users of
> > machine_is_mxlads().
> 
> If you have MXLADS and FOO boards support in the kernel (for example)
> and you want to start MXLADS version, your machine_is_FOO() will be positive,
> since machine_arch_type will be constant value FOO in this case.

I think it might be helpful - for people trying to understand this
thread - to add a quote from https://lkml.org/lkml/2013/3/8/473 :
    So, the result is that:
    - de-selected platforms have their if (machine_is_xxx()) { } optimised
      out of the kernel.
    - for a kernel built targetting one platform, all the
      if (machine_is_xxx()) tests are optimised away, leaving only the
      relevant code behind.
    - otherwise, we get the _appropriate_ conditional code for the
      configuration generated.

Back to the issue at hand: without my patch ARCH_MX1ADS selects
MACH_MXLADS. So it seems in this case people will have to select
ARCH_MX1ADS besides selecting FOO. Wouldn't that solve this problem?
Note that the MACH_MXLADS is now basically meant to be selected by
ARCH_MX1ADS and not set directly anyway.


Paul Bolle

WARNING: multiple messages have this Message-ID (diff)
From: Paul Bolle <pebolle@tiscali.nl>
To: Alexander Shiyan <shc_work@mail.ru>
Cc: Russell King <linux@arm.linux.org.uk>,
	Richard Weinberger <richard@nod.at>,
	linux-kernel@vger.kernel.org,
	Sascha Hauer <kernel@pengutronix.de>,
	Shawn Guo <shawn.guo@linaro.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm: imx: remove MACH_MXLADS
Date: Sun, 16 Feb 2014 21:35:00 +0100	[thread overview]
Message-ID: <1392582900.28866.85.camel@x220> (raw)
In-Reply-To: <1392578464.996901773@f49.i.mail.ru>

On Sun, 2014-02-16 at 23:21 +0400, Alexander Shiyan wrote:
> Воскресенье, 16 февраля 2014, 20:12 +01:00 от Paul Bolle <pebolle@tiscali.nl>:
> > On Sun, 2014-02-16 at 23:06 +0400, Alexander Shiyan wrote:
> > > Kconfig selects MACH_MXLADS, this enables machine_arch_type
> > > from include/generated/mach-types.h which used for machine_is_xx() macro,
> > > so if multiple boards is defined in the kernel, this cause to incorrect
> > matching.
> > 
> > But, as I stated in the commit explanation, there are no users of
> > machine_is_mxlads().
> 
> If you have MXLADS and FOO boards support in the kernel (for example)
> and you want to start MXLADS version, your machine_is_FOO() will be positive,
> since machine_arch_type will be constant value FOO in this case.

I think it might be helpful - for people trying to understand this
thread - to add a quote from https://lkml.org/lkml/2013/3/8/473 :
    So, the result is that:
    - de-selected platforms have their if (machine_is_xxx()) { } optimised
      out of the kernel.
    - for a kernel built targetting one platform, all the
      if (machine_is_xxx()) tests are optimised away, leaving only the
      relevant code behind.
    - otherwise, we get the _appropriate_ conditional code for the
      configuration generated.

Back to the issue at hand: without my patch ARCH_MX1ADS selects
MACH_MXLADS. So it seems in this case people will have to select
ARCH_MX1ADS besides selecting FOO. Wouldn't that solve this problem?
Note that the MACH_MXLADS is now basically meant to be selected by
ARCH_MX1ADS and not set directly anyway.


Paul Bolle


  reply	other threads:[~2014-02-16 20:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-16 18:03 [PATCH] arm: imx: remove MACH_MXLADS Paul Bolle
2014-02-16 18:03 ` Paul Bolle
2014-02-16 18:16 ` Alexander Shiyan
2014-02-16 18:16   ` Alexander Shiyan
2014-02-16 18:43   ` Paul Bolle
2014-02-16 18:43     ` Paul Bolle
2014-02-16 19:06     ` Alexander Shiyan
2014-02-16 19:06       ` Alexander Shiyan
2014-02-16 19:12       ` Paul Bolle
2014-02-16 19:12         ` Paul Bolle
2014-02-16 19:21         ` Alexander Shiyan
2014-02-16 19:21           ` Alexander Shiyan
2014-02-16 20:35           ` Paul Bolle [this message]
2014-02-16 20:35             ` Paul Bolle
2014-02-17  4:43             ` Alexander Shiyan
2014-02-17  4:43               ` Alexander Shiyan
2014-02-17  9:02               ` Paul Bolle
2014-02-17  9:02                 ` Paul Bolle
2014-02-17  9:18                 ` Sascha Hauer
2014-02-17  9:18                   ` Sascha Hauer

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=1392582900.28866.85.camel@x220 \
    --to=pebolle@tiscali.nl \
    --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 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.