Subject: Re: [net-next 01/18] ieee802154: hwsim: Ensure proper channel selection at probe time

From: Miquel Raynal <[email-masked]>
Date: Tue, 4 Jan 2022 16:44:49 +0100

Hi Alexander,

[email-masked] wrote on Tue, 28 Dec 2021 16:05:43 -0500:

> Hi,
> 
> On Wed, 22 Dec 2021 at 10:57, Miquel Raynal <[email-masked]> wrote:
> >
> > A default channel is selected by default (13), let's clarify that this
> > is page 0 channel 13. Call the right helper to ensure the necessary
> > configuration for this channel has been applied.
> >
> > So far there is very little configuration done in this helper but we
> > will soon add more information (like the symbol duration which is
> > missing) and having this helper called at probe time will prevent us to
> > this type of initialization at two different locations.
> >  
> 
> I see why this patch is necessary because in later patches the symbol
> duration is set at ".set_channel()" callback like the at86rf230 driver
> is doing it.
> However there is an old TODO [0]. I think we should combine it and
> implement it in ieee802154_set_channel() of "net/mac802154/cfg.c".
> Also do the symbol duration setting according to the channel/page when
> we call ieee802154_register_hw(), so we have it for the default
> settings.

While I totally agree on the background idea, I don't really see how
this is possible. Every driver internally knows what it supports but
AFAIU the core itself has no easy and standard access to it?

Another question that I have: is the protocol and center frequency
enough to always derive the symbol rate? I am not sure this is correct,
but I thought not all symbol rates could be derived, like for example
certain UWB PHY protocols which can use different PRF on a single
channel which has an effect on the symbol duration?

> > So far there is very little configuration done in this helper but thanks
> > to this improvement, future enhancements in this area (like setting a
> > symbol duration, which is missing) will be reflected automatically in
> > the default probe state.
> >
> > Signed-off-by: Miquel Raynal <[email-masked]>
> > ---
> >  drivers/net/ieee802154/mac802154_hwsim.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ieee802154/mac802154_hwsim.c b/drivers/net/ieee802154/mac802154_hwsim.c
> > index 62ced7a30d92..b1a4ee7dceda 100644
> > --- a/drivers/net/ieee802154/mac802154_hwsim.c
> > +++ b/drivers/net/ieee802154/mac802154_hwsim.c
> > @@ -778,8 +778,6 @@ static int hwsim_add_one(struct genl_info *info, struct device *dev,
> >
> >         ieee802154_random_extended_addr(&hw->phy->perm_extended_addr);
> >
> > -       /* hwsim phy channel 13 as default */
> > -       hw->phy->current_channel = 13;
> >         pib = kzalloc(sizeof(*pib), GFP_KERNEL);
> >         if (!pib) {
> >                 err = -ENOMEM;
> > @@ -793,6 +791,11 @@ static int hwsim_add_one(struct genl_info *info, struct device *dev,
> >         hw->flags = IEEE802154_HW_PROMISCUOUS | IEEE802154_HW_RX_DROP_BAD_CKSUM;  
> 
> sadly this patch doesn't apply on current net-next/master because
> IEEE802154_HW_RX_DROP_BAD_CKSUM is not set.
> I agree that it should be set, so we need a patch for it.

Right, I just have a patch aside setting this to enforce beacons
checksum were good. I can certainly set this flag officially.

> 
> - Alex
> 
> [0] https://elixir.bootlin.com/linux/v5.16-rc7/source/drivers/net/ieee802154/at86rf230.c#L1059

Thanks,
Miquèl