linux-kernel - RE: [PATCH 1/2]Intel Moorestown NAND driver patch for mainline

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 23 Jun 2009 18:59:24 +0800
From:	"Gao, Yunpeng" <yunpeng.gao@...el.com>
To:	Greg KH <gregkh@...e.de>, David Woodhouse <dwmw2@...radead.org>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/2]Intel Moorestown NAND driver patch for mainline

>-----Original Message-----
>From: Greg KH [mailto:gregkh@...e.de]
>Sent: 2009年6月9日 8:39
>To: David Woodhouse
>Cc: Gao, Yunpeng; Alan Cox; linux-kernel@...r.kernel.org
>Subject: Re: [PATCH 1/2]Intel Moorestown NAND driver patch for mainline
>
>On Mon, Jun 08, 2009 at 11:47:10AM +0100, David Woodhouse wrote:
>> On Mon, 2009-06-08 at 12:23 +0800, Gao, Yunpeng wrote:
>> > The Moorestown NAND flash driver is licensed from the Moorestown NAND
>> > controller vendor. It's a standalone NAND driver. According to the
>> > vendor, this driver has some advanced features specific to the
>> > controller hardware and is difficult to port to MTD subsystem.
>>
>> I don't believe it. If the MTD subsystem doesn't support certain
>> features, the MTD subsystem needs to be updated to cope.
>
>Based on this response, I am guessing that you do not want me to take
>this in the staging tree? :)
>
>If so, please let me know and I'll drop it.
>
>thanks,
>
>greg k-h

Hi Greg, David and Alan,

I have discussed with the architect of Moorestown NAND driver today, and we agreed that the Moorestown NAND driver can not be ported to MTD subsystem.
The reason is: 
The NAND driver has to keep compatibility with Moorestown IA Firmware (which also operates on NAND device and is close source), and if the NAND driver is ported to MTD, the driver has to be changed much and thus will fail to keep the compatibility with Firmware.

As this is a standalone NAND driver, I think I can re-submit it to the block subsystem (maintained by Jens Axboe). Thus the NAND driver need not to change its architecture and can keep the compatibility with Firmware.

Also, it'll be better if the NAND driver can be in Greg's staging tree before the driver becomes 'good enough' and accepted by the block subsystem. Because some customers and partners want to get the latest NAND driver code from the kernel tree before the driver is accepted finally.

Does this suggestion make sense?

Thanks for your time.

Rgds,
Yunpeng Gao