netdev - Re: [wpan-next v2 01/27] net: mac802154: Split the set channel hook implementation

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:   Thu, 13 Jan 2022 18:27:30 -0500
From:   Alexander Aring <alex.aring@...il.com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        Michael Hennerich <michael.hennerich@...log.com>,
        Harry Morris <h.morris@...coda.com>,
        Varka Bhadram <varkabhadram@...il.com>,
        Xue Liu <liuxuenetmail@...il.com>, Alan Ott <alan@...nal11.us>,
        David Girault <david.girault@...vo.com>,
        Romuald Despres <romuald.despres@...vo.com>,
        Frederic Blain <frederic.blain@...vo.com>,
        Nicolas Schodet <nico@...fr.eu.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        "linux-wireless@...r.kernel.org Wireless" 
        <linux-wireless@...r.kernel.org>
Subject: Re: [wpan-next v2 01/27] net: mac802154: Split the set channel hook implementation

Hi,

On Thu, 13 Jan 2022 at 04:32, Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
> Hi Alexander,
>
> alex.aring@...il.com wrote on Wed, 12 Jan 2022 17:30:35 -0500:
>
> > Hi,
> >
> > On Wed, 12 Jan 2022 at 12:33, Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> > >
> > > As it is currently designed, the set_channel() cfg802154 hook
> > > implemented in the softMAC is doing a couple of checks before actually
> > > performing the channel change. However, as we enhance the support for
> > > automatically setting the symbol duration during channel changes, it
> > > will also be needed to ensure that the corresponding channel as properly
> > > be selected at probe time. In order to verify this, we will need to
> >
> > no, we don't set channels at probe time. We set the
> > current_page/channel whatever the default is according to the hardware
> > datasheet. I think this channel should be dropped and all drivers set
> > the defaults before registering hw as what we do at e.g. at86rf230,
> > see [0].
>
> Is there a reason for refusing to call ->set_channel() at probe time?
>

because the current drivers work the way to not set the channel/page
during probe time. Also the 802.15.4 spec states that this default
value is hardware specific and this goes back whatever the vendor
decides. Also you drop the check that if the same channel is already
set don't set it which works like a shadow register for registers.
Is there a reason why to set a channel during probe time? Are you
setting the value which is the default one again? If the driver has a
random default value it should choose some and stick to one, the
others do whatever the datasheet has after resetting the hardware.

I really don't see the sense here why every driver should introduce on
driver level a set channel call. At probing time the transceiver
registers are already in a state which we should reflect.

> Anyway, I'll put the symbol duration setting in the registration helper
> and I will fix hwsim aside.
>

ok, thanks.

- Alex