lkml.org 
[lkml]   [2022]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [net-next 01/18] ieee802154: hwsim: Ensure proper channel selection at probe time
    Hi,

    On Tue, 4 Jan 2022 at 10:44, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
    >
    > Hi Alexander,
    >
    > alex.aring@gmail.com wrote on Tue, 28 Dec 2021 16:05:43 -0500:
    >
    > > Hi,
    > >
    > > On Wed, 22 Dec 2021 at 10:57, Miquel Raynal <miquel.raynal@bootlin.com> 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?
    >

    I am a little bit confused here, because a lot of timing related
    things in the phy information rate points to "x times symbols". If
    this value depends on the transceiver, how are they compatible then?

    > 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?

    Regarding UWB PHY I see that for values like LIFS/SIFS they reference
    a "preambleSymbols" value which is defined.

    I need to do more research regarding this.

    - Alex

    \
     
     \ /
      Last update: 2022-01-05 00:09    [W:5.496 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site