Hey guys,

Sorry for the delays in response due to local issues here..

Thanks for spotting this issue that slipped through the cracks. I actually think this came about from a local merge conflict resolution. We had breakages internally for all sorts of random reasons as well while trying the other way around to bring the higher quality upstream code back down into our tree. :<

I am working locally on building out a test infrastructure that uses EM100's to emulate flashchips and a bunch of different Chromebooks to exercise flashrom more. The idea I have is to turn this into a upstream CI bot somehow but I have to work out how that would work in practice and if it is sufficient to use EM100's to test most things? The problem with QEMU is that only a limited chipset range is there so I guess that would only exercise the core flashrom logic itself? I am open to more ideas on what we need as a community setup to help catch these things better than having breakage merged which is less than ideal!

Kind Regards,

On Mon, Jan 20, 2020 at 8:32 AM Angel Pons <th3fanbus@gmail.com> wrote:

On Sat, Jan 18, 2020 at 7:31 PM Nico Huber <nico.h@gmx.de> wrote:
> Hi,
> On 14.01.20 17:10, Carl-Daniel Hailfinger wrote:
> > commit e28d75ed7204d7fac2c0fac13978098530b0574e dropped some logic
> > during refactoring.
> > PCI-based programmers now fail to initialize IFF the desired PCI device
> > not the last one enumerated by libpci.
> yup, I already commented on that change post-merge. Just waited for the
> holidays to pass, no reaction after all so I pushed a revert:
> https://review.coreboot.org/c/flashrom/+/38319

I noticed the revert today. I'm not sure what unit tests are good for
without, for example, regression tests on hardware.

> Nico
> _______________________________________________
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-leave@flashrom.org

Best regards,