[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <440b1e9e-cba7-4716-a78e-570dbc733606@quicinc.com>
Date: Wed, 12 Jun 2024 18:35:55 +0800
From: quic_zijuhu <quic_zijuhu@...cinc.com>
To: Johannes Berg <johannes@...solutions.net>, <davem@...emloft.net>,
<edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
<emmanuel.grumbach@...el.com>
CC: <linux-wireless@...r.kernel.org>, <netdev@...r.kernel.org>
Subject: Re: [PATCH v1 2/2] net: rfkill: Fix a logic error within
rfkill_set_hw_state_reason()
On 6/12/2024 6:18 PM, Johannes Berg wrote:
> On Fri, 2024-06-07 at 22:40 +0800, Zijun Hu wrote:
>> Kernel API rfkill_set_hw_state_reason() wrongly gets previous block state
>> by using its parameter @reason as reason mask.
>>
>> Fixed by using @reason_mask as reason mask.
>>
>
> Actually, this *introduces* a bug. I'll leave it to you to figure out
> what that is, I'm not convinced that you're actually doing *anything*
> useful here.
>
i feels that current logic is weird and it is very difficult to
understand when i read rfkill code.
i think it deserves a comments for current logic if it is right.
current logic was introduced by below code applet of the commit
Commit: 14486c82612a ("rfkill: add a reason to the HW rfkill state")
- prev = !!(rfkill->state & RFKILL_BLOCK_HW);
- if (blocked)
+ prev = !!(rfkill->hard_block_reasons & reason);
+ if (blocked) {
rfkill->state |= RFKILL_BLOCK_HW;
i maybe need to find history to try to understand current logic if it is
right.
> johannes
Powered by blists - more mailing lists