Sharp SL Series NAND Driver

[John Lenz]

On 11/12/04 11:38:54, Richard Purdie wrote:
> As mentioned on IRC, I've ported the nand driver for the Sharp SL series  
> to
> the current kernel. This first patch adds the driver which supports all  
> the
> Zaurus models that use nand flash. (thanks for the pointers in trimming  
> it
> down! :)
> 
> http://www.rpsys.net/openzaurus/mtd/rp-mtd-sharpsl.patch

In the suspend and resume functions, you still have some prinks... those  
should be removed.  And does there need to be any code in resume?

This patch is very similar to the patch in my tree, except you also provide
the scan_bbt function.

I just got poodle to boot up correctly with my patch.  The problem all
along was that I was passing the wrong root= option to the kernel!  Passing
the correct root device, and poodle boots up fine.  I can log in and run a
few commands.  Note, this is with my patch but it should work with yours as
well since they are so similar.  Secondly, I have it working without any of
the other patches you posted...

> 
> I also have some other patches I'd appreciate your views on. Two of these
> should be straightforward. The third is more for comments.
> 
> http://www.rpsys.net/openzaurus/mtd/rp-mtd-sharpsl-map.patch - maps a ROM  
> on
> the device (I think its used to access configuration information?).

Do we actually need this patch?  Perhaps we should hold off including it  
until we have a program that needs to access this stuff.


> http://www.rpsys.net/openzaurus/mtd/rp-mtd-sharpsl-map.patch - maps a ROM
> on
> the device (I think its used to access configuration information?).
> 
>  http://www.rpsys.net/openzaurus/mtd/rp-jffs2-longfilename.patch - if you
> try  and create filenames longer than 255 characters, the fs gets
> corrupted.  This  adds a couple of checks to prevent it.
> 
>  http://www.rpsys.net/openzaurus/mtd/rp-mtd-sharpsl-extra.patch - This is
> for  comments. The sharp driver uses a smaller eraseblock than the
> current mtd  code supports so I have to disable a check to get the code
> to work  properly.  I think this is due to a limitation on kmalloc? The
> code gets around this  by  using dma_alloc_coherent. Is there a way I can
> do this in an acceptable  manner? (I'm assuming the above patch isn't
> acceptable?)
> 
>  (NB: The filesystem is written out by an older driver we can't change so
> we  have to remain compatible with it - changing eraseblock size
> therefore  isn't  an option).

I notice in this patch you have CONFIG_MACH_HUSKY used... do we need to add  
CONFIG_MACH_POODLE?  Is this something that poodle would have as well?  It  
seems to be working here without this change... although I haven't tested  
it a lot yet.

John