linux-kernel - Re: Smartmedia/xd card support

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 19 Apr 2008 10:31:51 +0200
From:	matthieu castet <castet.matthieu@...e.fr>
To:	Linux Kernel list <linux-kernel@...r.kernel.org>
CC:	Thomas Gleixner <tglx@...utronix.de>, Alex Dubov <oakad@...oo.com>
Subject: Re: Smartmedia/xd card support - request for comments

Hi,

> On Fri, 18 Apr 2008, Alex Dubov wrote:
> 
> First off, can you please use a mail client which does line breaks at
> around 78 chars ?
>  
>> As you understand, both smartmedia media and hosts follow certain
>> spec (publicly available here:
>> http://www.ssfdc.or.jp/spec/index_e.htm, basic registration
>> required). xd card spec is almost identical, adding some cosmetic
>> features and restrictions (such as prohibition of single page
>> programming). This means, that smartmedia access protocol can be
>> abstracted out in the reader-independent way. You can seen in the
>> xd_card_blk.c that it can operate both completely dumb controllers,
>> while taking protocol shortcuts (using host->caps) to accommodate
>> smarter readers (the only feature currently not there is
>> adapter-side page copy - it can be easily added under FBD_COPY
>> clause in xd_card_trans_req). The backend itself (jmb38x_xd.c)
BTW some bare nand flash have support to page copy (there is some issue 
because of no ecc checking during the copy). So the support of this 
could be usefull in mtd.


> Having a separate driver infrastructure for clever controllers, which
> provide only semi raw access to the FLASH chip is fine simply because
> such controllers do not fit into the MTD layer.
I wonder if mtd shouldn't modified to handler more clever controller :
I saw some raw nand controller where you can program a batch of 
command/read/write/ecc checking (that work on a internal RAM of the 
controller (and may be use DMA)) and all you have to do is to wait the 
controller do the job.
These controllers are very hard to integrate in current nand layer 
because it is very low level controller oriented.

>> > Correct.  Erase() is the only callback-based function and every single
>> > driver implements it synchronous anyway.  Improving this situation is
>> > needed for mtd's own sake anyway.  Either that or replacing mtd with
>> > something else, likely the block device code.
>>
Current mtd have other limitations (4GB limit fix, dma buffer, ...),
but in the end it should be fixed.


Matthieu

PS : by using mtd layer you :
- will make improvement that will be useful for everybody
- will use a stack that have been and will be well tested
- will have some controller drivers for free
- will have nand fs for free (for people that don't trust FTL).
- may be provide interesting FTL for raw nand controller
--
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/