Previously it provides an easy way to override keys, for testing and debugging.

It is possible to be replaced with another name, say --sig or whatever matches the new terminology.

However I think we should keep one option to allow setting outside, since VPD values were cached at boot time. In other words, consider this:

Device PM tells partner to try updating system to a new key.
Parner did: 'vpd -s customization_id=ABC'
Without reboot, partner runs 'chromeos-firmwareupdate --mode=recovery'

And in your current implementation, that will lead to mosys -> vpd_get_value -> read from /sys/firmware/vpd (boot time cache so what it fetched was not ABC)

So the test result will be wrong, and partner confused again.

In fact that's one of the reason updater should trust what value it has fetched...

I added a --signature_id which does a similar thing. Is that good enough?

Re the cache, are you saying that 'vpd -s' does not update /sys/firmware/vpd? That seems bad to me.

Shouldn't vpd work through the kernel interface?

Correct. vpd -s works on SPI while /sys/firmware/vpd is reading CBMEM that is mirrored in firmware startup.

The VPD support in ChromeOS was pretty bad. In fact it didn't have any native interface before the firmware cache was added, that people has to access using either flashrom or trust a cache file on disk.

OK, I filed crbug.com/797337 to deal with that problem.