linux-kernel - Re: [PATCH 00/13] DocG3 fixes and write 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4EADC4F5.2050201@newsguy.com>
Date:	Sun, 30 Oct 2011 14:43:17 -0700
From:	Mike Dunn <mikedunn@...sguy.com>
To:	Robert Jarzmik <robert.jarzmik@...e.fr>
CC:	Marek Vasut <marek.vasut@...il.com>, linux-mtd@...ts.infradead.org,
	dwmw2@...radead.org, dedekind1@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/13]  DocG3 fixes and write support

Hi guys,

On 10/30/2011 02:04 AM, Robert Jarzmik wrote:
> Marek Vasut <marek.vasut@...il.com> writes:
>
>> Hi,
>>
>> can you sum up the situation about the another (docg4) driver for us not 
>> watching this too tightly? Was there any improvement/progress/... ?
> The review is underway, my comments should be dealt with, and a V2 of the patch
> should be sent. It's not in my hands.

I've been busy working on this, and should post a patch within the next few
days.  Progress has been very good.  I still want to run the mtd tests in the
kernel before posting the patch (except the torture test - I'm not ready to
sacrifice my development Treo), but it continues to pass the nandtest userspace
utility (part of mtd-utils) flawlessly, and a ubifs still appears to be working
well.  The code is now in a much cleaner state.

> The global view we have with Mike is that chips are different, and each one
> deserves its own driver. Several registers are common, and the docg3.h could
> become common.
>

Actually, I'm open on this.  My opinion is that they should share a header file
for sure, because the register set largely overlaps.  To that end, my upcoming
patch will adopt Robert's register #defines, with just a few additional ones
that are G4 specific.

On the broader question of combined or separate drivers... a combined driver is
certainly doable.  Each device would have to use its own set of low-level
functions, but I think there's merit in combining them because it would provide
a consistent interface with the mtd nand infrastructure code, which is rather
messy.  But before that discussion can take place, the more fundamental question
of whether or not the drivers should use the nand interface needs to be
resolved.  I used the nand interface when I started on the G4 driver, because it
*is* a nand device, and the legacy diskonchip.c driver was updated not long ago
from a stand-alone driver to the nand interface.  I'm not knowledgeable enough
of the mtd subsystem to argue for or against the nand interface, but the end
result (once I invested the time slogging through nand_base.c) is fairly clean,
with just a couple minor hacks to get around the fact that it doesnt have a
"standard" nand controller.

Hopefully some mtd experts can share an opinion on this.

Thanks,
Mike

--
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/