Change in coreboot[master]: soc/amd/common/block/espi_util: Workaround in-band reset race condition

[Furquan Shaikh (Code Review)]

Attention is currently required from: Jason Glenesk, Raul Rangel, Marshall Dawson, Rob Barnes, Felix Held.
Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/54070 )

Change subject: soc/amd/common/block/espi_util: Workaround in-band reset race condition
......................................................................

Patch Set 1: Code-Review+2

(3 comments)

Patchset:

PS1: 
Change looks okay as a workaround for now. But, we might need to reconsider the decision about what eSPI_RESET# should be tied to on the SoC.

File src/soc/amd/common/block/lpc/espi_util.c:

https://review.coreboot.org/c/coreboot/+/54070/comment/13d6d06d_0d516854 
PS1, Line 544: If the peripheral is alerting when we perform an in-band
             : 		 * reset
Do we know why the peripheral is alerting?

https://review.coreboot.org/c/coreboot/+/54070/comment/64bd5d8f_98145d33 
PS1, Line 558: workaround
I am a bit skeptical about this. This is one race condition that we are working around. Depending upon what state the espi controller was in when the platform reset, could we see different kinds of race conditions?

Basically we are working around the fact that we are not tying the eSPI_RESET# to anything on the SoC that resets on platform reset. Would it make sense to have a GPIO control eSPI_RESET# (at least as a no-stuff connection for future build)? It might give some flexibility if we start seeing more issues during other kinds of testing.