On Sat, 7 Nov 2020 17:21:31 + Taehee Yoo wrote:
> When debugfs file is opened, its module should not be removed until
> it's closed.
> Because debugfs internally uses the module's data.
> So, it could access freed memory.
>
> In order to avoid panic, it just sets .owner to THIS_MODULE.
> So t
On Mon, 23 Nov 2020 00:40:30 +0100 Rikard Falkeborn wrote:
> These are only used as input arguments to qmi_handle_init() which
> accepts const pointers to both qmi_ops and qmi_msg_handler. Make them
> const to allow the compiler to put them in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
On Wed, 25 Nov 2020 15:45:05 -0600 Alex Elder wrote:
> On 11/22/20 5:40 PM, Rikard Falkeborn wrote:
> > These are only used as input arguments to qmi_handle_init() which
> > accepts const pointers to both qmi_ops and qmi_msg_handler. Make them
> > const to allow the compiler to put them in read-onl
Adding Kalle and Hainer.
On Wed, 24 Nov 2021 14:45:05 -0800 Stephen Hemminger wrote:
> Begin forwarded message:
>
> Date: Wed, 24 Nov 2021 21:14:53 +
> From: bugzilla-dae...@bugzilla.kernel.org
> To: step...@networkplumber.org
> Subject: [Bug 215129] New: Linux kernel hangs during power down
On Thu, 25 Nov 2021 08:32:18 +0100 Heiner Kallweit wrote:
> I think the reference to ath10k_pci is misleading, Kalle isn't needed here.
> The actual issue is a RTNL deadlock in igb_resume(). See log snippet:
>
> Nov 24 18:56:19 MartinsPc kernel: igb_resume+0xff/0x1e0 [igb
> 21bf6a00cb1f20e9b0e84
On Tue, 14 Dec 2021 22:39:36 + Abhishek Kumar wrote:
> NAPI poll can be done in threaded context along with soft irq
> context. Threaded context can be scheduled efficiently, thus
> creating less of bottleneck during Rx processing. This patch is
> to enable threaded NAPI on ath10k driver.
You
Defining local versions of NAPI_POLL_WEIGHT with the same
values in the drivers just makes refactoring harder.
Signed-off-by: Jakub Kicinski
---
CC: kv...@kernel.org
CC: ath10k@lists.infradead.org
CC: linux-wirel...@vger.kernel.org
---
drivers/net/wireless/ath/ath10k/core.h | 3 ---
drivers/net
On Fri, 29 Apr 2022 22:06:20 +0300 Kalle Valo wrote:
> This failed to build as recently usb.c got napi poll as well, I fixed it
> in the pending branch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=89fc2e14d3e50cad605104572228d3740df7ca77
Sorry & thanks!
On Thu, 10 Nov 2022 11:12:28 +0800 Xiu Jianfeng wrote:
> To: , , ,
> , ,
> CC: , ,
>
How did you come up with this CC list? If you're CCing netdev
maintainers you should also CC net...@vger.kernel.org
Somehow you managed to CC LMKL but not netdev :S
On Mon, 2 Oct 2023 17:10:20 +0200 Christian Marangi wrote:
> queue_work(priv->xfer_wq, &priv->rx_work);
> - else if (napi_schedule_prep(&priv->napi))
> - __napi_schedule(&priv->napi);
> + else
> + napi_schedule(&
On Thu, 5 Oct 2023 18:11:56 +0200 Eric Dumazet wrote:
> OK, but I suspect some users of napi_reschedule() might not be race-free...
What's the race you're thinking of?
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman
On Wed, 20 Mar 2024 08:12:46 -0700 Jeff Johnson wrote:
> NAK this based upon the ath11k patch results.
The ath11 patch is much more complex, I'd wager this one is fine.
> As suggested there we should just use kmalloc/kfree to match the existing
> logic.
Please no. There is no magic here. alloc
On Thu, 21 Mar 2024 15:02:39 -0700 Jeff Johnson wrote:
> >> As suggested there we should just use kmalloc/kfree to match the existing
> >> logic.
> >
> > Please no. There is no magic here. alloc + free must match whether
> > you're using magic object alloc wrapper (alloc_netdev()) or straight
>
On Fri, 22 Mar 2024 07:58:02 -0700 Breno Leitao wrote:
> > Looks like init_dummy_netdev wipes the netdev structure clean, so I
> > don't think we can use it directly as the setup function, Breno :(
>
> Before my patch, init_dummy_netdev was being also used. The patch was
> basically replacing t
On Wed, 27 Mar 2024 07:38:05 -0700 Breno Leitao wrote:
> -void init_dummy_netdev(struct net_device *dev)
> +void init_dummy_netdev_core(struct net_device *dev)
Can init_dummy_netdev_core() be a static function (and no export)?
alloc_netdev_dummy() is probably going to be the only user.
I'd al
On Wed, 27 Mar 2024 08:42:55 -0700 Jeff Johnson wrote:
> On 3/27/2024 7:45 AM, Jakub Kicinski wrote:
> > On Wed, 27 Mar 2024 07:38:05 -0700 Breno Leitao wrote:
> >> -void init_dummy_netdev(struct net_device *dev)
> >> +void init_dummy_netdev_core(struct net_
On Tue, 9 Apr 2024 05:57:15 -0700 Breno Leitao wrote:
> For dummy devices, exit earlier at free_netdev() instead of executing
> the whole function. This is necessary, because dummy devices are
> special, and shouldn't have the second part of the function executed.
>
> Otherwise reg_state, which i
On Wed, 10 Apr 2024 06:13:41 -0700 Breno Leitao wrote:
> wifi: ath11k: allocate dummy net_device dynamically
Sorry Breno, I didn't notice earlier, patch 10 didn't make it
to the list. The series wasn't ingested by CI and tested because
of this. Could you repost?
--
pw-bot: cr
On Thu, 11 Apr 2024 06:59:27 -0700 Breno Leitao wrote:
> +/**
> + * alloc_netdev_dummy - Allocate and initialize a dummy net device.
> + * @sizeof_priv: size of private data to allocate space for
> + */
> +struct net_device *alloc_netdev_dummy(int sizeof_priv)
Sorry, one more round :)
We started
On Tue, 25 Jun 2024 09:56:35 +0300 Kalle Valo wrote:
> > Adding netdev to the initial message in the thread.
> > https://lore.kernel.org/all/CAPh3n83zb1PwFBFijJKChBqY95zzpYh=2iPf8tmh=yts6e3...@mail.gmail.com/
> >
> > There was some discussion in the thread, with the observation that the
> > splat
On Mon, 18 May 2020 21:25:09 +0200 Johannes Berg wrote:
> It's pretty clear, but even then, first of all I doubt this is the case
> for many of the places that you've sprinkled the annotation on, and
> secondly it actually hides useful information.
>
> Regardless of the support issue, I think this
On Mon, 18 May 2020 22:29:53 +0200 Johannes Berg wrote:
> On Mon, 2020-05-18 at 13:28 -0700, Jakub Kicinski wrote:
> > On Mon, 18 May 2020 21:25:09 +0200 Johannes Berg wrote:
> > > It's pretty clear, but even then, first of all I doubt this is the case
> > > fo
On Mon, 18 May 2020 22:41:48 +0200 Johannes Berg wrote:
> On Mon, 2020-05-18 at 13:35 -0700, Jakub Kicinski wrote:
> > It's intended to be a generic netlink channel for configuring devices.
> >
> > All the firmware-related interfaces have no dependencies on netdevs,
>
On Mon, 18 May 2020 21:22:02 + Luis Chamberlain wrote:
> Indeed my issue with devlink is that it did not seem generic enough for
> all devices which use firmware and for which firmware can crash. Support
> should not have to be "add devlink support" + "now use this new hook",
> but rather a ver
It builds.
Signed-off-by: Jakub Kicinski
---
drivers/net/wimax/i2400m/rx.c | 2 ++
drivers/net/wimax/i2400m/usb.c | 5 +
2 files changed, 7 insertions(+)
diff --git a/drivers/net/wimax/i2400m/rx.c b/drivers/net/wimax/i2400m/rx.c
index c9fb619a9e01..cc7fe78f2df0 100644
--- a/drivers/net
rrors:
$ devlink health
pci/:07:00.0:
reporter fw
state error error 7 recover 0
Obviously drivers may upgrade to the full devlink health API
which includes state dump, state dump auto-collect and automatic
error recovery control.
Signed-off-by: Jakub Kicinski
---
include/linux/devl
On Fri, 22 May 2020 05:20:46 + Luis Chamberlain wrote:
> > diff --git a/net/core/Makefile b/net/core/Makefile
> > index 3e2c378e5f31..6f1513781c17 100644
> > --- a/net/core/Makefile
> > +++ b/net/core/Makefile
> > @@ -31,7 +31,7 @@ obj-$(CONFIG_LWTUNNEL_BPF) += lwt_bpf.o
> > obj-$(CONFIG_BPF_S
On Fri, 22 May 2020 22:46:07 +0200 Johannes Berg wrote:
> > The irony is you have a problem with a networking device and all the
> > devices your initial set touched are networking. Two of the drivers
> > you touched either have or will soon have devlink health reporters
> > implemented.
>
> Li
On Tue, 21 Jul 2020 19:25:14 +0200 Andrew Lunn wrote:
> On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:
> > NAPI gets scheduled on the CPU core which got the
> > interrupt. The linux scheduler cannot move it to a
> > different core, even if the CPU on which NAPI is running
> > is hea
On Fri, 31 Jul 2020 23:57:19 +0530 Rakesh Pillai wrote:
> The history recording will be compiled only if
> ATH10K_DEBUG is enabled, and also enabled via
> the module parameter. Once the history recording
> is enabled via module parameter, it can be enabled
> or disabled runtime via debugfs.
Have y
On Mon, 27 Nov 2017 18:56:21 +0100, Matthias Schiffer wrote:
> Signed-off-by: Matthias Schiffer
> ---
> drivers/net/wireless/ath/ath9k/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/Makefile
> b/drivers/net/wireless/ath/ath9k/Mak
31 matches
Mail list logo
