[flashrom] [RFC] Add struct flashchip * everywhere

[Stefan Tauner]

On Wed, 02 Nov 2011 04:53:22 +0100
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at 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(?).

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner