From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Alexander Aring <alex.aring@gmail.com>
Cc: Stefan Schmidt <stefan@datenfreihafen.org>,
linux-wpan - ML <linux-wpan@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
"open list:NETWORKING [GENERAL]" <netdev@vger.kernel.org>,
Michael Hennerich <michael.hennerich@analog.com>,
Varka Bhadram <varkabhadram@gmail.com>,
Xue Liu <liuxuenetmail@gmail.com>, Alan Ott <alan@signal11.us>
Subject: Re: [PATCH wpan-next v2 1/5] net: ieee802154: Improve the way supported channels are declared
Date: Mon, 31 Jan 2022 15:23:45 +0100 [thread overview]
Message-ID: <20220131152345.3fefa3aa@xps13> (raw)
In-Reply-To: <CAB_54W60OiGmjLQ2dAvnraq6fkZ6GGTLMVzjVbVAobcvNsaWtQ@mail.gmail.com>
Hi Alexander,
alex.aring@gmail.com wrote on Sun, 30 Jan 2022 16:35:35 -0500:
> Hi,
>
> On Fri, Jan 28, 2022 at 6:08 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > The idea here is to create a structure per set of channels so that we
> > can define much more than basic bitfields for these.
> >
> > The structure is currently almost empty on purpose because this change
> > is supposed to be a mechanical update without additional information but
> > more details will be added in the following commits.
> >
>
> In my opinion you want to put more information in this structure which
> is not necessary and force the driver developer to add information
> which is already there encoded in the page/channel bitfields.
The information I am looking forward to add is clearly not encoded in
the page/channel bitfields (these information are added in the
following patches). At least I don't see anywhere in the spec a
paragraph telling which protocol and band must be used as a function of
the page and channel information. So I improved the way channels are
declared to give more information than what we currently have.
BTW I see the wpan tools actually derive the protocol/band from the
channel/page information and I _really_ don't get it. I believe it only
works with hwsim but if it's not the case I would like to hear
more about it.
> Why not
> add helper functionality and get your "band" and "protocol" for a
> page/channel combination?
This information is as static as the channel/page information, so why
using two different channels to get it? This means two different places
where the channels must be described, which IMHO hardens the work for
device driver writers.
I however agree that the final presentation looks a bit more heavy to
the eyes, but besides the extra fat that this change brings, it is
rather easy to give the core all the information it needs in a rather
detailed and understandable way.
Thanks,
Miquèl
next prev parent reply other threads:[~2022-01-31 14:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-28 11:08 [PATCH wpan-next v2 0/5] ieee802154: Improve durations handling Miquel Raynal
2022-01-28 11:08 ` [PATCH wpan-next v2 1/5] net: ieee802154: Improve the way supported channels are declared Miquel Raynal
2022-01-30 21:35 ` Alexander Aring
2022-01-31 14:23 ` Miquel Raynal [this message]
2022-02-01 0:04 ` Alexander Aring
2022-02-01 14:55 ` Miquel Raynal
2022-02-06 21:37 ` Alexander Aring
2022-02-07 7:49 ` Miquel Raynal
2022-02-20 23:05 ` Alexander Aring
2022-03-02 13:21 ` Miquel Raynal
2022-03-13 20:58 ` Alexander Aring
2022-03-18 9:09 ` Miquel Raynal
2022-01-28 11:08 ` [PATCH wpan-next v2 2/5] net: ieee802154: Give more details to the core about the channel configurations Miquel Raynal
2022-01-28 11:08 ` [PATCH wpan-next v2 3/5] net: mac802154: Convert the symbol duration into nanoseconds Miquel Raynal
2022-01-28 13:00 ` Stefan Schmidt
2022-01-28 11:08 ` [PATCH wpan-next v2 4/5] net: mac802154: Set durations automatically Miquel Raynal
2022-01-28 11:08 ` [PATCH wpan-next v2 5/5] net: ieee802154: Drop duration settings when the core does it already Miquel Raynal
2022-02-01 17:40 ` Miquel Raynal
2022-02-01 20:51 ` Stefan Schmidt
2022-02-02 7:40 ` Miquel Raynal
2022-02-02 12:17 ` Stefan Schmidt
2022-02-02 13:50 ` Miquel Raynal
2022-02-02 17:07 ` Stefan Schmidt
2022-01-28 11:11 ` [PATCH wpan-next v2 0/5] ieee802154: Improve durations handling Miquel Raynal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220131152345.3fefa3aa@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=alan@signal11.us \
--cc=alex.aring@gmail.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-wpan@vger.kernel.org \
--cc=liuxuenetmail@gmail.com \
--cc=michael.hennerich@analog.com \
--cc=netdev@vger.kernel.org \
--cc=stefan@datenfreihafen.org \
--cc=varkabhadram@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox