[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cfi_cmdset_001.c problem
> > I see that after write and erase operations, the current version of
> > cfi_cmdset_0001.c driver can left a Flash device not in the READY
> > state. If soft reboot is performed in such a situation, applications
> > that use flash will behave erroneously since they expect that the
> > flash is in the READY state. For instance, if the system is supposed
> > to boot from flash, it will hang.
> Thanks for this. One thing that concerns me is that I have a vague
> recollection that Nico once drastically improved the performance of the
> same driver by ripping out all the gratuitous state changes.
I seem to remember this, too. But it was in the read() routine. It used to
switch flash to the status mode and then back to ready even if it had been
ready right away. Our modification affects only write and erase routines.
> I wonder if it would be better to do this with a reboot notifier
> than by changing back to read mode after every other operation?
Probably you are right. The thing is that our modification was originally
made in the context of 2.2.x kernel, which didn't have any reboot
> Also, we need to make sure we do the right thing if the JFFS or JFFS2 GC
> thread is actually in the process of writing to the flash while
> machine_restart() happens on another CPU.
In this case, our patch won't help. A reboot notifier probably would.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org