Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/45774 )
Change subject: [RFC] Introduce vpd_get_option() ......................................................................
Patch Set 3:
a. An option name is associated with a data type, regardless of data source. Based on the data type, appropriate vpd_get_* can be used. get_option() takes option name as input, it looks up at a table to get the data type, pass the option name and data type to vpd_get_option(). vpd_get_option() calls appropriate vpd_get_* based on data type, to look up the option name. In other words, the vpd_get_option() design is very similar to cmos_get_option().
There is no general need for tables. The CMOS "option table" is only a table because CMOS space is so tight that we have to pack things. The current get_option() API is definitely at an impasse. Beside the lack of typing, it's dangerous because the caller has no way to pass the length of storage available.
We have all the type information in C code and should make use of it. That needs a new API, ofc. For instance, integer and enum values could simply be read with a get_int_option() function, booleans with a get_bool_option(). Well, for enums there could be look-up tables if one wants to store strings in the backend, for instance. But such information should be provided by the caller, not the backend.
c. For a specific option, there are several possible sources (cmos/cbfs/vpd/gpio/i2c, etc). For a mainboard, not all options may come from same source. A mainboard will have a table to enumerate which option comes from which source.
Sounds possible, but should be optional. Not everybody needs multiple sources. In the core I would keep things as simple as possible.