* Re: [PATCH] mt76: change the retun type of mt76_dma_attach()
From: Sergei Shtylyov @ 2019-02-11 8:38 UTC (permalink / raw)
To: Ryder Lee, Lorenzo Bianconi, Felix Fietkau, Kalle Valo
Cc: Roy Luo, linux-wireless, linux-kernel, netdev, linux-mediatek
In-Reply-To: <228fdddb9ca96e8ce861e324eb9039722cf18f49.1549850911.git.ryder.lee@mediatek.com>
Hello!
On 11.02.2019 5:13, Ryder Lee wrote:
> There is no need to retun 0 in mt76_dma_attach(), so switch it to void.
^ r missing :-)
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] mt76: change the retun type of mt76_dma_attach()
From: Ryder Lee @ 2019-02-11 8:48 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Lorenzo Bianconi, Felix Fietkau, Kalle Valo, netdev,
linux-mediatek, linux-wireless, Roy Luo, linux-kernel
In-Reply-To: <f65c85c2-ef47-d141-d78e-db2a138a1daf@cogentembedded.com>
On Mon, 2019-02-11 at 11:38 +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 11.02.2019 5:13, Ryder Lee wrote:
>
> > There is no need to retun 0 in mt76_dma_attach(), so switch it to void.
> ^ r missing :-)
> >
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> [...]
>
> MBR, Sergei
>
I will resend a new one.
Thanks
Ryder
^ permalink raw reply
* [Resend PATCH] mt76: change the return type of mt76_dma_attach()
From: Ryder Lee @ 2019-02-11 8:48 UTC (permalink / raw)
To: Lorenzo Bianconi, Felix Fietkau, Kalle Valo
Cc: Roy Luo, linux-wireless, linux-kernel, netdev, linux-mediatek,
Ryder Lee
There is no need to return 0 in mt76_dma_attach(), so switch it to void.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
drivers/net/wireless/mediatek/mt76/dma.c | 3 +--
drivers/net/wireless/mediatek/mt76/dma.h | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireless/mediatek/mt76/dma.c
index e2ba263..d934d72 100644
--- a/drivers/net/wireless/mediatek/mt76/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/dma.c
@@ -522,10 +522,9 @@ int mt76_dma_tx_queue_skb(struct mt76_dev *dev, struct mt76_queue *q,
.kick = mt76_dma_kick_queue,
};
-int mt76_dma_attach(struct mt76_dev *dev)
+void mt76_dma_attach(struct mt76_dev *dev)
{
dev->queue_ops = &mt76_dma_ops;
- return 0;
}
EXPORT_SYMBOL_GPL(mt76_dma_attach);
diff --git a/drivers/net/wireless/mediatek/mt76/dma.h b/drivers/net/wireless/mediatek/mt76/dma.h
index 357cc35..e3292df 100644
--- a/drivers/net/wireless/mediatek/mt76/dma.h
+++ b/drivers/net/wireless/mediatek/mt76/dma.h
@@ -54,7 +54,7 @@ enum mt76_mcu_evt_type {
EVT_EVENT_DFS_DETECT_RSP,
};
-int mt76_dma_attach(struct mt76_dev *dev);
+void mt76_dma_attach(struct mt76_dev *dev);
void mt76_dma_cleanup(struct mt76_dev *dev);
#endif
--
1.9.1
^ permalink raw reply related
* Re: [Resend PATCH] mt76: change the return type of mt76_dma_attach()
From: Kalle Valo @ 2019-02-11 9:19 UTC (permalink / raw)
To: Ryder Lee
Cc: Lorenzo Bianconi, Felix Fietkau, Roy Luo, linux-wireless,
linux-kernel, netdev, linux-mediatek
In-Reply-To: <228fdddb9ca96e8ce861e324eb9039722cf18f49.1549850911.git.ryder.lee@mediatek.com>
Ryder Lee <ryder.lee@mediatek.com> writes:
> There is no need to return 0 in mt76_dma_attach(), so switch it to void.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
When you send a new version mark it as v2:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#patch_version_missing
And add a changelog:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#changelog_missing
No need to resend because of this, but please do remember this in the
future.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v6 4/4] ath10k: reporting estimated tx airtime for fairness
From: Kalle Valo @ 2019-02-11 9:24 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: linux-wireless, Kan Yan, Rajkumar Manoharan, ath10k,
make-wifi-fast, Toke Høiland-Jørgensen
In-Reply-To: <20190122142019.21417-5-toke@redhat.com>
Toke Høiland-Jørgensen wrote:
> The airtime of a transmitted frame will be estimated from last used tx rate
> which the firmware reports with the peer stats feature
> (WMI_SERVICE_PEER_STATS). The airtime is computed on the tx path and it
> will be reported to mac80211 upon tx completion.
>
> This change is based on Kan's orginal commit in Chromium tree
> ("CHROMIUM: ath10k: Implementing airtime fairness based TX scheduler")
> ref: https://chromium-review.googlesource.com/588190
>
> Tested on QCA4019 with firmware version 10.4-3.2.1.1-00015
> Tested on QCA9984 with firmware version 10.4-3.9.0.1-00005
>
> Signed-off-by: Kan Yan <kyan@google.com>
> [rmanohar@codeaurora.org: ported only the airtime computation]
> Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
> [toke@redhat.com: Rebase to mac80211-next, add test note]
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
There was a trivial conflict, please check my resolution in the pending branch.
I also reworded the commit log a bit.
$ git am -s --reject 10775551.mbox
Applying: ath10k: reporting estimated tx airtime for fairness
Checking patch drivers/net/wireless/ath/ath10k/core.h...
Checking patch drivers/net/wireless/ath/ath10k/htt_rx.c...
Hunk #1 succeeded at 3080 (offset 2 lines).
Checking patch drivers/net/wireless/ath/ath10k/mac.c...
Hunk #1 succeeded at 3566 (offset 22 lines).
Hunk #2 succeeded at 3583 (offset 22 lines).
Hunk #3 succeeded at 3971 (offset 22 lines).
Hunk #4 succeeded at 4029 (offset 22 lines).
Hunk #5 succeeded at 4047 (offset 22 lines).
Hunk #6 succeeded at 4315 (offset 22 lines).
Hunk #7 succeeded at 8671 (offset 20 lines).
Checking patch drivers/net/wireless/ath/ath10k/txrx.c...
error: while searching for:
wake_up(&htt->empty_tx_wq);
spin_unlock_bh(&htt->tx_lock);
if (ar->dev_type != ATH10K_DEV_TYPE_HL)
dma_unmap_single(dev, skb_cb->paddr, msdu->len, DMA_TO_DEVICE);
error: patch failed: drivers/net/wireless/ath/ath10k/txrx.c:95
Applied patch drivers/net/wireless/ath/ath10k/core.h cleanly.
Applied patch drivers/net/wireless/ath/ath10k/htt_rx.c cleanly.
Applied patch drivers/net/wireless/ath/ath10k/mac.c cleanly.
Applying patch drivers/net/wireless/ath/ath10k/txrx.c with 1 reject...
Rejected hunk #1.
Patch failed at 0001 ath10k: reporting estimated tx airtime for fairness
--
https://patchwork.kernel.org/patch/10775551/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: Add support to configure ftm responder role
From: Kalle Valo @ 2019-02-11 9:28 UTC (permalink / raw)
To: Pradeep Kumar Chitrapu; +Cc: ath10k, linux-wireless, Pradeep Kumar Chitrapu
In-Reply-To: <1549439910-9315-1-git-send-email-pradeepc@codeaurora.org>
Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> wrote:
> Configure fine timing measurement (FTM) responder role from the
> ftm_responder bss param sent by mac80211. With FTM functionality offloaded
> to firmware, adding the interface allows userspace to enable or disable
> FTM responder functionality. ath10k disables it at the time of interface
> creation.
>
> Supported FW: 10.4
>
> Tested on IPQ4019 with firmware: 10.4-3.2.1.1-00022
>
> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
I had to fix some conflicts, please carefully check my resolution in the pending branch:
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=a3e53eb1c7c58b131ebc0581aa44b0912809e430
$ git am -s -3 10798883.mbox
Applying: ath10k: Add support to configure ftm responder role
Using index info to reconstruct a base tree...
M drivers/net/wireless/ath/ath10k/core.h
M drivers/net/wireless/ath/ath10k/mac.c
M drivers/net/wireless/ath/ath10k/wmi.c
M drivers/net/wireless/ath/ath10k/wmi.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/net/wireless/ath/ath10k/wmi.h
CONFLICT (content): Merge conflict in drivers/net/wireless/ath/ath10k/wmi.h
Auto-merging drivers/net/wireless/ath/ath10k/wmi.c
CONFLICT (content): Merge conflict in drivers/net/wireless/ath/ath10k/wmi.c
Auto-merging drivers/net/wireless/ath/ath10k/mac.c
CONFLICT (content): Merge conflict in drivers/net/wireless/ath/ath10k/mac.c
Auto-merging drivers/net/wireless/ath/ath10k/core.h
Recorded preimage for 'drivers/net/wireless/ath/ath10k/mac.c'
Recorded preimage for 'drivers/net/wireless/ath/ath10k/wmi.c'
Recorded preimage for 'drivers/net/wireless/ath/ath10k/wmi.h'
error: Failed to merge in the changes.
Patch failed at 0001 ath10k: Add support to configure ftm responder role
--
https://patchwork.kernel.org/patch/10798883/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] ath10k: add dynamic vlan support
From: Kalle Valo @ 2019-02-11 9:30 UTC (permalink / raw)
To: Manikanta Pubbisetty; +Cc: ath10k, linux-wireless, Manikanta Pubbisetty
In-Reply-To: <1542798288-8946-1-git-send-email-mpubbise@codeaurora.org>
Manikanta Pubbisetty <mpubbise@codeaurora.org> wrote:
> Multicast/broadcast traffic destined for a particular vlan group will
> always be encrypted in software. To enable dynamic VLANs, it requires
> driver support for sending software encrypted packets.
>
> In ath10k, sending software encrypted frames is allowed only when we insmod
> the driver with cryptmode param set to 1, this configuration disables
> hardware crypto and enables RAW mode implicitly. Since, enabling raw
> mode has performance impact, this cannot be considered as an ideal
> solution for supporting VLANs in the driver.
>
> As an alternative take, in this approach, cryptographic keys for
> unicast traffic (per peer PTKs) and keys for non-vlan group traffic
> will be configured in hardware, allowing hardware encryption for unicast
> and non-vlan group traffic. Only vlan group traffic will be encrypted in
> software and pushed to the target with encap mode set to RAW in the TX
> descriptors.
>
> Not all firmwares can support this type of key configuration(having few
> keys installed in hardware and few only in software); for this purpose a
> new WMI service flag "WMI_SERVICE_PER_PACKET_SW_ENCRYPT" is introduced to
> advertise this support.
>
> Also, adding the logic required to send sw encrypted frames in raw mode.
>
> Hardwares Tested : QCA9984, QCA988X
> Firmwares Tested : 10.4-3.5.3-00057, 10.2.4-1.0-00042
>
> Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
I had to fix some conflicts, please carefully check my resolution in the pending branch:
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=7ae879447535ae1327e78dc614385ff6dd45c2fd
Applying: ath10k: add dynamic vlan support
Using index info to reconstruct a base tree...
M drivers/net/wireless/ath/ath10k/core.h
M drivers/net/wireless/ath/ath10k/mac.c
M drivers/net/wireless/ath/ath10k/wmi.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/net/wireless/ath/ath10k/wmi.h
CONFLICT (content): Merge conflict in drivers/net/wireless/ath/ath10k/wmi.h
Auto-merging drivers/net/wireless/ath/ath10k/mac.c
Auto-merging drivers/net/wireless/ath/ath10k/core.h
Recorded preimage for 'drivers/net/wireless/ath/ath10k/wmi.h'
error: Failed to merge in the changes.
Patch failed at 0001 ath10k: add dynamic vlan support
--
https://patchwork.kernel.org/patch/10692385/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: report tx airtime provided by fw
From: Kalle Valo @ 2019-02-11 9:33 UTC (permalink / raw)
To: Manikanta Pubbisetty; +Cc: ath10k, linux-wireless, Manikanta Pubbisetty
In-Reply-To: <1542298483-15879-1-git-send-email-mpubbise@codeaurora.org>
Manikanta Pubbisetty <mpubbise@codeaurora.org> wrote:
> If supported, update transmit airtime in mac80211 with the airtime
> values reported by the firmware. TX airtime of the PPDU is reported
> via HTT data TX completion indication message.
>
> A new service flag 'WMI_SERVICE_REPORT_AIRTIME' is added to advertise
> the firmware support. For firmwares which do not support this feature,
> TX airtime is calculated in the driver using TX bitrate.
>
> Hardwares tested : QCA9984
> Firmwares tested : 10.4-3.6.1-00841
>
> Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
I had some conflicts, please carefully check my resolution in the pending branch:
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=1baca5592c99c9d61924956c56c620d371b61d96
$ git am -s --reject 10684687.mbox
Applying: ath10k: report tx airtime provided by fw
Checking patch drivers/net/wireless/ath/ath10k/core.c...
Hunk #1 succeeded at 2631 (offset 32 lines).
Checking patch drivers/net/wireless/ath/ath10k/htt.h...
Hunk #1 succeeded at 571 (offset 7 lines).
Hunk #2 succeeded at 584 (offset 7 lines).
Hunk #3 succeeded at 877 (offset 7 lines).
Checking patch drivers/net/wireless/ath/ath10k/htt_rx.c...
Hunk #1 succeeded at 2220 (offset 217 lines).
Hunk #2 succeeded at 2249 (offset 217 lines).
Hunk #3 succeeded at 2286 (offset 217 lines).
Checking patch drivers/net/wireless/ath/ath10k/mac.c...
Hunk #1 succeeded at 4007 (offset 40 lines).
error: while searching for:
wiphy_ext_feature_set(ar->hw->wiphy,
NL80211_EXT_FEATURE_ACK_SIGNAL_SUPPORT);
if (ath10k_peer_stats_enabled(ar))
wiphy_ext_feature_set(ar->hw->wiphy,
NL80211_EXT_FEATURE_AIRTIME_FAIRNESS);
/*
error: patch failed: drivers/net/wireless/ath/ath10k/mac.c:8615
Checking patch drivers/net/wireless/ath/ath10k/txrx.c...
Checking patch drivers/net/wireless/ath/ath10k/wmi.h...
error: while searching for:
WMI_SERVICE_SPOOF_MAC_SUPPORT,
WMI_SERVICE_TX_DATA_ACK_RSSI,
WMI_SERVICE_VDEV_DIFFERENT_BEACON_INTERVAL_SUPPORT,
/* keep last */
WMI_SERVICE_MAX,
error: patch failed: drivers/net/wireless/ath/ath10k/wmi.h:205
error: while searching for:
WMI_10_4_SERVICE_PEER_TID_CONFIGS_SUPPORT,
WMI_10_4_SERVICE_VDEV_BCN_RATE_CONTROL,
WMI_10_4_SERVICE_VDEV_DIFFERENT_BEACON_INTERVAL_SUPPORT,
};
static inline char *wmi_service_name(int service_id)
error: patch failed: drivers/net/wireless/ath/ath10k/wmi.h:359
error: while searching for:
SVCSTR(WMI_SERVICE_RESET_CHIP);
SVCSTR(WMI_SERVICE_TX_DATA_ACK_RSSI);
SVCSTR(WMI_SERVICE_VDEV_DIFFERENT_BEACON_INTERVAL_SUPPORT);
default:
return NULL;
}
error: patch failed: drivers/net/wireless/ath/ath10k/wmi.h:474
error: while searching for:
WMI_SERVICE_TX_DATA_ACK_RSSI, len);
SVCMAP(WMI_10_4_SERVICE_VDEV_DIFFERENT_BEACON_INTERVAL_SUPPORT,
WMI_SERVICE_VDEV_DIFFERENT_BEACON_INTERVAL_SUPPORT, len);
}
#undef SVCMAP
error: patch failed: drivers/net/wireless/ath/ath10k/wmi.h:786
Hunk #5 succeeded at 2989 (offset -7 lines).
Applied patch drivers/net/wireless/ath/ath10k/core.c cleanly.
Applied patch drivers/net/wireless/ath/ath10k/htt.h cleanly.
Applied patch drivers/net/wireless/ath/ath10k/htt_rx.c cleanly.
Applying patch drivers/net/wireless/ath/ath10k/mac.c with 1 reject...
Hunk #1 applied cleanly.
Rejected hunk #2.
Applied patch drivers/net/wireless/ath/ath10k/txrx.c cleanly.
Applying patch drivers/net/wireless/ath/ath10k/wmi.h with 4 rejects...
Rejected hunk #1.
Rejected hunk #2.
Rejected hunk #3.
Rejected hunk #4.
Hunk #5 applied cleanly.
Patch failed at 0001 ath10k: report tx airtime provided by fw
--
https://patchwork.kernel.org/patch/10684687/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC] mt76x02u: correct pad for fragments
From: Lorenzo Bianconi @ 2019-02-11 9:47 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Felix Fietkau, linux-wireless
In-Reply-To: <1549874264-7661-1-git-send-email-sgruszka@redhat.com>
> Modifying skb->len & data_len doesn't look correct. Issue is not critical
> we just pad 2 times, except first padding is not filled with zeros.
>
> However I'm not sure if we should not add pad to all skb's in frags
> list.
Hi Stanislaw,
IIRC the first packet of a A-MSDU burst keeps track of the burst length
so if we add the a pad to last one we need to update the skb->len/data_len
of the first one. No need to pad all skbs in the frag list, just last one
Regards,
Lorenzo
> Additionally remove unlikely(pad) condition, we always pad for at least
> four bytes what is needed by HW.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> .../wireless/mediatek/mt76/mt76x02_usb_core.c | 22 +++++++------------
> 1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
> index dc2226c722dd..c7ca2d93720a 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
> @@ -49,21 +49,15 @@ int mt76x02u_skb_dma_info(struct sk_buff *skb, int port, u32 flags)
> FIELD_PREP(MT_TXD_INFO_DPORT, port) | flags;
> put_unaligned_le32(info, skb_push(skb, sizeof(info)));
>
> - pad = round_up(skb->len, 4) + 4 - skb->len;
> - skb_walk_frags(skb, iter) {
> + skb_walk_frags(skb, iter)
> last = iter;
> - if (!iter->next) {
> - skb->data_len += pad;
> - skb->len += pad;
> - break;
> - }
> - }
> -
> - if (unlikely(pad)) {
> - if (skb_pad(last, pad))
> - return -ENOMEM;
> - __skb_put(last, pad);
> - }
> +
> + /* Add zero pad of 4 - 7 bytes at the end of buffer */
> + pad = round_up(skb->len, 4) + 4 - skb->len;
> + if (skb_pad(last, pad))
> + return -ENOMEM;
> + __skb_put(last, pad);
> +
> return 0;
> }
>
> --
> 2.19.2
>
^ permalink raw reply
* Re: [PATCH] mt76x02u: use usb_bulk_msg to upload firmware
From: Lorenzo Bianconi @ 2019-02-11 9:51 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Felix Fietkau, linux-wireless
In-Reply-To: <1549872974-7268-1-git-send-email-sgruszka@redhat.com>
> We don't need to send firmware data asynchronously, much simpler is just
> use synchronous usb_bulk_msg().
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Tested-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> ---
> drivers/net/wireless/mediatek/mt76/mt76.h | 13 +++++
> .../wireless/mediatek/mt76/mt76x02_usb_mcu.c | 52 ++++++-------------
> drivers/net/wireless/mediatek/mt76/usb.c | 1 -
> 3 files changed, 29 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
> index 2e5bcb3fdff7..94e0f1379e68 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76.h
> +++ b/drivers/net/wireless/mediatek/mt76/mt76.h
> @@ -664,6 +664,19 @@ static inline bool mt76u_check_sg(struct mt76_dev *dev)
> udev->speed == USB_SPEED_WIRELESS));
> }
>
> +static inline int
> +mt76u_bulk_msg(struct mt76_dev *dev, void *data, int len, int timeout)
> +{
> + struct usb_interface *intf = to_usb_interface(dev->dev);
> + struct usb_device *udev = interface_to_usbdev(intf);
> + struct mt76_usb *usb = &dev->usb;
> + unsigned int pipe;
> + int sent;
> +
> + pipe = usb_sndbulkpipe(udev, usb->out_ep[MT_EP_OUT_INBAND_CMD]);
> + return usb_bulk_msg(udev, pipe, data, len, &sent, timeout);
> +}
> +
> int mt76u_vendor_request(struct mt76_dev *dev, u8 req,
> u8 req_type, u16 val, u16 offset,
> void *buf, size_t len);
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_mcu.c b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_mcu.c
> index da299b8a1334..642df4287082 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_mcu.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_mcu.c
> @@ -121,11 +121,8 @@ static int
> __mt76x02u_mcu_send_msg(struct mt76_dev *dev, struct sk_buff *skb,
> int cmd, bool wait_resp)
> {
> - struct usb_interface *intf = to_usb_interface(dev->dev);
> - struct usb_device *udev = interface_to_usbdev(intf);
> struct mt76_usb *usb = &dev->usb;
> - unsigned int pipe;
> - int ret, sent;
> + int ret;
> u8 seq = 0;
> u32 info;
>
> @@ -135,7 +132,6 @@ __mt76x02u_mcu_send_msg(struct mt76_dev *dev, struct sk_buff *skb,
> if (test_bit(MT76_REMOVED, &dev->state))
> return 0;
>
> - pipe = usb_sndbulkpipe(udev, usb->out_ep[MT_EP_OUT_INBAND_CMD]);
> if (wait_resp) {
> seq = ++usb->mcu.msg_seq & 0xf;
> if (!seq)
> @@ -149,7 +145,7 @@ __mt76x02u_mcu_send_msg(struct mt76_dev *dev, struct sk_buff *skb,
> if (ret)
> return ret;
>
> - ret = usb_bulk_msg(udev, pipe, skb->data, skb->len, &sent, 500);
> + ret = mt76u_bulk_msg(dev, skb->data, skb->len, 500);
> if (ret)
> return ret;
>
> @@ -263,14 +259,12 @@ void mt76x02u_mcu_fw_reset(struct mt76x02_dev *dev)
> EXPORT_SYMBOL_GPL(mt76x02u_mcu_fw_reset);
>
> static int
> -__mt76x02u_mcu_fw_send_data(struct mt76x02_dev *dev, struct mt76u_buf *buf,
> +__mt76x02u_mcu_fw_send_data(struct mt76x02_dev *dev, u8 *data,
> const void *fw_data, int len, u32 dst_addr)
> {
> - u8 *data = sg_virt(&buf->urb->sg[0]);
> - DECLARE_COMPLETION_ONSTACK(cmpl);
> __le32 info;
> u32 val;
> - int err;
> + int err, data_len;
>
> info = cpu_to_le32(FIELD_PREP(MT_MCU_MSG_PORT, CPU_TX_PORT) |
> FIELD_PREP(MT_MCU_MSG_LEN, len) |
> @@ -286,25 +280,12 @@ __mt76x02u_mcu_fw_send_data(struct mt76x02_dev *dev, struct mt76u_buf *buf,
> mt76u_single_wr(&dev->mt76, MT_VEND_WRITE_FCE,
> MT_FCE_DMA_LEN, len << 16);
>
> - buf->len = MT_CMD_HDR_LEN + len + sizeof(info);
> - err = mt76u_submit_buf(&dev->mt76, USB_DIR_OUT,
> - MT_EP_OUT_INBAND_CMD,
> - buf, GFP_KERNEL,
> - mt76u_mcu_complete_urb, &cmpl);
> - if (err < 0)
> - return err;
> -
> - if (!wait_for_completion_timeout(&cmpl,
> - msecs_to_jiffies(1000))) {
> - dev_err(dev->mt76.dev, "firmware upload timed out\n");
> - usb_kill_urb(buf->urb);
> - return -ETIMEDOUT;
> - }
> + data_len = MT_CMD_HDR_LEN + len + sizeof(info);
>
> - if (mt76u_urb_error(buf->urb)) {
> - dev_err(dev->mt76.dev, "firmware upload failed: %d\n",
> - buf->urb->status);
> - return buf->urb->status;
> + err = mt76u_bulk_msg(&dev->mt76, data, data_len, 1000);
> + if (err) {
> + dev_err(dev->mt76.dev, "firmware upload failed: %d\n", err);
> + return err;
> }
>
> val = mt76_rr(dev, MT_TX_CPU_FROM_FCE_CPU_DESC_IDX);
> @@ -317,17 +298,16 @@ __mt76x02u_mcu_fw_send_data(struct mt76x02_dev *dev, struct mt76u_buf *buf,
> int mt76x02u_mcu_fw_send_data(struct mt76x02_dev *dev, const void *data,
> int data_len, u32 max_payload, u32 offset)
> {
> - int err, len, pos = 0, max_len = max_payload - 8;
> - struct mt76u_buf buf;
> + int len, err = 0, pos = 0, max_len = max_payload - 8;
> + u8 *buf;
>
> - err = mt76u_buf_alloc(&dev->mt76, &buf, 1, max_payload, max_payload,
> - GFP_KERNEL);
> - if (err < 0)
> - return err;
> + buf = kmalloc(max_payload, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
>
> while (data_len > 0) {
> len = min_t(int, data_len, max_len);
> - err = __mt76x02u_mcu_fw_send_data(dev, &buf, data + pos,
> + err = __mt76x02u_mcu_fw_send_data(dev, buf, data + pos,
> len, offset + pos);
> if (err < 0)
> break;
> @@ -336,7 +316,7 @@ int mt76x02u_mcu_fw_send_data(struct mt76x02_dev *dev, const void *data,
> pos += len;
> usleep_range(5000, 10000);
> }
> - mt76u_buf_free(&buf);
> + kfree(buf);
>
> return err;
> }
> diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
> index 5f0faf07c346..358a95a2bbcb 100644
> --- a/drivers/net/wireless/mediatek/mt76/usb.c
> +++ b/drivers/net/wireless/mediatek/mt76/usb.c
> @@ -328,7 +328,6 @@ int mt76u_buf_alloc(struct mt76_dev *dev, struct mt76u_buf *buf,
>
> return mt76u_fill_rx_sg(dev, buf, nsgs, len, sglen);
> }
> -EXPORT_SYMBOL_GPL(mt76u_buf_alloc);
>
> void mt76u_buf_free(struct mt76u_buf *buf)
> {
> --
> 2.19.2
>
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Lorenzo Bianconi @ 2019-02-11 9:52 UTC (permalink / raw)
To: Stefan Wahren
Cc: Stanislaw Gruszka, Felix Fietkau, Doug Anderson,
Minas Harutyunyan, linux-wireless, linux-usb
In-Reply-To: <32eebaf4-f728-17a9-62e0-8c694ab83f86@i2se.com>
> Hi,
>
> Am 11.02.19 um 08:50 schrieb Stanislaw Gruszka:
> > On Sun, Feb 10, 2019 at 05:52:30PM +0100, Lorenzo Bianconi wrote:
> >> Anyway we will need to avoid SG since dwc_otg controller does not support it
>
> this isn't correct. AFAIK the dwc2 host driver doesn't implement it,
> which doesn't mean the controller does not support it.
This is what I meant :)
Regards,
Lorenzo
>
> Stefan
>
> > What does it mean the dwc_otg does not support SG ? Please be more specific.
> >
> > Stanislaw
>
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Lorenzo Bianconi @ 2019-02-11 10:04 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Stefan Wahren, Felix Fietkau, Doug Anderson, Minas Harutyunyan,
linux-wireless, linux-usb
In-Reply-To: <20190211074455.GA6292@redhat.com>
> On Sun, Feb 10, 2019 at 11:22:25AM +0100, Lorenzo Bianconi wrote:
> > > On Sat, Feb 09, 2019 at 09:29:05PM +0100, Stefan Wahren wrote:
> > > > > could you please test the following series:
> > > > > https://patchwork.kernel.org/cover/10764453/
> > > >
> > > > yeah this fixed the probing timeout and the driver will probe successful. AFAIK the dwc2 host mode doesn't support scatter-gather yet.
> > >
> > > So this is either dwc2 scatter-gather problem which should be addressed in
> > > this driver or mt76x0u does something wrong when configuring SG.
> > >
> > > Disabling SG is just workaround, which do not address actual problem.
> > >
> > > I think I found mt76x0u issue that could cause this USB probe error
> > > (and possibly also address AMD IOMMU issue). We seems do not correctly
> > > set URB transfer length smaller than sg buffer length. Attached patch
> > > should correct that.
> >
> > Hi Stanislaw,
> >
> > I think 'sg[0].length' is already set in mt76u_fill_rx_sg().
>
> It is, buf->len and sg[0].length are initialized to the same value for 1
> segment. But then buf->len (assigned to urb->buffer_transfer_length) change
> to smaller value , but sg[0].length stay the same. What I think can be
> problem for usb host driver.
>
> > Moreover applying this patch I got the following crash (rpi-5.0.y):
>
> Ok, so with patch probe fail instantly and trigger yet another bug(s)
> on error path. You seems to address that already.
>
> > Moreover for mt76x0u SG is 'already' disabled since we use just one
> > buffer so from performance point of view I do not see any difference
> > of using a standard usb buffer.
> > This patch has been tested in multiple scenarios and seems to fix
> > reported issues (for usb2.0).
>
> Ok, so passing buffer via urb->transfer_buffer works. But why urb->sg
> does not work for 1 segment ?
Here it is a different issue respect to the AMD IOMMU one, dwc2 host driver
does not implement SG I/O so probing fails. I guess it is still useful to
implement a 'legacy' mode that enable mt76 on host controllers that do not implement
SG I/O (rpi is a very common device so it will be cool to have mt76 working on
it). Moreover we are not removing functionalities, user experience will remain
the same
>
> > Are you concerned about increasing code complexity?
>
> That's one of my concerns. Another, more important one, is that
> changing to urb->transfer_buffer just hide the problems. And they will
> pop up when someone will start to use SG (BTW how this can be tested
> for more than one fragment, IOW how multiple fragments skb's can
> be generated ? ).
You need:
- usb 3.0 controller/device
- A-MSDU capable AP
>
> And now I think the bugs can be in mt76 driver taking that problems
> happened on different platforms (rpi and AMD IOMMU), i.e. we do not
> correctly set urb->nub_seg or length or do some other thing wrong.
We still need to fix it on usb3.0 with AMD cpu/motherboard :)
Regards,
Lorenzo
>
> Stanislaw
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Stefan Wahren @ 2019-02-11 10:33 UTC (permalink / raw)
To: Lorenzo Bianconi, Stanislaw Gruszka
Cc: Felix Fietkau, Doug Anderson, Minas Harutyunyan, linux-wireless,
linux-usb
In-Reply-To: <20190211100405.GD3467@localhost.localdomain>
Hi,
Am 11.02.19 um 11:04 schrieb Lorenzo Bianconi:
>> On Sun, Feb 10, 2019 at 11:22:25AM +0100, Lorenzo Bianconi wrote:
>>>> On Sat, Feb 09, 2019 at 09:29:05PM +0100, Stefan Wahren wrote:
>>>>>> could you please test the following series:
>>>>>> https://patchwork.kernel.org/cover/10764453/
>>>>> yeah this fixed the probing timeout and the driver will probe successful. AFAIK the dwc2 host mode doesn't support scatter-gather yet.
>>>> So this is either dwc2 scatter-gather problem which should be addressed in
>>>> this driver or mt76x0u does something wrong when configuring SG.
>>>>
>>>> Disabling SG is just workaround, which do not address actual problem.
>>>>
>>>> I think I found mt76x0u issue that could cause this USB probe error
>>>> (and possibly also address AMD IOMMU issue). We seems do not correctly
>>>> set URB transfer length smaller than sg buffer length. Attached patch
>>>> should correct that.
>>> Hi Stanislaw,
>>>
>>> I think 'sg[0].length' is already set in mt76u_fill_rx_sg().
>> It is, buf->len and sg[0].length are initialized to the same value for 1
>> segment. But then buf->len (assigned to urb->buffer_transfer_length) change
>> to smaller value , but sg[0].length stay the same. What I think can be
>> problem for usb host driver.
>>
>>> Moreover applying this patch I got the following crash (rpi-5.0.y):
>> Ok, so with patch probe fail instantly and trigger yet another bug(s)
>> on error path. You seems to address that already.
>>
>>> Moreover for mt76x0u SG is 'already' disabled since we use just one
>>> buffer so from performance point of view I do not see any difference
>>> of using a standard usb buffer.
>>> This patch has been tested in multiple scenarios and seems to fix
>>> reported issues (for usb2.0).
>> Ok, so passing buffer via urb->transfer_buffer works. But why urb->sg
>> does not work for 1 segment ?
> Here it is a different issue respect to the AMD IOMMU one, dwc2 host driver
> does not implement SG I/O so probing fails. I guess it is still useful to
> implement a 'legacy' mode that enable mt76 on host controllers that do not implement
> SG I/O (rpi is a very common device so it will be cool to have mt76 working on
> it). Moreover we are not removing functionalities, user experience will remain
> the same
>
i'm not sure that you understand my mail [1] with the summary of my test
results.
In case of using the arm/multi_v7_defconfig (32 bit) the mt76 works like
a charm without your sg avoid patch series, but the arm64/defconfig (64
bit) requires the series to probe at least. So i wouldn't conclude from
the fact that dwc2 doesn't support SG any probing issues on arm64. So we
need to investigate which config option triggers the problem.
Stefan
[1] - https://marc.info/?l=linux-usb&m=154981675724078
^ permalink raw reply
* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Lorenzo Bianconi @ 2019-02-11 11:06 UTC (permalink / raw)
To: Stefan Wahren
Cc: Stanislaw Gruszka, Felix Fietkau, Doug Anderson,
Minas Harutyunyan, linux-wireless, linux-usb
In-Reply-To: <f7c29b08-c7d5-4d10-4be1-958ee79678f1@i2se.com>
> Hi,
>
> Am 11.02.19 um 11:04 schrieb Lorenzo Bianconi:
> >> On Sun, Feb 10, 2019 at 11:22:25AM +0100, Lorenzo Bianconi wrote:
> >>>> On Sat, Feb 09, 2019 at 09:29:05PM +0100, Stefan Wahren wrote:
> >>>>>> could you please test the following series:
> >>>>>> https://patchwork.kernel.org/cover/10764453/
> >>>>> yeah this fixed the probing timeout and the driver will probe successful. AFAIK the dwc2 host mode doesn't support scatter-gather yet.
> >>>> So this is either dwc2 scatter-gather problem which should be addressed in
> >>>> this driver or mt76x0u does something wrong when configuring SG.
> >>>>
> >>>> Disabling SG is just workaround, which do not address actual problem.
> >>>>
> >>>> I think I found mt76x0u issue that could cause this USB probe error
> >>>> (and possibly also address AMD IOMMU issue). We seems do not correctly
> >>>> set URB transfer length smaller than sg buffer length. Attached patch
> >>>> should correct that.
> >>> Hi Stanislaw,
> >>>
> >>> I think 'sg[0].length' is already set in mt76u_fill_rx_sg().
> >> It is, buf->len and sg[0].length are initialized to the same value for 1
> >> segment. But then buf->len (assigned to urb->buffer_transfer_length) change
> >> to smaller value , but sg[0].length stay the same. What I think can be
> >> problem for usb host driver.
> >>
> >>> Moreover applying this patch I got the following crash (rpi-5.0.y):
> >> Ok, so with patch probe fail instantly and trigger yet another bug(s)
> >> on error path. You seems to address that already.
> >>
> >>> Moreover for mt76x0u SG is 'already' disabled since we use just one
> >>> buffer so from performance point of view I do not see any difference
> >>> of using a standard usb buffer.
> >>> This patch has been tested in multiple scenarios and seems to fix
> >>> reported issues (for usb2.0).
> >> Ok, so passing buffer via urb->transfer_buffer works. But why urb->sg
> >> does not work for 1 segment ?
> > Here it is a different issue respect to the AMD IOMMU one, dwc2 host driver
> > does not implement SG I/O so probing fails. I guess it is still useful to
> > implement a 'legacy' mode that enable mt76 on host controllers that do not implement
> > SG I/O (rpi is a very common device so it will be cool to have mt76 working on
> > it). Moreover we are not removing functionalities, user experience will remain
> > the same
> >
> i'm not sure that you understand my mail [1] with the summary of my test
> results.
>
Yes right, I did not get it sorry :)
as indicated here https://www.raspberrypi.org/documentation/linux/kernel/building.md
I am using bcm2709_defconfig config (using it I spotted the mt76 crashes and
probe failure)
Regards,
Lorenzo
> In case of using the arm/multi_v7_defconfig (32 bit) the mt76 works like
> a charm without your sg avoid patch series, but the arm64/defconfig (64
> bit) requires the series to probe at least. So i wouldn't conclude from
> the fact that dwc2 doesn't support SG any probing issues on arm64. So we
> need to investigate which config option triggers the problem.
>
> Stefan
>
> [1] - https://marc.info/?l=linux-usb&m=154981675724078
>
^ permalink raw reply
* Re: [PATCH] libertas_tf: lower the debug level of command trace
From: Steve deRosier @ 2019-02-11 13:23 UTC (permalink / raw)
To: Lubomir Rintel; +Cc: Kalle Valo, David S. Miller, linux-wireless, LKML
In-Reply-To: <20190210194735.17939-1-lkundrak@v3.sk>
On Sun, Feb 10, 2019 at 11:47 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> Logging each and every command response is way too much for INFO level.
> Silence this, unless CONFIG_LIBERTAS_THINFIRM_DEBUG has been enabled.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> ---
> drivers/net/wireless/marvell/libertas_tf/cmd.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/libertas_tf/cmd.c b/drivers/net/wireless/marvell/libertas_tf/cmd.c
> index 909ac3685010..64b147dd2432 100644
> --- a/drivers/net/wireless/marvell/libertas_tf/cmd.c
> +++ b/drivers/net/wireless/marvell/libertas_tf/cmd.c
> @@ -737,10 +737,9 @@ int lbtf_process_rx_command(struct lbtf_private *priv)
> respcmd = le16_to_cpu(resp->command);
> result = le16_to_cpu(resp->result);
>
> - if (net_ratelimit())
> - pr_info("libertastf: cmd response 0x%04x, seq %d, size %d\n",
> - respcmd, le16_to_cpu(resp->seqnum),
> - le16_to_cpu(resp->size));
> + lbtf_deb_cmd("libertastf: cmd response 0x%04x, seq %d, size %d\n",
> + respcmd, le16_to_cpu(resp->seqnum),
> + le16_to_cpu(resp->size));
>
> if (resp->seqnum != priv->cur_cmd->cmdbuf->seqnum) {
> spin_unlock_irqrestore(&priv->driver_lock, flags);
> --
> 2.20.1
>
Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
^ permalink raw reply
* Re: [PATCH] libertas_tf: don't set URB_ZERO_PACKET on IN USB transfer
From: Steve deRosier @ 2019-02-11 13:38 UTC (permalink / raw)
To: Lubomir Rintel; +Cc: Kalle Valo, David S. Miller, linux-wireless, LKML, stable
In-Reply-To: <20190210194749.18135-1-lkundrak@v3.sk>
On Sun, Feb 10, 2019 at 11:48 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> It doesn't make sense and the USB core warns on each submit of such
> URB, easily flooding the message buffer with tracebacks.
>
> Analogous issue was fixed in regular libertas driver in commit 6528d8804780
> ("libertas: don't set URB_ZERO_PACKET on IN USB transfer").
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> ---
> drivers/net/wireless/marvell/libertas_tf/if_usb.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/libertas_tf/if_usb.c b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
> index 789337ea676a..6ede6168bd85 100644
> --- a/drivers/net/wireless/marvell/libertas_tf/if_usb.c
> +++ b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
> @@ -433,8 +433,6 @@ static int __if_usb_submit_rx_urb(struct if_usb_card *cardp,
> skb_tail_pointer(skb),
> MRVDRV_ETH_RX_PACKET_BUFFER_SIZE, callbackfn, cardp);
>
> - cardp->rx_urb->transfer_flags |= URB_ZERO_PACKET;
> -
> lbtf_deb_usb2(&cardp->udev->dev, "Pointer for rx_urb %p\n",
> cardp->rx_urb);
> ret = usb_submit_urb(cardp->rx_urb, GFP_ATOMIC);
> --
> 2.20.1
>
Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
^ permalink raw reply
* Re: [PATCH] libertas_tf: move the banner to a more appropriate place
From: Steve deRosier @ 2019-02-11 13:38 UTC (permalink / raw)
To: Lubomir Rintel; +Cc: Kalle Valo, David S. Miller, linux-wireless, LKML
In-Reply-To: <20190210194811.18345-1-lkundrak@v3.sk>
On Sun, Feb 10, 2019 at 11:48 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> Also, turn it to a dev_info() to make checkpatch.pl happy.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> ---
> drivers/net/wireless/marvell/libertas_tf/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/libertas_tf/main.c b/drivers/net/wireless/marvell/libertas_tf/main.c
> index 1d45da187b9b..c71ad87cdc44 100644
> --- a/drivers/net/wireless/marvell/libertas_tf/main.c
> +++ b/drivers/net/wireless/marvell/libertas_tf/main.c
> @@ -318,7 +318,6 @@ static int lbtf_op_start(struct ieee80211_hw *hw)
> goto err_prog_firmware;
> }
>
> - printk(KERN_INFO "libertastf: Marvell WLAN 802.11 thinfirm adapter\n");
> lbtf_deb_leave(LBTF_DEB_MACOPS);
> return 0;
>
> @@ -649,6 +648,7 @@ struct lbtf_private *lbtf_add_card(void *card, struct device *dmdev)
> if (ieee80211_register_hw(hw))
> goto err_init_adapter;
>
> + dev_info(dmdev, "libertastf: Marvell WLAN 802.11 thinfirm adapter\n");
> goto done;
>
> err_init_adapter:
> --
> 2.20.1
>
Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
^ permalink raw reply
* Re: [PATCH] libertas_tf: fix signal reporting
From: Steve deRosier @ 2019-02-11 13:39 UTC (permalink / raw)
To: Lubomir Rintel; +Cc: Kalle Valo, David S. Miller, linux-wireless, LKML
In-Reply-To: <20190210194822.18539-1-lkundrak@v3.sk>
On Sun, Feb 10, 2019 at 11:48 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> Instead of exposing the signal-to-noise ration, calculate the actual signal
> level taking the noise floor into account.
>
> Also, flip the SIGNAL_DBM bit on, so that mac80211 exposes the signal
> level along with the station info in scan results. This fills
> NetworkManager's "nmcli d wifi output" output with colors, bars and joy.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> ---
> drivers/net/wireless/marvell/libertas_tf/main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/libertas_tf/main.c b/drivers/net/wireless/marvell/libertas_tf/main.c
> index c71ad87cdc44..f93b400db949 100644
> --- a/drivers/net/wireless/marvell/libertas_tf/main.c
> +++ b/drivers/net/wireless/marvell/libertas_tf/main.c
> @@ -562,7 +562,7 @@ int lbtf_rx(struct lbtf_private *priv, struct sk_buff *skb)
> stats.flag |= RX_FLAG_FAILED_FCS_CRC;
> stats.freq = priv->cur_freq;
> stats.band = NL80211_BAND_2GHZ;
> - stats.signal = prxpd->snr;
> + stats.signal = prxpd->snr - prxpd->nf;
> priv->noise = prxpd->nf;
> /* Marvell rate index has a hole at value 4 */
> if (prxpd->rx_rate > 4)
> @@ -626,6 +626,7 @@ struct lbtf_private *lbtf_add_card(void *card, struct device *dmdev)
>
> hw->queues = 1;
> ieee80211_hw_set(hw, HOST_BROADCAST_PS_BUFFERING);
> + ieee80211_hw_set(hw, SIGNAL_DBM);
> hw->extra_tx_headroom = sizeof(struct txpd);
> memcpy(priv->channels, lbtf_channels, sizeof(lbtf_channels));
> memcpy(priv->rates, lbtf_rates, sizeof(lbtf_rates));
> --
> 2.20.1
>
Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
^ permalink raw reply
* Re: [PATCH 1/3] libertas_tf: move hardware callbacks to a separate structure
From: Steve deRosier @ 2019-02-11 13:47 UTC (permalink / raw)
To: Lubomir Rintel; +Cc: Kalle Valo, David S. Miller, linux-wireless, LKML
In-Reply-To: <20190210195217.18817-2-lkundrak@v3.sk>
On Sun, Feb 10, 2019 at 11:52 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> We'll need to talk to the firmware to get a hardware address before
> device is registered with ieee80211 subsystem at the end of
> lbtf_add_card(). Hooking the callbacks after that is too late.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> ---
> drivers/net/wireless/marvell/libertas_tf/cmd.c | 2 +-
> .../net/wireless/marvell/libertas_tf/if_usb.c | 12 +++++++-----
> .../wireless/marvell/libertas_tf/libertas_tf.h | 17 +++++++++++------
> drivers/net/wireless/marvell/libertas_tf/main.c | 10 ++++++----
> 4 files changed, 25 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/libertas_tf/cmd.c b/drivers/net/wireless/marvell/libertas_tf/cmd.c
> index 64b147dd2432..130f578daafd 100644
> --- a/drivers/net/wireless/marvell/libertas_tf/cmd.c
> +++ b/drivers/net/wireless/marvell/libertas_tf/cmd.c
> @@ -256,7 +256,7 @@ static void lbtf_submit_command(struct lbtf_private *priv,
> command, le16_to_cpu(cmd->seqnum), cmdsize);
> lbtf_deb_hex(LBTF_DEB_CMD, "DNLD_CMD", (void *) cmdnode->cmdbuf, cmdsize);
>
> - ret = priv->hw_host_to_card(priv, MVMS_CMD, (u8 *) cmd, cmdsize);
> + ret = priv->ops->hw_host_to_card(priv, MVMS_CMD, (u8 *)cmd, cmdsize);
> spin_unlock_irqrestore(&priv->driver_lock, flags);
>
> if (ret) {
> diff --git a/drivers/net/wireless/marvell/libertas_tf/if_usb.c b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
> index 6ede6168bd85..7a5a1a85dcf7 100644
> --- a/drivers/net/wireless/marvell/libertas_tf/if_usb.c
> +++ b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
> @@ -131,6 +131,12 @@ static void if_usb_fw_timeo(struct timer_list *t)
> lbtf_deb_leave(LBTF_DEB_USB);
> }
>
> +static const struct lbtf_ops if_usb_ops = {
> + .hw_host_to_card = if_usb_host_to_card,
> + .hw_prog_firmware = if_usb_prog_firmware,
> + .hw_reset_device = if_usb_reset_device,
> +};
> +
> /**
> * if_usb_probe - sets the configuration values
> *
> @@ -216,15 +222,11 @@ static int if_usb_probe(struct usb_interface *intf,
> goto dealloc;
> }
>
> - priv = lbtf_add_card(cardp, &udev->dev);
> + priv = lbtf_add_card(cardp, &udev->dev, &if_usb_ops);
> if (!priv)
> goto dealloc;
>
> cardp->priv = priv;
> -
> - priv->hw_host_to_card = if_usb_host_to_card;
> - priv->hw_prog_firmware = if_usb_prog_firmware;
> - priv->hw_reset_device = if_usb_reset_device;
> cardp->boot2_version = udev->descriptor.bcdDevice;
>
> usb_get_dev(udev);
> diff --git a/drivers/net/wireless/marvell/libertas_tf/libertas_tf.h b/drivers/net/wireless/marvell/libertas_tf/libertas_tf.h
> index ad77b92d0b41..11d5ff68bc5e 100644
> --- a/drivers/net/wireless/marvell/libertas_tf/libertas_tf.h
> +++ b/drivers/net/wireless/marvell/libertas_tf/libertas_tf.h
> @@ -173,10 +173,19 @@ struct channel_range {
>
> struct if_usb_card;
>
> +struct lbtf_ops {
> + /** Hardware access */
> + int (*hw_host_to_card)(struct lbtf_private *priv, u8 type,
> + u8 *payload, u16 nb);
> + int (*hw_prog_firmware)(struct if_usb_card *cardp);
> + int (*hw_reset_device)(struct if_usb_card *cardp);
> +};
> +
> /** Private structure for the MV device */
> struct lbtf_private {
> void *card;
> struct ieee80211_hw *hw;
> + const struct lbtf_ops *ops;
>
> /* Command response buffer */
> u8 cmd_resp_buff[LBS_UPLD_SIZE];
> @@ -188,11 +197,6 @@ struct lbtf_private {
>
> struct work_struct cmd_work;
> struct work_struct tx_work;
> - /** Hardware access */
> - int (*hw_host_to_card) (struct lbtf_private *priv, u8 type, u8 *payload, u16 nb);
> - int (*hw_prog_firmware) (struct if_usb_card *cardp);
> - int (*hw_reset_device) (struct if_usb_card *cardp);
> -
>
> /** Wlan adapter data structure*/
> /** STATUS variables */
> @@ -486,7 +490,8 @@ void lbtf_cmd_response_rx(struct lbtf_private *priv);
> /* main.c */
> struct chan_freq_power *lbtf_get_region_cfp_table(u8 region,
> int *cfp_no);
> -struct lbtf_private *lbtf_add_card(void *card, struct device *dmdev);
> +struct lbtf_private *lbtf_add_card(void *card, struct device *dmdev,
> + const struct lbtf_ops *ops);
> int lbtf_remove_card(struct lbtf_private *priv);
> int lbtf_start_card(struct lbtf_private *priv);
> int lbtf_rx(struct lbtf_private *priv, struct sk_buff *skb);
> diff --git a/drivers/net/wireless/marvell/libertas_tf/main.c b/drivers/net/wireless/marvell/libertas_tf/main.c
> index f93b400db949..8ed3cd158cf5 100644
> --- a/drivers/net/wireless/marvell/libertas_tf/main.c
> +++ b/drivers/net/wireless/marvell/libertas_tf/main.c
> @@ -281,7 +281,7 @@ static void lbtf_tx_work(struct work_struct *work)
> BUG_ON(priv->tx_skb);
> spin_lock_irq(&priv->driver_lock);
> priv->tx_skb = skb;
> - err = priv->hw_host_to_card(priv, MVMS_DAT, skb->data, skb->len);
> + err = priv->ops->hw_host_to_card(priv, MVMS_DAT, skb->data, skb->len);
> spin_unlock_irq(&priv->driver_lock);
> if (err) {
> dev_kfree_skb_any(skb);
> @@ -301,7 +301,7 @@ static int lbtf_op_start(struct ieee80211_hw *hw)
>
> if (!priv->fw_ready)
> /* Upload firmware */
> - if (priv->hw_prog_firmware(card))
> + if (priv->ops->hw_prog_firmware(card))
> goto err_prog_firmware;
>
> /* poke the firmware */
> @@ -322,7 +322,7 @@ static int lbtf_op_start(struct ieee80211_hw *hw)
> return 0;
>
> err_prog_firmware:
> - priv->hw_reset_device(card);
> + priv->ops->hw_reset_device(card);
> lbtf_deb_leave_args(LBTF_DEB_MACOPS, "error programming fw; ret=%d", ret);
> return ret;
> }
> @@ -605,7 +605,8 @@ EXPORT_SYMBOL_GPL(lbtf_rx);
> *
> * Returns: pointer to struct lbtf_priv.
> */
> -struct lbtf_private *lbtf_add_card(void *card, struct device *dmdev)
> +struct lbtf_private *lbtf_add_card(void *card, struct device *dmdev,
> + const struct lbtf_ops *ops)
> {
> struct ieee80211_hw *hw;
> struct lbtf_private *priv = NULL;
> @@ -622,6 +623,7 @@ struct lbtf_private *lbtf_add_card(void *card, struct device *dmdev)
>
> priv->hw = hw;
> priv->card = card;
> + priv->ops = ops;
> priv->tx_skb = NULL;
>
> hw->queues = 1;
> --
> 2.20.1
>
Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
^ permalink raw reply
* [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Stefan Wahren @ 2019-02-11 14:04 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Stanislaw Gruszka, Felix Fietkau, Doug Anderson,
Minas Harutyunyan, linux-wireless, linux-usb
In-Reply-To: <20190211110635.GD2293@localhost.localdomain>
Hi Lorenzo,
Am 11.02.19 um 12:06 schrieb Lorenzo Bianconi:
>> Hi,
>>
>> Am 11.02.19 um 11:04 schrieb Lorenzo Bianconi:
>>>> On Sun, Feb 10, 2019 at 11:22:25AM +0100, Lorenzo Bianconi wrote:
>>>>>> On Sat, Feb 09, 2019 at 09:29:05PM +0100, Stefan Wahren wrote:
>>>>>>>> could you please test the following series:
>>>>>>>> https://patchwork.kernel.org/cover/10764453/
>>>>>>> yeah this fixed the probing timeout and the driver will probe successful. AFAIK the dwc2 host mode doesn't support scatter-gather yet.
>>>>>> So this is either dwc2 scatter-gather problem which should be addressed in
>>>>>> this driver or mt76x0u does something wrong when configuring SG.
>>>>>>
>>>>>> Disabling SG is just workaround, which do not address actual problem.
>>>>>>
>>>>>> I think I found mt76x0u issue that could cause this USB probe error
>>>>>> (and possibly also address AMD IOMMU issue). We seems do not correctly
>>>>>> set URB transfer length smaller than sg buffer length. Attached patch
>>>>>> should correct that.
>>>>> Hi Stanislaw,
>>>>>
>>>>> I think 'sg[0].length' is already set in mt76u_fill_rx_sg().
>>>> It is, buf->len and sg[0].length are initialized to the same value for 1
>>>> segment. But then buf->len (assigned to urb->buffer_transfer_length) change
>>>> to smaller value , but sg[0].length stay the same. What I think can be
>>>> problem for usb host driver.
>>>>
>>>>> Moreover applying this patch I got the following crash (rpi-5.0.y):
>>>> Ok, so with patch probe fail instantly and trigger yet another bug(s)
>>>> on error path. You seems to address that already.
>>>>
>>>>> Moreover for mt76x0u SG is 'already' disabled since we use just one
>>>>> buffer so from performance point of view I do not see any difference
>>>>> of using a standard usb buffer.
>>>>> This patch has been tested in multiple scenarios and seems to fix
>>>>> reported issues (for usb2.0).
>>>> Ok, so passing buffer via urb->transfer_buffer works. But why urb->sg
>>>> does not work for 1 segment ?
>>> Here it is a different issue respect to the AMD IOMMU one, dwc2 host driver
>>> does not implement SG I/O so probing fails. I guess it is still useful to
>>> implement a 'legacy' mode that enable mt76 on host controllers that do not implement
>>> SG I/O (rpi is a very common device so it will be cool to have mt76 working on
>>> it). Moreover we are not removing functionalities, user experience will remain
>>> the same
>>>
>> i'm not sure that you understand my mail [1] with the summary of my test
>> results.
>>
> Yes right, I did not get it sorry :)
> as indicated here https://www.raspberrypi.org/documentation/linux/kernel/building.md
> I am using bcm2709_defconfig config (using it I spotted the mt76 crashes and
> probe failure)
no problem, at the beginning this could be very confusing. I only want
to clarify that this documentation refers to the vendor kernel (with a
different USB host driver) of the Raspberry Pi Foundation.
All my results refers to the mainline kernel we all should talk about. I
started a gist which try to describe the mainline variant:
https://gist.github.com/lategoodbye/c7317a42bf7f9c07f5a91baed8c68f75
Maybe this could be helpful.
Stefan
> Regards,
> Lorenzo
>
>> In case of using the arm/multi_v7_defconfig (32 bit) the mt76 works like
>> a charm without your sg avoid patch series, but the arm64/defconfig (64
>> bit) requires the series to probe at least. So i wouldn't conclude from
>> the fact that dwc2 doesn't support SG any probing issues on arm64. So we
>> need to investigate which config option triggers the problem.
>>
>> Stefan
>>
>> [1] - https://marc.info/?l=linux-usb&m=154981675724078
>>
^ permalink raw reply
* Re: [PATCH 2/3] libertas_tf: don't defer firmware loading until start()
From: Steve deRosier @ 2019-02-11 14:10 UTC (permalink / raw)
To: Lubomir Rintel; +Cc: Kalle Valo, David S. Miller, linux-wireless, LKML
In-Reply-To: <20190210195217.18817-3-lkundrak@v3.sk>
On Sun, Feb 10, 2019 at 11:52 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> In order to be able to get a MAC address before we register the device
> with ieee80211 we'll need to load the firmware way earlier.
>
> There seems to be one problem with this: the device seems to start
> with radio enabled and starts sending in frames right after the firmware
> load finishes. This might be a firmware bug. Disable the radio as soon
> as possible.
>
I've got a quibble with calling the behavior a bug. As far as I
remember, it's behaving as designed/specified and was quite
appropriate back when this driver originally went upstream. This is a
10 year old fw and driver and needs have changed - which doesn't mean
it was wrong to do originally.
Now, I'm not saying there's no bugs in the fw. Nor that it wouldn't be
nice to change the behavior to accommodate this change. If I still had
access to the firmware source I even might do so.
...
> @@ -648,6 +642,19 @@ struct lbtf_private *lbtf_add_card(void *card, struct device *dmdev,
>
> INIT_WORK(&priv->cmd_work, lbtf_cmd_work);
> INIT_WORK(&priv->tx_work, lbtf_tx_work);
> +
> + if (priv->ops->hw_prog_firmware(priv)) {
> + lbtf_deb_usbd(&udev->dev, "Error programming the firmware\n");
> + priv->ops->hw_reset_device(priv);
> + goto err_init_adapter;
> + }
> +
> + /* The firmware seems to start with the radio enabled. Turn it
> + * off before an actual mac80211 start callback is invoked.
> + */
> + priv->radioon = RADIO_OFF;
Maybe move this up a few lines to before you program the fw? Seems
appropriate to initialize it first. While I expect there's no chance
of a race as the
mac80211 start callback hasn't been invoked yet, superficially it
looks like there could be.
> + lbtf_set_radio_control(priv);
> +
> if (ieee80211_register_hw(hw))
> goto err_init_adapter;
>
> --
> 2.20.1
>
Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
^ permalink raw reply
* Re: [PATCH 3/3] libertas_tf: get the MAC address before registering the device
From: Steve deRosier @ 2019-02-11 14:11 UTC (permalink / raw)
To: Lubomir Rintel; +Cc: Kalle Valo, David S. Miller, linux-wireless, LKML
In-Reply-To: <20190210195217.18817-4-lkundrak@v3.sk>
On Sun, Feb 10, 2019 at 11:52 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> The start() callback is too late for this: NetworkManager would already
> have seen the hardware, thinking 00:00:00:00:00:00 is its permanent
> address.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> ---
> .../net/wireless/marvell/libertas_tf/main.c | 57 ++++---------------
> 1 file changed, 11 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/libertas_tf/main.c b/drivers/net/wireless/marvell/libertas_tf/main.c
> index b4bd3047eb4e..da53da71987e 100644
> --- a/drivers/net/wireless/marvell/libertas_tf/main.c
> +++ b/drivers/net/wireless/marvell/libertas_tf/main.c
> @@ -125,37 +125,6 @@ static void lbtf_cmd_work(struct work_struct *work)
> lbtf_deb_leave(LBTF_DEB_CMD);
> }
>
> -/**
> - * lbtf_setup_firmware: initialize firmware.
> - *
> - * @priv A pointer to struct lbtf_private structure
> - *
> - * Returns: 0 on success.
> - */
> -static int lbtf_setup_firmware(struct lbtf_private *priv)
> -{
> - int ret = -1;
> -
> - lbtf_deb_enter(LBTF_DEB_FW);
> - /*
> - * Read priv address from HW
> - */
> - eth_broadcast_addr(priv->current_addr);
> - ret = lbtf_update_hw_spec(priv);
> - if (ret) {
> - ret = -1;
> - goto done;
> - }
> -
> - lbtf_set_mac_control(priv);
> - lbtf_set_radio_control(priv);
> -
> - ret = 0;
> -done:
> - lbtf_deb_leave_args(LBTF_DEB_FW, "ret: %d", ret);
> - return ret;
> -}
> -
> /**
> * This function handles the timeout of command sending.
> * It will re-send the same command again.
> @@ -289,30 +258,17 @@ static void lbtf_tx_work(struct work_struct *work)
> static int lbtf_op_start(struct ieee80211_hw *hw)
> {
> struct lbtf_private *priv = hw->priv;
> - int ret = -1;
>
> lbtf_deb_enter(LBTF_DEB_MACOPS);
>
> - /* poke the firmware */
> priv->capability = WLAN_CAPABILITY_SHORT_PREAMBLE;
> priv->radioon = RADIO_ON;
> priv->mac_control = CMD_ACT_MAC_RX_ON | CMD_ACT_MAC_TX_ON;
> - ret = lbtf_setup_firmware(priv);
> - if (ret)
> - goto err_setup_firmware;
> -
> - if ((priv->fwrelease < LBTF_FW_VER_MIN) ||
> - (priv->fwrelease > LBTF_FW_VER_MAX)) {
> - ret = -1;
> - goto err_setup_firmware;
> - }
> + lbtf_set_mac_control(priv);
> + lbtf_set_radio_control(priv);
>
> lbtf_deb_leave(LBTF_DEB_MACOPS);
> return 0;
> -
> -err_setup_firmware:
> - lbtf_deb_leave_args(LBTF_DEB_MACOPS, "fw setup error; ret=%d", ret);
> - return ret;
> }
>
> static void lbtf_op_stop(struct ieee80211_hw *hw)
> @@ -649,6 +605,15 @@ struct lbtf_private *lbtf_add_card(void *card, struct device *dmdev,
> goto err_init_adapter;
> }
>
> + eth_broadcast_addr(priv->current_addr);
> + if (lbtf_update_hw_spec(priv))
> + goto err_init_adapter;
> +
> + if (priv->fwrelease < LBTF_FW_VER_MIN ||
> + priv->fwrelease > LBTF_FW_VER_MAX) {
> + goto err_init_adapter;
> + }
> +
> /* The firmware seems to start with the radio enabled. Turn it
> * off before an actual mac80211 start callback is invoked.
> */
> --
> 2.20.1
>
Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
^ permalink raw reply
* [PATCH] cfg80211: Use const more consistently in for_each_element macros
From: Jouni Malinen @ 2019-02-11 14:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Jouni Malinen
Enforce the first argument to be a correct type of a pointer to struct
element and avoid unnecessary typecasts from const to non-const pointers
(the change in validate_ie_attr() is needed to make this part work). In
addition, avoid signed/unsigned comparison within for_each_element() and
mark struct element packed just in case.
Signed-off-by: Jouni Malinen <j@w1.fi>
---
include/linux/ieee80211.h | 18 +++++++++---------
net/wireless/nl80211.c | 2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 8da5ba9..8584c14 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -3284,16 +3284,16 @@ struct element {
u8 id;
u8 datalen;
u8 data[];
-};
+} __packed;
/* element iteration helpers */
-#define for_each_element(element, _data, _datalen) \
- for (element = (void *)(_data); \
- (u8 *)(_data) + (_datalen) - (u8 *)element >= \
- sizeof(*element) && \
- (u8 *)(_data) + (_datalen) - (u8 *)element >= \
- sizeof(*element) + element->datalen; \
- element = (void *)(element->data + element->datalen))
+#define for_each_element(_elem, _data, _datalen) \
+ for (_elem = (const struct element *)(_data); \
+ (const u8 *)(_data) + (_datalen) - (const u8 *)_elem >= \
+ (int)sizeof(*_elem) && \
+ (const u8 *)(_data) + (_datalen) - (const u8 *)_elem >= \
+ (int)sizeof(*_elem) + _elem->datalen; \
+ _elem = (const struct element *)(_elem->data + _elem->datalen))
#define for_each_element_id(element, _id, data, datalen) \
for_each_element(element, data, datalen) \
@@ -3330,7 +3330,7 @@ struct element {
static inline bool for_each_element_completed(const struct element *element,
const void *data, size_t datalen)
{
- return (u8 *)element == (u8 *)data + datalen;
+ return (const u8 *)element == (const u8 *)data + datalen;
}
#endif /* LINUX_IEEE80211_H */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 5d85f60..80878b4 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -205,7 +205,7 @@ static int validate_ie_attr(const struct nlattr *attr,
{
const u8 *data = nla_data(attr);
unsigned int len = nla_len(attr);
- struct element *elem;
+ const struct element *elem;
for_each_element(elem, data, len) {
/* nothing */
--
2.7.4
^ permalink raw reply related
* [PATCH v2] cfg80211: fix and clean up cfg80211_gen_new_bssid()
From: Johannes Berg @ 2019-02-11 15:03 UTC (permalink / raw)
To: linux-wireless; +Cc: Jouni Malinen, Peng Xu, Sara Sharon, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Fix cfg80211_gen_new_bssid() to not rely on u64 modulo arithmetic,
which isn't needed since we really just want to mask there. Also,
clean it up to calculate the mask only once and use GENMASK_ULL()
instead of open-coding the mask calculation.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/cfg80211.h | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index b61b71f369c7..02a4d5a80521 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -5475,22 +5475,20 @@ cfg80211_inform_bss_frame(struct wiphy *wiphy,
* @bssid: transmitter BSSID
* @max_bssid: max BSSID indicator, taken from Multiple BSSID element
* @mbssid_index: BSSID index, taken from Multiple BSSID index element
- * @new_bssid_addr: address of the resulting BSSID
+ * @new_bssid: address of the resulting BSSID
*/
static inline void cfg80211_gen_new_bssid(const u8 *bssid, u8 max_bssid,
- u8 mbssid_index, u8 *new_bssid_addr)
+ u8 mbssid_index, u8 *new_bssid)
{
- u64 bssid_tmp, new_bssid;
- u64 lsb_n;
+ u64 bssid_u64 = ether_addr_to_u64(bssid);
+ u64 mask = GENMASK_ULL(max_bssid - 1, 0);
+ u64 new_bssid_u64;
- bssid_tmp = ether_addr_to_u64(bssid);
+ new_bssid_u64 = bssid_u64 & ~mask;
- lsb_n = bssid_tmp & ((1 << max_bssid) - 1);
- new_bssid = bssid_tmp;
- new_bssid &= ~((1 << max_bssid) - 1);
- new_bssid |= (lsb_n + mbssid_index) % (1 << max_bssid);
+ new_bssid_u64 |= ((bssid_u64 & mask) + mbssid_index) & mask;
- u64_to_ether_addr(new_bssid, new_bssid_addr);
+ u64_to_ether_addr(new_bssid_u64, new_bssid);
}
/**
--
2.17.2
^ permalink raw reply related
* [PATCH 1/6] ath10k: add missing values to wmi_service_name()
From: Kalle Valo @ 2019-02-11 15:09 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
After implementing the next patch GCC reported:
drivers/net/wireless/ath/ath10k/wmi.h:385:2: warning: enumeration value 'WMI_SERVICE_BTCOEX' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/wmi.h:385:2: warning: enumeration value 'WMI_SERVICE_MGMT_TX_WMI' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/wmi.h:385:2: warning: enumeration value 'WMI_SERVICE_SPOOF_MAC_SUPPORT' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/wmi.h:385:2: warning: enumeration value 'WMI_SERVICE_VDEV_DISABLE_4_ADDR_SRC_LRN_SUPPORT' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/wmi.h:385:2: warning: enumeration value 'WMI_SERVICE_BB_TIMING_CONFIG_SUPPORT' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/wmi.h:385:2: warning: enumeration value 'WMI_SERVICE_THERM_THROT' not handled in switch [-Wswitch]
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/wmi.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index b10ed523b99e..529f5a26f3f3 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -475,6 +475,7 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_TX_MODE_PUSH_PULL);
SVCSTR(WMI_SERVICE_TX_MODE_DYNAMIC);
SVCSTR(WMI_SERVICE_VDEV_RX_FILTER);
+ SVCSTR(WMI_SERVICE_BTCOEX);
SVCSTR(WMI_SERVICE_CHECK_CAL_VERSION);
SVCSTR(WMI_SERVICE_DBGLOG_WARN2);
SVCSTR(WMI_SERVICE_BTCOEX_DUTY_CYCLE);
@@ -484,13 +485,18 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_SMART_LOGGING_SUPPORT);
SVCSTR(WMI_SERVICE_TDLS_CONN_TRACKER_IN_HOST_MODE);
SVCSTR(WMI_SERVICE_TDLS_EXPLICIT_MODE_ONLY);
+ SVCSTR(WMI_SERVICE_MGMT_TX_WMI);
SVCSTR(WMI_SERVICE_TDLS_WIDER_BANDWIDTH);
SVCSTR(WMI_SERVICE_HTT_MGMT_TX_COMP_VALID_FLAGS);
SVCSTR(WMI_SERVICE_HOST_DFS_CHECK_SUPPORT);
SVCSTR(WMI_SERVICE_TPC_STATS_FINAL);
SVCSTR(WMI_SERVICE_RESET_CHIP);
+ SVCSTR(WMI_SERVICE_SPOOF_MAC_SUPPORT);
SVCSTR(WMI_SERVICE_TX_DATA_ACK_RSSI);
SVCSTR(WMI_SERVICE_VDEV_DIFFERENT_BEACON_INTERVAL_SUPPORT);
+ SVCSTR(WMI_SERVICE_VDEV_DISABLE_4_ADDR_SRC_LRN_SUPPORT);
+ SVCSTR(WMI_SERVICE_BB_TIMING_CONFIG_SUPPORT);
+ SVCSTR(WMI_SERVICE_THERM_THROT);
SVCSTR(WMI_SERVICE_RTT_RESPONDER_ROLE);
SVCSTR(WMI_SERVICE_PER_PACKET_SW_ENCRYPT);
SVCSTR(WMI_SERVICE_REPORT_AIRTIME);
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox