In message 430A4C2C.60506@orkun.us you wrote:
That is not true. There are several policies already.
Let's agree on the term that there are several existing implementations, ok?
Just a couple of emails ago you were saying all sectors should be in writable state in U-Boot. This is a policy which is announced today by you.
OK.
Leaving the state of sectors (except for U-Boot managed sectors) until user takes explicit lock/unlock action as they are is another policy .
I don't call this a policy.
Providing software protection for flash that does not have hardware protection is yet another policy.
I don't call this a policy.
It is the new patch (not from me) that is introducing new policies and
I did not even review this patch yet. I just commented on your requirements, which I do not agree with.
Why do you think it is OK for U-Boot to unlock sectors/blocks that it knows nothing about their usage? Wouldn't leaving these sectors in a
Because in the general case (and this is what cfi_flash is used for) you don't expect to have any hardware protected sectors. Not in U-Boot, and neither in Linux when you for example want to use these for a writable MTD partition.
safer state a common sense approach?
Not for me. I don't like the hardware doing magic things to me. I want to be in control over the hardware - not vice versa.
While you see it important to protect U-Boot environment (for various reasons and I agree), you do not seem to consider consistent protection for another area of flash that may be storing equally vital information for software system. Why?
Not on a *automatic* base. I accept this only if explicitely requested by the user (by using the "protect on" command) *and* the board designer (by providing a flash implementation that supports hardware write protection both in hardware [by selcting appropriate flash chips] and in software [by enabling the needed features in U-Boot]).
As mentioned before: if you want to have this on a board, OK, then implement it there and put apropriate big warnings and notes in your board documentation. If this is general code which is used by many boards that you don't control (and do not test!) then I want to provide a common interface. And common behaviour is that flash can be erased and written to in the boot loader.
Note: I had submitted a bug fix on July 2nd for a number of cfi_flash.c fixes. Do you still have that in your queue? I was expecting it would go
Yes.
to 1.1.3 since you picked some other fixes to go in that release. I am now worried that it is lost somewhere.
It's not lost. The selection of patches for 1.1.3 was done based on their complexity - simple fixes or changes that were obviously local to one board only went in, but more complex modifications or stuff like yours that needs testing on many platforms was further delayed.
Best regards,
Wolfgang Denk