On Sun, Oct 29, 2023 at 12:08:16PM +0100, Karel Balej wrote:
> Document the corresponding compatible string for the use of this driver
> with the Marvell SD8777 wireless chipset.
>
> Signed-off-by: Karel Balej
FWIW, the binding looks fine from mwifiex point of view, so:
Acked-by:
On Sun, Oct 29, 2023 at 12:08:15PM +0100, Karel Balej wrote:
> The driver requires proprietary firmware which is not yet part of
> linux-firmware, but it is packaged in postmarketOS.
You gotta get that done:
_code,
> > dialog_token, status_code,
> > skb)) {
> > - dev_kfree_skb_any(skb);
Good catch, and this looks correct for most cases, but I'll note that
you missed one issue: mwifiex_cons
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
providing tools that convey
kernel logs on behalf of a user -- e.g., when reporting bugs. So for
example, it's easy to automatically filter logs for MAC addresses, but
it's much harder to filter SSIDs out of unstructured text.
Signed-off-by: Brian Norris
---
drivers/net/wireless/marvell/mwifiex
d easily have obvious bugs like
this.
And since I got this far, and I'm still in MAINTAINERS, I guess:
Acked-by: Brian Norris
bss to a bss with the wrong channel.
>
> Let mwifiex_cfg80211_assoc return the selected BSS and then the caller
> can report it cfg80211_connect_bss.
>
> Signed-off-by: Yen-lin Lai
This seems sane to me:
Reviewed-by: Brian Norris
One more thing, for context:
On Tue, Jan 19, 2021 at 11:11 AM Brian Norris wrote:
> On Fri, Jan 15, 2021 at 1:39 AM Jiapeng Zhong
> wrote:
> >
> > Fix the follow coccicheck warnings:
> >
> > ./drivers/net/wireless/marvell/mwifiex/fw.h: WARNING use flexible-
Hi,
On Fri, Jan 15, 2021 at 1:39 AM Jiapeng Zhong
wrote:
>
> Fix the follow coccicheck warnings:
>
> ./drivers/net/wireless/marvell/mwifiex/fw.h: WARNING use flexible-array
> member instead(https://www.kernel.org/doc/html/latest/process/
> deprecated.html#zero-length-and-one-element-arrays)
>
>
(Note: this is version 1; there's a later version posted, which does
not have a v2 tag...)
https://lore.kernel.org/linux-wireless/20201208150951.35866-1-ruc_zhangxiao...@163.com/
On Sat, Jan 9, 2021 at 7:11 AM Peter Seiderer wrote:
> On Tue, 8 Dec 2020 20:45:23 +0800, Xiaohui Zhang
> wrote:
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 things, but I'm usua
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
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
QCAHLSWMTPLZ-1
>
> Fixes: 4945af5b264f ("ath10k: enable SRRI/DRRI support on ddr for WCN3990")
> Signed-off-by: Rakesh Pillai
Reviewed-by: Brian Norris
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) {
>
itting-patches.html#describe-changes
With luck, maintainers can fix that up when applying, so you don't need
to resend.
Otherwise, both patches look good to me, thanks!
Reviewed-by: Brian Norris
(FWIW, this author's mail has been routed to my spam mailbox. That's
partly my fault and/or my "choice" of mail provider, but that's why I
only see these once Kalle replies to them.)
On Tue, Dec 8, 2020 at 8:03 AM Xiaohui Zhang wrote:
>
> From: Zhang Xiaohui
>
> mwifiex_uap_bss_param_prepare()
On Tue, Dec 8, 2020 at 7:14 AM Xiaohui Zhang wrote:
>
> From: Zhang Xiaohui
>
> mwifiex_config_scan() calls memcpy() without checking
> the destination size may trigger a buffer overflower,
> which a local user could use to cause denial of service
> or the execution of arbitrary code.
> Fix it
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(>driver_recovery);
>
> -
On Fri, Oct 30, 2020 at 1:04 AM Tsuchiya Yuto wrote:
> On Thu, 2020-10-29 at 11:25 -0700, Brian Norris wrote:
> > For the record, Chrome OS supports plenty of mwifiex systems with 8897
> > (SDIO only) and 8997 (PCIe), with PS enabled, and you're hurting
> > those
(Sorry if anything's a bit slow here. I don't really have time to
write out full proposals myself.)
On Fri, Oct 30, 2020 at 3:30 AM Tsuchiya Yuto wrote:
> Let me know if splitting this patch like this works. 1) The first patch
> is to add this module parameter but don't change the default
et: sch_generic: aviod concurrent reset and enqueue op
> for lockless qdisc")
> Signed-off-by: Yunsheng Lin
For whatever it's worth, we've seen similar problems (particularly,
ENOBUFS on AF_PACKET sockets) and have tested this fix on 4.19.y (we're
also queueing it up on our 5.4.y branch, but haven't tested it as much):
Tested-by: Brian Norris
Thanks!
On Mon, Nov 2, 2020 at 3:25 AM Lee Jones wrote:
> --- a/drivers/net/wireless/realtek/rtw88/pci.h
> +++ b/drivers/net/wireless/realtek/rtw88/pci.h
> @@ -212,6 +212,10 @@ struct rtw_pci {
> void __iomem *mmap;
> };
>
> +int rtw_pci_probe(struct pci_dev *pdev, const struct pci_device_id
On Thu, Oct 29, 2020 at 11:37 AM Andy Shevchenko
wrote:
> And this feeling (that it's a FW issue) what I have. But the problem
> here, that Marvell didn't fix and probably won't fix their FW...
Sure, I wouldn't hold your breath. So some of these tactics (disabling
PS, etc.) may be valid, but you
On Wed, Oct 28, 2020 at 7:04 PM Tsuchiya Yuto wrote:
>
> On Microsoft Surface devices (PCIe-88W8897), the ps_mode causes
> connection unstable, especially with 5GHz APs. Then, it eventually causes
> fw crash.
>
> This commit disables ps_mode by default instead of enabling it.
>
> Required code is
On Wed, Oct 28, 2020 at 3:58 PM Tsuchiya Yuto wrote:
>
> The devicve_dump may take a little bit long time and users may want to
> disable the dump for daily usage.
>
> This commit adds a new module parameter enable_device_dump and disables
> the device_dump by default.
As with one of your other
On Wed, Oct 28, 2020 at 2:56 PM Tsuchiya Yuto wrote:
>
> To make the ps_mode (power_save) control easier, this commit adds a new
> module parameter allow_ps_mode and set it false (disallowed) by default.
This sounds like a bad idea, as it breaks all the existing users who
expect this feature to
, it looks like a second double free would
> happen with mwifiex_cleanup_sdio().
>
> So set both pointers to NULL when they are freed.
>
> Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex
> driver")
> Signed-off-by: Tom Rix
For whatever it's worth:
Reviewed-by: Brian Norris
stent between developers and buildbots, use an explicit
> > --abbrev=15 option (and for consistency, also use rev-parse --short=15
> > for the unlikely case of no signed tags being usable).
For the patch:
Reviewed-by: Brian Norris
> I agree that any randomness should be avoided.
&
On Mon, Aug 24, 2020 at 2:32 AM Kai-Heng Feng
wrote:
>
> Sometimes system freeze on cold/warm boot when rtw88 is probing.
>
> According to [1], platform firmware may not properly power manage the
> device during shutdown. I did some expirements and putting the device to
> D3 can workaround the
Thanks for this! I just happened to notice this breakage here, as we
just merged the relevant -stable updates. I think it would be wise to
get the Fixes tag Dan noted, when Kalle lands this.
Reviewed-by: Brian Norris
Tested-by: Brian Norris
Also, while technically the regressing commit (e186967
om
>
> Reported-by: syzbot
> Cc: Ganapathi Bhat
> Cc: Brian Norris
> Signed-off-by: Tetsuo Handa
This seems good to me:
Reviewed-by: Brian Norris
> ---
> drivers/net/wireless/marvell/mwifiex/usb.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff -
On Thu, Aug 6, 2020 at 8:33 AM Guenter Roeck wrote:
>
> With enhanced error reporting from cros_ec_cmd_xfer_status() in place,
> we can fully use it and no longer rely on EC error codes.
>
> Signed-off-by: Guenter Roeck
Reviewed-by: Brian Norris
On Tue, Jul 28, 2020 at 6:42 PM Xie He wrote:
> On Tue, Jul 28, 2020 at 12:52 PM -0700
> Brian Norris wrote:
> > What is the intention with this X25 protocol? I guess the headers added
> > in lapbeth_data_transmit() are supposed to be "invisible", as with
On Wed, Jul 29, 2020 at 4:22 PM Guenter Roeck wrote:
> On 7/29/20 3:21 PM, Brian Norris wrote:
> > On Sun, Jul 26, 2020 at 03:01:01PM -0700, Guenter Roeck wrote:
> >> --- a/drivers/platform/chrome/cros_ec_proto.c
> >> +++ b/drivers/platform/chrome/cros_ec_proto.c
>
D_VERSION
> Implement function to convert error codes
A small potential (i.e., being paranoid about future changes) note on
patch 6, but otherwise looks fine to me:
Reviewed-by: Brian Norris
ouble check 'ret != 0'? Or maybe
ret = cros_ec_error_map[result];
if (!ret) {
ret = -EPROTO;
dev_err(..., "Unexpected EC result code %d\n",
result);
}
? Could even be WARN_ON(), since
(Reviewing as requested; I'm not familiar with this driver either, or
really any WAN driver. It also seems that hard_header_len vs.
needed_headroom aren't very well documented, and even I can't guarantee
I understand them completely. So take my thoughts with a grain of salt.)
Hi,
On Sun, Jul 26,
x_aggr.timer_cnxt.is_hold_timer_set = false;
spin_unlock_bh(>tx_aggr_lock);
/* Timer could still be running, but it can't be restarted at this
point, so this is safe. */
del_timer_sync(>tx_aggr.timer_cnxt.hold_timer);
} else {
spin_unlock_bh(>tx_aggr_lock);
}
Ot
On Thu, Jul 23, 2020 at 1:04 AM Enric Balletbo i Serra
wrote:
> Another thing that we can do (although this is specific for you and doesn't
> solve the problem with people like you that are interested on this), is add
> you
> as a reviewer in the MAINTAINERS file. The CrOS EC has a lot of
patch "platform/chrome: cros_ec_proto: ignore battery/AC
wakeups on old ECs" helps to mitigate this.
Signed-off-by: Brian Norris
---
v2:
* EOPNOTSUPP, not ENOTSUPP
---
drivers/platform/chrome/cros_ec_proto.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/platf
r ECs do not support that
command either, so this solution is not 100% complete.
Signed-off-by: Brian Norris
---
v2:
* more notes in commit message
---
drivers/platform/chrome/cros_ec_proto.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/dri
On Wed, Jul 22, 2020 at 5:43 PM Brian Norris wrote:
> unless I got
> refactor cros_ec_get_host_event_wake_mask() to use
> cros_ec_cmd_xfer_status() instead of send_command(). I'm actually not
> sure why we don't do that, now that I think about it...
Ah, that would appear to
On Wed, Jul 22, 2020 at 2:13 PM Guenter Roeck wrote:
> On Wed, Jul 22, 2020 at 1:50 PM Brian Norris wrote:
> > Other than perhaps taking a lesson not to propagate -ENOTSUPP, I don't
> > think this series should block on that, as this is a bugfix IMO.
>
> My patch wi
pwms() might need fixing too? Boy, I
wrote that, but it sure ain't easy to read...(*checks watch*)...4 years
later.
Apart from the notes already made, I think the series looks good:
Reviewed-by: Brian Norris
Feel free to CC me on v3, if you want another look
Brian
+ drinkcat, aseda
On Tue, Jul 21, 2020 at 07:23:20AM -0700, Guenter Roeck wrote:
> On Tue, Jul 21, 2020 at 01:29:01PM +0200, Enric Balletbo i Serra wrote:
> > On 20/7/20 22:22, Guenter Roeck wrote:
> > > + [EC_RES_INVALID_HEADER_VERSION] = -EBADMSG,
>
> Any idea for EC_RES_INVALID_HEADER_VERSION
On Wed, Jul 22, 2020 at 3:19 AM Enric Balletbo i Serra
wrote:
>
> Hi Brian,
>
> Thank you for your patch, I'll take a look soon but I'd like to ask if you can
> join the discussion with this patchset [1], specially this one [2]. We're
> trying
> to match EC errors with standard linux kernel
patch "platform/chrome: cros_ec_proto: ignore battery/AC
wakeups on old ECs" helps to mitigate this.
Signed-off-by: Brian Norris
---
drivers/platform/chrome/cros_ec_proto.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/platform/chrome/cros_ec_proto.c
mplemented.
Signed-off-by: Brian Norris
---
drivers/platform/chrome/cros_ec_proto.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_proto.c
b/drivers/platform/chrome/cros_ec_proto.c
index 3e745e0fe092..e93024b55
around for some testing on other systems.
Signed-off-by: Brian Norris
---
drivers/firmware/qcom_scm.c | 20
drivers/firmware/qcom_scm.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 0e7233a20f34
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 correct! I hadn't no
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
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.
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
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
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.
> >
: 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],
On Wed, May 13, 2020 at 12:02 PM Brian Norris wrote:
>
> On Wed, May 13, 2020 at 12:05 AM Kalle Valo wrote:
> > Actually it's already reverted in -next, nobody just realised that it's
> > a regression from commit 728c1e2a05e4:
> >
> > ced21a4c726b
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
On Tue, May 12, 2020 at 8:25 PM Navid Emamdoost
wrote:
> I found this via static analysis and as a result, did had the inputs
> to test it with (like the way fuzzing works).
Fuzzing is dynamic analysis, so I'm not sure how that fits.
> It may be beneficial if you could point me to any testing
>
On Wed, May 13, 2020 at 12:05 AM Kalle Valo wrote:
> Actually it's already reverted in -next, nobody just realised that it's
> a regression from commit 728c1e2a05e4:
>
> ced21a4c726b ath9k: Fix use-after-free Read in htc_connect_service
Nice.
> v5.8-rc1 should be the first release having the
On Fri, Sep 6, 2019 at 11:59 AM Navid Emamdoost
wrote:
>
> In ath9k_wmi_cmd, the allocated network buffer needs to be released
> if timeout happens. Otherwise memory will be leaked.
>
> Signed-off-by: Navid Emamdoost
I wonder, did you actually test your patches? I ask, because it seems
that all
On Tue, May 5, 2020 at 6:36 AM Geert Uytterhoeven
wrote:
>
> The standard DT property name is "interrupt-names".
>
> Fixes: fd913ef7ce619467 ("Bluetooth: btusb: Add out-of-band wakeup support")
> Signed-off-by: Geert Uytterhoeven
> Acked-by: Rob Herrin
(Markus is clearly not taking the hint, but FYI for everyone else:)
On Mon, May 4, 2020 at 8:00 AM Markus Elfring wrote:
> > BTW, In the past week, you asked me to change the commit comments in my
> > 6 patches like this one. Let me return to the essence of patch, point
> > out the code problems
On Mon, Oct 21, 2019 at 10:48 AM Alexandre Belloni
wrote:
> On 21/10/2019 10:20:08-0700, Brian Norris wrote:
> > Hi Alexandre!
> >
> > On Mon, Oct 21, 2019 at 9:11 AM Alexandre Belloni
> > wrote:
> > > On 21/05/2018 09:42:22-0700, Brian Norris wrote:
>
Hi Alexandre!
On Mon, Oct 21, 2019 at 9:11 AM Alexandre Belloni
wrote:
> On 21/05/2018 09:42:22-0700, Brian Norris wrote:
> > __rtc_read_time() can fail (e.g., if the RTC uses an unreliable medium).
> > When it does, we don't report the error, but instead calculate a
> >
as such.
>
> For this same reason, let’s trim the maintainers list with the
> actually active ones over the past two years.
>
> [1] http://laforge.gnumonks.org/blog/20180307-mchardy-gpl/
>
> Cc: David Woodhouse
> Cc: Brian Norris
> Cc: Artem Bityutskiy
> Cc: Adria
On Sat, Oct 5, 2019 at 3:16 AM Ikjoon Jang wrote:
>
> Whiskers needs to get notifications from EC for getting current base
> attached state. EC sends extra bits in event_type field that receiver
> should mask out.
Notably, this patch was never actually landed upstream:
On Mon, Sep 30, 2019 at 2:45 PM Brian Norris wrote:
> Fixes: 4b708b7b1a2c ("firmware: google: check if size is valid when decoding
> VPD data")
> Cc:
Perhaps I should have modified the subject to note the urgency (e.g.,
[PATCH 5.4]). The above regression was recently s
d when decoding
VPD data")
Cc:
Cc: Hung-Te Lin
Cc: Guenter Roeck
Cc: Stephen Boyd
Signed-off-by: Brian Norris
---
drivers/firmware/google/vpd_decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/google/vpd_decode.c
b/drivers/firmware/googl
is. A driver supports FT if it either is mac80211 or supports this
> command.
>
> Signed-off-by: Matthew Wang
FWIW:
Reviewed-by: Brian Norris
> Change-Id: I93e3d09a6d949466d1aea48bff2c3ad862edccc6
Oops :)
Hi all,
I realize this already is merged, and it had some previous review
comments that led to the decisions in this patch, but I'd still like
to ask here, where I think I'm reaching the relevant parties:
On Wed, Jul 10, 2019 at 1:43 AM Jian-Hong Pan wrote:
...
> This patch allocates a new,
+ yhchuang
On Tue, Aug 6, 2019 at 7:32 AM 고준 wrote:
>
> Hello,
>
> I recently reported a bug to Ubuntu regarding a regression in wireless
> driver support for the Realtek r8822be wireless chipset. The issue
> link on launchpad is:
>
> https://bugs.launchpad.net/bugs/1838133
>
> After Canonical
On Mon, Jul 29, 2019 at 1:50 PM Brian Norris wrote:
> Side note: it might have helped alleviate some of this pain if there
> were email notifications to the mailing list when a patch gets applied.
> I didn't realize (and I'm not sure if Enrico did) that v2 was already
> merged by the
quot;
Cc: Amitkumar Karwar
Signed-off-by: Brian Norris
Reviewed-by: Dmitry Torokhov
Acked-by: Amitkumar Karwar
Tested-by: Matthias Kaehlcke
---
drivers/net/wireless/marvell/mwifiex/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/i
On Fri, Aug 2, 2019 at 6:55 PM Kalle Valo wrote:
>
> Brian Norris writes:
>
> > + Doug, Matthias, who are seeing problems (or, failure to try to
> > recover, as predicted below)
> > + Amit's new email
> > + new maintainers
> >
> > Perhaps it's
instead, this is unnecessarily creating scenarios where we can't recover
> Wifi.
>
> Cc: Amitkumar Karwar
> Signed-off-by: Brian Norris
> ---
> Amit, please take a look. AIUI, your "fix" is wrong, and quite racy. If you
> still think it's needed, can you please prop
On Mon, Jul 29, 2019 at 1:54 PM Nathan Chancellor
wrote:
> On Mon, Jul 29, 2019 at 01:49:54PM -0700, Brian Norris wrote:
> > Side note: it might have helped alleviate some of this pain if there
> > were email notifications to the mailing list when a patch gets applied.
>
nd remains unfixed.
I differ from the v3 patch by:
* allowing for ret==0, even though acpi_dev_gpio_irq_get() specifically
documents (and enforces) that 0 is not a valid return value (noted on
the v3 review)
* adding a small comment
Reported-by: Brian Norris
Reported-by: Salvatore Bellizzi
On Mon, Jul 29, 2019 at 9:01 AM Takashi Iwai wrote:
> This isn't seen in linux-next yet.
Apparently not.
> Still pending review?
I guess? Probably mostly pending maintainer attention.
Also, Johannes already had noticed (and privately messaged me): this
patch took a while to show up on the
corrupting the
IEs in hostapd_eid_wmm().
Signed-off-by: Brian Norris
---
net/mac80211/mlme.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index a99ad0325309..4c888dc9bd81 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
ds, commit 63d7ef36103d breaks compatibility with WPA (not
WPA2) 802.11n networks, since we hit the "info: Disable 11n if AES is
not supported by AP" case in mwifiex_is_network_compatible().
Fixes: 63d7ef36103d ("mwifiex: Don't abort on small, spec-compliant vendor IEs")
Cc
On Wed, Jul 24, 2019 at 12:46:34PM -0700, Brian Norris wrote:
> Fixes: 63d7ef36103d ("mwifiex: Don't abort on small, spec-compliant vendor
> IEs")
> Cc:
> Signed-off-by: Brian Norris
To add to this: unfortunately, the above went out to -stable earlier
this week. So
> + sdio_trigger_replug(func);
> + sdio_release_host(func);
And...we're approximately back to where we were 4 years ago :)
commit b4336a282db86b298b70563f8ed51782b36b772c
Author: Andreas Fenkart
Date: Thu Jul 16 18:50:01 2015 +0200
mwifiex: sdio: reset adapter using mmc_hw_
On Thu, Jul 18, 2019 at 12:45 AM Stanislaw Gruszka wrote:
> Fix looks fine for me. However I think rtw88 should implement
> drv_conf_tx() because parameters can be different on different
> network setups and maybe more important WMM/AC parameters become
> quite recently part of ETSI regulatory.
ept it complains here about the invalid CW parameters.
Let's just skip the WARN if we weren't going to do anything useful with
the parameters.
Signed-off-by: Brian Norris
---
Noticed because rtw88 does not currently implement .conf_tx()
I think there are several ways to slice this one. I picked one
On Thu, Jul 11, 2019 at 6:50 PM Masahiro Yamada
wrote:
> GCC 8 added this flag.
> So, it will be eventually all solved in the GCC world.
Ack.
> Clang has not supported it yet...
That's what it appeared like. I've bugged our Clang-loving toolchain
folks to see if we can get parity.
> Trimming
On Thu, Jul 11, 2019 at 6:14 PM Masahiro Yamada
wrote:
> BTW, did you see this?
>
> commit a73619a845d5625079cc1b3b820f44c899618388
> Author: Masahiro Yamada
> Date: Fri Mar 30 13:15:26 2018 +0900
>
> kbuild: use -fmacro-prefix-map to make __FILE__ a relative path
Oh, wow, no I did not.
pens that lib/dynamic_debug.c already solves this sort of
problem, so I steal its solution for use in panic/warn/bug code as well.
Signed-off-by: Brian Norris
---
I'd be happy to entertain better solutions to this problem, but so far,
I haven't been creative enough to come up with one.
I'm also unsur
On Wed, Jul 10, 2019 at 7:51 AM Sasha Levin wrote:
> I see that 63d7ef36103d didn't make it into 5.2, so I'll just drop this
> for now.
Yeah, I think it's stuck at net/master. Presumably it'll get into
5.3-rc somewhere.
Brian
On Wed, Jun 26, 2019 at 5:49 PM Sasha Levin wrote:
>
> From: Takashi Iwai
>
> [ Upstream commit 685c9b7750bfacd6fc1db50d86579980593b7869 ]
>
> Currently mwifiex_update_bss_desc_with_ie() implicitly assumes that
> the source descriptor entries contain the enough size for each type
> and performs
997 / PCIe, although I've given 8897 / SDIO
a quick spin as well.
Signed-off-by: Brian Norris
---
v2:
* add new Step 2, because I missed a few functions that were passing
along the IRQ flags as arguments (fixes "used but not set" warnings,
because these flags were no longer really in u
e effect
for this particular sort of bug.
Changelog:
v2:
* fix warnings about using uninitialized "flags" variables
Brian Norris (2):
mwifiex: dispatch/rotate from reorder table atomically
mwifiex: don't disable hardirqs; just softirqs
drivers/net/wireless/marvell/mwifiex/11n.c|
ex: restructure rx_reorder_tbl_lock usage"). I've
primarily tested on Marvell 8997 / PCIe, although I've given 8897 / SDIO
a quick spin as well.
Signed-off-by: Brian Norris
Acked-by: Ganapathi Bhat
---
v2: no change
---
.../wireless/marvell/mwifiex/11n_rxreorder.c | 43 +++
1 file ch
On Mon, Jun 24, 2019 at 9:45 PM Kalle Valo wrote:
> New warning:
>
> drivers/net/wireless/marvell/mwifiex/wmm.c: In function
> 'mwifiex_wmm_process_tx':
> drivers/net/wireless/marvell/mwifiex/wmm.c:1438:4: warning: 'flags' may be
> used uninitialized in this function [-Wmaybe-uninitialized]
>
subtype and version fields into
the WMM structs, to avoid this confusion in the future about generic
"vendor header" attributes.
Fixes: 685c9b7750bf ("mwifiex: Abort at too short BSS descriptor element")
Cc: Takashi Iwai
Signed-off-by: Brian Norris
---
It appears that
This is clearer than copy/pasting the magic number '+ 2' around, and it
even saves the need for one existing comment.
Cc: Takashi Iwai
Signed-off-by: Brian Norris
---
drivers/net/wireless/marvell/mwifiex/scan.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git
1 - 100 of 4813 matches
Mail list logo
