[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