David Woodhouse <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] said:
> > The chances are poor. By the end of the week with a touch of luck.
> > So I'll probably miss the current merge :(
>
> Fair enough - I'll keep trying :)
>
> > I actually have 3 chip drivers I need to send to you. As I do my
> > first merge I probably need to have the conversation on how we want to
> > support non-cfi devices long term.
>
> As far as possible, by doing whatever chip-specific probe is necessary and
> handing a faked CFI structure over to the generic cfi_cmdset_000[12]
> drivers. Those two between them should handle the actual _operation_ of
> just about all flash chips we're likely to encounter. I'd like to phase out
> the other, more specific drivers.
I'm in the same category. I currently have been using the current cfi_jedec
code patch to recognize more devices. I had to patch cif_cmdset_001 the intel
command set to work with that setup.
> See the recently re-written 'jedec_probe' code, which does just that and is
> no longer horrifically intertwined with the CFI probe code - it just
> invokes the CFI back end if it finds a chip it likes, that's all.
Sounds good. Most of the ugly intertwining seemed to be for overlapping
chips and not for the cfi cases.
I commonly have cases where I either I don't know what kind of flash
chip will be on the other end. Either because of hot-plugging
the flash chip. Or due to writing a driver that will work on different
motherboards. So I'd like to have a sequence that can work with the
chips supproing the legacy jedec interface, or the more recent jedec
cfi interface. And then be able to force it by just compiling in the
correct drivers.
Eric
