Re: [Intel-gfx] [PATCH] treewide: Convert del_timer*() to timer_shutdown*()
Steven Rostedt writes: > [ > Linus, > > I ran the script against your latest master branch: > commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf > > As the timer_shutdown*() code is now in your tree, I figured > we can start doing the conversions. At least add the trivial ones > now as Thomas suggested that this gets applied at the end of the > merge window, to avoid conflicts with linux-next during the > development cycle. I can wait to Friday to run it again, and > resubmit. > > What is the best way to handle this? > ] > > From: "Steven Rostedt (Google)" > > Due to several bugs caused by timers being re-armed after they are > shutdown and just before they are freed, a new state of timers was added > called "shutdown". After a timer is set to this state, then it can no > longer be re-armed. > > The following script was run to find all the trivial locations where > del_timer() or del_timer_sync() is called in the same function that the > object holding the timer is freed. It also ignores any locations where the > timer->function is modified between the del_timer*() and the free(), as > that is not considered a "trivial" case. > > This was created by using a coccinelle script and the following commands: > > $ cat timer.cocci > @@ > expression ptr, slab; > identifier timer, rfield; > @@ > ( > - del_timer(>timer); > + timer_shutdown(>timer); > | > - del_timer_sync(>timer); > + timer_shutdown_sync(>timer); > ) > ... when strict > when != ptr->timer > ( > kfree_rcu(ptr, rfield); > | > kmem_cache_free(slab, ptr); > | > kfree(ptr); > ) > > $ spatch timer.cocci . > /tmp/t.patch > $ patch -p1 < /tmp/t.patch > > Link: https://lore.kernel.org/lkml/20221123201306.823305...@linutronix.de/ > > Signed-off-by: Steven Rostedt (Google) For wireless: > .../broadcom/brcm80211/brcmfmac/btcoex.c | 2 +- > drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c | 2 +- > drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 2 +- > drivers/net/wireless/intersil/hostap/hostap_ap.c | 2 +- > drivers/net/wireless/marvell/mwifiex/main.c | 2 +- > drivers/net/wireless/microchip/wilc1000/hif.c| 6 +++--- Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [Intel-gfx] [PATCH 0/1] add support for enum module parameters
+ linux-wireless, netdev Jani Nikula writes: > On Thu, 14 Apr 2022, Greg Kroah-Hartman wrote: >> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote: >>> Hey, I've sent this before, ages ago, but haven't really followed >>> through with it. I still think it would be useful for many scenarios >>> where a plain number is a clumsy interface for a module param. >>> >>> Thoughts? >> >> We should not be adding new module parameters anyway (they operate on >> code, not data/devices), so what would this be used for? > > I think it's just easier to use names than random values, and this also > gives you range check on the input. > > I also keep telling people not to add new module parameters, but it's > not like they're going away anytime soon. > > If there's a solution to being able to pass device specific debug > parameters at probe time, I'm all ears. At least i915 has a bunch of > things which can't really be changed after probe, when debugfs for the > device is around. Module parameters aren't ideal, but debugfs doesn't > work for this. Wireless drivers would also desperately need to pass device specific parameters at (or before) probe time. And not only debug parameters but also configuration parameters, for example firmware memory allocations schemes (optimise for features vs number of clients etc) and whatnot. Any ideas how to implement that? Is there any prior work for anything like this? This is pretty hard limiting usability of upstream wireless drivers and I really want to find a proper solution. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [Intel-gfx] [PATCH 04/11] ath11: Wstringop-overread warning
Arnd Bergmann wrote:
> gcc-11 with the kernel address sanitizer prints a warning for this
> driver:
>
> In function 'ath11k_peer_assoc_h_vht',
> inlined from 'ath11k_peer_assoc_prepare' at
> drivers/net/wireless/ath/ath11k/mac.c:1632:2:
> drivers/net/wireless/ath/ath11k/mac.c:1164:13: error:
> 'ath11k_peer_assoc_h_vht_masked' reading 16 bytes from a region of size 4
> [-Werror=stringop-overread]
> 1164 | if (ath11k_peer_assoc_h_vht_masked(vht_mcs_mask))
> | ^~~~
> drivers/net/wireless/ath/ath11k/mac.c: In function
> 'ath11k_peer_assoc_prepare':
> drivers/net/wireless/ath/ath11k/mac.c:1164:13: note: referencing argument 1
> of type 'const u16 *' {aka 'const short unsigned int *'}
> drivers/net/wireless/ath/ath11k/mac.c:969:1: note: in a call to function
> 'ath11k_peer_assoc_h_vht_masked'
> 969 | ath11k_peer_assoc_h_vht_masked(const u16
> vht_mcs_mask[NL80211_VHT_NSS_MAX])
> | ^~
>
> According to analysis from gcc developers, this is a glitch in the
> way gcc tracks the size of struct members. This should really get
> fixed in gcc, but it's also easy to work around this instance
> by changing the function prototype to no include the length of
> the array.
>
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673
> Signed-off-by: Arnd Bergmann
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of ath.git, thanks.
eb19efed836a ath11k: Wstringop-overread warning
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210322160253.4032422-5-a...@kernel.org/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [Intel-gfx] [PATCH 0/9] relay: cleanup and const callbacks, take 2
Jani Nikula writes: > This is v2 of [1], with a number of cleanups added first based on > Christoph's feedback, making the actual constness patch much smaller and > cleaner. > > I don't know who actually maintains relay, it's not in MAINTAINERS - > Cc'd Andrew just in case. > > I'd think it would be simplest to queue patches 5-9 via whichever tree > the relay patches get merged. They're all one-liners so neglible > conflict potential. > > BR, > Jani. > > > [1] http://lore.kernel.org/r/20201118165320.26829-1-jani.nik...@intel.com > > > Cc: linux-bl...@vger.kernel.org > Cc: Jens Axboe > Cc: ath...@lists.infradead.org > Cc: ath...@lists.infradead.org > Cc: Kalle Valo > Cc: linux-wirel...@vger.kernel.org > Cc: QCA ath9k Development > Cc: intel-gfx@lists.freedesktop.org > Cc: Christoph Hellwig > Cc: Andrew Morton > > > Jani Nikula (9): > relay: remove unused buf_mapped and buf_unmapped callbacks > relay: require non-NULL callbacks in relay_open() > relay: make create_buf_file and remove_buf_file callbacks mandatory > relay: allow the use of const callback structs > drm/i915: make relay callbacks const > ath10k: make relay callbacks const > ath11k: make relay callbacks const > ath9k: make relay callbacks const > blktrace: make relay callbacks const For ath9k, ath10k & ath11k: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] ath11k: make relay callbacks const
Jani Nikula writes: > On Wed, 18 Nov 2020, Jani Nikula wrote: >> Now that relay_open() accepts const callbacks, make relay callbacks >> const. >> >> Cc: Kalle Valo >> Cc: ath...@lists.infradead.org >> Signed-off-by: Jani Nikula > > Kalle, thanks for the acks on the other two ath patches - can I have > your ack on this one too please? Oops, missed that: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] ath10k: make relay callbacks const
Jani Nikula writes: > Now that relay_open() accepts const callbacks, make relay callbacks > const. > > Cc: Kalle Valo > Cc: ath...@lists.infradead.org > Signed-off-by: Jani Nikula I assume this goes via some other tree: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] ath9k: make relay callbacks const
Kalle Valo writes: > Jani Nikula writes: > >> Now that relay_open() accepts const callbacks, make relay callbacks >> const. >> >> Cc: Kalle Valo >> Cc: QCA ath9k Development >> Cc: linux-wirel...@vger.kernel.org >> Signed-off-by: Jani Nikula > > Can I take this to my ath tree or what's the plan? Ah, saw patch 1 only now. So I assume this goes via some other tree: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] ath9k: make relay callbacks const
Jani Nikula writes: > Now that relay_open() accepts const callbacks, make relay callbacks > const. > > Cc: Kalle Valo > Cc: QCA ath9k Development > Cc: linux-wirel...@vger.kernel.org > Signed-off-by: Jani Nikula Can I take this to my ath tree or what's the plan? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] video: X sets brightness to zero after resume
Hans de Goede hdego...@redhat.com writes: If I set video.use_native_backlight=0 in kernel command line the problem goes away. Or if I revert your commit 0e9f81d3b7c the problem also goes away. Any ideas? Not really... I've added i915 people maybe they have an idea. This is a known issue in xf86-video-intel, which gets exposed due to the video.use_native_backlight=1 option. This should be fixed in the latest 2.99.912 xf86-video-intel release. Ok, thanks. As Ubuntu 12.04 doesn't have that I'll continue to use video.use_native_backlight=0 until I update my distro. -- Kalle Valo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 3.11-rc2 (acpi backlight, revert)
Rafael J. Wysocki r...@sisk.pl writes: James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch fixes the backlight for you. I did three suspend-resume cycles and didn't notice anything wrong so this patch fixes the issue for me. I'll continue testing and will report if I spot any problems. Tested-by: Kalle Valo kv...@adurom.com -- Kalle Valo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
