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]
Message-ID: <38D9F46DFF92C54980D2F2C1E8EE313001A47964EB@pdsmsx503.ccr.corp.intel.com>
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




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ