Re: [PATCH RESEND 2/2] wlcore: align member-assigns in a structure-copy block

From: Kalle Valo
Date: Thu Jan 15 2015 - 08:23:55 EST


Eliad Peller <eliad@xxxxxxxxxx> writes:

> On Fri, Jan 9, 2015 at 7:03 PM, Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote:
>> Giel van Schijndel <me@xxxxxxxxx> writes:
>>
>>> This highlights the differences (e.g. the bug fixed in the previous
>>> commit).
>>>
>>> Signed-off-by: Giel van Schijndel <me@xxxxxxxxx>
>>> ---
>>> drivers/net/wireless/ti/wlcore/acx.c | 22 +++++++++++-----------
>>> 1 file changed, 11 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ti/wlcore/acx.c b/drivers/net/wireless/ti/wlcore/acx.c
>>> index f28fa3b..93a2fa8 100644
>>> --- a/drivers/net/wireless/ti/wlcore/acx.c
>>> +++ b/drivers/net/wireless/ti/wlcore/acx.c
>>> @@ -1715,17 +1715,17 @@ int wl12xx_acx_config_hangover(struct wl1271 *wl)
>>> goto out;
>>> }
>>>
>>> - acx->recover_time = cpu_to_le32(conf->recover_time);
>>> - acx->hangover_period = conf->hangover_period;
>>> - acx->dynamic_mode = conf->dynamic_mode;
>>> - acx->early_termination_mode = conf->early_termination_mode;
>>> - acx->max_period = conf->max_period;
>>> - acx->min_period = conf->min_period;
>>> - acx->increase_delta = conf->increase_delta;
>>> - acx->decrease_delta = conf->decrease_delta;
>>> - acx->quiet_time = conf->quiet_time;
>>> - acx->increase_time = conf->increase_time;
>>> - acx->window_size = conf->window_size;
>>> + acx->recover_time = cpu_to_le32(conf->recover_time);
>>> + acx->hangover_period = conf->hangover_period;
>>> + acx->dynamic_mode = conf->dynamic_mode;
>>> + acx->early_termination_mode = conf->early_termination_mode;
>>> + acx->max_period = conf->max_period;
>>> + acx->min_period = conf->min_period;
>>> + acx->increase_delta = conf->increase_delta;
>>> + acx->decrease_delta = conf->decrease_delta;
>>> + acx->quiet_time = conf->quiet_time;
>>> + acx->increase_time = conf->increase_time;
>>> + acx->window_size = conf->window_size;
>>
>> I would like to get an ACK from one of the wlcore developers if I should
>> apply this (or not).
>
> I don't have a strong opinion here. However, it looks pretty much
> redundant to take a random blob (which was just fixed by a correct
> patch) and re-indent it. The rest of the file doesn't follow this
> style, so i don't see a good reason to apply it here.

Yeah, this should be a driver decision and not just a single change in
one function. Hence I'm dropping patch 2.

--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/