[PATCH v8 1/3] Runtime Interpreted Power Sequences

[Alexandre Courbot]

On Fri, Nov 16, 2012 at 9:25 PM, Anton Vorontsov <cbouatmailru at gmail.com> wrote:
>> The POWER_SEQ_*_TYPE macros are defined in the C files. It's the
>> simplest way to initialize this table, and the code inside these C
>> files is short and simple enough that I thought I would be forgiven.
>> :)
>
> I think in the header file you could just write
>
> extern ..... power_seq_delay_type;
> #ifndef ...
> #define power_seq_delay_type NULL
> #endif
>
> And then, in the .c file:
>
> static const struct power_seq_res_ops power_seq_ops[POWER_SEQ_NUM_TYPES] = {
>         [POWER_SEQ_DELAY] = power_seq_delay_type,
>         ...
> };
>
> And then you can stop including the .c files directly, and link them
> instead.

I have done something similar, but that avoids exporting resource ops
into the header file. I am still not satisfied with it though - I'd
rather have one init function per resource file that changes the
pointer of the ops table from NULL to its own set of functions. That
way the core could live without knowing anything about the different
resources, and that would be nicer. Unfortunately modules only support
one init function, so this is not doable here.

>> >nit: one variable declaration per line.
>>
>> Fair enough - but is that a convention? checkpatch.pl was happy with these.
>
> It's not a rule, although there is a small passage about it in CodingStyle
> file when it describes commenting style. Though, some folks choose to
> ignore this suggestion quite frequently, especially if variables have no
> comments.
>
> Often, the multiple declarations per line are used to hide ugly functions
> w/ tons of variables, or just to confuse the reader for the fun of it.
>
> There are exceptions, of course. E.g.
>
>         int i, j, k; /* Our iterators. */
>
> Is perfectly fine.
>
> But
>         int i, err;
>
> At least to me seems weird, this stuff is logically disjunct.
>
> Only human can truly differentiate when the stuff "looks better" together
> or apart, so that's why checkpatch doesn't complain. Personally, I use
> this rule of thumb: when in doubt, use just one declaration per line, it
> is always OK. :)

That totally makes sense - thanks for the precision.

Prepping another patchset with audience extended to linux-arm-kernel
as Mark suggested.

Alex.