summaryrefslogtreecommitdiffstats
path: root/drivers/video/stifb.c
diff options
context:
space:
mode:
authorVitaly Wool <vwool@ru.mvista.com>2006-11-03 18:20:38 +0300
committerDavid Woodhouse <dwmw2@infradead.org>2006-11-28 22:39:03 +0000
commit7014568bad55c20b7ee4f439d78c9e875912d51f (patch)
tree1b558ef8d77d31925cc396ed69d8f785615cf09f /drivers/video/stifb.c
parent191876729901d0c8dab8a331f9a1e4b73a56457b (diff)
downloadkernel-crypto-7014568bad55c20b7ee4f439d78c9e875912d51f.tar.gz
kernel-crypto-7014568bad55c20b7ee4f439d78c9e875912d51f.tar.xz
kernel-crypto-7014568bad55c20b7ee4f439d78c9e875912d51f.zip
[MTD] [NAND] remove len/ooblen confusion.
As was discussed between Ricard Wanderlöf, David Woodhouse, Artem Bityutskiy and me, the current API for reading/writing OOB is confusing. The thing that introduces confusion is the need to specify ops.len together with ops.ooblen for reads/writes that concern only OOB not data area. So, ops.len is overloaded: when ops.datbuf != NULL it serves to specify the length of the data read, and when ops.datbuf == NULL, it serves to specify the full OOB read length. The patch inlined below is the slightly updated version of the previous patch serving the same purpose, but with the new Artem's comments taken into account. Artem, BTW, thanks a lot for your valuable input! Signed-off-by: Vitaly Wool <vwool@ru.mvista.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Diffstat (limited to 'drivers/video/stifb.c')
0 files changed, 0 insertions, 0 deletions