public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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