Attention is currently required from: Arthur Heymans, Dinesh Gehlot, Kapil Porwal, Lean Sheng Tan, Subrata Banik, Werner Zeh.
Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/76393?usp=email )
Change subject: src: Implement framework for PRERAM VSD store ......................................................................
Patch Set 12:
(1 comment)
Patchset:
PS10:
If it just one file where we are declaring all required global variables and then migrate into the cbmem, I would have easily follow your instructions but the usage model is different and there would be multiple file and files between the stages are involved hence, write function to sync those global variables after CBMEM comes online is a job honestly. Compared to that, calling into cbmem_vsd is much simpler where the caller adds the newer variable into the VSD and it's getting auto synced when cbmem comes online.
I really don't follow you here. Where are these multiple files that need to be involved here? Are you talking about code that is not uploaded as part of this patch series yet? As far as I can tell, CB:76395 is the only user of this API, and in that patch the entire code to handle this would be kept within cse_lite.c (and amount to literally one line to declare the variable, one line to memcpy() into it, and a trivial CBMEM_CREATION_HOOK() function to copy it from there into CBMEM). All the other stuff from that patch (in ish.c and cse.c) runs in ramstage and would only need to call cbmem_find(). Or am I misunderstanding something? (Also note that there is plenty of existing precedent for this kind of thing in coreboot already, for example the `mem_chip_info` variable in `src/soc/qualcomm/common/qclib.c`.)
Meanwhile, I think what you're trying to add here is "messy". You're adding something that sounds like a multi-purpose container ("vendor data"), but really there's only space for a single allocation inside it, and there's no way to identify what kind of data it contains other than reading through the code to find out what was put in there on the other side. What's the point in calling it "vendor data" in the first place, instead of "ISH version", when that's the only thing it can ever really be used for? You're making it sound reusable but the way you're writing it it really isn't. And why are you allocating a separate CAR area for something that isn't actually getting passed between stages?
I'm sorry, but I just think this is a bad design. It is confusingly named for what it does, it is a lot more complex than it needs to be to solve this problem, and it can't be reused for anything else to justify that extra complexity because now it is already "full" with the ISH version. If you want something that can really be reused for other pre-RAM passing-between-stage needs, then it needs to be able to handle multiple different allocations side by side, and that would essentially be the pre-RAM CBMEM thing that we already agreed was a good idea but takes too long for your time frame right now.