[M] Change in coreboot[main]: drivers/intel/fsp2_0: Simplify FSP global reset definition

[Subrata Banik (Code Review)]

Attention is currently required from: Andrey Petrov, Dinesh Gehlot, Eran Mitrani, Jakub Czapiga, Jayvik Desai, Jérémy Compostella, Kapil Porwal, Lean Sheng Tan, Nick Vaccaro, Paul Menzel, Pranava Y N, Rishika Raj, Ronak Kanabar, Sean Rhodes, Tarun, Werner Zeh.

Subrata Banik has posted comments on this change by Jérémy Compostella. ( https://review.coreboot.org/c/coreboot/+/84356?usp=email )

Change subject: drivers/intel/fsp2_0: Simplify FSP global reset definition
......................................................................

Patch Set 12:

(1 comment)

File src/soc/intel/common/fsp_reset.c:

https://review.coreboot.org/c/coreboot/+/84356/comment/71c0ea4b_39f60cc2?usp... :
PS11, Line 35: CONFIG_FSP_STATUS_GLOBAL_RESET
> IMO, it is adding yet another layer of potential disconnect between definitions in Kconfig and header files. Someone looking at the values in Kconfig would not understand why 0x40000003 work on 64-bits when looking at the FSP specification. To me, it looks like a band-aid on a implementation not taking into account the details of FSP 2.x specification.
>
> What is wrong with having a solution which automatically comply with the specification ?

We need a versatile solution that supports older platforms running FSP spec < 2.4 (Intel) and AMD platforms running FSP 2.0 spec.

Instead of using an index, we should use a 32-bit value for FSP reset type. If we want to support 64-bit values, we can create additional FSP reset types in 64-bit format.

Alternatively, we can use meaningful comments to explain why we're converting 32-bit reset types to 64-bit values when FSP expects a 64-bit reset type. (like the code I have shared)

The goal is to create a hybrid solution that supports both older and newer platforms.