All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vignesh R <vigneshr@ti.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: Mark Brown <broonie@kernel.org>, Tony Lindgren <tony@atomide.com>,
	Rob Herring <robh@kernel.org>,
	Michal Suchanek <hramrach@gmail.com>,
	Russell King <linux@arm.linux.org.uk>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Marek Vasut <marex@denx.de>
Subject: Re: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices
Date: Thu, 12 Nov 2015 10:02:56 +0530	[thread overview]
Message-ID: <56441678.6040504@ti.com> (raw)
In-Reply-To: <20151111192441.GG12143@google.com>

Hi Brian,

On 11/12/2015 12:54 AM, Brian Norris wrote:
> In addition to my other comments:
> 

[...]

>> +	int (*spi_mtd_mmap_read)(struct  spi_device *spi,
>> +				 loff_t from, size_t len,
>> +				 size_t *retlen, u_char *buf,
>> +				 u8 read_opcode, u8 addr_width,
>> +				 u8 dummy_bytes);
> 
> This is seeming to be a longer and longer list of arguments. I know MTD
> has a bad habit of long argument lists (which then cause a ton of
> unnecessary churn when things need changed in the API), but perhaps we
> can limit the damage to the SPI layer. Perhaps this deserves a struct to
> encapsulate all the flash read arguments? Like:
> 
> struct spi_flash_read_message {
> 	loff_t from;
> 	size_t len;
> 	size_t *retlen;
> 	void *buf;
> 	u8 read_opcode;
> 	u8 addr_width;
> 	u8 dummy_bits;
> 	// additional fields to describe rx_nbits for opcode/addr/data
> };
> 
> struct spi_master {
> 	...
> 	int (*spi_flash_read)(struct spi_device *spi,
> 			      struct spi_flash_message *msg);
> };


Yeah.. I think struct encapsulation helps, this can also be used to pass
sg lists for dma in future. I will rework the series with your
suggestion to include nbits for opcode/addr/data.
Also, will add validation logic (similar to __spi_validate()) to check
whether master supports dual/quad mode for opcode/addr/data. I am
planning to add this validation code to spi_flash_read_validate(in place
of spi_mmap_read_supported())
Thanks!


-- 
Regards
Vignesh

WARNING: multiple messages have this Message-ID (diff)
From: vigneshr@ti.com (Vignesh R)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices
Date: Thu, 12 Nov 2015 10:02:56 +0530	[thread overview]
Message-ID: <56441678.6040504@ti.com> (raw)
In-Reply-To: <20151111192441.GG12143@google.com>

Hi Brian,

On 11/12/2015 12:54 AM, Brian Norris wrote:
> In addition to my other comments:
> 

[...]

>> +	int (*spi_mtd_mmap_read)(struct  spi_device *spi,
>> +				 loff_t from, size_t len,
>> +				 size_t *retlen, u_char *buf,
>> +				 u8 read_opcode, u8 addr_width,
>> +				 u8 dummy_bytes);
> 
> This is seeming to be a longer and longer list of arguments. I know MTD
> has a bad habit of long argument lists (which then cause a ton of
> unnecessary churn when things need changed in the API), but perhaps we
> can limit the damage to the SPI layer. Perhaps this deserves a struct to
> encapsulate all the flash read arguments? Like:
> 
> struct spi_flash_read_message {
> 	loff_t from;
> 	size_t len;
> 	size_t *retlen;
> 	void *buf;
> 	u8 read_opcode;
> 	u8 addr_width;
> 	u8 dummy_bits;
> 	// additional fields to describe rx_nbits for opcode/addr/data
> };
> 
> struct spi_master {
> 	...
> 	int (*spi_flash_read)(struct spi_device *spi,
> 			      struct spi_flash_message *msg);
> };


Yeah.. I think struct encapsulation helps, this can also be used to pass
sg lists for dma in future. I will rework the series with your
suggestion to include nbits for opcode/addr/data.
Also, will add validation logic (similar to __spi_validate()) to check
whether master supports dual/quad mode for opcode/addr/data. I am
planning to add this validation code to spi_flash_read_validate(in place
of spi_mmap_read_supported())
Thanks!


-- 
Regards
Vignesh

  reply	other threads:[~2015-11-12  4:32 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-10  5:29 [PATCH v3 0/5] Add memory mapped read support for ti-qspi Vignesh R
2015-11-10  5:29 ` Vignesh R
2015-11-10  5:29 ` Vignesh R
2015-11-10  5:29 ` Vignesh R
2015-11-10  5:29 ` [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices Vignesh R
2015-11-10  5:29   ` Vignesh R
2015-11-10  5:29   ` Vignesh R
2015-11-10 23:23   ` Brian Norris
2015-11-10 23:23     ` Brian Norris
2015-11-10 23:23     ` Brian Norris
2015-11-11  6:50     ` R, Vignesh
2015-11-11  6:50       ` R, Vignesh
2015-11-11  6:50       ` R, Vignesh
2015-11-11  7:20       ` Brian Norris
2015-11-11  7:20         ` Brian Norris
2015-11-11  7:20         ` Brian Norris
2015-11-13 16:05         ` Cyrille Pitchen
2015-11-13 16:05           ` Cyrille Pitchen
2015-11-13 16:05           ` Cyrille Pitchen
2015-11-13 16:05           ` Cyrille Pitchen
2015-11-17  6:32           ` Vignesh R
2015-11-17  6:32             ` Vignesh R
2015-11-17  6:32             ` Vignesh R
2015-11-17  6:32             ` Vignesh R
2015-11-17 17:48             ` Brian Norris
2015-11-17 17:48               ` Brian Norris
2015-11-13 14:06       ` Mike Looijmans
2015-11-13 14:06         ` Mike Looijmans
2015-11-13 14:06         ` Mike Looijmans
2015-11-11 19:24   ` Brian Norris
2015-11-11 19:24     ` Brian Norris
2015-11-11 19:24     ` Brian Norris
2015-11-12  4:32     ` Vignesh R [this message]
2015-11-12  4:32       ` Vignesh R
2015-11-10  5:29 ` [PATCH v3 2/5] spi: spi-ti-qspi: add mmap mode read support Vignesh R
2015-11-10  5:29   ` Vignesh R
2015-11-10  5:29   ` Vignesh R
2015-11-10  5:29 ` [PATCH v3 3/5] mtd: devices: m25p80: add support for mmap read request Vignesh R
2015-11-10  5:29   ` Vignesh R
2015-11-10  5:29   ` Vignesh R
2015-11-10  5:29 ` [PATCH v3 4/5] ARM: dts: DRA7: add entry for qspi mmap region Vignesh R
2015-11-10  5:29   ` Vignesh R
2015-11-10  5:29   ` Vignesh R
2015-11-10  5:29 ` [PATCH v3 5/5] ARM: dts: AM4372: " Vignesh R
2015-11-10  5:29   ` Vignesh R
2015-11-10  5:29   ` Vignesh R

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=56441678.6040504@ti.com \
    --to=vigneshr@ti.com \
    --cc=broonie@kernel.org \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hramrach@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=marex@denx.de \
    --cc=robh@kernel.org \
    --cc=tony@atomide.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.