Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/38221 )
Change subject: soc/amd/picasso: Drop forked copy of SMBus source ......................................................................
Patch Set 4:
Kyosti, you are stepping WAY over the line here. You need to follow the code of conduct and the guidelines for gerrit. If you need to vent, choose a more professional way to do it.
Surprisingly, I agree. And it is the leaderships' role to assess the situation as you Martin are also intimely involved in the review and merge-process of amd/picasso.
Aside the ad-hominem here, please pinpoint some commits, where you find I have not followed gerrit guidelines. In search of these, I found some comments where I specifically state that I shall not -2 amd/picasso work, nor do I feel I have enough authority to +2 any works that touch arch/x86. Being restricted to leaked and partially outdated documentation around AMD Secure Processor, it's actually impossible for most members of the community to do any purposeful review on amd/picasso. When possible, I have tried to forward the works I found confusing or overly complicated, to certain senior Google developers to have a look at instead. There is little I can do if they are too busy dealing with their other projects and Your patchtrain gets stalled due to that.
There's is really nothing I can do about the delays caused for the cases where You agree that my -1 review was actually spot-on and You decide to refactor things, and then someone from Google or community side comes up with different ideas. I acknowledge I don't possess the authority to block things on amd/picasso and I have many times adviced You to get second opinions should You find that my REQUESTS, not DEMANDS, cause overloads and disturbance on Your workflow. Sadly from Your perspective, seems like I am often able to find some senior developer to agree with my reasoning.
My request for coreboot leadership is to make a statement that src/arch/x86 integrity and future maintainability is guaranteed by (in-)formally requiring more authority to merge commits there.
I never "PROMISED" you anything. I don't control AMD. Both Marshall and I are WORKING on getting you a CRB. It's gone through AMD legal and I believe it has been okayed, but with the attitude displayed here, I see no reason that ANYONE would want to work with you in any fashion.
That's all I'm saying here.
90% of the confrontations I have had in the last 10 or so years are about stalled maintenance or review processes on AMD codebase in coreboot proper. You are entitled to Your opinion that my review work has no value. You can then revisit AGESA boards and realise that in terms of lines-of-code their footprint has been reduced by some 70% per board from the state AMD and SAGE originally shipped them in. It is largely due to AMD licensing that binaryPI is in the shape You see it.
Enforcing APIs will always be painful to vendors with deadlines. Yet that is exactly what is required to achieve any longterm design evolution like dropping LATE_CBMEM_INIT and CAR_GLOBAL and ROMCC like was done in the fall of 2019. Discussion on the mailing list hopefully gets us all back-on-the track wrt. technical details.