Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/38209 ) Change subject: raiden_debug: Upstream ChromiumOS servo debug board prog ...................................................................... Patch Set 3: (5 comments) I like the USB code and its potential to unify programmer parameters. It belongs into a separate patch, though, to ease review. https://review.coreboot.org/c/flashrom/+/38209/3/raiden_debug_spi.c File raiden_debug_spi.c: https://review.coreboot.org/c/flashrom/+/38209/3/raiden_debug_spi.c@35 PS3, Line 35: * Software Foundation. I guess one could infer GPLv3 compatibility from the 3-clause above. But IANAL, so I better ask. Can we get this under "GPLv2 and later"? I try to encourage contributors to this because of libflashrom. Having a GPLv2- only library is not of much use these days (won't get better in the future, I guess). We are still far from a GPLv2+ flashrom core, though :-/ https://review.coreboot.org/c/flashrom/+/38209/3/raiden_debug_spi.c@154 PS3, Line 154: * maximum USB packet size for the device. NB. Writing and reviewing such comments takes much more time than fixing the interface, IMHO. https://review.coreboot.org/c/flashrom/+/38209/3/raiden_debug_spi.c@157 PS3, Line 157: command header maximum size That's kind of true, but highly confusing when one knows what the macros are actually referring to: JEDEC_BYTE_PROGRAM_OUTSIZE is the size of a full byte-program command not just a header. It's including the byte to be programmed. The calculation is correct nevertheless, because it matches the `header` of a 4BA byte programm. Anyway, it renders this paragraph useless, IMO. https://review.coreboot.org/c/flashrom/+/38209/3/usb_device.h File usb_device.h: https://review.coreboot.org/c/flashrom/+/38209/3/usb_device.h@64 PS3, Line 64: return
That kind of thing breaks people's internal parsers I agree, this macro is a blocker. Hidden control flow statements are not a good idea.
Also, the whole expression is not valid C. Turning a compound statement into an expression ({ ... }) is a GNU extension, IIRC. And with our limited compile testing, I wouldn't want to take any risks. Also, with an implementation in a C function, one doesn't have to repeat too much boilerplate, e.g. ret = libusb_control_transfer(...); if (usb_check_error(ret, "OMG, it failed")) return ret; I think that would be much easier to read than those CHECK(LIBUSB(libusb_... blocks. https://review.coreboot.org/c/flashrom/+/38209/3/usb_device.c File usb_device.c: https://review.coreboot.org/c/flashrom/+/38209/3/usb_device.c@35 PS3, Line 35: * Software Foundation. See `raiden_debug_spi.c`. -- To view, visit https://review.coreboot.org/c/flashrom/+/38209 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: flashrom Gerrit-Branch: master Gerrit-Change-Id: Ifad273a708acea4de797a0808be58960635a8864 Gerrit-Change-Number: 38209 Gerrit-PatchSet: 3 Gerrit-Owner: Edward O'Callaghan <quasisec@chromium.org> Gerrit-Reviewer: Angel Pons <th3fanbus@gmail.com> Gerrit-Reviewer: David Hendricks <david.hendricks@gmail.com> Gerrit-Reviewer: Edward O'Callaghan <quasisec@chromium.org> Gerrit-Reviewer: Nico Huber <nico.h@gmx.de> Gerrit-Reviewer: Patrick Georgi <pgeorgi@google.com> Gerrit-Reviewer: Stefan Reinauer <stefan.reinauer@coreboot.org> Gerrit-Reviewer: Vadim Bendebury <vbendeb@chromium.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply@coreboot.org> Gerrit-CC: Paul Menzel <paulepanter@users.sourceforge.net> Gerrit-Comment-Date: Fri, 17 Jan 2020 12:11:50 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Angel Pons <th3fanbus@gmail.com> Gerrit-MessageType: comment