linux-kernel - Re: [PATCH 3/3] ath6kl: Reduce scopes for two variables in ath6kl_sdio_power

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45f6c8a7-4021-483a-aa81-a836cd3fbcd8@web.de>
Date: Mon, 23 Sep 2024 19:00:05 +0200
From: Markus Elfring <Markus.Elfring@....de>
To: Jeff Johnson <quic_jjohnson@...cinc.com>, linux-wireless@...r.kernel.org,
 Kalle Valo <kvalo@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Julia Lawall
 <julia.lawall@...ia.fr>, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 3/3] ath6kl: Reduce scopes for two variables in
 ath6kl_sdio_power_on()

>> Adjust the definitions for the local variables "func" and "ret"
>> so that the corresponding setting will be performed a bit later.
…
>> +++ b/drivers/net/wireless/ath/ath6kl/sdio.c
>> @@ -503,17 +503,15 @@ static void ath6kl_sdio_irq_handler(struct sdio_func *func)
>>  static int ath6kl_sdio_power_on(struct ath6kl *ar)
>>  {
>>  	struct ath6kl_sdio *ar_sdio = ath6kl_sdio_priv(ar);
>> -	struct sdio_func *func = ar_sdio->func;
>> -	int ret = 0;
>>
>>  	if (!ar_sdio->is_disabled)
>>  		return 0;
>>
>>  	ath6kl_dbg(ATH6KL_DBG_BOOT, "sdio power on\n");
>> -
>> +	struct sdio_func *func = ar_sdio->func;
>>  	sdio_claim_host(func);
>>
>> -	ret = sdio_enable_func(func);
>> +	int ret = sdio_enable_func(func);
>>  	sdio_release_host(func);
>>  	if (ret) {
>>  		ath6kl_err("Unable to enable sdio func: %d)\n", ret);
>> --
>> 2.46.0
>
> NAK
>
> no maintainer wants to spend time on patches like this which bring no real
> value to code that is not actively being maintained, and which violates the
> established understanding that, except under certain recently established
> criteria, declarations and code should not be interleaved.
…

Would you find other software design options more acceptable for further
collateral evolution?

1. Additional compound statements (by using extra curly brackets)

2. Moving a bit of source code into an additional function implementation


Regards,
Markus