From: Jon Hunter <jon-hunter@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: linux-omap <linux-omap@vger.kernel.org>,
linux-arm <linux-arm-kernel@lists.infradead.org>,
Afzal Mohammed <afzal@ti.com>
Subject: Re: [PATCH 1/2] ARM: OMAP2+: Prevent potential crash if GPMC probe fails
Date: Fri, 8 Feb 2013 16:56:19 -0600 [thread overview]
Message-ID: <51158293.8010101@ti.com> (raw)
In-Reply-To: <20130201220804.GZ22517@atomide.com>
On 02/01/2013 04:08 PM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter@ti.com> [130201 08:42]:
>> If the GPMC probe fails, devices that use the GPMC (such as ethernet
>> chips, flash memories, etc) can still allocate a GPMC chip-select and
>> register the device. On the OMAP2420 H4 board, this was causing the
>> kernel to crash after the gpmc probe failed and the board attempted
>> to start networking. Prevent this by marking all the chip-selects as
>> reserved by default and only make them available for devices to request
>> if the GPMC probe succeeds.
>
> Thanks applying into omap-for-v3.9/gpmc.
Hi Tony, this one appears to be merged incorrectly. The unreserve ended
up in the gpmc_calc_timings() function. Here is a patch to fix.
Cheers
Jon
>From ebc0613fb5a70f36fcb119cbe58724f9b442903a Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Fri, 8 Feb 2013 16:48:25 -0600
Subject: [PATCH] ARM: OMAP2+: Fix-up gpmc merge error
Commit "ARM: OMAP2+: Prevent potential crash if GPMC probe fails" added
code to ensure that GPMC chip-selects could not be requested until the
device probe was successful. The chip-selects should have been
unreserved at the end of the probe function, but the code to unreserve
them appears to have ended up in the gpmc_calc_timings() function and
hence, this is causing problems requesting chip-selects. Fix this merge
error by unreserving the chip-selects at the end of the probe, but
before we call the gpmc child probe functions (for device-tree) which
request a chip-select.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/mach-omap2/gpmc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1adb2d4..1e8bcb4 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1125,9 +1125,6 @@ int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
/* TODO: remove, see function definition */
gpmc_convert_ps_to_ns(gpmc_t);
- /* Now the GPMC is initialised, unreserve the chip-selects */
- gpmc_cs_map = 0;
-
return 0;
}
@@ -1388,6 +1385,9 @@ static int gpmc_probe(struct platform_device *pdev)
if (IS_ERR_VALUE(gpmc_setup_irq()))
dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
+ /* Now the GPMC is initialised, unreserve the chip-selects */
+ gpmc_cs_map = 0;
+
rc = gpmc_probe_dt(pdev);
if (rc < 0) {
clk_disable_unprepare(gpmc_l3_clk);
--
1.7.10.4
WARNING: multiple messages have this Message-ID (diff)
From: jon-hunter@ti.com (Jon Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: OMAP2+: Prevent potential crash if GPMC probe fails
Date: Fri, 8 Feb 2013 16:56:19 -0600 [thread overview]
Message-ID: <51158293.8010101@ti.com> (raw)
In-Reply-To: <20130201220804.GZ22517@atomide.com>
On 02/01/2013 04:08 PM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter@ti.com> [130201 08:42]:
>> If the GPMC probe fails, devices that use the GPMC (such as ethernet
>> chips, flash memories, etc) can still allocate a GPMC chip-select and
>> register the device. On the OMAP2420 H4 board, this was causing the
>> kernel to crash after the gpmc probe failed and the board attempted
>> to start networking. Prevent this by marking all the chip-selects as
>> reserved by default and only make them available for devices to request
>> if the GPMC probe succeeds.
>
> Thanks applying into omap-for-v3.9/gpmc.
Hi Tony, this one appears to be merged incorrectly. The unreserve ended
up in the gpmc_calc_timings() function. Here is a patch to fix.
Cheers
Jon
>From ebc0613fb5a70f36fcb119cbe58724f9b442903a Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Fri, 8 Feb 2013 16:48:25 -0600
Subject: [PATCH] ARM: OMAP2+: Fix-up gpmc merge error
Commit "ARM: OMAP2+: Prevent potential crash if GPMC probe fails" added
code to ensure that GPMC chip-selects could not be requested until the
device probe was successful. The chip-selects should have been
unreserved at the end of the probe function, but the code to unreserve
them appears to have ended up in the gpmc_calc_timings() function and
hence, this is causing problems requesting chip-selects. Fix this merge
error by unreserving the chip-selects at the end of the probe, but
before we call the gpmc child probe functions (for device-tree) which
request a chip-select.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/mach-omap2/gpmc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1adb2d4..1e8bcb4 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1125,9 +1125,6 @@ int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
/* TODO: remove, see function definition */
gpmc_convert_ps_to_ns(gpmc_t);
- /* Now the GPMC is initialised, unreserve the chip-selects */
- gpmc_cs_map = 0;
-
return 0;
}
@@ -1388,6 +1385,9 @@ static int gpmc_probe(struct platform_device *pdev)
if (IS_ERR_VALUE(gpmc_setup_irq()))
dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
+ /* Now the GPMC is initialised, unreserve the chip-selects */
+ gpmc_cs_map = 0;
+
rc = gpmc_probe_dt(pdev);
if (rc < 0) {
clk_disable_unprepare(gpmc_l3_clk);
--
1.7.10.4
next prev parent reply other threads:[~2013-02-08 22:56 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-01 16:38 [PATCH 0/2] ARM: OMAP2+: GPMC Fixes Jon Hunter
2013-02-01 16:38 ` Jon Hunter
2013-02-01 16:38 ` [PATCH 1/2] ARM: OMAP2+: Prevent potential crash if GPMC probe fails Jon Hunter
2013-02-01 16:38 ` Jon Hunter
2013-02-01 22:08 ` Tony Lindgren
2013-02-01 22:08 ` Tony Lindgren
2013-02-08 22:56 ` Jon Hunter [this message]
2013-02-08 22:56 ` Jon Hunter
2013-02-09 15:55 ` Ezequiel Garcia
2013-02-09 15:55 ` Ezequiel Garcia
2013-02-14 12:04 ` Philip, Avinash
2013-02-14 12:04 ` Philip, Avinash
2013-02-16 22:37 ` Grazvydas Ignotas
2013-02-16 22:37 ` Grazvydas Ignotas
2013-02-01 16:38 ` [PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation Jon Hunter
2013-02-01 16:38 ` Jon Hunter
2013-02-01 21:51 ` Tony Lindgren
2013-02-01 21:51 ` Tony Lindgren
2013-02-02 1:22 ` Jon Hunter
2013-02-02 1:22 ` Jon Hunter
2013-02-02 18:11 ` Tony Lindgren
2013-02-02 18:11 ` Tony Lindgren
2013-02-04 15:05 ` Jon Hunter
2013-02-04 15:05 ` Jon Hunter
2013-02-04 17:45 ` Tony Lindgren
2013-02-04 17:45 ` Tony Lindgren
2013-02-04 18:46 ` Jon Hunter
2013-02-04 18:46 ` Jon Hunter
2013-02-04 19:15 ` Tony Lindgren
2013-02-04 19:15 ` Tony Lindgren
2013-02-04 19:33 ` Jon Hunter
2013-02-04 19:33 ` Jon Hunter
2013-02-04 19:47 ` Tony Lindgren
2013-02-04 19:47 ` Tony Lindgren
2013-02-04 19:51 ` Jon Hunter
2013-02-04 19:51 ` Jon Hunter
2013-02-04 22:12 ` Jon Hunter
2013-02-04 22:12 ` Jon Hunter
2013-02-04 22:45 ` Jon Hunter
2013-02-04 22:45 ` Jon Hunter
2013-02-05 23:34 ` Tony Lindgren
2013-02-05 23:34 ` Tony Lindgren
2013-02-06 0:22 ` Jon Hunter
2013-02-06 0:22 ` Jon Hunter
2013-02-06 17:28 ` Tony Lindgren
2013-02-06 17:28 ` 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=51158293.8010101@ti.com \
--to=jon-hunter@ti.com \
--cc=afzal@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.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.