Re: [PATCH 00/13] DocG3 fixes and write support

[Marek Vasut <marek.vasut@gmail.com>]

> Hi guys,
> 
> On 10/30/2011 02:04 AM, Robert Jarzmik wrote:
> > Marek Vasut <marek.vasut@gmail.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