Re: [PATCH] wireless/marvell/mwifiex: Fix a double free in mwifiex_send_tdls_action_frame

2021-04-13 Thread Brian Norris
_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

Re: [RFC 2/7] ath10k: Add support to process rx packet in thread

2021-03-22 Thread Brian Norris
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

[PATCH] mwifiex: don't print SSID to logs

2021-02-24 Thread Brian Norris
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

Re: [PATCH v2] nand: brcmnand: fix OOB R/W with Hamming ECC

2021-02-24 Thread Brian Norris
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

Re: [PATCH] mwifiex: Report connected BSS with cfg80211_connect_bss()

2021-02-01 Thread 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

Re: [PATCH] marvell/mwifiex: replace one-element array with flexible-array member.

2021-01-19 Thread 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-

Re: [PATCH] marvell/mwifiex: replace one-element array with flexible-array member.

2021-01-19 Thread Brian Norris
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) > >

Re: [PATCH 1/1] mwifiex: Fix possible buffer overflows in mwifiex_config_scan

2021-01-11 Thread Brian Norris
(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:

Re: [PATCH 0/3] mac80211: Trigger disconnect for STA during recovery

2020-12-17 Thread Brian Norris
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

Re: [PATCH 0/3] mac80211: Trigger disconnect for STA during recovery

2020-12-17 Thread Brian Norris
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

Re: [PATCH 0/3] mac80211: Trigger disconnect for STA during recovery

2020-12-17 Thread Brian Norris
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

Re: [PATCH] ath10k: Fix error handling in case of CE pipe init failure

2020-12-11 Thread Brian Norris
QCAHLSWMTPLZ-1 > > Fixes: 4945af5b264f ("ath10k: enable SRRI/DRRI support on ddr for WCN3990") > Signed-off-by: Rakesh Pillai Reviewed-by: Brian Norris

Re: [PATCH] ath10k: Remove voltage regulator votes during wifi disable

2020-12-10 Thread 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) { >

Re: [PATCH 1/2] platform/chrome: cros_ec_proto: Use EC_HOST_EVENT_MASK not BIT

2020-12-09 Thread Brian Norris
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

Re: [PATCH 1/1] mwifiex: Fix possible buffer overflows in mwifiex_uap_bss_param_prepare

2020-12-08 Thread 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()

Re: [PATCH 1/1] mwifiex: Fix possible buffer overflows in mwifiex_config_scan

2020-12-08 Thread Brian Norris
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

Re: [PATCH v2] ath10k: skip the wait for completion to recovery in shutdown path

2020-12-01 Thread Brian Norris
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); > > -

Re: [PATCH 1/3] mwifiex: disable ps_mode explicitly by default instead

2020-11-20 Thread Brian Norris
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

Re: [PATCH] mwifiex: pcie: add enable_device_dump module parameter

2020-11-20 Thread Brian Norris
(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

Re: [PATCH stable] net: sch_generic: fix the missing new qdisc assignment bug

2020-11-12 Thread Brian Norris
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!

Re: [PATCH 41/41] realtek: rtw88: pci: Add prototypes for .probe, .remove and .shutdown

2020-11-02 Thread Brian Norris
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

Re: [PATCH 1/3] mwifiex: disable ps_mode explicitly by default instead

2020-10-29 Thread Brian Norris
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

Re: [PATCH 1/3] mwifiex: disable ps_mode explicitly by default instead

2020-10-29 Thread Brian Norris
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

Re: [PATCH] mwifiex: pcie: add enable_device_dump module parameter

2020-10-28 Thread Brian Norris
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

Re: [PATCH 2/3] mwifiex: add allow_ps_mode module parameter

2020-10-28 Thread Brian Norris
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

Re: [PATCH] wireless: mwifiex: fix double free

2020-10-05 Thread Brian Norris
, 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

Re: [PATCH] scripts/setlocalversion: make git describe output more reliable

2020-09-10 Thread 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. &

Re: [PATCH] rtw88: pci: Power cycle device during shutdown

2020-08-25 Thread Brian Norris
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

Re: [PATCH net] mwifiex: Increase AES key storage size to 256 bits

2020-08-25 Thread Brian Norris
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

Re: [PATCH v2] mwifiex: don't call del_timer_sync() on uninitialized timer

2020-08-24 Thread Brian Norris
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 -

Re: [PATCH v4 7/7] pwm: cros-ec: Simplify EC error handling

2020-08-06 Thread Brian Norris
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

Re: [PATCH] drivers/net/wan/lapbether: Use needed_headroom instead of hard_header_len

2020-07-30 Thread 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

Re: [PATCH v3 6/6] platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes

2020-07-29 Thread Brian Norris
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 >

Re: [PATCH v3 0/6] platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes

2020-07-29 Thread Brian Norris
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

Re: [PATCH v3 6/6] platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes

2020-07-29 Thread 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

Re: [PATCH] drivers/net/wan/lapbether: Use needed_headroom instead of hard_header_len

2020-07-28 Thread Brian Norris
(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,

Re: [PATCH] mwifiex: don't call del_timer_sync() on uninitialized timer

2020-07-28 Thread Brian Norris
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

Re: [PATCH 2/2] platform/chrome: cros_ec_proto: check for missing EC_CMD_HOST_EVENT_GET_WAKE_MASK

2020-07-24 Thread Brian Norris
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 v2 2/2] platform/chrome: cros_ec_proto: check for missing EC_CMD_HOST_EVENT_GET_WAKE_MASK

2020-07-24 Thread Brian Norris
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

[PATCH v2 1/2] platform/chrome: cros_ec_proto: ignore unnecessary wakeups on old ECs

2020-07-24 Thread Brian Norris
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

Re: [PATCH 2/2] platform/chrome: cros_ec_proto: check for missing EC_CMD_HOST_EVENT_GET_WAKE_MASK

2020-07-22 Thread Brian Norris
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

Re: [PATCH 2/2] platform/chrome: cros_ec_proto: check for missing EC_CMD_HOST_EVENT_GET_WAKE_MASK

2020-07-22 Thread Brian Norris
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

Re: [PATCH v2 0/4] platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes

2020-07-22 Thread Brian Norris
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

Re: [PATCH v2 4/4] platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes

2020-07-22 Thread Brian Norris
+ 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

Re: [PATCH 2/2] platform/chrome: cros_ec_proto: check for missing EC_CMD_HOST_EVENT_GET_WAKE_MASK

2020-07-22 Thread Brian Norris
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 2/2] platform/chrome: cros_ec_proto: check for missing EC_CMD_HOST_EVENT_GET_WAKE_MASK

2020-07-21 Thread Brian Norris
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

[PATCH 1/2] platform/chrome: cros_ec_proto: ignore unnecessary wakeups on old ECs

2020-07-21 Thread Brian Norris
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

[RFC PATCH] firmware: qcom_scm: disable SDI at boot

2020-07-21 Thread Brian Norris
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

Re: [PATCH] ath10k: Keep track of which interrupts fired, don't poll them

2020-07-08 Thread Brian Norris
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

Re: [PATCH] ath10k: Keep track of which interrupts fired, don't poll them

2020-07-08 Thread Brian Norris
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

Re: [PATCH] ath10k: Add interrupt summary based CE processing

2020-06-26 Thread 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.

Re: [PATCH v3 5/8] ath10k: use new taint_firmware_crashed()

2020-06-02 Thread Brian Norris
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

Re: [PATCH] wireless: ath10k: Return early in ath10k_qmi_event_server_exit() to avoid hard crash on reboot

2020-06-02 Thread Brian Norris
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

Re: [PATCH] wireless: ath10k: Return early in ath10k_qmi_event_server_exit() to avoid hard crash on reboot

2020-06-02 Thread Brian Norris
+ 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

Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"

2020-06-02 Thread Brian Norris
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. > >

[PATCH] Revert "ath: add support for special 0x0 regulatory domain"

2020-05-27 Thread Brian Norris
: 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

Re: [PATCH v2 12/15] ath10k: use new module_firmware_crashed()

2020-05-21 Thread Brian Norris
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],

Re: [PATCH] ath9k: release allocated buffer if timed out

2020-05-20 Thread Brian Norris
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

Re: [PATCH v2 12/15] ath10k: use new module_firmware_crashed()

2020-05-19 Thread Brian Norris
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 >

Re: [PATCH v2 12/15] ath10k: use new module_firmware_crashed()

2020-05-18 Thread Brian Norris
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

Re: [PATCH] ath9k: release allocated buffer if timed out

2020-05-13 Thread Brian Norris
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 >

Re: [PATCH] ath9k: release allocated buffer if timed out

2020-05-13 Thread Brian Norris
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

Re: [PATCH] ath9k: release allocated buffer if timed out

2020-05-12 Thread Brian Norris
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

Re: [PATCH v4 resend 2] dt-bindings: net: btusb: DT fix s/interrupt-name/interrupt-names/

2020-05-05 Thread Brian Norris
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

Re: [PATCH] net: rtw88: fix an issue about leak system resources

2020-05-04 Thread Brian Norris
(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

Re: [PATCH] rtc: report time-retrieval errors when updating alarm

2019-10-21 Thread Brian Norris
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: >

Re: [PATCH] rtc: report time-retrieval errors when updating alarm

2019-10-21 Thread Brian Norris
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 > >

Re: [PATCH] MAINTAINERS: mtd/ubi/ubifs: Remove inactive maintainers

2019-10-18 Thread Brian Norris
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

Re: [PATCH 3/3] HID: google: whiskers: mask out extra flags in EC event_type

2019-10-07 Thread Brian Norris
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:

Re: [PATCH] firmware: google: increment VPD key_len properly

2019-09-30 Thread Brian Norris
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

[PATCH] firmware: google: increment VPD key_len properly

2019-09-30 Thread Brian Norris
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

Re: [PATCH] nl80211: add NL80211_CMD_UPDATE_FT_IES to supported commands

2019-08-22 Thread Brian Norris
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 :)

Re: [PATCH v3 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR

2019-08-15 Thread Brian Norris
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,

Re: Realtek r8822be wireless card fails to work with new rtw88 kernel module

2019-08-06 Thread Brian Norris
+ 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

Re: [PATCH] driver core: platform: return -ENXIO for missing GpioInt

2019-08-06 Thread Brian Norris
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

[PATCH] Revert "mwifiex: fix system hang problem after resume"

2019-08-05 Thread Brian Norris
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

Re: [RFC PATCH] Revert "mwifiex: fix system hang problem after resume"

2019-08-02 Thread Brian Norris
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

Re: [RFC PATCH] Revert "mwifiex: fix system hang problem after resume"

2019-08-02 Thread Brian Norris
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

Re: [PATCH] driver core: platform: return -ENXIO for missing GpioInt

2019-07-29 Thread Brian Norris
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. >

[PATCH] driver core: platform: return -ENXIO for missing GpioInt

2019-07-29 Thread Brian Norris
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

Re: [PATCH 5.3] mwifiex: fix 802.11n/WPA detection

2019-07-29 Thread Brian Norris
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

[PATCH] mac80211: don't WARN on short WMM parameters from AP

2019-07-26 Thread Brian Norris
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

[PATCH 5.3] mwifiex: fix 802.11n/WPA detection

2019-07-24 Thread Brian Norris
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

Re: [PATCH 5.3] mwifiex: fix 802.11n/WPA detection

2019-07-24 Thread Brian Norris
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

Re: [PATCH 2/2] mwifiex: Make use of the new sdio_trigger_replug() API to reset

2019-07-19 Thread Brian Norris
> + 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_

Re: [PATCH] mac80211: don't warn about CW params when not using them

2019-07-18 Thread Brian Norris
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.

[PATCH] mac80211: don't warn about CW params when not using them

2019-07-17 Thread Brian Norris
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

Re: [RFC PATCH] bug: always show source-tree-relative paths in WARN()/BUG()

2019-07-12 Thread Brian Norris
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

Re: [RFC PATCH] bug: always show source-tree-relative paths in WARN()/BUG()

2019-07-11 Thread Brian Norris
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.

[RFC PATCH] bug: always show source-tree-relative paths in WARN()/BUG()

2019-07-11 Thread Brian Norris
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

Re: [PATCH AUTOSEL 4.19 14/60] mwifiex: Abort at too short BSS descriptor element

2019-07-10 Thread Brian Norris
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

Re: [PATCH AUTOSEL 4.19 14/60] mwifiex: Abort at too short BSS descriptor element

2019-06-28 Thread Brian Norris
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

[PATCH v2 2/2] mwifiex: don't disable hardirqs; just softirqs

2019-06-25 Thread Brian Norris
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

[PATCH v2 0/2] mwifiex: spinlock usage improvements

2019-06-25 Thread Brian Norris
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|

[PATCH v2 1/2] mwifiex: dispatch/rotate from reorder table atomically

2019-06-25 Thread Brian Norris
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

Re: [PATCH 1/2] mwifiex: dispatch/rotate from reorder table atomically

2019-06-25 Thread Brian Norris
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] >

[PATCH 5.2 1/2] mwifiex: Don't abort on small, spec-compliant vendor IEs

2019-06-14 Thread Brian Norris
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

[PATCH 2/2] mwifiex: use 'total_ie_len' in mwifiex_update_bss_desc_with_ie()

2019-06-14 Thread Brian Norris
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

Re: [PATCH v3 3/4] backlight: pwm_bl: compute brightness of LED linearly to human eye.

2019-06-11 Thread Brian Norris
On Tue, Jun 11, 2019 at 3:49 AM Daniel Thompson wrote: > This is a long standing flaw in the backlight interfaces. AFAIK generic > userspaces end up with a (flawed) heuristic. Bingo! Would be nice if we could start to fix this long-standing flaw. > Basically devices with a narrow range of

Re: [EXT] Re: [4.20 PATCH] Revert "mwifiex: restructure rx_reorder_tbl_lock usage"

2019-06-04 Thread Brian Norris
Hi Ganapathi, On Mon, Jun 3, 2019 at 8:04 PM Ganapathi Bhat wrote: > > There are a few possible ways to handle this: > > (a) prevent processing softirqs in that context; e.g., with > > local_bh_disable(). This seems somewhat of a hack. > > (Side note: I think most of the locks in this

  1   2   3   4   5   6   7   8   9   10   >