On Mon, Jun 27, 2022 at 11:12:35AM +1000, Edward O'Callaghan wrote:
It is probably a good idea to create two branches but probably more for the sake of very old hardware not so easily accessible, par masters springs most to mind. Exceedingly old Intel/VIA could also be included although I am not sure which year to pick as the line in the sand there for 'old'? Specifically to freeze them on a branch and let them live out the rest of their life?
Is this about chipsets, or is this about programmers attached to network/storage devices?
If this is about chipsets, i do not understand the reasoning behind deprecation.
First, for context, i am the guy who introduced board enables to flashrom. I also came up with modesetting (which would have been better named "structured display driver development") while fixing, then cleaning up, then rewriting the display side of the via/unichrome driver. Which also led me to introduce the first fully native display initialization to coreboot, as back in the mid 2000s i was the only person who saw that it was possible to rid display drivers off of their shortsighted dependence on int10/vga/vesa.
When i tried flashrom on my unichrome based laptop (which was still alive the last time i tried), it turned off my backlight. So then it was clear that the chipset enable had to be split up.
I also am the author of the wild asus P5A board enable. This was just because i wanted to see how things were done with hardware a decade older. While this might sound like a good candidate for immediate deprecation, it turns out that the P5A is still a very popular retro-computing platform today.
Enough history.
From where i sit, as the guy who introduced structure in display drivers, flashrom is trivial.
1) Even though pci-ids were introduced in the 90s, and board ids were only really getting used properly (mostly) towards the end of that decade, pci-ids is still what we have today, even with the newest pcie standards. So detecting pci style devices has to work today, just as it did 25 years ago. Nothing changes there.
2) Since the hardware is this trivial, both chipset and superio enables are for whole families of chipsets, sometimes covering nearly a decades worth. If you really need to test the "bulk" of this code, all you need is one working example of what usually is a vast range of possible hardware. And if the chipset enable does break, it is much more likely that a user will file a bug report.
3) 90% of the time board enables is about gpio pins which need to be raised or lowered, and the code to do so is shared as well. If you break that code you usually break all the boards with the same family of chipsets.
4) chipset, superio and board enables are absolutely trivial. How anyone who is slightly dilligent could potentially break these is beyond me.
So no amount of rewriting the infrastructure should break older chipsets or board enables.
To me, this reeks of an unwillingness to deal with supporting slightly older hw, or to deal with chipsets/superios/boards at a time where we backslid into depending on BIOS hooks again.
Luc Verhaegen.