From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
To: Jon Hunter <jon-hunter@ti.com>
Cc: Tony Lindgren <tony@atomide.com>,
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: Sat, 9 Feb 2013 12:55:49 -0300 [thread overview]
Message-ID: <20130209155547.GA5253@localhost> (raw)
In-Reply-To: <51158293.8010101@ti.com>
On Fri, Feb 08, 2013 at 04:56:19PM -0600, Jon Hunter wrote:
>
> 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>
Without this patch, GPMC is currently broken on my igep board setup,
if initialized through a device tree.
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Thanks a lot for the fix,
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: ezequiel.garcia@free-electrons.com (Ezequiel Garcia)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: OMAP2+: Prevent potential crash if GPMC probe fails
Date: Sat, 9 Feb 2013 12:55:49 -0300 [thread overview]
Message-ID: <20130209155547.GA5253@localhost> (raw)
In-Reply-To: <51158293.8010101@ti.com>
On Fri, Feb 08, 2013 at 04:56:19PM -0600, Jon Hunter wrote:
>
> 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>
Without this patch, GPMC is currently broken on my igep board setup,
if initialized through a device tree.
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Thanks a lot for the fix,
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
next prev parent reply other threads:[~2013-02-09 15:55 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
2013-02-08 22:56 ` Jon Hunter
2013-02-09 15:55 ` Ezequiel Garcia [this message]
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=20130209155547.GA5253@localhost \
--to=ezequiel.garcia@free-electrons.com \
--cc=afzal@ti.com \
--cc=jon-hunter@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.