Dear Wolfgang Denk,
I have searched such a usage in the tree, but did not find any, so this should not break anything.
You cannot expect to see the real, production environments in the mainline source tree.
Right, but the same applied to serial# and ethaddr when they were added, except if U-Boot deployment was not large enough at that time to worry you.
It could be renamed to hwrev, board_rev or whatever you like. This is not really an issue. Its purpose is the board hardware revision. The CPU revision can often be read from the CPU and is printed upon startup. U-Boot's revision already has the ver env var and the version command. On the contrary, the board revision can not always be determined by analyzing the hardware (OTP, fuses, EEPROM, GPIOs, etc.), so it can be useful to have an official env var to store it in the backed up env, exactly like for the serial# env var that can not always be stored in some dedicated hardware location.
As mentioned before, I don't see need for such a thing in general. Any such use is highly board specific, and vendors use different ways to address this.
The same applies to serial# again.
I don't intend to apply this patch, sorry.
OK.
Anyway, when you will have implemented read-only and volatile flags for env vars, this patch will no longer be needed. But with the current code, there is no way board-specific code can create a board revision env var and make it read-only, except with this patch.
Best regards, Benoît