Attention is currently required from: Anjaneya "Reddy" Chagam, Patrick Rudolph, Jonathan Zhang, Christian Walter, Angel Pons, Arthur Heymans, Morgan Jang.
Jingle Hsu has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/50179 )
Change subject: mb/ocp/deltalake: Fill ECC type in romstage
......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1:
> It wasn't
I verified it's correct.
--
To view, visit https://review.coreboot.org/c/coreboot/+/50179
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I8370b3ee7d75914b895946b53923598adf87b522
Gerrit-Change-Number: 50179
Gerrit-PatchSet: 1
Gerrit-Owner: Angel Pons <th3fanbus(a)gmail.com>
Gerrit-Reviewer: Anjaneya "Reddy" Chagam <anjaneya.chagam(a)intel.com>
Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz>
Gerrit-Reviewer: Christian Walter <christian.walter(a)9elements.com>
Gerrit-Reviewer: Johnny Lin <Johnny_Lin(a)wiwynn.com>
Gerrit-Reviewer: Jonathan Zhang <jonzhang(a)fb.com>
Gerrit-Reviewer: Morgan Jang <Morgan_Jang(a)wiwynn.com>
Gerrit-Reviewer: Patrick Rudolph <patrick.rudolph(a)9elements.com>
Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-CC: Jingle Hsu <jingle_hsu(a)wiwynn.com>
Gerrit-Attention: Anjaneya "Reddy" Chagam <anjaneya.chagam(a)intel.com>
Gerrit-Attention: Patrick Rudolph <patrick.rudolph(a)9elements.com>
Gerrit-Attention: Jonathan Zhang <jonzhang(a)fb.com>
Gerrit-Attention: Christian Walter <christian.walter(a)9elements.com>
Gerrit-Attention: Angel Pons <th3fanbus(a)gmail.com>
Gerrit-Attention: Arthur Heymans <arthur(a)aheymans.xyz>
Gerrit-Attention: Morgan Jang <Morgan_Jang(a)wiwynn.com>
Gerrit-Attention: Patrick Rudolph <siro(a)das-labor.org>
Gerrit-Comment-Date: Thu, 04 Feb 2021 01:26:07 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Patrick Rudolph <patrick.rudolph(a)9elements.com>
Comment-In-Reply-To: Angel Pons <th3fanbus(a)gmail.com>
Gerrit-MessageType: comment
Attention is currently required from: HAOUAS Elyes.
Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/50268 )
Change subject: payloads/libpayload/arch/arm64/mmu.c: Fix typo in comment
......................................................................
Patch Set 1: Code-Review+2
--
To view, visit https://review.coreboot.org/c/coreboot/+/50268
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ieb10a881ef1d983f11318f0f6934491fd19fd0bf
Gerrit-Change-Number: 50268
Gerrit-PatchSet: 1
Gerrit-Owner: HAOUAS Elyes <ehaouas(a)noos.fr>
Gerrit-Reviewer: Julius Werner <jwerner(a)chromium.org>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-Attention: HAOUAS Elyes <ehaouas(a)noos.fr>
Gerrit-Comment-Date: Thu, 04 Feb 2021 01:15:35 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
Attention is currently required from: Martin Roth, chris wang.
Felix Held has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/50240 )
Change subject: soc/amd/picasso: add UPD for USB3 phy setting adjust
......................................................................
Patch Set 7:
(5 comments)
File src/soc/amd/picasso/chip.h:
https://review.coreboot.org/c/coreboot/+/50240/comment/781144cd_46590575
PS7, Line 75: #define USB3_PORT_COUNT 4
only true for dali/pollock. picasso has an additional usb3 port on xhci1, so this should be changed to 5; the devices with only 4 usb3 ports then just ignore the last one
https://review.coreboot.org/c/coreboot/+/50240/comment/c7e02b35_56d4f1e6
PS7, Line 258: uint8_t usb3_phy_en;
i wonder if just having one setting to enable all usb3 port overrides would be sufficient. if the override is not selected, then just the defaults are used, no no board will break if it doesn't have all those settings in the devicetree, and if not then just all values have to be provided? not sure if having enable bits for the various settings is something that's needed. haven't looked closely at the fsp patch though, so i'm not sure
https://review.coreboot.org/c/coreboot/+/50240/comment/b340a6d3_dfaf3253
PS7, Line 258: usb3_phy_en
usb3_phy_override would be a much more descriptive name.
from the name i'd assume that it's for enabling the usb3 part of the usb ports, which isn't what it does
File src/vendorcode/amd/fsp/picasso/FspsUpd.h:
https://review.coreboot.org/c/coreboot/+/50240/comment/b39c3f8a_a06aa5cf
PS7, Line 58: /** Offset 0x013D**/ uint8_t usb_3_port0_phy_tune[2];
: /** Offset 0x013F**/ uint8_t usb_3_port1_phy_tune[2];
: /** Offset 0x0141**/ uint8_t usb_3_port2_phy_tune[2];
: /** Offset 0x0143**/ uint8_t usb_3_port3_phy_tune[2];
you could do something like i did for the fch_usb_2_port_phy_tune setting above. that allows to just loop over the ports and apply the settings to the upd fields. i'm ok with both. feel free to keep it as it is right now and just ack this comment; that's someting that could be also done in the future.
https://review.coreboot.org/c/coreboot/+/50240/comment/6d8188ad_f783d3b7
PS7, Line 61: /** Offset 0x0143**/ uint8_t usb_3_port3_phy_tune[2];
there are 5 usb3 ports on the picasso chips; dali/pollock have 4 only. so there's the data structure for the last port missing
--
To view, visit https://review.coreboot.org/c/coreboot/+/50240
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I1d5f69e840952cc5171af1ce8597628d1bede5cb
Gerrit-Change-Number: 50240
Gerrit-PatchSet: 7
Gerrit-Owner: chris wang <Chris.Wang(a)amd.com>
Gerrit-Reviewer: Chris Wang <chris.wang(a)amd.corp-partner.google.com>
Gerrit-Reviewer: Felix Held <felix-coreboot(a)felixheld.de>
Gerrit-Reviewer: Jason Glenesk <jason.glenesk(a)gmail.com>
Gerrit-Reviewer: Marshall Dawson <marshalldawson3rd(a)gmail.com>
Gerrit-Reviewer: Raul Rangel <rrangel(a)chromium.org>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-CC: Martin Roth <martinroth(a)google.com>
Gerrit-Attention: Martin Roth <martinroth(a)google.com>
Gerrit-Attention: chris wang <Chris.Wang(a)amd.com>
Gerrit-Comment-Date: Thu, 04 Feb 2021 01:05:25 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Attention is currently required from: chris wang.
Felix Held has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/50212 )
Change subject: soc/amd/picasso: clean up and re-sort UPD table
......................................................................
Patch Set 7:
(1 comment)
Commit Message:
https://review.coreboot.org/c/coreboot/+/50212/comment/ba2f4115_602bca50
PS7, Line 32:
> For such changes, it is important to add Cq-Depend to ensure that when it lands in chromium tree, th […]
since the fsp side change to use the upds isn't merged yet, only the change id of this patch in the cros review system really needs to be added to the fsp-side patch in there as cq-depend. if there are incompatible upd changes, it's important to add the circular cq-depends tags in both patches and the one on the fsp patch canonly be added when the coreboot one is already submitted in upstream and pulled into the cros repos. since that has a bit more potential for disaster, i wanted to have everything in good shape before the fsp patch gets merged. but if in doubt ask Furquan or Martin about the cros commit queue dependency thing; i think i just pinged them when i needed to make an incompatible upd change when there were already images for zork devices built automatically
--
To view, visit https://review.coreboot.org/c/coreboot/+/50212
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I655af08e2f86398d088e30d330f49e71cf7e1275
Gerrit-Change-Number: 50212
Gerrit-PatchSet: 7
Gerrit-Owner: chris wang <Chris.Wang(a)amd.com>
Gerrit-Reviewer: Chris Wang <chris.wang(a)amd.corp-partner.google.com>
Gerrit-Reviewer: EricR Lai <ericr_lai(a)compal.corp-partner.google.com>
Gerrit-Reviewer: Felix Held <felix-coreboot(a)felixheld.de>
Gerrit-Reviewer: Jason Glenesk <jason.glenesk(a)gmail.com>
Gerrit-Reviewer: Marshall Dawson <marshalldawson3rd(a)gmail.com>
Gerrit-Reviewer: Martin Roth <martinroth(a)google.com>
Gerrit-Reviewer: Raul Rangel <rrangel(a)chromium.org>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-CC: 9elements QA <hardwaretestrobot(a)gmail.com>
Gerrit-CC: Frank Wu <frank_wu(a)compal.corp-partner.google.com>
Gerrit-CC: Furquan Shaikh <furquan(a)google.com>
Gerrit-CC: John Su <john_su(a)compal.corp-partner.google.com>
Gerrit-Attention: chris wang <Chris.Wang(a)amd.com>
Gerrit-Comment-Date: Thu, 04 Feb 2021 00:37:09 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Furquan Shaikh <furquan(a)google.com>
Gerrit-MessageType: comment
9elements QA has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/50243 )
Change subject: amd/common/block/acpi/pm_state: fix comparison in get_index_bit
......................................................................
Patch Set 3:
Automatic boot test returned (PASS/FAIL/TOTAL): 4/1/5
"HP Z220 SFF Workstation" (x86_32) using payload LinuxBoot_BusyBox_kexec : FAIL : https://lava.9esec.io/r/40999
"QEMU x86 q35/ich9" (x86_32) using payload SeaBIOS : SUCCESS : https://lava.9esec.io/r/40995
"QEMU x86 i440fx/piix4" (x86_64) using payload SeaBIOS : SUCCESS : https://lava.9esec.io/r/40994
"QEMU x86 i440fx/piix4" (x86_32) using payload SeaBIOS : SUCCESS : https://lava.9esec.io/r/40993
"QEMU AArch64" using payload LinuxBoot_u-root_kexec : SUCCESS : https://lava.9esec.io/r/40992
Please note: This test is under development and might not be accurate at all!
--
To view, visit https://review.coreboot.org/c/coreboot/+/50243
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I6ca341841bad62abcb4ea26a350c539813a29de7
Gerrit-Change-Number: 50243
Gerrit-PatchSet: 3
Gerrit-Owner: Felix Held <felix-coreboot(a)felixheld.de>
Gerrit-Reviewer: Felix Held <felix-coreboot(a)felixheld.de>
Gerrit-Reviewer: Jason Glenesk <jason.glenesk(a)gmail.com>
Gerrit-Reviewer: Kyösti Mälkki <kyosti.malkki(a)gmail.com>
Gerrit-Reviewer: Marshall Dawson <marshalldawson3rd(a)gmail.com>
Gerrit-Reviewer: Raul Rangel <rrangel(a)chromium.org>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-CC: 9elements QA <hardwaretestrobot(a)gmail.com>
Gerrit-Comment-Date: Thu, 04 Feb 2021 00:33:14 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Attention is currently required from: Furquan Shaikh, Meera Ravindranath, Andrey Petrov, Patrick Rudolph, Felix Held.
Marshall Dawson has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/50241 )
Change subject: drivers/intel/fsp2_0/memory_init: check if UPD struct has expected size
......................................................................
Patch Set 1:
(1 comment)
File src/drivers/intel/fsp2_0/memory_init.c:
https://review.coreboot.org/c/coreboot/+/50241/comment/d1370e1e_a3a84b85
PS1, Line 242: !=
What about <= instead of !=? Assuming UPD only grows at the end, that would allow flexibility to update the binaries, then update the header file to match.
--
To view, visit https://review.coreboot.org/c/coreboot/+/50241
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ia7e9f6f20d0091bbb4abfd42abb40b485da2079d
Gerrit-Change-Number: 50241
Gerrit-PatchSet: 1
Gerrit-Owner: Felix Held <felix-coreboot(a)felixheld.de>
Gerrit-Reviewer: Andrey Petrov <andrey.petrov(a)gmail.com>
Gerrit-Reviewer: Furquan Shaikh <furquan(a)google.com>
Gerrit-Reviewer: Justin Frodsham <justin.frodsham(a)amd.corp-partner.google.com>
Gerrit-Reviewer: Marshall Dawson <marshalldawson3rd(a)gmail.com>
Gerrit-Reviewer: Meera Ravindranath <meera.ravindranath(a)intel.com>
Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org>
Gerrit-Reviewer: Subrata Banik <subrata.banik(a)intel.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-Attention: Furquan Shaikh <furquan(a)google.com>
Gerrit-Attention: Meera Ravindranath <meera.ravindranath(a)intel.com>
Gerrit-Attention: Andrey Petrov <andrey.petrov(a)gmail.com>
Gerrit-Attention: Patrick Rudolph <siro(a)das-labor.org>
Gerrit-Attention: Felix Held <felix-coreboot(a)felixheld.de>
Gerrit-Comment-Date: Thu, 04 Feb 2021 00:29:40 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Felix Held has submitted this change. ( https://review.coreboot.org/c/coreboot/+/50243 )
Change subject: amd/common/block/acpi/pm_state: fix comparison in get_index_bit
......................................................................
amd/common/block/acpi/pm_state: fix comparison in get_index_bit
In the case of passing 32 as limit the code returned -1, but should have
continued, since 32 is a valid value here.
Signed-off-by: Felix Held <felix-coreboot(a)felixheld.de>
Change-Id: I6ca341841bad62abcb4ea26a350c539813a29de7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50243
Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org>
Reviewed-by: Raul Rangel <rrangel(a)chromium.org>
---
M src/soc/amd/common/block/acpi/pm_state.c
1 file changed, 1 insertion(+), 1 deletion(-)
Approvals:
build bot (Jenkins): Verified
Raul Rangel: Looks good to me, approved
diff --git a/src/soc/amd/common/block/acpi/pm_state.c b/src/soc/amd/common/block/acpi/pm_state.c
index a009718..05bb927 100644
--- a/src/soc/amd/common/block/acpi/pm_state.c
+++ b/src/soc/amd/common/block/acpi/pm_state.c
@@ -13,7 +13,7 @@
uint16_t i;
uint32_t t;
- if (limit >= TOTAL_BITS(uint32_t))
+ if (limit > TOTAL_BITS(uint32_t))
return -1;
/* get a mask of valid bits. Ex limit = 3, set bits 0-2 */
--
To view, visit https://review.coreboot.org/c/coreboot/+/50243
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I6ca341841bad62abcb4ea26a350c539813a29de7
Gerrit-Change-Number: 50243
Gerrit-PatchSet: 3
Gerrit-Owner: Felix Held <felix-coreboot(a)felixheld.de>
Gerrit-Reviewer: Felix Held <felix-coreboot(a)felixheld.de>
Gerrit-Reviewer: Jason Glenesk <jason.glenesk(a)gmail.com>
Gerrit-Reviewer: Kyösti Mälkki <kyosti.malkki(a)gmail.com>
Gerrit-Reviewer: Marshall Dawson <marshalldawson3rd(a)gmail.com>
Gerrit-Reviewer: Raul Rangel <rrangel(a)chromium.org>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-MessageType: merged
Attention is currently required from: Michael Niewöhner.
Benjamin Doron has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/49140 )
Change subject: soc/intel/skylake/acpi: Add PEP table
......................................................................
Patch Set 3:
(1 comment)
Commit Message:
https://review.coreboot.org/c/coreboot/+/49140/comment/a271556e_53f686fd
PS3, Line 11:
> > > > > > > > > Awesome, then at least S0ix states work just fine.
> > > > > > > > >
> > > > > > > > > That error message comes from the kernel SlpS0 self-test. So, let's test something. I assume `cat /sys/power/mem_sleep` has `s2idle` selected? (With s0ix_enable=1 it should. If not, we have another problem.)
> > > > > > > >
> > > > > > > > Yes. (I think that's based on the FADT)
> > > > > > >
> > > > > > > Right, there is some bit in FADT for that.
> > > > > > >
> > > > > > > >
> > > > > > > > > Does your system stay in sleep after executing `echo freeze >/sys/power/state`?
> > > > > > > >
> > > > > > > > Is the alternative that it wakes immediately? Then yes, it stays in sleep. However, when it does wake, it has always been unlocked. I don't know if that's relevant.
> > > > > > >
> > > > > > > Unlocked vs. locked is user-space and depends on the desktop environment. XFCE has an option for locking before going to sleep but that only works when sleep was initiated from the DE.
> > > > > >
> > > > > > That makes sense; I thought it might have been a possibility.
> > > > > >
> > > > > > > If it wakes immediately with that error, the self-test failed. I'm surprised to see the self-test fail *without* immediate wake, though.... Maybe we have to exclude the SlpS0 state from the table LPIT, when s0ix is not supported on a board :S Could you test this, please? Insert a "return" right before the comment "System (Slp_S0) residency counter" in `src/soc/intel/common/block/acpi/lpit.c` and see if the error disappears.
> > > > > >
> > > > > > Based on https://01.org/blogs/qwang59/2020/linux-s0ix-troubleshooting, PC10 without S0ix residency is a possible case. If I understand correctly, that situation would be what I see with this board: No S0ix/failed self-test, but PC10 residency/no immediate wake. I will attempt to troubleshoot that sometime by disabling devices, I suppose, following that link.
> > > > > >
> > > > > > I'm also not certain what you mean. If S0ix is disabled, would LPIT factor? Besides, if S0ix does relate to hardware state, but not board-design, shouldn't LPIT always advertise both PC10 residency and system residency to warn about broken S0ix support for a board?
> > > > >
> > > > > Well, yes PC10 without S0ix is possible. s0ix_enable means means "PC10 and/or SlpS0 possible". Note that SlpS0 is a substate of s0ix but s0ix != SlpS0.
> > > > >
> > > > > The LPIT table contains two entries, one for PC10 (the first one) and SlpS0 (the second one. Based on these entries, the OS decides what *actually* is possible. When PC10 and SlpS0 is advertised but SlpS0 doesn't work, that error triggers. So, I want to test what happens, when SlpS0 is not advertised, because it doesn't apply to your board.
> > > >
> > > > I see the same error.
> > >
> > > Strange....
> >
> > I can double-check.
> >
> > > >
> > > > Additionally, I noticed while looking over the vendor firmware's LPIT table that it defines the PC10 subtable twice, if I'm reading it correctly (two copies of address 0x632 as "FunctionalFixedHW" - the PKG_C10_RESIDENCY MSR?). Even so, the kernel warns that the system was unable to enter PC10.
> > >
> > > Oh yeah, I've seen that too somewhere but I doubt that's correct.
> > >
> > > >
> > > > So, while I was initially surprised to hear that SlpS0 might not apply to my board, perhaps that is the case. I can always try to troubleshoot some other time.
> > > >
> > > > > > But regardless: `return` or `return current`? The PC10 residency counter portion does increment "current"
> > > > >
> > > > > Yes, you're right, it should be `return current` ofc :-)
> > > >
> > > > Was this only for testing, or do you think that the S0ix subtable should only be advertised if S0ix is known to work?
> > >
> > > Very good question. S0ix isn't documented very good but I wouldn't advertise something that isn't usable. However, that will require us to introduce a dt option `slps0_supported`. That's already planned but I currently have higher-prio stuff. I'll come back to that asap. If you're curious, have a look on my WIP patches on s0ix.
> > >
> > > Since it doesn't seem to make a difference irt that error/warning, let's keep it as-is for now and resolve that as soon as I get back to these patches. Wdyt?
> >
> > The warning is informative and not harmful, so that's fine by me.
> >
> > > > If S0ix can be temperamental, I think that the OS should always be able to warn about errors.
> > >
> > > Well, when the board does not support SlpS0 (= SlpS0 is unconnected) I wouldn't want the OS to warn about it. That warning/error is triggered by the S0ix self-test, which may also be buggy btw.
> >
> > Ah. If the pad being disconnected means that lower S0ix states aren't possible, then there might not be anything to debug.
>
> Wait... I had some knot in my brain. SlpS0 wouldn't *do* anything (b/c it's nc) but it should still be asserted and that error is telling us that it isn't.
I have `PAD_CFG_TERM_GPO(GPP_B12, 1, DN_20K, DEEP),` for SLP_S0# in the gpio.c for my board, I can change it to "UP_20K" if it won't cause problems with the PMC.
> We just don't know yet, why the error is triggered, when SlpS0 is not advertised... *That* could be the bug here, which would be in the kernel. So, we need to check if Linux only checks the FADT flag or differentiates C10-only and SlpS0 devices.
I'll double-check this. Regarding the kernel, it appears it uses the default address if LPIT doesn't advertise one (https://github.com/torvalds/linux/blob/master/drivers/platform/x86/intel_pm…).
> > > > Sorry it took me so long to get back to you.
> > >
> > > No problem :-)
> > >
> > >
> > > So... last question - I hope I didn't ask that already, but I haven't seen it above. Is this patch the cause for that error message or does the error message appear even without it?
> >
> > The error is produced by the intel_pmc_core driver, which is only loaded if the PEP table is present?
>
> Oh right... that was it :/
--
To view, visit https://review.coreboot.org/c/coreboot/+/49140
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I08d8c1fde4f447e9292a0508649f802fdc2721e1
Gerrit-Change-Number: 49140
Gerrit-PatchSet: 3
Gerrit-Owner: Benjamin Doron <benjamin.doron00(a)gmail.com>
Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com>
Gerrit-Reviewer: Benjamin Doron <benjamin.doron00(a)gmail.com>
Gerrit-Reviewer: Michael Niewöhner <foss(a)mniewoehner.de>
Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-Attention: Michael Niewöhner <foss(a)mniewoehner.de>
Gerrit-Comment-Date: Wed, 03 Feb 2021 23:23:40 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Benjamin Doron <benjamin.doron00(a)gmail.com>
Comment-In-Reply-To: Michael Niewöhner <foss(a)mniewoehner.de>
Gerrit-MessageType: comment