[PATCH v2] mtd/nand: don't use {read,write}_buf for 8-bit transfers
David Woodhouse
dwmw2 at infradead.org
Fri Apr 5 08:13:41 EDT 2013
On Mon, 2013-03-04 at 17:47 +0100, Uwe Kleine-König wrote:
> + */
> +static void nand_write_byte16(struct mtd_info *mtd, uint8_t byte)
> +{
> + struct nand_chip *chip = mtd->priv;
> +
> + /*
> + * It's not entirely clear what should happen to I/O[15:8] when writing
> + * a byte. The ONFi spec (Revision 3.1; 2012-09-19, Section 2.16) reads:
> + *
> + * When the host supports a 16-bit bus width, only data is
> + * transferred at the 16-bit width. All address and command line
> + * transfers shall use only the lower 8-bits of the data bus. During
> + * command transfers, the host may place any value on the upper
> + * 8-bits of the data bus. During address transfers, the host shall
> + * set the upper 8-bits of the data bus to 00h.
> + *
> + * One user of the write_byte callback is nand_onfi_set_features. The
> + * four parameters are specified to be written to I/O[7:0], but this is
> + * neither an address nor a command transfer. Let's assume a 0 on the
> + * upper I/O lines is OK.
> + */
> + chip->write_buf(mtd, (uint8_t[]){ byte, 0 }, 2);
Ick. Can you declare that array separately, rather than in the function
call please?
And also this seems broken on big-endian. nand_write_buf16() will cast
the 'buf' pointer to a uint16_t *, load a single uint16_t from it (for
example 0x5a00 if byte==0x5a), and proceed to write the 'byte' value on
the *high* side of the data bus, not the low side. Won't it?
--
David Woodhouse Open Source Technology Centre
David.Woodhouse at intel.com Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20130405/1526d83d/attachment.bin>
More information about the linux-mtd
mailing list