Change in coreboot[master]: drivers/fsp2_0: drop support for FSP-T

[Arthur Heymans (Code Review)]

Arthur Heymans has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/36622 )

Change subject: drivers/fsp2_0: drop support for FSP-T
......................................................................

Patch Set 4:
> Patch Set 4:
> > Patch Set 4:
> > > Patch Set 4: Code-Review+1
> > >
> > > (1 comment)
> > > > Patch Set 4: Code-Review-1
> > > >
> > > > (1 comment)
> > > >
> > > > Is this really necessary, FSP-T is optional right?
> > >
> > > coreboot is an open source project, blobs that replace open source code have no place here. The reason for its removal is exactly that it is optional.
> >
> > Further we already have a superior open source version. Why try to mainting something that is not working for most people?
>
> coreboot is an open-source project and is used by both businesses and the community. There may be a reason that this is needed for some business applications.  I don't know.
>
> I think we need to evaluate the trade-offs.  Intel should also be allowed to weigh-in before it's summarily deleted.
>
> Please start a discussion on the mailing list about this deletion.  That's the official communication channel as it's easy to miss individual patches.
>
> Finally, if the decision ultimately is to delete this, it should happen after the next release and be documented in the release notes.
>
> Also, please note that I really have no stake in it staying or going - I just want to make sure that it's properly discussed and decided upon before being removed.

It's also on tomorrows agenda for the leadership meeting.

No stakes either, but I'd rather see FSP-T support (and FSP-T exit) go. One of the FSP2.0 goals was to make it optional. If not even setting up an execution environment is done by coreboot when it is possible, it's really not taking the open source nature of the project serious. That being said, if someone want FSP-T support to stay, I'd like to hear good arguments why. Currently the documentation about this API is pretty vague (and incorrect), so from an outsiders perspective there is no way to know what it does what the open source version does not. I hope the discussion will not boil down to 'we need fsp-t because fsp-t is validated' as I guess a few million? chromeos devices not using FSP-T should provide enough validation.