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

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Stefan,

stefan@datenfreihafen.org wrote on Wed, 2 Feb 2022 13:17:39 +0100:

> Hello.
> 
> On 02.02.22 08:40, Miquel Raynal wrote:
> > Hi Stefan,
> > 
> > stefan@datenfreihafen.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 ;)

Thanks,
Miquèl