On Fri, Dec 30, 2022 at 10:51:28PM -0800, Brian Norris wrote:
> In preparing OpenWrt support for the TP-Link OnHub, I've extracted its
> BDF for inclusion in the mainline board-2.bin.
Apologies, I just realized that:
(a) QCA988X devices have a board.bin file upstream, not a boar
Hi,
In preparing OpenWrt support for the TP-Link OnHub, I've extracted its
BDF for inclusion in the mainline board-2.bin.
Per the wiki [1]:
* description for what hardware this is
- IPQ8064-based router, with three radios -- a 2.4 GHz, a 5 GHz, and
an auxiliary (monitoring?) radio
-
Hi Cale,
I meant to respond a while back, but didn't get around to it, sorry.
In case it's still helpful:
On Wed, May 11, 2022 at 3:52 PM Cale Collins wrote:
> On Mon, May 9, 2022 at 11:16 AM Cale Collins wrote:
> > I'm experiencing an issue very similar to this. The regulatory domain
> > sett
On Tue, Apr 26, 2022 at 10:20 PM Abhishek Kumar wrote:
> On Tue, Apr 26, 2022 at 3:34 PM Brian Norris wrote:
> > You could have retained my:
> >
> > Reviewed-by: Brian Norris
> >
> > but no worries; it's just a few characters ;)
> Oh! sorry about tha
r
> ---
>
> Changes in v2:
> - Fixed typo, replaced ath11k by ath10k in the comments.
> - Adjusted the position of my S-O-B tag.
> - Added the Tested-on tag.
You could have retained my:
Reviewed-by: Brian Norris
but no worries; it's just a few characters ;)
_
V_SUSPEND_AND_DISABLE_INTR);
> + }
> ar->state = ATH10K_STATE_OFF;
> }
> mutex_unlock(&ar->conf_mutex);
Otherwise, I believe this is the right solution to the problem pointed
out in the commit message:
Reviewed-by: Brian Norris
On Mon, Apr 25, 2022 at 04:11:44PM -0700, Brian Norris wrote:
> On Mon, Apr 25, 2022 at 02:15:20AM +, Abhishek Kumar wrote:
> > --- a/drivers/net/wireless/ath/ath10k/mac.c
> > +++ b/drivers/net/wireless/ath/ath10k/mac.c
> > @@ -5345,8 +5345,22 @@ static void ath10k_stop(st
Hi Patrick,
On Sat, Apr 23, 2022 at 3:52 AM Patrick Steinhardt wrote:
> This revert is in fact causing problems on my machine. I have a QCA9984,
> which exports two network interfaces. While I was able to still use one
> of both NICs for 2.4GHz, I couldn't really use the other card to set up
> a
On Tue, Aug 24, 2021 at 1:00 AM Alvin Šipraga wrote:
> Numerous people - myself included - have cited sources clearly
> indicating that 0x0 = US, NOT unset. See the same post[1] for more info.
>
> I still think this patch should be reverted unless somebody can provide
> a source to the contrary, r
Hi,
OpenWrt support for Google Wifi is under review, so I'd like to push the BDFs
into the mainline board-2.bin.
Per the wiki [1]:
* description for what hardware this is
- IPQ4019-based router, with two QCA4019 radios -- one for 2.4GHz (BMI board
ID 16) and one for 5GHz (BMI board ID
cient
> datapath changes.
>
> ---
> Changes from v3:
> - Fixed commit text errors
> - Remove excess space in "hardware restart"
> - Removed blank line between the function description and the arguments
For whatever it's worth, the series looks good to me:
Rev
On Mon, Aug 23, 2021 at 1:19 PM Andrey Skvortsov
wrote:
> On 21-08-23 10:23, Brian Norris wrote:
> > Maybe it needs an Nth person to submit a revert?
>
> Later (Dec 23, 2020) said "Actually I don't see how I could apply the
> revert due to the regulatory problems
On Sun, Aug 22, 2021 at 9:49 AM Andrey Skvortsov
wrote:
> 4) As many users are affected by this problem and maintainers don't really
> want to revert the problematic patch,
I'm not totally sure that's true. So far, it looks like an oversight.
Over a year ago, Kalle said he "just need[ed] to chec
On Mon, Mar 22, 2021 at 4:58 PM Ben Greear wrote:
> On 7/22/20 6:00 AM, Felix Fietkau wrote:
> > On 2020-07-22 14:55, Johannes Berg wrote:
> >> On Wed, 2020-07-22 at 14:27 +0200, Felix Fietkau wrote:
> >>
> >>> I'm considering testing a different approach (with mt76 initially):
> >>> - Add a mac80
On Tue, Feb 9, 2021 at 6:12 PM Wen Gong wrote:
> On 2021-02-10 03:35, Brian Norris wrote:
> so this patch is to dump the top 1024 bytes only,
> its 1st goal is make log smaller.
Agreed. I wasn't objecting to this patch. I just wanted to highlight
the second part should pr
+ Steven Rostedt
Hi Wen,
(Trimming down the description a bit:)
On Mon, Feb 8, 2021 at 6:59 PM Wen Gong wrote:
>
> Kernel panic every time in kernel when running below case:
> steps:
> 1. connect to an AP with good signal strength
> 2. echo 0x7f > /sys/kernel/debug/ieee80211/phy0/ath10k/pktlog_
On Wed, Dec 23, 2020 at 3:02 AM Kalle Valo wrote:
> Brian Norris writes:
> > Kalle is still planning on applying my revert patch someday, I think:
> >
> > https://patchwork.kernel.org/project/linux-wireless/patch/20200527165718.129307-1-briannor...@chromium.org/
> &g
On Mon, Dec 21, 2020 at 7:43 PM Wen Gong wrote:
>
> On 2020-12-21 05:06, Sustek Goran wrote:
> > Hi, on my ath10k Chipset,
> > QCA9984(https://compex.com.sg/shop/wifi-module/802-11ac-wave-2/wle1216v5-20-2/)
> > afetr this patch i can not longer to initialize my card.
> >
> > my dmesg log: So i nee
>data_lock vs list->lock, the result is no protection.
Reviewed-by: Brian Norris
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
On Mon, Dec 21, 2020 at 11:53 AM Kalle Valo wrote:
> Brian Norris writes:
> > On Sun, Dec 20, 2020 at 5:53 PM Miaoqing Pan
> > wrote:
> >> if (skb_queue_len(q) == ATH10K_MAX_NUM_MGMT_PENDING) {
> >
> > I believe you should be switching this to
Hi,
On Sun, Dec 20, 2020 at 5:53 PM Miaoqing Pan wrote:
>
> Failed to transmit wmi management frames:
>
> [84977.840894] ath10k_snoc a00.wifi: wmi mgmt tx queue is full
> [84977.840913] ath10k_snoc a00.wifi: failed to transmit packet, dropping:
> -28
> [84977.840924] ath10k_snoc a00.
On Thu, Dec 17, 2020 at 2:57 PM Ben Greear wrote:
> On 12/17/20 2:24 PM, Brian Norris wrote:
> > I'd also note that we don't operate in AP mode -- only STA -- and IIRC
> > Ben, you've complained about AP mode in the past.
>
> I complain about all sorts of thing
On Tue, Dec 15, 2020 at 10:51:13PM +0530, Youghandhar Chintala wrote:
> From: Rakesh Pillai
I meant to mention in my other reply: the threading on this series is
broken (as in, it doesn't exist). It looks like you're using
git-send-email (good!), but somehow it doesn't have any In-Reply-To or
Ref
On Tue, Dec 15, 2020 at 10:23:33AM -0800, Ben Greear wrote:
> On 12/15/20 9:21 AM, Youghandhar Chintala wrote:
> > From: Rakesh Pillai
> >
> > Currently in case of target hardware restart ,we just reconfig and
> > re-enable the security keys and enable the network queues to start
> > data traffic
QCAHLSWMTPLZ-1
>
> Fixes: 4945af5b264f ("ath10k: enable SRRI/DRRI support on ddr for WCN3990")
> Signed-off-by: Rakesh Pillai
Reviewed-by: Brian Norris
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
On Thu, Dec 10, 2020 at 7:09 AM Rakesh Pillai wrote:
> --- a/drivers/net/wireless/ath/ath10k/snoc.c
> +++ b/drivers/net/wireless/ath/ath10k/snoc.c
> @@ -1045,14 +1085,18 @@ static int ath10k_snoc_hif_power_up(struct ath10k *ar,
> ret = ath10k_snoc_init_pipes(ar);
> if (ret) {
>
On Thu, Nov 26, 2020 at 9:16 AM Youghandhar Chintala
wrote:
> --- a/drivers/net/wireless/ath/ath10k/snoc.c
> +++ b/drivers/net/wireless/ath/ath10k/snoc.c
> @@ -1790,9 +1790,6 @@ static int ath10k_snoc_remove(struct platform_device
> *pdev)
>
> reinit_completion(&ar->driver_recovery);
>
>
ang
I think the API is reasonably clear and usable. I'm a little skeptical
that the complexity related to indexes is absolutely necessary [1],
but at least you make clear what should happen in the case of missing
indexes (treated as "max"). But you've addressed my concerns, I think:
On Thu, Nov 5, 2020 at 3:10 AM Carl Huang wrote:
> On 2020-11-05 16:35, Kalle Valo wrote:
> > Brian Norris writes:
> >> On Tue, Nov 3, 2020 at 11:32 PM Carl Huang
> >> wrote:
> >>> On 2020-11-04 10:00, Brian Norris wrote:
> >>> > Wh
On Thu, Nov 5, 2020 at 3:27 AM Carl Huang wrote:
> On 2020-11-05 07:11, Brian Norris wrote:
> > On Tue, Sep 22, 2020 at 01:49:35PM +0800, Carl Huang wrote:
> >> +if (ar->tx_power_2g_limit == 0 || ar->tx_power_5g_limit == 0)
> >
> > ath10k_mac_txpower_rec
Hi,
On Tue, Sep 22, 2020 at 01:49:35PM +0800, Carl Huang wrote:
> ath10k assigns ath10k_mac_set_sar_specs to ath10k_ops, and
> this function is called when user space application calls
> NL80211_CMD_SET_SAR_SPECS. ath10k also registers SAR type,
> and supported frequency ranges to wiphy so user sp
On Mon, Sep 28, 2020 at 02:36:09PM +0200, Johannes Berg wrote:
> > +#define NUM_MAX_NL80211_SAR_FREQ_RANGES 0xfe
>
> but I'm not sure what these are used for in the first place, they seem
> more like internal implementation details?
I think the MAX value does have some utility in the API -- as me
Hi Carl,
Sorry, I lied; I have a few more notes after spending another day
looking at this:
On Tue, Sep 22, 2020 at 01:49:34PM +0800, Carl Huang wrote:
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -1663,6 +1663,55 @@ struct station_info {
> +/**
> + * @struct cfg80211_sar_ch
On Wed, Nov 4, 2020 at 12:44 AM Carl Huang wrote:
> On 2020-09-28 20:36, Johannes Berg wrote:
> > On Tue, 2020-09-22 at 13:49 +0800, Carl Huang wrote:
> >> +struct cfg80211_sar_freq_ranges {
> >> +u8 index;
> >
> > Does an index here make sense?
> >
> With agreement from Google, it's OK to rem
+ ath10k
[ I realize I replied to the "wrong" RFC v1; I fell trap to Kalle's note:
"When you submit a new version mark it as "v2". Otherwise people don't
know what's the latest version." ]
On Tue, Nov 3, 2020 at 11:32 PM Carl Huang wrote:
> On 20
On Thu, Jul 30, 2020 at 6:24 AM Johannes Berg wrote:
> > Good, I was just checking that we all are on the same page.
>
> But are we? ;-)
I think you were deferring to, "how would user space use it?" And,
"would a common API really help anyone?" (And then you implied
"anyone" = "Chrome OS.")
I e
On Thu, Jul 16, 2020 at 2:35 AM Kalle Valo wrote:
> Brian Norris writes:
> > Really, I could live with per-vendor APIs. My primary goal is to get
> > these upstream in some form, so vendors can stop using things like
> > this as a reason for shipping us non-upstrea
On Wed, Jul 8, 2020 at 4:14 PM Doug Anderson wrote:
> On Wed, Jul 8, 2020 at 4:03 PM Brian Norris wrote:
> > If I'm reading correctly, you're removing the only remaining use of
> > 'per_ce_irq'. Should we kill the field entirely?
>
> Ah, you are indeed c
cases, which is the only place
you clear the map, and if the hardware/firmware has been reset, the
state map is probably not valid.
Otherwise, looks OK to me:
Reviewed-by: Brian Norris
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
On Fri, Jun 26, 2020 at 2:49 PM Doug Anderson wrote:
> I should also note that, while I'm not terribly familiar with Kalle's
> workflow, I would have expected to see him in the "To:" list. I've
> added him, but it's possible he'll need you to repost the patch with
> him in the "To:" list.
https:
[ rearranged your message to avoid top-posting
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ]
On Mon, Jun 22, 2020 at 3:57 PM Nick Marriott wrote:
> > On May 27, 2020, at 12:58 PM, Brian Norris wrote:
> > On Sat, May 23, 2020 at 7:37 PM Michael
On Tue, May 26, 2020 at 7:58 AM Luis Chamberlain wrote:
>
> This makes use of the new taint_firmware_crashed() to help
> annotate when firmware for device drivers crash. When firmware
> crashes devices can sometimes become unresponsive, and recovery
> sometimes requires a driver unload / reload an
On Tue, Jun 2, 2020 at 12:40 PM John Stultz wrote:
> On Tue, Jun 2, 2020 at 12:16 PM Brian Norris wrote:
> > On Mon, Jun 1, 2020 at 10:25 PM John Stultz wrote:
> > >
> > > Ever since 5.7-rc1, if we call
> > > ath10k_qmi_remove_msa_permission(), the db845c har
+ Sibi
On Mon, Jun 1, 2020 at 10:25 PM John Stultz wrote:
>
> Ever since 5.7-rc1, if we call
> ath10k_qmi_remove_msa_permission(), the db845c hard crashes on
> reboot, resulting in the device getting stuck in the usb crash
> debug mode and not coming back up wihthout a hard power off.
>
> This ha
On Thu, May 28, 2020 at 8:42 AM Adrian Chadd wrote:
> On Thu, 28 May 2020 at 05:02, Julian Calaby wrote:
> > On Thu, May 28, 2020 at 5:18 AM Brian Norris
> > wrote:
> > >
> > > This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
> > >
I haven't quite reached the 3 month lag on the prior replies here :)
I do want to see this question resolved somehow, or else we'll be
dragging along out-of-tree patches for...(counts on fingers)...4
different nl80211 APIs for the same feature, and a driver-detecting
user space for it. I think I w
On Sat, May 23, 2020 at 7:37 PM Michael Berg wrote:
>
> More follow up on the following patch that broke 5GHz AP mode on Compex
> cards
> https://github.com/torvalds/linux/commit/2dc016599cfa9672a147528ca26d70c3654a5423
>
> I just downloaded and checked the linux-5.7-rc6 kernel source,
> and the p
: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain")
Cc:
Cc: Wen Gong
Signed-off-by: Brian Norris
---
drivers/net/wireless/ath/regd.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/re
On Tue, May 19, 2020 at 10:37 PM Emmanuel Grumbach wrote:
> So I believe we already have this uevent, it is the devcoredump. All
> we need is to add the unique id.
I think there are a few reasons that devcoredump doesn't satisfy what
either Luis or I want.
1) it can be disabled entirely [1], for
Hi Luis,
On Tue, May 19, 2020 at 7:02 AM Luis Chamberlain wrote:
> On Mon, May 18, 2020 at 06:23:33PM -0700, Brian Norris wrote:
> > On Sat, May 16, 2020 at 6:51 AM Johannes Berg
> > wrote:
> > > In addition, look what we have in iwl_trans_pcie_removal_wk(). If we
>
On Sat, May 16, 2020 at 6:51 AM Johannes Berg wrote:
> In addition, look what we have in iwl_trans_pcie_removal_wk(). If we
> detect that the device is really wedged enough that the only way we can
> still try to recover is by completely unbinding the driver from it, then
> we give userspace a uev
On Thu, Dec 19, 2019 at 10:55 AM Jouni Malinen wrote:
>
> On Thu, Dec 19, 2019 at 10:32:06AM -0800, Brian Norris wrote:
> > On Thu, Dec 19, 2019 at 7:48 AM Jouni Malinen wrote:
> > > On Thu, Dec 19, 2019 at 09:44:52AM +, Pkshih wrote:
> > > > On Wed, 2019
On Thu, Dec 19, 2019 at 7:48 AM Jouni Malinen wrote:
> On Thu, Dec 19, 2019 at 09:44:52AM +, Pkshih wrote:
> > On Wed, 2019-12-18 at 17:48 +0200, Kalle Valo wrote:
> > > diff --git a/include/uapi/nl80211-vnd-qca.h
> > > b/include/uapi/nl80211-vnd-qca.h
> > > + * NOTE: The authoritative place
On Fri, Mar 8, 2019 at 1:42 AM Kalle Valo wrote:
> Brian Norris writes:
> > On Fri, Feb 8, 2019 at 5:42 AM Kalle Valo wrote:
> >> No replies from anyone (including Wen) for 3 months about testing this
> >> patch on anything else than QCA6174. So I'll drop thi
Hi Kalle,
Sorry, I failed to follow up on some of this.
On Fri, Sep 20, 2019 at 12:32 AM Kalle Valo wrote:
> But I mixed up the flags. I meant that can we enable
> NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR in ath10k? Does the firmware
> releases which have WMI_SERVICE_NLO support
> NL80211_FEATURE_SC
(I realize I replied to the v3, not the v4 which was merged.)
On Wed, Sep 18, 2019 at 7:03 AM Kalle Valo wrote:
> Brian Norris writes:
> > Since Wen has once again suggested I use this patch in other forums,
> > I'll ping here to note:
> >
> > On Wed, Nov
Since Wen has once again suggested I use this patch in other forums,
I'll ping here to note:
On Wed, Nov 14, 2018 at 2:59 PM Brian Norris wrote:
> You've introduced a regression in 4.20-rc1:
This regression still survives in the latest tree. Is it fair to just
submit a revert?
Brian
Hi Arnd,
On Mon, Jul 8, 2019 at 5:50 AM Arnd Bergmann wrote:
>
> As clang points out, the vht_pfr is assigned to a struct member
> without being initialized in one case:
>
> drivers/net/wireless/ath/ath10k/mac.c:7528:7: error: variable 'vht_pfr' is
> used uninitialized whenever 'if' condition
>
On Thu, May 23, 2019 at 9:42 AM Brian Norris wrote:
> IIUC, you have basically the same failure case a few lines up, where
> ath10k_sdio_mbox_alloc_pkt_bundle() may fail. Do the same there?
Oh, I see Erik Stromdahl already got that one:
ath10k: sdio: add missing error check
il. Do the same there?
This (including the error label to which it's jumping) looks fine to me though:
Reviewed-by: Brian Norris
> + ath10k_warn(ar, "alloc_rx_pkt error %d\n", ret);
> + goto err;
> + }
> }
>
> ar_sdio->n_rx_pkts = i;
On Mon, May 6, 2019 at 7:26 AM Govind Singh wrote:
> --- a/drivers/net/wireless/ath/ath10k/snoc.c
> +++ b/drivers/net/wireless/ath/ath10k/snoc.c
> @@ -1586,6 +1587,72 @@ static int ath10k_hw_power_off(struct ath10k *ar)
> return ret;
> }
>
> +static void ath10k_msa_dump_memory(struct ath
On Mon, Apr 8, 2019 at 10:09 PM Wen Gong wrote:
> > From: Michał Kazior
> > To satisfy both I would suggest you either expose ar->state via
> > debugfs and make your test procedure wait for that to get back into ON
> > state before simulating a crash again, or to extend the set of current
> > sim
On Wed, Apr 3, 2019 at 2:47 PM Rafael J. Wysocki wrote:
> I have been wondering whether or not I need to resend this patch or something
> ...
I think the linux-wireless Patchwork instance is the source of truth
-- Kalle and Johannes use it for tracking status, IIUC. So this says
your patch is st
quot;ath10k: add support for configuring management packet
rate")
and sent to stable. This has been bugging people since 4.19. Spurious
WARN_ON()s can trigger reports to various crash trackers, and on some
systems appear as user-visible warnings ("System problem detected").
&
+ Rafael
+ authors of these bad commits:
cd93b83ad927 ath10k: support for multicast rate control
f279294e9ee2 ath10k: add support for configuring management packet rate
Hi,
On Mon, Mar 25, 2019 at 8:46 PM Claire Chang wrote:
> On Tue, Mar 26, 2019 at 12:49 AM Brian Norris
> wrote:
>
ons on QCA6174A.
Reported here:
http://lkml.kernel.org/linux-wireless/20190325202706.ga68...@google.com
Fixes: 25733c4e67df ("ath10k: pci: use mutex for diagnostic window CE polling")
Signed-off-by: Brian Norris
---
drivers/net/wireless/ath/ath10k/ce.c | 2 +-
drivers/net/wirele
On Mon, Mar 25, 2019 at 3:14 PM Brian Norris wrote:
> On Mon, Mar 25, 2019 at 2:20 PM Michał Kazior wrote:
> > For one, you'll need to defer ath10k_pci_fw_crashed_dump to a worker.
> > Maybe into ar->restart_work which the dump function calls now.
>
> Hmm, that'
Hi Michal,
Thanks for the quick and useful response.
On Mon, Mar 25, 2019 at 2:20 PM Michał Kazior wrote:
> On Mon, 25 Mar 2019 at 21:27, Brian Norris wrote:
> > It would appear that this triggers new warnings
> >
> > BUG: sleeping function called from invalid context
Hi Kalle,
On Wed, Feb 06, 2019 at 05:41:43PM -0800, Brian Norris wrote:
> The DIAG copy engine is only used via polling, but it holds a spinlock
> with softirqs disabled. Each iteration of our read/write loops can
> theoretically take 20ms (two 10ms timeout loops), and this loop can be
On Tue, Mar 19, 2019 at 9:48 PM Govind Singh wrote:
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -81,6 +81,7 @@ Optional properties:
> Definition: Name of external front end module used. S
Hi Kalle,
On Fri, Mar 8, 2019 at 2:58 AM Kalle Valo wrote:
> Gabriel C writes:
> > Am Mo., 4. März 2019 um 12:59 Uhr schrieb Kalle Valo :
> >> Gabriel C writes:
> >> > I reported that twice and no one seems to care about.
> >> >
> >> > http://lists.infradead.org/pipermail/ath10k/2018-November/0
On Fri, Feb 8, 2019 at 5:42 AM Kalle Valo wrote:
> No replies from anyone (including Wen) for 3 months about testing this
> patch on anything else than QCA6174. So I'll drop this now, please
> resubmit once test coverage is better.
I know this isn't exactly what you're asking for, but FWIW we've
on of diag
read/write operations.
Tested on QCA6174A, firmware version WLAN.RM.4.4.1-00132-QCARMSWPZ-1.
Fixes: 39501ea64116 ("ath10k: download firmware via diag Copy Engine for
QCA6174 and QCA9377.")
Signed-off-by: Brian Norris
---
I'm not quite sure if this is -stable material. It
ged, 31 insertions(+), 14 deletions(-)
What ever happened here? I'm told this is useful, but I see no comments
and it's marked Deferred in patchwork:
https://patchwork.kernel.org/patch/10579559/
FWIW, it looks OK to me:
Reviewed-by: Brian Norris
_
On Mon, Feb 4, 2019 at 8:43 AM Kalle Valo wrote:
> Brian Norris wrote:
>
> > This reverts commit cfb353c0dc058bc1619cc226d3cbbda1f360bdd3.
> >
> > WCN3990 firmware does not yet implement this feature, and so it crashes
> > like this:
> >
> > fatal err
ation data and issues a response
> to the ath10k linux driver. Which was designed to take the main MAC in
> ath10k_wmi_event_ready().
>
> Part of the "setting an alternate MAC" issue was already tackled by a
> patch from Brian Norris:
> commit 9d5804662ce1
> ("ath1
0.091401] qcom-q6v5-mss 408.remoteproc: fatal error received:
err_qdi.c:456:EF:wlan_process:1:cmnos_thread.c:3921:Asserted in
wlan_dev.c:WLAN_GET_MAC_ID_FROM_WMI_PDEV_ID:536
Note that I'm running WCN3990, and I haven't configure any
Hello!
On Mon, Jan 14, 2019 at 7:36 AM Christian Lamparter wrote:
> Part of the "setting an alternate MAC" issue was already tackled by a
> patch from Brian Norris:
> commit 9d5804662ce1
> ("ath10k: retrieve MAC address from system firmware if provided")
> b
sdio_register_driver() doesn't do this for us, unlike (for example)
platform_driver_register(). This is important for helping track
module-to-device relationships.
Signed-off-by: Brian Norris
---
drivers/net/wireless/ath/ath10k/sdio.c | 5 -
1 file changed, 4 insertions(+), 1 del
WCN3990 is SNOC, not PCI. This prevents probing WCN3990.
Fixes: 367c899f622c ("ath10k: add bus type check in ath10k_init_hw_params")
Signed-off-by: Brian Norris
---
This was a regression in 4.20.
drivers/net/wireless/ath/ath10k/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
anup':
> > drivers/net/wireless/ath/ath10k/snoc.c:681:22: warning:
> > variable 'ar_snoc' set but not used [-Wunused-but-set-variable]
> >
> > Signed-off-by: Yue Haibing
...patch looks fine to me:
Reviewed-by: Brian Norris
__
On Thu, Dec 20, 2018 at 06:40:43PM +0200, Kalle Valo wrote:
> Brian Norris writes:
> > Alternatively, you could add these ignored commands to wmi-tlv.h, and
> > just ignore them specifically. That's better documentation, in case
> > new WMI events come along that *are* i
On Wed, Nov 28, 2018 at 8:25 PM Govind Singh wrote:
>
> During driver load below warn logs are printed in the console.
> Since driver may not implement all wmi events sent by fw and
> all of them are non-fatal, move this log to debug level to
> remove un-necessary warn message on console.
>
> [ 3
On Fri, Nov 16, 2018 at 4:47 PM Brian Norris wrote:
> This ancient Wifi still tells me I can send patches here, though I
s/Wifi/Wiki/
Sorry,
Brian
> haven't seen that much :)
>
> https://github.com/mcgrof/qca-swiss-army-knife/wiki
_
Signed-off-by: Brian Norris
---
This ancient Wifi still tells me I can send patches here, though I
haven't seen that much :)
https://github.com/mcgrof/qca-swiss-army-knife/wiki
tools/scripts/ath10k/ath10k-fwencoder | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/
On Fri, Nov 16, 2018 at 2:15 AM Kalle Valo wrote:
> Thanks Brian for investigating this and providing the revert!
I think Govind did most of the investigation, but I did at least do
the hard work of submitting the revert ;)
___
ath10k mailing list
ath1
Hi,
On Thu, Nov 15, 2018 at 06:38:25AM +, Wen Gong wrote:
> > -Original Message-
> > From: ath10k On Behalf Of Brian Norris
> >
> > Is there some reason L1 was disabled in the first place? Was it known to be
> > unreliable?
>
> Hi Brian,
&g
Hi Govind,
On Mon, Nov 05, 2018 at 06:38:37PM +0530, Govind Singh wrote:
> Add device node for the ath10k SNOC platform driver probe
> and add resources required for WCN3990 on SDM845 soc.
>
> Signed-off-by: Govind Singh
> Reviewed-by: Brian Norris
> Tested-by: Brian Nor
Hi Wen,
On Wed, Nov 14, 2018 at 10:50:48AM +0800, Wen Gong wrote:
> QCA6174A/QCA9377 PCIe chips support PCIe L1 and L1SS, and indicate the
> L1/L1SS capabilities in PCI configuration space. Currently ath10k driver
> write target PCIe config flags to disallow HW enter into L1, this leads
> some HW
Hi Wen,
You've introduced a regression in 4.20-rc1:
On Thu, Aug 16, 2018 at 02:48:33PM +0800, Wen Gong wrote:
> For WoWLAN support, it expect to support wake up based on discovery of
> one or more known SSIDs. This is the WIPHY_WOWLAN_NET_DETECT feature,
> which shows up as an NL80211 feature fla
On Wed, Nov 7, 2018 at 8:32 PM Govind Singh wrote:
> On 2018-11-08 03:00, Rajkumar Manoharan wrote:
> > On 2018-11-07 10:56, Brian Norris wrote:
> >> This reverts commit cfb353c0dc058bc1619cc226d3cbbda1f360bdd3.
> >>
> >> WCN3990 firmware does not y
("ath10k: add peer flush in ath10k_flush for STATION")
Signed-off-by: Brian Norris
---
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index a1
On Mon, Oct 8, 2018 at 2:03 AM Wen Gong wrote:
>
> In the noisy environment, if there are packets in the queue and can't
> send out, the suspend timing will be more than 5 seconds due to the wait,
> flush the queue to optimize the suspend timing, and let the upper layer to
> retry the packets afte
other
feature-discovery mechanism in the future. But it should not break
working boards.
Fixes: cfb353c0dc05 ("ath10k: add quiet mode support for QCA6174/QCA9377")
Cc: Yu Wang
Cc: Rakesh Pillai
Cc: Govind Singh
Cc:
Signed-off-by: Brian Norris
---
drivers/net/wireless/ath/ath10k/wmi-
On Tue, Nov 06, 2018 at 04:07:01PM -0800, Brian Norris wrote:
> On Mon, Nov 05, 2018 at 08:33:02AM -0800, Stephen Boyd wrote:
> > And yes, from what you've told me here it would make sense to make the
> > WCN chip a subnode of this SoC node instead of a phandle connecting the
&
Hi Stephen,
On Mon, Nov 05, 2018 at 08:33:02AM -0800, Stephen Boyd wrote:
> Quoting Brian Norris (2018-11-02 11:43:17)
> > Hi Stephen and Govind,
> >
> > I was chatting with Govind, and he seemed to be a bit stalled on this.
> > I'd encourage him to reply with wh
On Mon, Nov 5, 2018 at 5:04 AM Kalle Valo wrote:
> This patchset (I think it was with the first patch, but not sure) had some
> conflicts but 3-way merge was able to automatically solve them. Please check
> the end result anyway:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/co
Hi Stephen and Govind,
I was chatting with Govind, and he seemed to be a bit stalled on this.
I'd encourage him to reply with whatever knowledge he has, because it's
a bit hard to give definitive answers when I don't know all the inner
workings here. (In fact, you, Stephen, probably know more than
They're provided as callbacks in ath10k_hif_ops and should be accessed
that way, if needed outside of snoc.c, and anyway, they're currently
unused outside snoc.c.
Signed-off-by: Brian Norris
---
drivers/net/wireless/ath/ath10k/snoc.c | 4 ++--
drivers/net/wireless/ath/ath10k/snoc.h
Rather than seeing this warning every boot
ath10k_snoc 1880.wifi: invalid hw_params.n_cipher_suites 0
let's provide the appropriate value.
Cc: Rakesh Pillai
Cc: Govind Singh
Signed-off-by: Brian Norris
---
drivers/net/wireless/ath/ath10k/core.c | 1 +
1 file changed, 1 insertion(+)
1 - 100 of 159 matches
Mail list logo
