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

[Raul Rangel (Code Review)]

Attention is currently required from: Jason Glenesk, Marshall Dawson, Rob Barnes, Felix Held.
Raul Rangel 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:

(2 comments)

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

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

It's a keyboard IRQ from the little bit I've seen. I haven't done a deep dive to see what causes it yet.

https://review.coreboot.org/c/coreboot/+/54070/comment/a24c8a34_21d19766 
PS1, Line 558: workaround
> I am a bit skeptical about this. This is one race condition that we are working around. […]

Yes we could, A port 80 write in the middle of espi_setup is another race condition. Ideally there would be a mutex that prevents the eSPI hardware from sending any transactions over the bus so the firmware can write and wait for transactions. I can't find any such mutex, so we will always be fighting with the hardware.

On boards that have a full rework #22 that ties eSPI_RESET# to SLP_S5, this condition isn't hit. We currently have b/187538731 open to pick which option we want to use on proto 1.