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] [day] [month] [year] [list]

Message-Id: <201110302318.47617.marek.vasut@gmail.com>
Date:	Sun, 30 Oct 2011 23:18:47 +0100
From:	Marek Vasut <marek.vasut@...il.com>
To:	Mike Dunn <mikedunn@...sguy.com>
Cc:	Robert Jarzmik <robert.jarzmik@...e.fr>,
	linux-mtd@...ts.infradead.org, dwmw2@...radead.org,
	dedekind1@...il.com, linux-kernel@...r.kernel.org, tcech@...e.cz
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.

CCing Tomas Cech, we might be able to get you a spare device if really 
necessary.
> 
> > 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/