Hello,
Thanks for the feedback > In this scenario, do you know which programmer is physically connected? Yes! I *can* pass -p, but today I already need to write a wrapper script to detect which adapter is connected and map it to the correct programmer name. > What if the wrong programmer is connected? That risk already exists today. Passing -p ch341a_spi does not magically guarantee I plugged the right device when i have ch371 there, it just tells me that programmer is not detected. Auto-detection can *reduce* mistakes by printing: Detected programmer "ch341a_spi" (VID:PID ...) > USB programmers only ? Yes, that a safe bet, we ignore even ambiguous protocol-compatible like Hydrabus and BusPirate 3 (detected as normal FTDI). Only devices with a clear VID/PID match should be considered. > Command line flag? I don’t think a flag is the right UX here. The behavior would be: 1. If -p is provided -> use it (no change) 2. Else if default programmer is configured -> use it (no change too) 3. Enumarate USB and autoselect if there is just ONE. (If multiple programmers are connected, we cancel). > how the workflow looks like... I don’t swap programmers for convenience, i do because of *electrical constraints*. • If I use a CH341A on a 1.8V chip -> I fry it • If I use a CH347 on a noisy board => I get garbage reads • Some programmers handle 0.8V–3.3V -> but they are not always on my desk So the workflow is: 1. Look at the chip / board / datasheet 2. Pick the correct programmer for *that* situation 3. Plug it in 4. Run the command I'm not alone facing this problem, i can find multiple youtube videos where presenter either had to cut the video after spending too much time debugging connection, or had to retype the programmer name. On Sat, 11 Apr 2026, at 11:52, Anastasia Klimchuk wrote: > Hello Abdelkader, > > Thank you for posting your idea! I want to understand some more > details about it. > > > I rotate between multiple USB programmers depending on signal quality or > > sockets i have handy. > > Exactly one supported USB programmer is physically connected. > > In this scenario, do you (the person who runs flashrom) know which > programmer is the one that physically connected? If you know which > programmer it is, could you provide it in -p parameter? I understand > that it makes command line longer, but also it makes it safer. > The picture in my head was that you have several programmers on the > table in front of you and switching between them. What if you think > you have one connected but actually a different one is connected, and > then with auto-select programmer you could realise that half-way > through flashing... > > Do you envision the feature for USB programmers only? This would > narrow down the idea (not looking at all of 40+ programmers) > > Another thing is: that would need to have a command line option > (--auto-select-usb-device or something), so that the feature would > only be enabled by the option. This way the standard command line > keeps the same behaviour. But for you this would mean to add > --auto-select-usb-device for each command line invocation - which > makes it longer again? > > It would also be very interesting to know if there are other people > who switch between different USB programmers, how the workflow looks > like, would you use the feature? > > > On Tue, Mar 31, 2026 at 7:53 AM Abdelkader Boudih <[email protected]> wrote: > > > > Hi again, > > > > This need email since look like "behaviour change" , but we just entered > > 1.8.0. > > > > Here is the context: > > > > flashrom supports default_programmer_name for users who always use the same > > programmer. (it also a compile time default, not available in distro). > > > > That's not my workflow. I rotate between multiple USB programmers depending > > on signal quality or sockets i have handy. > > > > When flashrom is invoked without --programmer and no default is configured, > > it exits and lists all compiled programmers. > > > > That is correct when there is ambiguity. > > > > However, in many practical cases there isn't: > > > > Exactly one supported USB programmer is physically connected. > > Its VID/PID is known. > > flashrom already has the identification logic inside each programmer driver. > > > > Yet the user must still specify -p. > > > > The proposal , and i already have the patch ready. > > > > When invoked without --programmer, flashrom should: > > > > Enumerate connected USB devices. > > Match them against the known programmer VID/PID entries. > > If exactly one supported programmer is detected: > > > > Auto-select it. > > Print a clear informational message. > > Proceed normally. > > > > > > This will ignore the internal programmer (we don't want read the bios of > > the host machine).. it will also not work for programmers like serprog or > > programmers that are compatible with others protocol (example hydrabus). > > > > Flashrom will become frictionless in that part: > > ``` > > $ flashrom -r dump.bin > > Detected programmer "ch341a_spi" > > ``` > > > > Manual override still works (to apply speed and other settings). > > > > Overall this approach could be wrong, because i did not try it with every > > programmer in the list + i could be missing some important details. > > > > Looking forward to get feed back so i open or no a gerrit patch. > > > > Regards > > > > Abdelkader > > _______________________________________________ > > flashrom mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > > > -- > Anastasia. >
_______________________________________________ flashrom mailing list -- [email protected] To unsubscribe send an email to [email protected]
