Re: [PATH 0/4] Memstick patches for 2.6.39

[Maxim Levitsky <maximlevitsky@gmail.com>]

On Sat, 2011-03-19 at 23:47 -0700, Andrew Morton wrote:
> On Sun, 20 Mar 2011 05:09:05 +0200 Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> 
> > On Tue, 2011-03-15 at 14:04 -0700, Andrew Morton wrote:
> > > On Tue, 15 Mar 2011 22:00:10 +0200
> > > Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> > > 
> > > > On Sat, 2011-03-12 at 18:23 +0200, Maxim Levitsky wrote:
> > > > > On Fri, 2011-03-04 at 06:16 +0200, Maxim Levitsky wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > This is a repost of my patches for 2.6.39 inclusion, which I hope not to
> > > > > > miss this time.
> > > > > > 
> > > > > > I addressed the comments on the scatterlist issues.
> > > > > > 
> > > > > > Andrew, please note that my richoh memstick driver is standalone, unchanged from previos versions
> > > > > > has many users which use the version I posted at ubuntu's Launchpad and happy with it.
> > > > > > Please include it regardless of other patches.
> > > > > > 
> > > > > > The other half of my work is support for legacy memorysticks which consists of 2 patches,
> > > > > > first that adds few functions to scatterlist.c, and the other patch that adds the driver.
> > > > > > Driver is also stable and tested.
> > > > > > 
> > > > > > Best regards,
> > > > > > 	Maxim Levitsky
> > > > > 
> > > > > 
> > > > > Any update?
> > > > 
> > > > Any update?
> > > > 
> > > 
> > > I'm hoping that Alex will soon have time to (re)review these patches.
> > 
> > Andrew Morton, what the current state now?
> > 
> 
> Technical discussion is ongoing.  James has described what appears to
> be the architecturally preferred way of implementing this and there is
> as yet no followup to his suggestion.
> 

But I will at least see my r592 driver in kernel?
It doesn't depend on ether ms legacy driver nor on changes in
scatterlist.c

Also, I don't have much time now to improve the ms_block driver till
this summer (studying).
The driver works. Yes it has a flaw in regard to scatterlist processing,
because I didn't find a better way to deal with this monster, but I will
fix that later. I am not the kind of guy that runs away after a merge.
It would be nice to just see my code in kernel, code I wrote more that a
year ago.

This flaw is purely theoretical. Driver does work.

One of the ways to fix this is just use plain good kernel pointers.
Yes that means bouncing of high mem, but like they say "to hell with
that". The driver deals with legacy, and quite slow devices, so there
won't be any performance difference.
Besides, my other driver for that card reader, for xD portion, does
precisely that (more correctly common code in FTL frontend, the
mtd_blkdev.c does that) and the end result is quite good.


So, I am waiting for a word from you,


-- 
Thanks in advance,
Best regards,
        Maxim Levitsky

Visit my blog: http://maximlevitsky.wordpress.com
Warning: Above blog contains rants.