From: Alex Dubov <oakad@yahoo.com>
To: linux-kernel@vger.kernel.org
Cc: tglx@linutronix.de, joern@logfs.org, ben@fluff.org
Subject: Re: Smartmedia/xd card support - request for comments
Date: Fri, 18 Apr 2008 19:49:45 -0700 (PDT) [thread overview]
Message-ID: <51700.66276.qm@web36708.mail.mud.yahoo.com> (raw)
In-Reply-To: <alpine.LFD.1.10.0804181126350.3261@apollo.tec.linutronix.de>
> > Third, there's no attempt made by mtd to support advanced
> > functionality present in many smartmedia and all memorystick
> > readers: adapter side copy and multi page programming (this mostly
> > relates to memorystick, of course). I also failed to see any support
> > for device writing policy, needed to discern, for example,
> > sequential page programmable devices vs. block programmable
> > devices. I also failed to see an unified approach to page-accessible
> > devices, meaning duplication of "bouncing" code in the backends.
>
> And instead of addressing the missing features and shortcomings you
> add a new duplicated code layer which is only useful for a restricted
> set of hardware.
>
> > Considering all this, amount of effort needed for satisfactory
> > support of smartmedia through mtd was found by me to be far greater
> > than coming with stand-alone implementation.
>
> Yeah and you made this decision on your own w/o even discussing the
> issues at hand with the mtd developers before implementing a separate
> code stack. And now we should be impressed and merge it. That's not
> the way it works.
>
I do not expect you, or anybody, to be "impressed" with anything. As I said before, from my
analysis of mtd it will require a great deal of patching to acquire certain functionality. This
will invariably require a large time span, as many people depend on the mtd in it present state.
If your position on the proposed interim solution is definite "no", I'll make an effort to rewrite
the driver in the mtd-friendly way.
This brings me to the first technical question:
mtd_blkdevs breaks the block layer request into separate pages, effectively disabling lower layer
from making decision based on a real data block size, and using dma to any useful extent. What is
the proposed way to deal with this?
(By the way, first question already puts us into a "quirk" area of the statement "smartmedia are
flash chips with quirks". Both memorystick and smartmedia are always operated in tandem with their
controllers, as you could notice.)
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
next prev parent reply other threads:[~2008-04-19 2:49 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-17 8:50 Alex Dubov
2008-04-17 9:01 ` Ben Dooks
2008-04-17 9:11 ` Alex Dubov
2008-04-17 13:10 ` Andy Lutomirski
2008-04-17 13:36 ` Arnd Bergmann
2008-04-17 13:38 ` Thomas Gleixner
2008-04-17 14:07 ` Jörn Engel
2008-04-17 19:11 ` Thomas Gleixner
2008-04-17 21:21 ` Jörn Engel
2008-04-18 8:47 ` Alex Dubov
2008-04-18 9:35 ` Thomas Gleixner
2008-04-19 2:49 ` Alex Dubov [this message]
2008-04-19 5:56 ` Thomas Gleixner
2008-04-18 14:00 ` Jörn Engel
2008-04-19 3:05 ` Alex Dubov
2008-04-19 6:37 ` Thomas Gleixner
2008-04-19 16:35 ` Jörn Engel
2008-04-20 2:25 ` Alex Dubov
2008-04-17 13:35 ` Thomas Gleixner
2008-04-17 14:19 ` Jörn Engel
2008-04-19 8:31 matthieu castet
2008-04-20 16:01 ` Jörn Engel
2008-04-21 1:33 ` Alex Dubov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51700.66276.qm@web36708.mail.mud.yahoo.com \
--to=oakad@yahoo.com \
--cc=ben@fluff.org \
--cc=joern@logfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome