[flashrom] [PATCH] ichspi: use a variable to distinguish ich generations instead of spi_programmer->type

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Sun Nov 6 23:56:42 CET 2011


Am 03.11.2011 01:58 schrieb Stefan Tauner:
> The type member is enough most of the time to derive the wanted
> information, but
>  - not always (e.g. ich_set_bbar),
>  - only available after registration, which we want to delay till the
>    end of init, and
>  - we really want to distinguish between chipset version-grained
>    attributes which are not reflected by the registered programmer.
>
> Hence this patch introduces a new static variable which is set up
> early by the init functions and allows us to get rid of all "switch
> (spi_programmer->type)" in ichspi.c. We reuse the enum introduced
> for descriptor mode for the type of the new variable.
>
> Previously magic numbers were passed by chipset_enable wrappers. Now
> they use the enumeration items too. To get this working the enum
> definition had to be moved to programmer.h, which was fixed on the
> way by adding necessary includes.
>
> Another noteworthy detail: previously we have checked for a valid
> programmer/ich generation all over the place. I have removed those
> checks and added one single check in the init method. Calling any
> function of a programmer without executing the init method first, is
> undefined behavior.
>
> Signed-off-by: Stefan Tauner <stefan.tauner at student.tuwien.ac.at>

Excellent.

> On Wed, 02 Nov 2011 02:44:17 +0100
> Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>>> i think it might be a good idea to get rid of the whole
>>> switch(spi_programmer->type)
>>> pattern and create a file-scope static ich_generation variable instead
>>> of using the type member and the ich_generation parameters everywhere.  
>> Absolutely agreed.
>> The only possible generic problem with that approach would be the
>> registration of multiple ICH-style SPI programmers, but unless we see
>> boards with two active ICH-style southbridges I think we can assume the
>> static variable handles it well. (Note that boards with multiple MCP55
>> southbridges exist, but only one southbridge has an attached flash chip.)
> and even then they would have to be from different incompatible generations...
> i think we are quite safe ;)
>
>> There might be an issue for those who want to use flashrom as a
>> standalone tool (e.g. on top of  libpayload) where heap allocations for
>> static variables are unwanted, but that's a huge can of worms and I'd
>> rather ignore that issue until either static variables work well in that
>> environment or until someone hacks a way around static variables being a
>> problem there.
>>
>>> the type member is enough most of the time to derive the wanted
>>> information, but
>>> - not always (e.g. ich_set_bbar)
>>> - only available after registration, which we want to delay till the end
>>>   of init.
>>> - we really want to distinguish between chipset version-grained
>>>   attributes which are not reflected by the registered programmer.  
>> Indeed. So if you could rework the patch to use your static variable
>> suggestion, it would reduce patch size and make the code more readable.
> you may want to evaluate that "patch size" argument again... *sigh*

Heh.


> i have added the first applicable chipset to each default case for
> documentation purposes.

Good idea.

Please go ahead.
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/





More information about the flashrom mailing list