On Wed, 02 Nov 2011 04:53:22 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
We need a way to identify which registered programmer should be used for a given access. Especially for cases where multiple programmers for the same bus type are registered (e.g. IT87+MCP79 SPI or Dual BIOS solutions), probing has to happen on each programmer. Somehow we have to tell the dispatcher (spi_send_command etc.) this information, and the only way to get the info to the dispatcher is either an ugly global variable which makes dealing with multiple flash chips and multiple bus probing really messy, or we store the info inside struct flashchip. Given that struct flashchip is passed around almost everywhere already, it is the natural location for such information and only very few function prototypes have to be changed to handle this.
I have a prototype patch in the queue, but it's only half ready. If there is any interest, I can send the patch as is to give you an option to shoot it down while it is still unfinished.
changing prototypes should be no concern in such decisions imho. it is a one-time change that may break some patches in the queue (which is no problem, because there should be only a short queue, right? ;) but this should not play a major role in the design.
the reason i bring this argument up explicitly is that i think the name "flashchip" may get a bit abused and changing it might be better. that's not necessarily the case, i just wanted to criticize something, because else it sounds good at this level of detail ;)
another layer of redirection is - as always - also a possibility: introducing a new struct with pointers to the actual chip and the programmer to be used (and other information related to the actual situation/probing... e.g. access right ranges). but that's probably not needed (yet) and the splitting could be done later anyway if need be. OTOH if it is clear that there will be more information stuffed into struct flashchip, that is not really static and does not need to/should not reside in flashchips.c/struct flashchip, we may better discuss a separation now(?).