Attention is currently required from: Nico Huber, Patrick Georgi, Martin Roth, Caveh Jalali, Stefan Reinauer, Tim Wawrzynczak, Sridhar Siricilla, Angel Pons, Alex Levin, Nick Vaccaro, YH Lin, Boris Mittelberg. Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/61854 )
Change subject: ichspi.c: Check SPI Cycle In-Progress prior start HW Seq ......................................................................
Patch Set 6:
(1 comment)
Patchset:
PS6:
My recommendation was given in my very first comment on this change and was repeated later. You choose to ignore it from the beginning. I can't help you there any more.
I've tried to respond to each questions being asked and shared the possible information that we are getting out from debug. Sometime early debug data was misleading (like, I suspected CSE FW is accessing the SPI bus when we are seeing 61849 is failing at Host side) and then have clarified saying (multiple processes might trying to access the same flashrom at host side is the culprit). Please help me know which one you felt is being ignored.
I don't know what's so hard to understand about "very first comment" this was it: ``` The whole driver works synchronously, i.e. waits for any cycle to finish that it started itself. So unless I miss something, checking SCIP would only serve us in case of hardware failures or another program trying to use the SPI controller at the same time (e.g. broken SMM). In both cases, I'd say all bets are off anyway and we should definitely bail out.
Datasheets say to check the SCIP bit; we could just do so once (without waiting) and if the bit is set bail out. ```
If you have questions about it just ask.
It will just take time to answer your questions
Sure, take time, In either case I was not going to merge this CL with just one +2 from Intel (Rizwan) and waited for community for review time.
It seems you are confusing projects. This is flashrom. Nobody who hasn't contributed to this project before can just merge patches here. And we don't merge patches here hastily. The code your change is touching is part of the `internal` programmer, hence a regression here could brick machines. Changes to the code need many eyes and tests.