[coreboot-gerrit] Change in coreboot[master]: libpayload: Parse DDR Information through coreboot tables

[mturney mturney (Code Review)]

Attention is currently required from: Hung-Te Lin, Shelley Chen, Ravi kumar, Ravi Kumar Bokka, mturney mturney, Angel Pons, Julius Werner, Arthur Heymans, Xixi Chen.
mturney mturney has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/59193 )

Change subject: libpayload: Parse DDR Information through coreboot tables
......................................................................

Patch Set 34:

(1 comment)

File src/commonlib/bsd/include/commonlib/bsd/mem_chip_info.h:

https://review.coreboot.org/c/coreboot/+/59193/comment/10ac88ad_d1bb33d0 
PS32, Line 24: 2
> > Hmmm, using a linked list would avoid limiting the maximum number of channels, but I'm not sure if […]

I wasn't suggesting creating or using a linked-list.
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html#:~:text=6.18%20Arrays%20....

Depthcharge is a consumer of this information, which is provided by the DDR sub-system during DDR training.  Original requirement was to support two channels, which is what current hardware uses.

This is a new request to not limit the number of channels to 2 in the struct definition and to provide a channel count field (or density if you prefer).

If we add the channel count/density field it makes sense for the struct definition to not be limited to two channels, hence the ask for clarification on using [0] on the last element of the struct, indicating that the number of channels is not pre-defined.  The channel field would still be treated as an array and the consuming code in Depthcharge that creates the /proc entry info via DTB manipulation would check the density field and make sure to not step past the end of the array.

Julius, please weigh-in on this discussion.