Wolfgang Denk wrote:
That way, any board with custom data bus (reversed lanes for example) or address bus (messed up address line) arrangements or specialized handling (need floating point) as in this case would override them easily and we would not end up blocks of #if/#elif/#else/#endif etc. in
No. The whole idea of the CFI flash driver is to have standard code for all boards. If your design does not fit the standard, then provide your own non-standard driver. Don't add complexity to the CFI driver - it has just a single advantage (being "standard"), so please don't drop this.
So, you are saying: it is better to have variations of cfi_flash.c in board directories and maintenance problems because of code forking of cfi_flash.c code is better than having the possibility of board specific read/write access functions. By doing this we not only would save the day and solve his problem but make cfi_flash.c useful to a broader application.
For some reason, my mind works to factor common code. It does not make sense for me but you are the boss.
the cfi_flash.c. The board would also enable FP unit in its board file or within these functions if necessary as well.
"enabling FP" has nothing to do with this. The FPU is never disabled or so. It's just that the compiler is told to never emit any FP instructions :-)
He had to modify MSR before using FP instructions as well. That was what I was pointing to.
Best regards, Tolunay