From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Alexander Aring <aahringo@redhat.com>
Cc: Alexander Aring <alex.aring@gmail.com>,
Stefan Schmidt <stefan@datenfreihafen.org>,
linux-wpan - ML <linux-wpan@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
Network Development <netdev@vger.kernel.org>,
David Girault <david.girault@qorvo.com>,
Romuald Despres <romuald.despres@qorvo.com>,
Frederic Blain <frederic.blain@qorvo.com>,
Nicolas Schodet <nico@ni.fr.eu.org>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
werner@almesberger.net
Subject: Re: [PATCH wpan-next 01/20] net: mac802154: Allow the creation of coordinator interfaces
Date: Mon, 5 Sep 2022 05:16:08 +0200 [thread overview]
Message-ID: <20220905051608.5354637a@xps-13> (raw)
In-Reply-To: <CAK-6q+jiDcf_M6S+gWh_qms=dMPaSb4daPC7Afs6RZjQdHGinQ@mail.gmail.com>
Hi Alexander,
aahringo@redhat.com wrote on Sat, 3 Sep 2022 15:40:35 -0400:
> Hi,
>
> On Sat, Sep 3, 2022 at 3:10 PM Alexander Aring <aahringo@redhat.com> wrote:
> >
> > On Sat, Sep 3, 2022 at 3:07 PM Alexander Aring <aahringo@redhat.com> wrote:
> > >
> > > Hi,
> > >
> > > On Sat, Sep 3, 2022 at 12:06 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > ...
> > > >
> > > > On the Tx side, when sending eg. an association request or an
> > > > association response, I must expect and wait for an ack. This is
> > > > what I am struggling to do. How can I know that a frame which I just
> > > > transmitted has been acked? Bonus points, how can I do that in such a
> > > > way that it will work with other devices? (hints below)
> > > >
> > > > > AACK will send a back if a frame with ack request bit was received.
> > > > >
> > > > > > say in a commit) I have seen no further updates about it so I guess
> > > > > > it's still not available. I don't see any other way to know if a
> > > > > > frame's ack has been received or not reliably.
> > > > >
> > > > > You implemented it for the at86rf230 driver (the spi one which is what
> > > > > also atusb uses). You implemented the
> > > > >
> > > > > ctx->trac = IEEE802154_NO_ACK;
> > > > >
> > > > > which signals the upper layer that if the ack request bit is set, that
> > > > > there was no ack.
> > > > >
> > > > > But yea, there is a missing feature for atusb yet which requires
> > > > > firmware changes as well.
> > > >
> > > > :'(
> > >
> > > There is a sequence handling in tx done on atusb firmware and I think
> > > it should be pretty easy to add a byte for trac status.
> > >
> > > diff --git a/atusb/fw/mac.c b/atusb/fw/mac.c
> > > index 835002c..156bd95 100644
> > > --- a/atusb/fw/mac.c
> > > +++ b/atusb/fw/mac.c
> > > @@ -116,7 +116,7 @@ static void receive_frame(void)
> > >
> > > static bool handle_irq(void)
> > > {
> > > - uint8_t irq;
> > > + uint8_t irq, data[2];
> > >
> > > irq = reg_read(REG_IRQ_STATUS);
> > > if (!(irq & IRQ_TRX_END))
> > > @@ -124,7 +124,15 @@ static bool handle_irq(void)
> > >
> > > if (txing) {
> > > if (eps[1].state == EP_IDLE) {
> > > - usb_send(&eps[1], &this_seq, 1, tx_ack_done, NULL);
> > > + data[0] = tx_ack_done;
> > > +
> > > + spi_begin();
> > > + spi_io(REG_TRX_STATE);
> > > +
> > > + data[1] = spi_recv();
> > > + spi_end();
> >
> > data[1] = reg_read(REG_TRX_STATE) as seen above for REG_IRQ_STATUS
> > would be better here...
> >
>
> after digging the code more, there is another queue case which we
> should handle, also correct using buffer parameter instead of the
> callback parameter which was stupid... However I think the direction
> is clear. Sorry for the spam.
Don't be, your feedback is just super useful.
> diff --git a/atusb/fw/mac.c b/atusb/fw/mac.c
> index 835002c..b52ba1a 100644
> --- a/atusb/fw/mac.c
> +++ b/atusb/fw/mac.c
> @@ -32,7 +32,7 @@ static uint8_t tx_buf[MAX_PSDU];
> static uint8_t tx_size = 0;
> static bool txing = 0;
> static bool queued_tx_ack = 0;
> -static uint8_t next_seq, this_seq, queued_seq;
> +static uint8_t next_seq, this_seq, queued_seq, queued_tx_trac;
>
>
> /* ----- Receive buffer management ----------------------------------------- */
> @@ -57,6 +57,7 @@ static void tx_ack_done(void *user);
> static void usb_next(void)
> {
> const uint8_t *buf;
> + uint8_t data[2];
>
> if (rx_in != rx_out) {
> buf = rx_buf[rx_out];
> @@ -65,7 +66,9 @@ static void usb_next(void)
> }
>
> if (queued_tx_ack) {
> - usb_send(&eps[1], &queued_seq, 1, tx_ack_done, NULL);
> + data[0] = queued_seq;
> + data[1] = queued_tx_trac;
> + usb_send(&eps[1], data, sizeof(data), tx_ack_done, NULL);
> queued_tx_ack = 0;
> }
> }
> @@ -116,7 +119,7 @@ static void receive_frame(void)
>
> static bool handle_irq(void)
> {
> - uint8_t irq;
> + uint8_t irq, data[2];
I don't know why, but defining data on the stack just does not work.
Defining it above with the other static variables is okay. I won't
fight more for "today" but if someone has an explanation I am all hears.
> irq = reg_read(REG_IRQ_STATUS);
> if (!(irq & IRQ_TRX_END))
> @@ -124,10 +127,13 @@ static bool handle_irq(void)
>
> if (txing) {
> if (eps[1].state == EP_IDLE) {
> - usb_send(&eps[1], &this_seq, 1, tx_ack_done, NULL);
> + data[0] = this_seq;
> + data[1] = reg_read(REG_TRX_STATE);
> + usb_send(&eps[1], data, sizeof(data),
> tx_ack_done, NULL);
> } else {
> queued_tx_ack = 1;
> queued_seq = this_seq;
> + queued_tx_trac = reg_read(REG_TRX_STATE);
> }
> txing = 0;
> return 1;
>
Thanks,
Miquèl
next prev parent reply other threads:[~2022-09-05 3:16 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-01 14:30 [PATCH wpan-next 00/20] net: ieee802154: Support scanning/beaconing Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 01/20] net: mac802154: Allow the creation of coordinator interfaces Miquel Raynal
2022-07-06 1:51 ` Alexander Aring
2022-08-19 17:11 ` Miquel Raynal
2022-08-23 12:33 ` Alexander Aring
2022-08-23 16:29 ` Miquel Raynal
2022-08-23 21:44 ` Alexander Aring
2022-08-24 7:35 ` Miquel Raynal
2022-08-24 21:43 ` Alexander Aring
2022-08-25 8:40 ` Miquel Raynal
2022-08-26 0:51 ` Alexander Aring
2022-08-26 1:35 ` Alexander Aring
2022-08-26 8:08 ` Miquel Raynal
2022-08-29 2:31 ` Alexander Aring
2022-08-29 8:05 ` Miquel Raynal
2022-08-26 7:30 ` Miquel Raynal
2022-08-24 10:20 ` Miquel Raynal
2022-08-24 12:43 ` Alexander Aring
2022-08-24 13:26 ` Miquel Raynal
2022-08-24 21:53 ` Alexander Aring
2022-08-25 1:02 ` Alexander Aring
2022-08-25 8:46 ` Miquel Raynal
2022-08-25 12:58 ` Miquel Raynal
2022-08-26 1:05 ` Alexander Aring
2022-08-26 7:54 ` Miquel Raynal
2022-08-29 2:52 ` Alexander Aring
2022-08-29 8:02 ` Miquel Raynal
2022-08-30 2:23 ` Alexander Aring
2022-08-31 15:39 ` Miquel Raynal
2022-09-01 0:09 ` Miquel Raynal
2022-09-01 13:09 ` Miquel Raynal
2022-09-02 2:38 ` Alexander Aring
2022-09-03 0:08 ` Miquel Raynal
2022-09-03 14:20 ` Alexander Aring
2022-09-03 14:31 ` Alexander Aring
2022-09-03 16:05 ` Miquel Raynal
2022-09-03 18:21 ` Alexander Aring
2022-09-03 18:29 ` Alexander Aring
2022-09-03 19:07 ` Alexander Aring
2022-09-03 19:10 ` Alexander Aring
2022-09-03 19:40 ` Alexander Aring
2022-09-05 3:16 ` Miquel Raynal [this message]
2022-09-05 22:35 ` Alexander Aring
2022-09-02 2:23 ` Alexander Aring
2022-09-02 2:39 ` Alexander Aring
2022-09-02 2:09 ` Alexander Aring
2022-07-01 14:30 ` [PATCH wpan-next 02/20] net: ieee802154: Advertize coordinators discovery Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 03/20] net: ieee802154: Handle " Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 04/20] net: ieee802154: Trace the registration of new PANs Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 05/20] net: ieee802154: Define frame types Miquel Raynal
2022-07-11 2:06 ` Alexander Aring
2022-08-19 17:13 ` Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 06/20] net: ieee802154: Add support for user scanning requests Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 07/20] net: ieee802154: Define a beacon frame header Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 08/20] net: mac802154: Prepare forcing specific symbol duration Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 09/20] net: mac802154: Introduce a global device lock Miquel Raynal
2022-07-04 1:12 ` Alexander Aring
2022-08-19 17:06 ` Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 10/20] net: mac802154: Handle passive scanning Miquel Raynal
2022-07-15 3:33 ` Alexander Aring
2022-07-15 3:42 ` Alexander Aring
2022-08-19 17:22 ` Miquel Raynal
2022-08-01 23:42 ` Alexander Aring
2022-08-01 23:54 ` Alexander Aring
2022-07-01 14:30 ` [PATCH wpan-next 11/20] net: ieee802154: Add support for user beaconing requests Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 12/20] net: mac802154: Handle basic beaconing Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 13/20] net: ieee802154: Add support for user active scan requests Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 14/20] net: mac802154: Handle active scanning Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 15/20] net: ieee802154: Add support for allowing to answer BEACON_REQ Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 16/20] net: mac802154: Handle received BEACON_REQ Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 17/20] net: ieee802154: Handle limited devices with only datagram support Miquel Raynal
2022-07-15 3:16 ` Alexander Aring
2022-08-19 17:13 ` Miquel Raynal
2022-08-23 12:43 ` Alexander Aring
2022-07-01 14:30 ` [PATCH wpan-next 18/20] ieee802154: ca8210: Flag the driver as being limited Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 19/20] ieee802154: hwsim: Do not check the rtnl Miquel Raynal
2022-07-06 1:23 ` Alexander Aring
2022-08-01 23:58 ` Alexander Aring
2022-08-19 17:09 ` Miquel Raynal
2022-08-25 22:41 ` Miquel Raynal
2022-07-01 14:30 ` [PATCH wpan-next 20/20] ieee802154: hwsim: Allow devices to be coordinators Miquel Raynal
2022-07-11 2:01 ` Alexander Aring
2022-08-19 17:12 ` Miquel Raynal
2022-07-04 1:17 ` [PATCH wpan-next 00/20] net: ieee802154: Support scanning/beaconing Alexander Aring
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=20220905051608.5354637a@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=aahringo@redhat.com \
--cc=alex.aring@gmail.com \
--cc=davem@davemloft.net \
--cc=david.girault@qorvo.com \
--cc=edumazet@google.com \
--cc=frederic.blain@qorvo.com \
--cc=kuba@kernel.org \
--cc=linux-wpan@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nico@ni.fr.eu.org \
--cc=pabeni@redhat.com \
--cc=romuald.despres@qorvo.com \
--cc=stefan@datenfreihafen.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=werner@almesberger.net \
/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;
as well as URLs for NNTP newsgroup(s).