All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Stefan Agner <stefan@agner.ch>
Cc: dwmw2@infradead.org, sebastian@breakpoint.cc, robh+dt@kernel.org,
	pawel.moll@arm.com, mark.rutland@arm.com,
	ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
	shawn.guo@linaro.org, kernel@pengutronix.de,
	boris.brezillon@free-electrons.com, marb@ixxat.de,
	aaron@tastycactus.com, bpringlemeir@gmail.com,
	linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, albert.aribaud@3adev.fr,
	klimov.linux@gmail.com, Bill Pringlemeir <bpringlemeir@nbsps.com>
Subject: Re: [PATCH v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
Date: Thu, 27 Aug 2015 09:47:36 -0700	[thread overview]
Message-ID: <20150827164736.GY81844@google.com> (raw)
In-Reply-To: <a2060e9f1ad9f26e508af64549da52e7@agner.ch>

On Wed, Aug 26, 2015 at 06:10:05PM -0700, Stefan Agner wrote:
> On 2015-08-25 13:34, Brian Norris wrote:
> > One more thing...
> > 
> > On Mon, Aug 03, 2015 at 11:27:26AM +0200, Stefan Agner wrote:
> >> --- /dev/null
> >> +++ b/drivers/mtd/nand/vf610_nfc.c
> >> @@ -0,0 +1,645 @@
> > ...
> >> +struct vf610_nfc {
> >> +	struct mtd_info mtd;
> >> +	struct nand_chip chip;
> >> +	struct device *dev;
> >> +	void __iomem *regs;
> >> +	struct completion cmd_done;
> >> +	uint buf_offset;
> >> +	int page_sz;
> > 
> > AFAICT (even with the 2nd patch), you never really use this field. You
> > just set it/increment it, but don't use it for anything. Kill it?
> 
> It is used in the write path, I think I meant to use it for subpage
> writes, when I thought it would just mean to transfer only parts of the
> page to the controller.

Ah, you're right. Sorry, I missed that. I got mixed up seeing most of
your uses of 'page_sz' were for a local variable of the same name, not
this field.

> However, as the subpage discussion basically concluded in not using it
> for now on this controller, we can as well transfer the complete page
> (page_sz). Or is there another case in which vf610_nfc_write_buf could
> be called with less than page_sz?

I'll leave that up to you. I'm perfectly fine leaving it in, now that I
see its proper use. Just in case things change in the future, I think it
does help to clarify the flow of information a little. Although, I might
recommend a change in naming, since it could get confused with the
actual page size -- which is normally constant -- whereas this field
changes dynamically depending on the command-in-flight.

Perhaps the struct could have 'write_len' (to help represent an action)
and the local variable in vf610_nfc_command() could be 'tfr_len' (to
distinguish how it isn't necessarily identical to 'write_len')? Just
throwing (likely bad) ideas out there.

Regards,
Brian

WARNING: multiple messages have this Message-ID (diff)
From: computersforpeace@gmail.com (Brian Norris)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
Date: Thu, 27 Aug 2015 09:47:36 -0700	[thread overview]
Message-ID: <20150827164736.GY81844@google.com> (raw)
In-Reply-To: <a2060e9f1ad9f26e508af64549da52e7@agner.ch>

On Wed, Aug 26, 2015 at 06:10:05PM -0700, Stefan Agner wrote:
> On 2015-08-25 13:34, Brian Norris wrote:
> > One more thing...
> > 
> > On Mon, Aug 03, 2015 at 11:27:26AM +0200, Stefan Agner wrote:
> >> --- /dev/null
> >> +++ b/drivers/mtd/nand/vf610_nfc.c
> >> @@ -0,0 +1,645 @@
> > ...
> >> +struct vf610_nfc {
> >> +	struct mtd_info mtd;
> >> +	struct nand_chip chip;
> >> +	struct device *dev;
> >> +	void __iomem *regs;
> >> +	struct completion cmd_done;
> >> +	uint buf_offset;
> >> +	int page_sz;
> > 
> > AFAICT (even with the 2nd patch), you never really use this field. You
> > just set it/increment it, but don't use it for anything. Kill it?
> 
> It is used in the write path, I think I meant to use it for subpage
> writes, when I thought it would just mean to transfer only parts of the
> page to the controller.

Ah, you're right. Sorry, I missed that. I got mixed up seeing most of
your uses of 'page_sz' were for a local variable of the same name, not
this field.

> However, as the subpage discussion basically concluded in not using it
> for now on this controller, we can as well transfer the complete page
> (page_sz). Or is there another case in which vf610_nfc_write_buf could
> be called with less than page_sz?

I'll leave that up to you. I'm perfectly fine leaving it in, now that I
see its proper use. Just in case things change in the future, I think it
does help to clarify the flow of information a little. Although, I might
recommend a change in naming, since it could get confused with the
actual page size -- which is normally constant -- whereas this field
changes dynamically depending on the command-in-flight.

Perhaps the struct could have 'write_len' (to help represent an action)
and the local variable in vf610_nfc_command() could be 'tfr_len' (to
distinguish how it isn't necessarily identical to 'write_len')? Just
throwing (likely bad) ideas out there.

Regards,
Brian

  reply	other threads:[~2015-08-27 16:47 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-03  9:27 [PATCH v10 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610 Stefan Agner
2015-08-03  9:27 ` Stefan Agner
2015-08-03  9:27 ` Stefan Agner
2015-08-03  9:27 ` [PATCH v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others Stefan Agner
2015-08-03  9:27   ` Stefan Agner
2015-08-25 20:16   ` Brian Norris
2015-08-25 20:16     ` Brian Norris
2015-08-27  1:02     ` Stefan Agner
2015-08-27  1:02       ` Stefan Agner
2015-08-27 16:34       ` Brian Norris
2015-08-27 16:34         ` Brian Norris
2015-08-27 16:34         ` Brian Norris
2015-08-27 17:25         ` Stefan Agner
2015-08-27 17:25           ` Stefan Agner
2015-08-27 17:25           ` Stefan Agner
2015-08-25 20:34   ` Brian Norris
2015-08-25 20:34     ` Brian Norris
2015-08-25 20:34     ` Brian Norris
2015-08-27  1:10     ` Stefan Agner
2015-08-27  1:10       ` Stefan Agner
2015-08-27  1:10       ` Stefan Agner
2015-08-27 16:47       ` Brian Norris [this message]
2015-08-27 16:47         ` Brian Norris
2015-08-03  9:27 ` [PATCH v10 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support Stefan Agner
2015-08-03  9:27   ` Stefan Agner
2015-08-03  9:27   ` Stefan Agner
2015-08-03  9:28   ` Stefan Agner
2015-08-03  9:28     ` Stefan Agner
2015-08-25 19:54     ` Brian Norris
2015-08-25 19:54       ` Brian Norris
2015-08-25 19:54       ` Brian Norris
2015-08-25 20:43       ` Boris Brezillon
2015-08-25 20:43         ` Boris Brezillon
2015-08-26 17:57       ` Stefan Agner
2015-08-26 17:57         ` Stefan Agner
2015-08-26 21:34         ` Brian Norris
2015-08-26 21:34           ` Brian Norris
2015-08-28 21:14           ` Bill Pringlemeir
2015-08-28 21:14             ` Bill Pringlemeir
2015-08-28 21:14             ` Bill Pringlemeir
2015-08-03  9:27 ` [PATCH v10 3/5] mtd: nand: vf610_nfc: add device tree bindings Stefan Agner
2015-08-03  9:27   ` Stefan Agner
2015-08-03  9:27   ` Stefan Agner
2015-08-25 20:25   ` Brian Norris
2015-08-25 20:25     ` Brian Norris
2015-08-25 20:25     ` Brian Norris
2015-08-26 15:26     ` Bill Pringlemeir
2015-08-26 15:26       ` Bill Pringlemeir
2015-08-26 15:26       ` Bill Pringlemeir
2015-08-26 15:39       ` Boris Brezillon
2015-08-26 15:39         ` Boris Brezillon
2015-08-26 15:39         ` Boris Brezillon
2015-08-26 21:15         ` Stefan Agner
2015-08-26 21:15           ` Stefan Agner
2015-08-26 21:15           ` Stefan Agner
2015-08-26 21:28           ` Brian Norris
2015-08-26 21:28             ` Brian Norris
2015-08-26 21:28             ` Brian Norris
2015-08-03  9:27 ` [PATCH v10 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial Stefan Agner
2015-08-03  9:27   ` Stefan Agner
2015-08-03  9:27 ` [PATCH v10 5/5] ARM: dts: vf-colibri: enable NAND flash controller Stefan Agner
2015-08-03  9:27   ` Stefan Agner
2015-08-03 10:35 ` [PATCH v10 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610 Albert ARIBAUD
2015-08-03 10:35   ` Albert ARIBAUD

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=20150827164736.GY81844@google.com \
    --to=computersforpeace@gmail.com \
    --cc=aaron@tastycactus.com \
    --cc=albert.aribaud@3adev.fr \
    --cc=boris.brezillon@free-electrons.com \
    --cc=bpringlemeir@gmail.com \
    --cc=bpringlemeir@nbsps.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=kernel@pengutronix.de \
    --cc=klimov.linux@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marb@ixxat.de \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=sebastian@breakpoint.cc \
    --cc=shawn.guo@linaro.org \
    --cc=stefan@agner.ch \
    /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.