Just to expand on what Jonathan wrote above: if you take a peek at theend result of the patch series, you will notice a pattern: constants ineach section are ordered alphabetically by their name. I wanted allsections to be consistently ordered. If you would rather have me orderthings by the bit index, sure, no problem, just please note that theorder above is not accidental.

> There is a lack of apparent consistency in the numeric mapping; for example,> OP_SET_EXT includes the OP_SET bit, but OP_GET_EXT does not include the> OP_GET bit. However, after inspecting the code I think this is simply> reflecting what the hardware expects.

Exactly, I could not find any rule which would explain the way theintegers hardcoded into the various firmware functions could be mappedto their purpose. The whole point of this series is just to givesomeone looking at the module code a quick hint about the purpose ofeach call; with plain integers used instead of constants, these callslook a bit too arbitrary for my taste.

> > And plain 0 doesn't look right in this concept (something like (0 <<> > 0) would probably do it).> > Given that all other definitions are in terms of BIT(), to my eye "(0 << 0)"> looks as much out of place as plain "0". However, if the convention in this> case would be to use the former then I have no objections. I presume the> "(0 << 0)" idea comes from the fact that BIT() ultimately expands to some> form of shift.

Yes, I would guess so. The syntax suggested by Andy looked odd andsuperfluous to me at first, but grepping the tree for this constructseems to suggest that it is a pretty common thing. So no problem, Iwill tweak this in v2. I understand I should apply the same concept inthese cases: