From: Huang Shijie <b32955@freescale.com>
To: Marek Vasut <marex@denx.de>
Cc: Huang Shijie <shijie8@gmail.com>,
Graham Moore <grmoore@altera.com>, <ggrahammoore@gmail.com>,
Geert Uytterhoeven <geert+renesas@linux-m68k.org>,
Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
Jingoo Han <jg1.han@samsung.com>, <linux-kernel@vger.kernel.org>,
Yves Vandervennet <rocket.yvanderv@gmail.com>,
<linux-mtd@lists.infradead.org>,
Insop Song <insop.song@gainspeed.com>,
Alan Tull <atull@altera.com>,
Sourav Poddar <sourav.poddar@ti.com>,
Brian Norris <computersforpeace@gmail.com>,
"David Woodhouse" <dwmw2@infradead.org>,
Dinh Nguyen <dinguyen@altera.com>
Subject: Re: [PATCH V3] Add support for flag status register on Micron chips.
Date: Mon, 28 Apr 2014 15:06:08 +0800 [thread overview]
Message-ID: <20140428070602.GA29525@localhost> (raw)
In-Reply-To: <201404280706.18068.marex@denx.de>
On Mon, Apr 28, 2014 at 07:06:17AM +0200, Marek Vasut wrote:
> On Saturday, April 26, 2014 at 05:10:13 AM, Huang Shijie wrote:
> > On Sat, Apr 26, 2014 at 12:12:24AM +0200, Marek Vasut wrote:
> > > > > > the drivers may fills this hook itself, so the code should like this:
> > > > > > --------------------------------------------------
> > > > > >
> > > > > > if ((info->flags & USE_FSR) &&
> > > > > >
> > > > > > nor->wait_till_ready == spi_nor_wait_till_fsr_ready)
> > > > > >
> > > > > > nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> > > > > >
> > > > > > --------------------------------------------------
> > > > >
> > > > > I sense a misdesign of the SPI NOR subsystem here. The subsystem and
> > > > > the driver compete for a function pointer here ? I guess one should
> > > > > have precedence in some way then ... and also, they should be two
> > > > > different pointers, where the subsystem decides which to use.
> > > >
> > > > the subsystem do not decides which one to use, the driver decides which
> > > > one to use.
> > > >
> > > > If driver has its own @wait_till_ready , it means the driver knows the
> > > > feature, and has implemented it in its own @wait_till_ready.
> > > >
> > > > If the driver does not fill any wait_till_ready, it means the driver
> > > > will use the default @wait_till_ready. We can treat the
> > > > spi_nor_wait_till_fsr_ready as a default hook too.
> > >
> > > I see the driver overwriting a hook previously set by the subsystem. This
> >
> > not sure ;)
> >
> > The driver set the hooks before the subsystem set these hooks.
> >
> > If the driver has already set the @wait_till_ready hook before it calls
> > the spi_nor_scan, the subsystem will not set the hook anymore.
> >
> > Please see the spi_nor_check().
>
> Two things competing over the same pointer looks misdesigned to me. I will need
> to dig into this one more time ...
Please refer to the code for NAND chip, the nand_get_flash_type() :
-----------------------------------------------------------
/* Do not replace user supplied command function! */
if (mtd->writesize > 512 && chip->cmdfunc == nand_command)
chip->cmdfunc = nand_command_lp;
-----------------------------------------------------------
It uses the same logic:
" Do not replace user supplied command function!"
thanks
Huang Shijie
next prev parent reply other threads:[~2014-04-28 8:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-22 14:03 [PATCH V3] Add support for flag status register on Micron chips Graham Moore
2014-04-22 14:03 ` Graham Moore
2014-04-22 16:55 ` Marek Vasut
2014-04-22 18:48 ` Graham Moore
2014-04-22 18:58 ` Marek Vasut
2014-04-25 4:47 ` Huang Shijie
2014-04-25 15:50 ` Marek Vasut
2014-04-22 18:45 ` Gerhard Sittig
2014-04-22 19:17 ` Graham Moore
2014-04-25 1:34 ` Huang Shijie
2014-04-25 2:42 ` Marek Vasut
2014-04-25 1:52 ` Huang Shijie
2014-04-25 22:12 ` Marek Vasut
2014-04-26 3:10 ` Huang Shijie
2014-04-28 5:06 ` Marek Vasut
2014-04-28 7:06 ` Huang Shijie [this message]
2014-04-28 14:22 ` Graham Moore
2014-04-28 15:37 ` Huang Shijie
2014-07-12 2:07 ` Brian Norris
2014-04-25 1:54 ` Huang Shijie
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=20140428070602.GA29525@localhost \
--to=b32955@freescale.com \
--cc=artem.bityutskiy@linux.intel.com \
--cc=atull@altera.com \
--cc=computersforpeace@gmail.com \
--cc=dinguyen@altera.com \
--cc=dwmw2@infradead.org \
--cc=geert+renesas@linux-m68k.org \
--cc=ggrahammoore@gmail.com \
--cc=grmoore@altera.com \
--cc=insop.song@gainspeed.com \
--cc=jg1.han@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
--cc=rocket.yvanderv@gmail.com \
--cc=s.hauer@pengutronix.de \
--cc=shijie8@gmail.com \
--cc=sourav.poddar@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox