All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	grinberg@compulab.co.il
Subject: Re: [PATCH] ARM: OMAP: move old debug-devices.c and debug-leds.c to be OMAP2+ only for now
Date: Mon, 8 Oct 2012 15:13:33 -0700	[thread overview]
Message-ID: <20121008221333.GZ13011@atomide.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1210080145080.5736@utopia.booyaka.com>

* Paul Walmsley <paul@pwsan.com> [121007 18:48]:
> 
> Commit 801475ccb2b2c1928b22aec4b9e5285d9e347602 ("ARM: OMAP: move
> debug_card_init() function") results in the following new sparse[1]
> warning:
> 
> arch/arm/plat-omap/debug-devices.c:71:12: warning: symbol 'debug_card_init' was not declared. Should it be static?
> 
> Normally this could be fixed by including the appropriate header file
> in plat-omap/debug-devices.c, but the header file now exists only in
> mach-omap2/, so this would require a "sideways include" and is thus
> impractical.  It turns out that only code in mach-omap2/ currently
> uses the debug-devices.c and debug-leds.c files, so move them there.
> In the long term, these devices should be created by DT, and the code
> should be moved into drivers/ somewhere.

Hmm are you sure that omap1 is not using debug-leds.c?
At least the initcall seems like it should run on omap1
if enabled.

The sideways include here is OK, it does not get exposed to
the drivers, it seems that plat-omap is still the right location
for at least debug-leds.c code.

> rename from arch/arm/plat-omap/debug-leds.c
> rename to arch/arm/mach-omap2/debug-leds.c
> index ea29bbe..c12350b 100644
> --- a/arch/arm/plat-omap/debug-leds.c
> +++ b/arch/arm/mach-omap2/debug-leds.c
> @@ -146,11 +146,8 @@ static struct platform_driver led_driver = {
>  
>  static int __init fpga_init(void)
>  {
> -	if (machine_is_omap_h4()
> -			|| machine_is_omap_h3()
> -			|| machine_is_omap_h2()
> -			|| machine_is_omap_perseus2()
> -			)
> +	if (machine_is_omap_h4() || machine_is_omap_h3() ||
> +	    machine_is_omap_h2() || machine_is_omap_perseus2())
>  		return platform_driver_register(&led_driver);
>  	return 0;
>  }

This looks like it should work fine for the boards using
the debug leds on omap1 too.

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: OMAP: move old debug-devices.c and debug-leds.c to be OMAP2+ only for now
Date: Mon, 8 Oct 2012 15:13:33 -0700	[thread overview]
Message-ID: <20121008221333.GZ13011@atomide.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1210080145080.5736@utopia.booyaka.com>

* Paul Walmsley <paul@pwsan.com> [121007 18:48]:
> 
> Commit 801475ccb2b2c1928b22aec4b9e5285d9e347602 ("ARM: OMAP: move
> debug_card_init() function") results in the following new sparse[1]
> warning:
> 
> arch/arm/plat-omap/debug-devices.c:71:12: warning: symbol 'debug_card_init' was not declared. Should it be static?
> 
> Normally this could be fixed by including the appropriate header file
> in plat-omap/debug-devices.c, but the header file now exists only in
> mach-omap2/, so this would require a "sideways include" and is thus
> impractical.  It turns out that only code in mach-omap2/ currently
> uses the debug-devices.c and debug-leds.c files, so move them there.
> In the long term, these devices should be created by DT, and the code
> should be moved into drivers/ somewhere.

Hmm are you sure that omap1 is not using debug-leds.c?
At least the initcall seems like it should run on omap1
if enabled.

The sideways include here is OK, it does not get exposed to
the drivers, it seems that plat-omap is still the right location
for at least debug-leds.c code.

> rename from arch/arm/plat-omap/debug-leds.c
> rename to arch/arm/mach-omap2/debug-leds.c
> index ea29bbe..c12350b 100644
> --- a/arch/arm/plat-omap/debug-leds.c
> +++ b/arch/arm/mach-omap2/debug-leds.c
> @@ -146,11 +146,8 @@ static struct platform_driver led_driver = {
>  
>  static int __init fpga_init(void)
>  {
> -	if (machine_is_omap_h4()
> -			|| machine_is_omap_h3()
> -			|| machine_is_omap_h2()
> -			|| machine_is_omap_perseus2()
> -			)
> +	if (machine_is_omap_h4() || machine_is_omap_h3() ||
> +	    machine_is_omap_h2() || machine_is_omap_perseus2())
>  		return platform_driver_register(&led_driver);
>  	return 0;
>  }

This looks like it should work fine for the boards using
the debug leds on omap1 too.

Regards,

Tony

  reply	other threads:[~2012-10-08 22:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-08  1:46 [PATCH] ARM: OMAP: move old debug-devices.c and debug-leds.c to be OMAP2+ only for now Paul Walmsley
2012-10-08  1:46 ` Paul Walmsley
2012-10-08 22:13 ` Tony Lindgren [this message]
2012-10-08 22:13   ` Tony Lindgren
2012-10-09  2:49   ` Paul Walmsley
2012-10-09  2:49     ` Paul Walmsley
2012-10-09 20:11   ` Paul Walmsley
2012-10-09 20:11     ` Paul Walmsley
2012-10-09 21:47     ` Tony Lindgren
2012-10-09 21:47       ` Tony Lindgren

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=20121008221333.GZ13011@atomide.com \
    --to=tony@atomide.com \
    --cc=grinberg@compulab.co.il \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    /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.