Attention is currently required from: Nico Huber, Edward O'Callaghan, Angel Pons.
4 comments:
Commit Message:
A good side-effect of the change is: 13 error paths of params
processing are not leaking data anymore. All those error paths
return 1 back to init function which frees data.
And there was just one more error path in init function were free(data)
needed to be added.
These are the actual changes. Everything else is a mere refactoring. […]
You are back!! This is awesome! :)
Done, I updated commit message.
Could add a […]
I haven't seen this tag before, is it used often? I saw people mention in commit message "follow-up something something that was introduced in CB:xxxxx" or similar. Can I do like this instead?
File dummyflasher.c:
/* Remove the #define below if you don't want SPI flash chip emulation. */
#define EMULATE_SPI_CHIP 1
IMO, both defines should just be dropped. If they were compile-time configs […]
Just to confirm, you mean, let's assume (EMULATE_CHIP && EMULATE_SPI_CHIP) always true and drop the code outside the #if? So that dummy will always be dummy_spi? But then maybe have another one dummy_par? Maybe someone needs those different values.
I don't know what was the initial meaning of !EMULATE_CHIP use case. What dummy is doing if it is not emulating any chip? I see it can emulate spi or par, I can understand, but not emulating anything?
File dummyflasher.c:
Patch Set #4, Line 994: dummy_buses_supported
Makes one wonder why this is not part of `emu_data`...
I was thinking about it, and my guess was, because it is only needed for init time, and not needed later. It would never be used as a part of emu_data.
Yes adding second parameter in init_data felt slightly awkward, but adding into emu_data and then never using it would also be...
To view, visit change 54748. To unsubscribe, or for help writing mail filters, visit settings.