From: Matthieu CASTET <matthieu.castet@parrot.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
Date: Wed, 2 Jan 2013 10:51:50 +0100 [thread overview]
Message-ID: <50E40336.2080008@parrot.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1212240023100.17282@utopia.booyaka.com>
Hi Paul,
Paul Walmsley a écrit :
> Hi
>
> On Mon, 3 Dec 2012, Artem Bityutskiy wrote:
>
>> On Tue, 2012-11-06 at 11:51 +0100, Matthieu CASTET wrote:
>>> - NAND_CMD_READID want an address that it is not scaled on x16 device (it is always 0x20)
>>> - NAND_CMD_PARAM want 8 bits data
>>>
>>> Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com>
>> Pushed this one to l2-mtd.git, thanks!
>
> This patch (commit ff3206b2450499203532af2505a7f6f8413e92c0 in mainline)
> is causing warnings on OMAP3730 Beagle XM, OMAP3530 Beagle, and DM37xx EVM
> as of v3.8-rc1:
>
> [ 1.349456] ------------[ cut here ]------------
> [ 1.351959] WARNING: at drivers/mtd/nand/nand_base.c:2861 nand_scan_ident+0xdb4/0xf90()
> [ 1.356292] Modules linked in:
> [ 1.357971] [<c001bf50>] (unwind_backtrace+0x0/0xf0) from [<c0045cec>] (warn_slowpath_common+0x4c/0x64)
> [ 1.363037] [<c0045cec>] (warn_slowpath_common+0x4c/0x64) from [<c0045d20>] (warn_slowpath_null+0x1c/0x24)
> [ 1.368194] [<c0045d20>] (warn_slowpath_null+0x1c/0x24) from [<c039d304>] (nand_scan_ident+0xdb4/0xf90)
> [ 1.373229] [<c039d304>] (nand_scan_ident+0xdb4/0xf90) from [<c03a2448>] (omap_nand_probe+0x2e8/0x678)
> [ 1.378234] [<c03a2448>] (omap_nand_probe+0x2e8/0x678) from [<c0357f84>] (platform_drv_probe+0x18/0x1c)
> [ 1.383239] [<c0357f84>] (platform_drv_probe+0x18/0x1c) from [<c0356b84>] (driver_probe_device+0x84/0x224)
> [ 1.388458] [<c0356b84>] (driver_probe_device+0x84/0x224) from [<c0356db8>] (__driver_attach+0x94/0x98)
> [ 1.393493] [<c0356db8>] (__driver_attach+0x94/0x98) from [<c0355330>] (bus_for_each_dev+0x50/0x7c)
> [ 1.398315] [<c0355330>] (bus_for_each_dev+0x50/0x7c) from [<c0356250>] (bus_add_driver+0xa0/0x2a0)
> [ 1.403198] [<c0356250>] (bus_add_driver+0xa0/0x2a0) from [<c03572ec>] (driver_register+0x78/0x18c)
> [ 1.408020] [<c03572ec>] (driver_register+0x78/0x18c) from [<c00086a4>] (do_one_initcall+0x34/0x194)
> [ 1.412933] [<c00086a4>] (do_one_initcall+0x34/0x194) from [<c0528188>] (kernel_init+0x154/0x2ec)
> [ 1.417724] [<c0528188>] (kernel_init+0x154/0x2ec) from [<c0013d50>] (ret_from_fork+0x14/0x24)
> [ 1.422454] ---[ end trace 7f5c9fb048cfa61e ]---
>
> The patch also looks bogus. The patch states that "ONFI need to be probed
> in 8 bits mode" (sic). But if that's so, shouldn't
> nand_flash_detect_onfi() just fail immediately, rather than warn?
>
I put a warning in order we fix drivers instead of a silent failure.
The omap driver was fixed in the same series with
http://article.gmane.org/gmane.linux.ports.arm.omap/88551 and
http://article.gmane.org/gmane.linux.ports.arm.omap/88549
For drivers that can't support ONFI, I don't know what to do.
May we should be replace the WARN_ON by a printk and early return.
Matthieu
WARNING: multiple messages have this Message-ID (diff)
From: Matthieu CASTET <matthieu.castet@parrot.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Artem Bityutskiy <dedekind1@gmail.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
Date: Wed, 2 Jan 2013 10:51:50 +0100 [thread overview]
Message-ID: <50E40336.2080008@parrot.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1212240023100.17282@utopia.booyaka.com>
Hi Paul,
Paul Walmsley a écrit :
> Hi
>
> On Mon, 3 Dec 2012, Artem Bityutskiy wrote:
>
>> On Tue, 2012-11-06 at 11:51 +0100, Matthieu CASTET wrote:
>>> - NAND_CMD_READID want an address that it is not scaled on x16 device (it is always 0x20)
>>> - NAND_CMD_PARAM want 8 bits data
>>>
>>> Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com>
>> Pushed this one to l2-mtd.git, thanks!
>
> This patch (commit ff3206b2450499203532af2505a7f6f8413e92c0 in mainline)
> is causing warnings on OMAP3730 Beagle XM, OMAP3530 Beagle, and DM37xx EVM
> as of v3.8-rc1:
>
> [ 1.349456] ------------[ cut here ]------------
> [ 1.351959] WARNING: at drivers/mtd/nand/nand_base.c:2861 nand_scan_ident+0xdb4/0xf90()
> [ 1.356292] Modules linked in:
> [ 1.357971] [<c001bf50>] (unwind_backtrace+0x0/0xf0) from [<c0045cec>] (warn_slowpath_common+0x4c/0x64)
> [ 1.363037] [<c0045cec>] (warn_slowpath_common+0x4c/0x64) from [<c0045d20>] (warn_slowpath_null+0x1c/0x24)
> [ 1.368194] [<c0045d20>] (warn_slowpath_null+0x1c/0x24) from [<c039d304>] (nand_scan_ident+0xdb4/0xf90)
> [ 1.373229] [<c039d304>] (nand_scan_ident+0xdb4/0xf90) from [<c03a2448>] (omap_nand_probe+0x2e8/0x678)
> [ 1.378234] [<c03a2448>] (omap_nand_probe+0x2e8/0x678) from [<c0357f84>] (platform_drv_probe+0x18/0x1c)
> [ 1.383239] [<c0357f84>] (platform_drv_probe+0x18/0x1c) from [<c0356b84>] (driver_probe_device+0x84/0x224)
> [ 1.388458] [<c0356b84>] (driver_probe_device+0x84/0x224) from [<c0356db8>] (__driver_attach+0x94/0x98)
> [ 1.393493] [<c0356db8>] (__driver_attach+0x94/0x98) from [<c0355330>] (bus_for_each_dev+0x50/0x7c)
> [ 1.398315] [<c0355330>] (bus_for_each_dev+0x50/0x7c) from [<c0356250>] (bus_add_driver+0xa0/0x2a0)
> [ 1.403198] [<c0356250>] (bus_add_driver+0xa0/0x2a0) from [<c03572ec>] (driver_register+0x78/0x18c)
> [ 1.408020] [<c03572ec>] (driver_register+0x78/0x18c) from [<c00086a4>] (do_one_initcall+0x34/0x194)
> [ 1.412933] [<c00086a4>] (do_one_initcall+0x34/0x194) from [<c0528188>] (kernel_init+0x154/0x2ec)
> [ 1.417724] [<c0528188>] (kernel_init+0x154/0x2ec) from [<c0013d50>] (ret_from_fork+0x14/0x24)
> [ 1.422454] ---[ end trace 7f5c9fb048cfa61e ]---
>
> The patch also looks bogus. The patch states that "ONFI need to be probed
> in 8 bits mode" (sic). But if that's so, shouldn't
> nand_flash_detect_onfi() just fail immediately, rather than warn?
>
I put a warning in order we fix drivers instead of a silent failure.
The omap driver was fixed in the same series with
http://article.gmane.org/gmane.linux.ports.arm.omap/88551 and
http://article.gmane.org/gmane.linux.ports.arm.omap/88549
For drivers that can't support ONFI, I don't know what to do.
May we should be replace the WARN_ON by a printk and early return.
Matthieu
--
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
next prev parent reply other threads:[~2013-01-02 9:52 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-06 10:51 [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode Matthieu CASTET
2012-11-06 10:51 ` Matthieu CASTET
2012-11-06 10:51 ` [PATCH 2/3] mtd nand : add NAND_BUSWIDTH_AUTO to autodetect bus width Matthieu CASTET
2012-11-06 10:51 ` Matthieu CASTET
2012-11-30 13:21 ` Artem Bityutskiy
2012-11-30 13:21 ` Artem Bityutskiy
2012-11-06 10:51 ` [PATCH 3/3] omap3 nand : use NAND_BUSWIDTH_AUTO Matthieu CASTET
2012-11-06 10:51 ` Matthieu CASTET
2012-11-06 12:37 ` Igor Grinberg
2012-11-06 12:37 ` Igor Grinberg
2012-11-06 16:47 ` Matthieu CASTET
2012-11-06 16:47 ` Matthieu CASTET
2012-11-06 18:40 ` Tony Lindgren
2012-11-06 18:40 ` Tony Lindgren
2012-11-16 8:22 ` Artem Bityutskiy
2012-11-16 8:22 ` Artem Bityutskiy
2012-11-22 17:48 ` Matthieu CASTET
2012-11-22 17:48 ` Matthieu CASTET
2012-12-03 10:20 ` [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode Artem Bityutskiy
2012-12-03 10:20 ` Artem Bityutskiy
2012-12-24 0:29 ` Paul Walmsley
2012-12-24 0:29 ` Paul Walmsley
2013-01-02 9:51 ` Matthieu CASTET [this message]
2013-01-02 9:51 ` Matthieu CASTET
2013-01-03 17:10 ` Paul Walmsley
2013-01-03 17:10 ` Paul Walmsley
2013-01-16 14:28 ` Matthieu CASTET
2013-01-16 14:28 ` Matthieu CASTET
2013-01-16 17:15 ` Paul Walmsley
2013-01-16 17:15 ` Paul Walmsley
2013-01-22 2:27 ` Paul Walmsley
2013-01-22 2:27 ` Paul Walmsley
2013-02-06 23:21 ` Paul Walmsley
2013-02-06 23:21 ` Paul Walmsley
2013-02-07 9:47 ` Matthieu CASTET
2013-02-07 9:47 ` Matthieu CASTET
2013-03-01 14:02 ` Matthieu CASTET
2013-03-01 14:02 ` Matthieu CASTET
2013-04-02 18:28 ` Paul Walmsley
2013-04-02 18:28 ` 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=50E40336.2080008@parrot.com \
--to=matthieu.castet@parrot.com \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@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.