lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 12 Nov 2015 10:02:56 +0530 From: Vignesh R <vigneshr@...com> To: Brian Norris <computersforpeace@...il.com> CC: Mark Brown <broonie@...nel.org>, Tony Lindgren <tony@...mide.com>, Rob Herring <robh@...nel.org>, Michal Suchanek <hramrach@...il.com>, Russell King <linux@....linux.org.uk>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>, "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>, "linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, Marek Vasut <marex@...x.de> Subject: Re: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists