er, action_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 issu
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
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
(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 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
Hi Jakub,
On Mon, Dec 7, 2020 at 12:10 PM Jakub Kicinski wrote:
> On Mon, 7 Dec 2020 11:35:53 -0800 Brian Norris wrote:
> > On Mon, Dec 7, 2020 at 2:42 AM Kalle Valo wrote:
> > > Jakub Kicinski writes:
> > > > On Thu, 3 Dec 2020 18:57:32 + (UTC) Kalle Valo
On Tue, Dec 8, 2020 at 7:01 AM Edward Cree wrote:
> My understanding is that it's because users can have them in their
> modprobe.conf, which causes breakage if an update removes the param.
> I think the module insert fails if there are unrecognised parameters
> there.
That's a nice understand
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 by
(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() c
On Mon, Dec 7, 2020 at 2:42 AM Kalle Valo wrote:
> Jakub Kicinski writes:
> > On Thu, 3 Dec 2020 18:57:32 + (UTC) Kalle Valo wrote:
> > There's also a patch which looks like it renames a module parameter.
> > Module parameters are considered uAPI.
>
> Ah, I have been actually wondering that
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 behavio
_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 *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 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 b
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 p
code, 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
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 iss
n Nikolov
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 commi
wdp3_bafmkncuqj3k+-...@mail.gmail.com
>
> 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
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 this
> &g
(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,
rt->tx_aggr.timer_cnxt.is_hold_timer_set) {
port->tx_aggr.timer_cnxt.is_hold_timer_set = false;
spin_unlock_bh(&port->tx_aggr_lock);
/* Timer could still be running, but it can't be restarted at this
point, so this is safe. */
del_timer_sync(&port->tx_aggr
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
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, 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
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:
> >
> > ced21a
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 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 fix
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
Hi Rafael,
On Wed, Feb 27, 2019 at 3:04 PM Rafael J. Wysocki wrote:
> On Wed, Feb 27, 2019 at 9:58 PM Brian Norris wrote:
> > On Wed, Feb 27, 2019 at 11:16:12AM +0100, Ard Biesheuvel wrote:
> > > So I'd argue that we should add an optional 'wake-gpio' DT prop
Hi Ard,
On Wed, Feb 27, 2019 at 11:16:12AM +0100, Ard Biesheuvel wrote:
> On Wed, 27 Feb 2019 at 11:02, Marc Zyngier wrote:
> > On 26/02/2019 23:28, Brian Norris wrote:
> > > You're not the first person to notice this. All the motivations are not
> > > necessaril
Hi Marc,
On Wed, Feb 27, 2019 at 10:02:16AM +, Marc Zyngier wrote:
> On 26/02/2019 23:28, Brian Norris wrote:
> > On Sun, Feb 24, 2019 at 02:04:22PM +, Marc Zyngier wrote:
> >> Note how the interrupt is part of the properties directly attached to the
> >> PCI no
Hi,
On Tue, Feb 26, 2019 at 05:14:00PM +, Marc Zyngier wrote:
> On 26/02/2019 16:21, Ard Biesheuvel wrote:
> > On Mon, 25 Feb 2019 at 15:53, Marc Zyngier wrote:
> >> It outlines one thing: If you have to interpret per-device PCI
> >> properties from DT, you're in for serious trouble. I should
On Tue, Feb 26, 2019 at 03:31:31PM -0800, Brian Norris wrote:
> Hi Marc,
>
> On Sun, Feb 24, 2019 at 02:04:25PM +, Marc Zyngier wrote:
> > The mwifiex driver makes unsafe assumptions about the state of the
> > wake-up interrupt. It requests it and only then disable i
ke-up subsystem) enables it.
>
> Signed-off-by: Marc Zyngier
This could be:
Fixes: 853402a00823 ("mwifiex: Enable WoWLAN for both sdio and pcie")
although, that was just borrowing the existing antipattern from SDIO
code..
Reviewed-by: Brian Norris
Thanks.
> ---
>
+ others
Hi Marc,
Thanks for the series. I have a few bits of history to add to this, and
some comments.
On Sun, Feb 24, 2019 at 02:04:22PM +, Marc Zyngier wrote:
> For quite some time, I wondered why the PCI mwifiex device built in my
> Chromebook was unable to use the good old legacy inter
_head() is also included further
down the page.
This diff tested via:
$ scripts/kernel-doc -rst include/linux/skbuff.h net/core/skbuff.c
No new warnings were seen, and the output makes a little more sense.
Signed-off-by: Brian Norris
---
include/linux/skbuff.h | 12 ++--
1 file
ers) uses dev_dbg()
instead of mwifiex_dbg() with an appropriate mask (e.g., EVENT). But
mwifiex_dbg() seems preferable for consistency.
> Signed-off-by: Stefan Agner
Reviewed-by: Brian Norris
> ---
> drivers/net/wireless/marvell/mwifiex/uap_event.c | 2 +-
> 1 file changed, 1 inserti
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, Nov 02, 2017 at 04:40:57PM +0100, Arnd Bergmann wrote:
> On Thu, Nov 2, 2017 at 4:23 PM, Kalle Valo wrote:
> > Brian has already fixed this, please check that:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=20665a9076d48e9abd9a2db13d307f58f7ef66
On Thu, Oct 05, 2017 at 08:52:33PM +0530, Himanshu Jha wrote:
> There are various instances where a function used in file say for eg
> int func_align (void* a)
> is used and it is defined in align.h
> But many files don't *directly* include align.h and rather include
> any other header which includ
> Signed-off-by: Jeffy Chen
>
> ---
>
> Changes in v2:
> Uninit wakeup when _mwifiex_fw_dpc failed too.
Looks good to me:
Reviewed-by: Brian Norris
&& firmware_stat == FIRMWARE_READY_SDIO &&
> + !adapter->mfg_mode) {
The PCIe driver has the same code structure. Might change both, if
you're changing one of them? The PCIe one is technically safe I guess,
since it will write to the 'firmware_stat
On Mon, Jul 03, 2017 at 03:54:30PM +0800, Jeffy Chen wrote:
> We inited wakeup info at the beginning of mwifiex_add_card, so we need
> to uninit it in the error handling.
>
> It's much the same as what we did in:
> 36908c4 mwifiex: uninit wakeup info when removing device
Yeah, I noticed I hadn't
On Fri, May 26, 2017 at 09:41:49AM +0800, Shawn Lin wrote:
> We don't need to check if the list is empty separately
> as we could use list_first_entry_or_null to cover it.
>
> Signed-off-by: Shawn Lin
Looks fine to me.
Reviewed-by: Brian Norris
On Thu, Apr 06, 2017 at 07:02:15AM +0300, Kalle Valo wrote:
> Brian Norris writes:
>
> > nl80211 provides the NL80211_SCAN_FLAG_RANDOM_ADDR for every scan
> > request that should be randomized; the absence of such a flag means we
> > should not randomize. However, mwifiex
ere for me.
Fixes: c2a8f0ff9c6c ("mwifiex: support random MAC address for scanning")
Signed-off-by: Brian Norris
---
Should this be tagged for -stable?
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wirel
/* Stop session thread */
> atomic_inc(&session->terminate);
> - wake_up_process(session->task);
> +
> + /* Ensure session->terminate is updated */
> + smp_mb__after_atomic();
And again.
But otherwise I think this looks OK, again with the caveat that I don't
know Bluetooth/CMTP that well:
Reviewed-by: Brian Norris
> +
> + wake_up_interruptible(sk_sleep(session->sock->sk));
> } else
> err = -ENOENT;
>
> --
> 2.1.4
>
>
e_up_process(s->task);
> +
> + /* Ensure session->terminate is updated */
> + smp_mb__after_atomic();
> +
__wake_up() suggests:
* It may be assumed that this function implies a write memory barrier before
* changing the task state if and only if any tas
Hi Jeffy,
I'm really not an expert on bluetooth or HIDP, but I can't bring myself
to say that this is correct. I still think you have a problem.
On Tue, Jan 24, 2017 at 12:07:51PM +0800, Jeffy Chen wrote:
> It looks like hidp_session_thread has same pattern as the issue reported in
> old rfcomm:
tree node, (using standard interrupt descriptors).
> A devcie tree binding document is also added for the driver. The
> compatible string is in compliance with
> Documentation/devicetree/bindings/usb/usb-device.txt
>
> Signed-off-by: Rajat Jain
> Reviewed-by: Brian Norris
> Ack
Hi Jeffy,
On Fri, Jan 20, 2017 at 09:52:08PM +0800, Jeffy Chen wrote:
> [ 39.044329] do not call blocking ops when !TASK_RUNNING; state=1 set
> at [] hidp_session_thread+0x110/0x568 [hidp]
> ...
> [ 40.159664] Call trace:
> [ 40.162122] [] __might_sleep+0x64/0x90
> [ 40.167443] [] lock_soc
On Mon, Dec 19, 2016 at 05:46:19PM -0800, Rajat Jain wrote:
> On Mon, Dec 19, 2016 at 3:10 PM, Brian Norris
> wrote:
> > On Fri, Dec 16, 2016 at 11:30:03AM -0800, Rajat Jain wrote:
> >> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> >>
han those, for the whole series:
Reviewed-by: Brian Norris
> ---
> v2: * Use interrupt-names ("wakeup") instead of assuming first interrupt.
> * Leave it on device tree to specify IRQ flags (level /edge triggered)
> * Mark the device as non wakeable on
Hi,
On Wed, Dec 14, 2016 at 11:12:58AM -0800, Rajat Jain wrote:
> Some BT chips (e.g. Marvell 8997) contain a wakeup pin that can be
> connected to a gpio on the CPU side, and can be used to wakeup
> the host out-of-band. This can be useful in situations where the
> in-band wakeup is not possible
s allocated in function
> + * mwifiex_fill_new_bss_desc(). Free it now.
> + */
> + kfree(bss_desc->beacon_buf);
For a bit, I thought this was possibly a sort of double-free, since
mwifiex_fill_new_bss_desc() might actually fail to allocate
->beacon_buf, but kfree(NULL) is safe, so:
Reviewed-by: Brian Norris
> kfree(bss_desc);
> return 0;
> }
> --
> 2.6.6
>
Hi,
On Thu, Jun 30, 2016 at 03:21:02PM -0700, Brian Norris wrote:
> The PCIe driver didn't mask the host interrupts before trying to tear
> down. This causes lockups at reboot or rmmod when using MSI-X on 8997,
> since the MSI handler gets confused and locks up the system.
>
e bug). No regressions seen there.
Signed-off-by: Brian Norris
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 0c7937eb6b77..af98371dc2af 10
On Thu, Aug 20, 2015 at 09:07:13AM +0200, Javier Martinez Canillas wrote:
> Patches #1 and #2 solves a), patches #3 to #8 solves b) and patches
^^^ I'm dying to know how this sentence ends :)
> Patch #18 changes the logic of spi_uevent() to report an OF modalias if
> the device was registered usi
69 matches
Mail list logo
