On 02/10/2016 01:06 AM, Mark Brown wrote:
> On Fri, Dec 11, 2015 at 09:39:58AM +0530, Vignesh R wrote:
>
>> + if (spi_flash_read_supported(spi)) {
>> + struct spi_flash_read_message msg;
>> + int ret;
>> +
>> + msg.buf = buf;
>> + msg.from = from;
>> + msg.len = len;
>> + msg.read_opcode = nor->read_opcode;
>> + msg.addr_width = nor->addr_width;
>> + msg.dummy_bytes = dummy;
>> + /* TODO: Support other combinations */
>> + msg.opcode_nbits = SPI_NBITS_SINGLE;
>> + msg.addr_nbits = SPI_NBITS_SINGLE;
>> + msg.data_nbits = m25p80_rx_nbits(nor);
>> +
>> + ret = spi_flash_read(spi, &msg);
>> + *retlen = msg.retlen;
>> + return ret;
>
> Looking at this I can't help but think that spi_flash_read() ought to
> have the stub in rather than the caller. But given that we're pretty
> much only ever expecting one user I'm not 100% sure it actually matters.
Well, my initial patch set passed long list of arguments to
spi_flash_read(), but Brian suggested to use struct[1] in order to avoid
unnecessary churn when things need changed in the API.
[1] https://lkml.org/lkml/2015/11/11/454
--
Regards
Vignesh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
