RE: [PATCH 1/2] mtdpart: memory accessor interface for MTD layer
- From: David Brownell <david-b@xxxxxxxxxxx>
- Date: Wed, 4 Aug 2010 04:27:38 -0700 (PDT)
--- On Wed, 8/4/10, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
Point is to ensure that enough of the right context
information is available to initialize correctly.
So the right data is extracted and passed on.
And also, ISTR, that the mechanism is general
enough to work with both MTD and EEPROM ...
Forgive me if I'm being dim (and in particular, please
forgive me if I'm
going over something that was already discussed; I know
it's been a
while).
I also am at risk of getting lost in a pile
of hypotheticals which have been left behind
earlier in these threads.
But I don't see why it needs to be passed through
the core MTD code.
To take the simple case of an unpartitioned MTD device --
why can't the
map driver (or whatever) just call the maccessor setup
function for
itself, directly, right after calling add_mtd_device() with
its newly-probed MTD device?
No idea, except that doing it once rather than
modifying every driver would seem healthier.
Surely changing all drivers is a Bad Thing.
And for partitions, why can't it do the same, on the
appropriate partition.
OK, the answer to the latter question is that you don't
actually *have*
the pointers to each partition you register. But that's
easily fixed.
If we make add_mtd_partitions() take an extra 'struct
mtd_info **'
argument and put pointers to the slave mtd 'devices' into
that, it means
that your board driver *can* reliably get the mtd pointer
for the fourth
partition, or whatever it needs. And can then just do the
memory
accessor setup for itself.
Isn't that enough?
Might be. Not my patch though... You asked why
the context was needed along with the partition
data (otherwise not available); I answered.
Still haven't seen a better patch though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- RE: [PATCH 1/2] mtdpart: memory accessor interface for MTD layer
- From: David Woodhouse
- RE: [PATCH 1/2] mtdpart: memory accessor interface for MTD layer
- Prev by Date: Re: [PATCH 2/3] Input: sysrq - drop tty argument form handle_sysrq()
- Next by Date: Re: [PATCH] hwmon: f71882fg: Add support for the Fintek F71808E
- Previous by thread: RE: [PATCH 1/2] mtdpart: memory accessor interface for MTD layer
- Next by thread: RE: [PATCH 1/2] mtdpart: memory accessor interface for MTD layer
- Index(es):
Relevant Pages
|