chip drivers

[Jonas Holmberg]

On Wed, 2002-02-06 at 15:43, David Woodhouse wrote:
> On 6 Feb 2002, Jonas Holmberg wrote:
> 
> > Do you mean Jörn Engels patches
> > (http://wh.fh-wedel.de/~joern/software/kernel/)? Are they expected to be
> > committed to the MTD CVS soon?
> 
> Yes - I believe they contain support for this. I'm intending to merge them 
> as soon as I've finished all the destabilising stuff in JFFS2 (eCos 
> support, NAND flash support) and when I stop ignoring Linus' 2.5 kernel.
> 
> At that point I'll look at merging Jörn's patches into a 2.5 branch, which
> should be usable in 2.4 but won't be submitted to Marcelo.

I need a solution that will work in 2.4. It sounds like I shouldn't rely
on Jörn's patches working in 2.4.

What really annoys me is that even though different probe funcions will
find two different chips, the same driver will still be used
(cfi_cmdset_0002 in my case) for both chips. So if I could merge the two
mtd_info structs (and everything they point to, like eraseregions and
flchip structs) the result ought to allow me to create devices that
start in one chip and end in the other using the partition code in
current CVS.

This can be done in two ways at least: an ugly merge-function (kind of a
+ operator for mtd_infos), or make the probe functions check the
map->fldrv_priv and use an existing mtd_info before creating a new one.
I prefer the latter. I think it would work if I add an offset field to
map_info that can be used for the second probe (added to all offsets in
eraseregions and flchips for the second probe). The only problem would
be the chipshift field in cfi_private (I think) and it could be removed
and replaced by the start (offset) field in flchip where used.

The second probe with the same map would, of course, have to fail if
there were a mismatch in interleave, device_type etc.

I would like to get your opinion on this. Would it have any chance of
ending up in 2.4 if it works?

/Jonas