All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huang Shijie <shijie8@gmail.com>
To: Marek Vasut <marex@denx.de>
Cc: Huang Shijie <b32955@freescale.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: Sat, 26 Apr 2014 11:10:13 +0800	[thread overview]
Message-ID: <20140426031011.GA4811@localhost.localdomain> (raw)
In-Reply-To: <201404260012.24311.marex@denx.de>

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().

thanks
Huang Shijie



WARNING: multiple messages have this Message-ID (diff)
From: Huang Shijie <shijie8@gmail.com>
To: Marek Vasut <marex@denx.de>
Cc: ggrahammoore@gmail.com,
	Yves Vandervennet <rocket.yvanderv@gmail.com>,
	Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Jingoo Han <jg1.han@samsung.com>,
	Geert Uytterhoeven <geert+renesas@linux-m68k.org>,
	linux-kernel@vger.kernel.org, Huang Shijie <b32955@freescale.com>,
	linux-mtd@lists.infradead.org, Graham Moore <grmoore@altera.com>,
	Alan Tull <atull@altera.com>,
	Sourav Poddar <sourav.poddar@ti.com>,
	Brian Norris <computersforpeace@gmail.com>,
	Insop Song <insop.song@gainspeed.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: Sat, 26 Apr 2014 11:10:13 +0800	[thread overview]
Message-ID: <20140426031011.GA4811@localhost.localdomain> (raw)
In-Reply-To: <201404260012.24311.marex@denx.de>

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().

thanks
Huang Shijie

  reply	other threads:[~2014-04-26  3:10 UTC|newest]

Thread overview: 40+ 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 14:03 ` Graham Moore
2014-04-22 14:03   ` Graham Moore
2014-04-22 16:55   ` Marek Vasut
2014-04-22 16:55     ` Marek Vasut
2014-04-22 18:48     ` Graham Moore
2014-04-22 18:48       ` Graham Moore
2014-04-22 18:58       ` Marek Vasut
2014-04-22 18:58         ` Marek Vasut
2014-04-25  4:47       ` Huang Shijie
2014-04-25  4:47         ` Huang Shijie
2014-04-25 15:50         ` Marek Vasut
2014-04-25 15:50           ` Marek Vasut
2014-04-22 18:45   ` Gerhard Sittig
2014-04-22 18:45     ` Gerhard Sittig
2014-04-22 19:17     ` Graham Moore
2014-04-22 19:17       ` Graham Moore
2014-04-25  1:34   ` Huang Shijie
2014-04-25  1:34     ` Huang Shijie
2014-04-25  2:42     ` Marek Vasut
2014-04-25  2:42       ` Marek Vasut
2014-04-25  1:52       ` Huang Shijie
2014-04-25  1:52         ` Huang Shijie
2014-04-25 22:12         ` Marek Vasut
2014-04-25 22:12           ` Marek Vasut
2014-04-26  3:10           ` Huang Shijie [this message]
2014-04-26  3:10             ` Huang Shijie
2014-04-28  5:06             ` Marek Vasut
2014-04-28  5:06               ` Marek Vasut
2014-04-28  7:06               ` Huang Shijie
2014-04-28  7:06                 ` Huang Shijie
2014-04-28 14:22                 ` Graham Moore
2014-04-28 14:22                   ` Graham Moore
2014-04-28 15:37                   ` Huang Shijie
2014-04-28 15:37                     ` Huang Shijie
2014-07-12  2:07               ` Brian Norris
2014-07-12  2:07                 ` Brian Norris
2014-04-25  1:54       ` Huang Shijie
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=20140426031011.GA4811@localhost.localdomain \
    --to=shijie8@gmail.com \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=atull@altera.com \
    --cc=b32955@freescale.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=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 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.