[S] Change in coreboot[main]: {commonlib, libpayload}: Add "has_fw_splash_screen" entry

[Subrata Banik (Code Review)]

Attention is currently required from: Andrey Petrov, Eric Lai, Kapil Porwal, Nick Vaccaro, Paz Zcharya, Tim Van Patten.

Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/78388?usp=email )

Change subject: {commonlib, libpayload}: Add "has_fw_splash_screen" entry
......................................................................

Patch Set 2:

(1 comment)

Commit Message:

https://review.coreboot.org/c/coreboot/+/78388/comment/65b7945b_e73458c1 :
PS1, Line 13: This information is useful for overriding the kernel command-line
            : argument fw_splash. If fw_splash=1, the kernel will skip modeset because
            : the splash screen has already been rendered by the firmware.
> > As long as fw_splash is a valid argument which can be overridden, I don't see a problem.
>
> `fw_splash` is not a valid argument. The linux kernel does not support it.
> > as I said earlier, this CL has no relation about how this information can be useful by payload/DC/crosos. We are just keeping this information handy.
>
> This is dead code if there's no consumer of the information. Specifically, depthcharge doesn't use it, but passes it along via kernel command line arguments, which the kernel doesn't recognize or use either.

I'm not sure why you are so concerned about DC being using this flag ?
do you know that Tianocore also renders the logo at pre-boot? Having coreboot rendering the FW splash screen and later tianocore also renders yet another FW splash screen would results into a confusion, hence, we could use this information to let tianocore know about skipping the FW splash screen rendering.
> The only reason it's being added is as a workaround to inform user space (frecon) that the display is initialized. However, that's also unnecessary, since we should be using a `cros_config` value to indicate this feature instead. Further, this is all temporary until the necessary kernel CLs exist to query the HW directly to prevent re-initialization.

I would request you to read the above comment, as mentioned earlier, the usecase is/can be much wider and DC is not alone the user of such information.