netdev - Re: [PATCH wpan-next v2 5/5] net: ieee802154: Drop duration settings when the core does it already

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]

Date:   Wed, 2 Feb 2022 18:07:11 +0100
From:   Stefan Schmidt <stefan@...enfreihafen.org>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Alexander Aring <alex.aring@...il.com>, linux-wpan@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Michael Hennerich <michael.hennerich@...log.com>,
        Varka Bhadram <varkabhadram@...il.com>,
        Xue Liu <liuxuenetmail@...il.com>, Alan Ott <alan@...nal11.us>
Subject: Re: [PATCH wpan-next v2 5/5] net: ieee802154: Drop duration settings
 when the core does it already


Hello.

On 02.02.22 14:50, Miquel Raynal wrote:
> Hi Stefan,
> 
> stefan@...enfreihafen.org wrote on Wed, 2 Feb 2022 13:17:39 +0100:
> 
>> Hello.
>>
>> On 02.02.22 08:40, Miquel Raynal wrote:
>>> Hi Stefan,
>>>
>>> stefan@...enfreihafen.org wrote on Tue, 1 Feb 2022 21:51:04 +0100:
>>>    
>>>> Hello.
>>>>
>>>> On 01.02.22 18:40, Miquel Raynal wrote:
>>>>> Hi,
>>>>>     >>>> --- a/drivers/net/ieee802154/ca8210.c
>>>>>> +++ b/drivers/net/ieee802154/ca8210.c
>>>>>> @@ -2978,7 +2978,6 @@ static void ca8210_hw_setup(struct ieee802154_hw *ca8210_hw)
>>>>>>     	ca8210_hw->phy->cca.mode = NL802154_CCA_ENERGY_CARRIER;
>>>>>>     	ca8210_hw->phy->cca.opt = NL802154_CCA_OPT_ENERGY_CARRIER_AND;
>>>>>>     	ca8210_hw->phy->cca_ed_level = -9800;
>>>>>> -	ca8210_hw->phy->symbol_duration = 16 * NSEC_PER_USEC;
>>>>>>     	ca8210_hw->phy->lifs_period = 40;
>>>>>>     	ca8210_hw->phy->sifs_period = 12;
>>>>>
>>>>> I've missed that error                ^^
>>>>>
>>>>> This driver should be fixed first (that's probably a copy/paste of the
>>>>> error from the other driver which did the same).
>>>>>
>>>>> As the rest of the series will depend on this fix (or conflict) we could
>>>>> merge it through wpan-next anyway, if you don't mind, as it was there
>>>>> since 2017 and these numbers had no real impact so far (I believe).
>>>>
>>>> Not sure I follow this logic. The fix you do is being removed in 4/4 of your v3 set again. So it would only be in place for these two in between commits.
>>>
>>> Exactly.
>>>    
>>>> As you laid out above this has been in place since 2017 and the number have no real impact. Getting the fix in wpan-next to remove it again two patches later would not be needed here.
>>>>
>>>> If you would like to have this fixed for 5.16 and older stable kernels I could go ahead and apply it to wpan and let it trickle down into stable trees.
>>>
>>> I'm fine "ignoring" the issue in stable kernels, it was just a warning
>>> for you that this would happen otherwise, given the fact that this is
>>> the second driver doing so (first fix has already been merged) and that
>>> I just realized it now.
>>>    
>>>> We would have to deal with either a merge of net into net-next or with
>>>> a merge conflicts when sending the pull request. Both can be done.
>>>>
>>>> But given the circumstances above I have no problem to drop this fix completely and have it fixed implicitly with the rest of the patchset.
>>>
>>> Fine by me!
>>
>> Let's do it like this.
>> You drop it from this series against wpan-next.
>> I will pull it out of the series and apply to wpan directly. That way we get it into the stable kernels as well. You already did the work so we should not waste it.
>> I will deal with the merge conflict get get between wpan/net and wpan-next/net-next on my side. Nothing to worry for you.
> 
> That's very kind, but don't feel forced to do that, I won't turn mad if
> you finally decide that this requires too much handling for such a
> short-in-time improvement ;)

Nah, don't worry. I just applied it to wpan. It's the right thing to do 
as we simply do not know who is using the driving in what situation. 
Holding off a fix that you already did would be silly.

I deal with the merge conflict when it comes to it.

regards
Stefan Schmidt