All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Schmidt <stefan@datenfreihafen.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>,
	Alexander Aring <alex.aring@gmail.com>,
	linux-wpan@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	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>,
	Alexander Aring <aahringo@redhat.com>
Subject: Re: [PATCH wpan/next v3 9/9] ieee802154: atusb: add support for trac feature
Date: Wed, 12 Oct 2022 19:50:34 +0200	[thread overview]
Message-ID: <addba337-b3a5-5e1f-9524-e9f3b2ebfb80@datenfreihafen.org> (raw)
In-Reply-To: <20220905203412.1322947-10-miquel.raynal@bootlin.com>

Hello Miquel, Alexander.

On 05.09.22 22:34, Miquel Raynal wrote:
> From: Alexander Aring <aahringo@redhat.com>
> 
> This patch adds support for reading the trac register if atusb firmware
> reports tx done. There is currently a feature to compare a sequence
> number, if the payload is 1 it tells the driver only the sequence number
> is available if it's two there is additional the trac status register as
> payload.
> 
> Currently the atusb_in_good() function determines if it's a tx done or
> rx done if according the payload length. This patch is doing the same
> and assumes this behaviour.
> 
> Signed-off-by: Alexander Aring <aahringo@redhat.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
>   drivers/net/ieee802154/atusb.c | 33 ++++++++++++++++++++++++++++-----
>   1 file changed, 28 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
> index 2c338783893d..95a4a3cdc8a4 100644
> --- a/drivers/net/ieee802154/atusb.c
> +++ b/drivers/net/ieee802154/atusb.c
> @@ -191,7 +191,7 @@ static void atusb_work_urbs(struct work_struct *work)
>   
>   /* ----- Asynchronous USB -------------------------------------------------- */
>   
> -static void atusb_tx_done(struct atusb *atusb, u8 seq)
> +static void atusb_tx_done(struct atusb *atusb, u8 seq, int reason)
>   {
>   	struct usb_device *usb_dev = atusb->usb_dev;
>   	u8 expect = atusb->tx_ack_seq;
> @@ -199,7 +199,10 @@ static void atusb_tx_done(struct atusb *atusb, u8 seq)
>   	dev_dbg(&usb_dev->dev, "%s (0x%02x/0x%02x)\n", __func__, seq, expect);
>   	if (seq == expect) {
>   		/* TODO check for ifs handling in firmware */
> -		ieee802154_xmit_complete(atusb->hw, atusb->tx_skb, false);
> +		if (reason == IEEE802154_SUCCESS)
> +			ieee802154_xmit_complete(atusb->hw, atusb->tx_skb, false);
> +		else
> +			ieee802154_xmit_error(atusb->hw, atusb->tx_skb, reason);
>   	} else {
>   		/* TODO I experience this case when atusb has a tx complete
>   		 * irq before probing, we should fix the firmware it's an
> @@ -215,7 +218,8 @@ static void atusb_in_good(struct urb *urb)
>   	struct usb_device *usb_dev = urb->dev;
>   	struct sk_buff *skb = urb->context;
>   	struct atusb *atusb = SKB_ATUSB(skb);
> -	u8 len, lqi;
> +	int result = IEEE802154_SUCCESS;
> +	u8 len, lqi, trac;
>   
>   	if (!urb->actual_length) {
>   		dev_dbg(&usb_dev->dev, "atusb_in: zero-sized URB ?\n");
> @@ -224,8 +228,27 @@ static void atusb_in_good(struct urb *urb)
>   
>   	len = *skb->data;
>   
> -	if (urb->actual_length == 1) {
> -		atusb_tx_done(atusb, len);
> +	switch (urb->actual_length) {
> +	case 2:
> +		trac = TRAC_MASK(*(skb->data + 1));
> +		switch (trac) {
> +		case TRAC_SUCCESS:
> +		case TRAC_SUCCESS_DATA_PENDING:
> +			/* already IEEE802154_SUCCESS */
> +			break;
> +		case TRAC_CHANNEL_ACCESS_FAILURE:
> +			result = IEEE802154_CHANNEL_ACCESS_FAILURE;
> +			break;
> +		case TRAC_NO_ACK:
> +			result = IEEE802154_NO_ACK;
> +			break;
> +		default:
> +			result = IEEE802154_SYSTEM_ERROR;
> +		}
> +
> +		fallthrough;
> +	case 1:
> +		atusb_tx_done(atusb, len, result);
>   		return;
>   	}
>   

There have been various RFC patches from either of you two on this. From 
what I can see this is the last one.

I am glad that this is done in a backwards compatible way, so it can 
keep working with the older v.03 firmware. See my comments on the 
firmware part of this in the other thread.

This patch has been applied to the wpan-next tree and will be
part of the next pull request to net-next. Thanks!

regards
Stefan Schmidt

  reply	other threads:[~2022-10-12 17:50 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-05 20:34 [PATCH wpan/next v3 0/9] net: ieee802154: Support scanning/beaconing Miquel Raynal
2022-09-05 20:34 ` [PATCH wpan/next v3 1/9] net: mac802154: Introduce filtering levels Miquel Raynal
2022-09-05 20:34 ` [PATCH wpan/next v3 2/9] net: mac802154: move receive parameters above start Miquel Raynal
2022-09-05 20:34 ` [PATCH wpan/next v3 3/9] net: mac802154: set filter at drv_start() Miquel Raynal
2022-09-05 20:34 ` [PATCH wpan/next v3 4/9] net: mac802154: Don't limit the FILTER_NONE level to monitors Miquel Raynal
2022-09-05 20:34 ` [PATCH wpan/next v3 5/9] net: mac802154: Drop IEEE802154_HW_RX_DROP_BAD_CKSUM Miquel Raynal
2022-09-09  0:49   ` Alexander Aring
2022-09-21 15:49     ` Miquel Raynal
2022-09-24 19:50       ` Alexander Aring
2022-09-05 20:34 ` [PATCH wpan/next v3 6/9] net: mac802154: Add promiscuous software filtering Miquel Raynal
2022-09-09  0:44   ` Alexander Aring
2022-09-05 20:34 ` [PATCH wpan/next v3 7/9] net: mac802154: Ensure proper scan-level filtering Miquel Raynal
2022-09-05 20:34 ` [PATCH wpan/next v3 8/9] net: mac802154: Ensure proper general purpose frame filtering Miquel Raynal
2022-09-09  1:00   ` Alexander Aring
2022-09-09  1:02     ` Alexander Aring
2022-09-21 15:59     ` Miquel Raynal
2022-09-25 22:27       ` Alexander Aring
2022-09-28  0:23         ` Alexander Aring
2022-09-05 20:34 ` [PATCH wpan/next v3 9/9] ieee802154: atusb: add support for trac feature Miquel Raynal
2022-10-12 17:50   ` Stefan Schmidt [this message]
2022-09-08  1:40 ` [PATCH wpan/next v3 0/9] net: ieee802154: Support scanning/beaconing Alexander Aring
2022-09-08  7:36   ` Miquel Raynal
2022-09-09  0:41     ` Alexander Aring
2022-09-21 15:45       ` Miquel Raynal
2022-09-25 18:56         ` 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=addba337-b3a5-5e1f-9524-e9f3b2ebfb80@datenfreihafen.org \
    --to=stefan@datenfreihafen.org \
    --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=miquel.raynal@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=nico@ni.fr.eu.org \
    --cc=pabeni@redhat.com \
    --cc=romuald.despres@qorvo.com \
    --cc=thomas.petazzoni@bootlin.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.