* Re: [PATCH 5/7] arm64: dts: qcom: sm8350: expand UART18 to 4 pins config
From: Bartosz Golaszewski @ 2026-06-02 7:58 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: linux-arm-msm, linux-pci, linux-kernel, linux-wireless, ath11k,
devicetree, Bartosz Golaszewski, linux-bluetooth,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio
In-Reply-To: <20260601-sm8350-wifi-v1-5-242917d88031@oss.qualcomm.com>
On Mon, 1 Jun 2026 11:46:53 +0200, Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> said:
> On SM8350 platforms the primary use of UART18 is a 4-pin UART (targeting
> Bluetooth or other similar applications). Add all 4 pins to the default
> pinctrl entry for the UART.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/sm8350.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> index c830953156ec..eb2a795d8edb 100644
> --- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> @@ -3309,7 +3309,7 @@ qup_uart6_default: qup-uart6-default-state {
> };
>
> qup_uart18_default: qup-uart18-default-state {
> - pins = "gpio68", "gpio69";
> + pins = "gpio68", "gpio69", "gpio70", "gpio71";
> function = "qup18";
> drive-strength = <2>;
> bias-disable;
>
> --
> 2.47.3
>
>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 6/7] arm64: dts: qcom: sm8350: modernize PCIe entries
From: Bartosz Golaszewski @ 2026-06-02 7:59 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: linux-arm-msm, linux-pci, linux-kernel, linux-wireless, ath11k,
devicetree, Bartosz Golaszewski, linux-bluetooth,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio
In-Reply-To: <20260601-sm8350-wifi-v1-6-242917d88031@oss.qualcomm.com>
On Mon, 1 Jun 2026 11:46:54 +0200, Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> said:
> The recent suggestion is to have PERST# / WAKE pins and PHYs in the PCIe
> port rather than RC device. The kernel recently started warning about
> the older style of DT. Modernize DT for SM8350 platform by moving the
> entries under the root port device node.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: sm8350-hdk: describe WiFi/BT chip
From: Bartosz Golaszewski @ 2026-06-02 8:00 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: linux-arm-msm, linux-pci, linux-kernel, linux-wireless, ath11k,
devicetree, Bartosz Golaszewski, linux-bluetooth,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio
In-Reply-To: <20260601-sm8350-wifi-v1-7-242917d88031@oss.qualcomm.com>
On Mon, 1 Jun 2026 11:46:55 +0200, Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> said:
> The SM8350 HDK has onboard WiFi/BT chip, WCN6851. It is an earlier
> version of well-known WCN6855 WiFI/BT SoC. Describe the PMU, BT and WiFI
> parts of the device.
>
> The firmware isn't (yet) available as a part of linux-firmware, so it
> was verified with the firmware files from the vendor-supplied package
> (wcn prefix was applied to Bluetooth firmware files to make them follow
> upstream driver changes, vendor provided hpbtfw10.tlv and hpnv10.b06).
>
> Bluetooth: hci0: QCA Product ID :0x00000013
> Bluetooth: hci0: QCA SOC Version :0x400c0110
> Bluetooth: hci0: QCA ROM Version :0x00000100
> Bluetooth: hci0: QCA Patch Version:0x00001017
> Bluetooth: hci0: QCA controller version 0x01100100
> Bluetooth: hci0: QCA Downloading qca/wcnhpbtfw10.tlv
> Bluetooth: hci0: QCA Downloading qca/wcnhpnv10.b06
> Bluetooth: hci0: QCA setup on UART is completed
> Bluetooth: hci0: HFP non-HCI data transport is supported
>
> ath11k_pci 0000:01:00.0: BAR 0 [mem 0x60400000-0x605fffff 64bit]: assigned
> ath11k_pci 0000:01:00.0: MSI vectors: 32
> ath11k_pci 0000:01:00.0: wcn6855 hw1.1
> mhi mhi0: Requested to power ON
> mhi mhi0: Power on setup success
> mhi mhi0: Wait for device to enter SBL or Mission mode
> ath11k_pci 0000:01:00.0: chip_id 0x0 chip_family 0xb board_id 0x6 soc_id 0x400c0110
> ath11k_pci 0000:01:00.0: fw_version 0x110c80c8 fw_build_timestamp 2021-05-25 21:43 fw_build_id WLAN.HSP.1.1.c3-00200-QCAHSPSWPL_V1_V2_SILICONZ-1
> ath11k_pci 0000:01:00.0 wlp1s0: renamed from wlan0
>
> For the reference, the driver looks for the board data for
> bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=0,qmi-board-id=6,variant=QC_8350_HDK
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Óscar Alfonso Díaz @ 2026-06-02 8:29 UTC (permalink / raw)
To: Johannes Berg
Cc: Devin Wittmayer, linux-wireless, Felix Fietkau, Lorenzo Bianconi,
linux-kernel, stable, fjhhz1997, Brite
In-Reply-To: <CA+bbHrXtEdHEDHDb+8KNaKu=ODvkYwjiEEOtU2HntSRb8-WZ5g@mail.gmail.com>
Hello, sorry for the delay, but here are the tests that were carried out:
-Compiled kernel 7.0.11 using the suggested patch:
https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
*Tests with Ralink RT3572:
Standard DoS 2.4ghz -> working
VIF DoS 2.4ghz -> working
Standard DoS 5ghz -> working
VIF DoS 5ghz -> working
*Tests with MediaTek MT7921U:
Standard DoS 2.4ghz -> working
VIF DoS 2.4ghz -> working
Standard DoS 5ghz -> working
VIF DoS 5ghz -> not working (no freeze or error)
-Compiled kernel 7.1-rc6 using same patch:
https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
*Tests with Ralink RT3572:
Standard DoS 2.4ghz -> working
VIF DoS 2.4ghz -> working
Standard DoS 5ghz -> working
VIF DoS 5ghz -> working
*Tests with MediaTek MT7921U:
Standard DoS 2.4ghz -> working
VIF DoS 2.4ghz -> working
Standard DoS 5ghz -> working
VIF DoS 5ghz -> not working (no freeze or error)
So exactly the same behavior on both kernels.
Hope it helps. Thanks and regards.
--
Oscar
OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--
El mié, 20 may 2026 a las 11:55, Óscar Alfonso Díaz
(<oscar.alfonso.diaz@gmail.com>) escribió:
>
> Ok, I'll do the testing using this one you suggested:
> https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
>
> Thanks.
> --
> Oscar
>
> OpenPGP Key: DA9C60E9 ||
> https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
> 4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
> --
>
> El mié, 20 may 2026 a las 11:53, Johannes Berg
> (<johannes@sipsolutions.net>) escribió:
> >
> > On Wed, 2026-05-20 at 11:51 +0200, Óscar Alfonso Díaz wrote:
> > > Ok, let me do one final test using Johannes’ v2 patch. The expected
> > > behavior is as follows:
> > >
> > > 6.18 or lower: no need to test, it will not work. It’s clear now that
> > > this does not matter, since the goal is only to fix newer kernel
> > > versions.
> > >
> > > 6.19: some versions of the 6.19 will crash and others will not. The
> > > crash was fixed at some point between 6.18.12 and 6.19.12. No need to
> > > test.
> > >
> > > 7.0, or 7.1: the expected result is that there will be no crash, and
> > > VIF + deauth will work only on 2.4 GHz. It will not work on 5 GHz
> > > (I'll test both, normal DoS and VIF+DoS). There should be no crash,
> > > but it will not work.
> > >
> > > So I'll focus my testing on 7.0 and 7.1 and I'll get back to you with
> > > the results. I'll be testing this patch (v2):
> > > https://patchwork.kernel.org/project/linux-wireless/patch/20251216111909.25076-2-johannes@sipsolutions.net/
> > >
> >
> > Thanks. For testing that one you'd have to revert the other first, I
> > think, you could also just test this one:
> >
> > https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
> >
> > But I think they're basically all equivalent.
> >
> > Since we eventually need a patch to apply w/o reverting, Devin's is
> > probably better than my old one.
> >
> > johannes
^ permalink raw reply
* Re: [patch V2 04/25] pps: Convert to ktime_get_snapshot_id()
From: Thomas Gleixner @ 2026-06-02 9:31 UTC (permalink / raw)
To: Rodolfo Giometti, LKML
Cc: David Woodhouse, Miroslav Lichvar, John Stultz, Stephen Boyd,
Anna-Maria Behnsen, Frederic Weisbecker, thomas.weissschuh,
Arthur Kiyanovski, Vincent Donnefort, Marc Zyngier, Oliver Upton,
kvmarm, Oliver Upton, Richard Cochran, netdev, Takashi Iwai,
Miri Korenblit, Johannes Berg, Jacob Keller, Tony Nguyen,
Saeed Mahameed, Peter Hilber, Michael S. Tsirkin, virtualization,
linux-wireless, linux-sound, David Woodhouse, Vadim Fedorenko
In-Reply-To: <912a22e8-878f-4763-958b-71052ee69b36@enneenne.com>
On Sat, May 30 2026 at 13:08, Rodolfo Giometti wrote:
> On 29/05/2026 22:00, Thomas Gleixner wrote:
>> static inline void pps_get_ts(struct pps_event_time *ts)
>> {
>> +#ifdef CONFIG_NTP_PPS
>> struct system_time_snapshot snap;
>>
>> - ktime_get_snapshot(&snap);
>> - ts->ts_real = ktime_to_timespec64(snap.real);
>> -#ifdef CONFIG_NTP_PPS
>> - ts->ts_raw = ktime_to_timespec64(snap.raw);
>> + ktime_get_snapshot_id(CLOCK_REALTIME, &snap);
>> + ts->ts_real = ktime_to_timespec64(snap.systime);
>> + ts->ts_raw = ktime_to_timespec64(snap.monoraw);
>> +#else
>> + ktime_get_real_ts64(&ts->ts_real);
>
> /*
> * Prevent kernel stack information disclosure if the
> * structure is later copied to userspace.
> */
> ts->ts_raw = (struct timespec64){0, 0};
Which will fail to build because of:
struct pps_event_time {
#ifdef CONFIG_NTP_PPS
struct timespec64 ts_raw;
#endif /* CONFIG_NTP_PPS */
struct timespec64 ts_real;
};
No?
^ permalink raw reply
* Re: [PATCH] nfc: trf7970a: fix comment typos
From: David Heidelberg @ 2026-06-02 10:13 UTC (permalink / raw)
To: Miles Krause, Mark Greer; +Cc: linux-wireless, oe-linux-nfc, linux-kernel
In-Reply-To: <20260501003548.6838-1-mileskrause5200@gmail.com>
On 01/05/2026 02:35, Miles Krause wrote:
> Fix a few spelling mistakes in comments.
>
> Signed-off-by: Miles Krause <mileskrause5200@gmail.com>
> ---
> drivers/nfc/trf7970a.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Applied, thank you!
^ permalink raw reply
* Re: [patch V2 04/25] pps: Convert to ktime_get_snapshot_id()
From: David Woodhouse @ 2026-06-02 10:56 UTC (permalink / raw)
To: Thomas Gleixner, Rodolfo Giometti, LKML
Cc: Miroslav Lichvar, John Stultz, Stephen Boyd, Anna-Maria Behnsen,
Frederic Weisbecker, thomas.weissschuh, Arthur Kiyanovski,
Vincent Donnefort, Marc Zyngier, Oliver Upton, kvmarm,
Oliver Upton, Richard Cochran, netdev, Takashi Iwai,
Miri Korenblit, Johannes Berg, Jacob Keller, Tony Nguyen,
Saeed Mahameed, Peter Hilber, Michael S. Tsirkin, virtualization,
linux-wireless, linux-sound, Vadim Fedorenko
In-Reply-To: <877boh8f0j.ffs@fw13>
[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]
On Tue, 2026-06-02 at 11:31 +0200, Thomas Gleixner wrote:
> On Sat, May 30 2026 at 13:08, Rodolfo Giometti wrote:
> > On 29/05/2026 22:00, Thomas Gleixner wrote:
> > > static inline void pps_get_ts(struct pps_event_time *ts)
> > > {
> > > +#ifdef CONFIG_NTP_PPS
> > > struct system_time_snapshot snap;
> > >
> > > - ktime_get_snapshot(&snap);
> > > - ts->ts_real = ktime_to_timespec64(snap.real);
> > > -#ifdef CONFIG_NTP_PPS
> > > - ts->ts_raw = ktime_to_timespec64(snap.raw);
> > > + ktime_get_snapshot_id(CLOCK_REALTIME, &snap);
> > > + ts->ts_real = ktime_to_timespec64(snap.systime);
> > > + ts->ts_raw = ktime_to_timespec64(snap.monoraw);
> > > +#else
> > > + ktime_get_real_ts64(&ts->ts_real);
> >
> > /*
> > * Prevent kernel stack information disclosure if the
> > * structure is later copied to userspace.
> > */
> > ts->ts_raw = (struct timespec64){0, 0};
>
> Which will fail to build because of:
>
> struct pps_event_time {
> #ifdef CONFIG_NTP_PPS
> struct timespec64 ts_raw;
> #endif /* CONFIG_NTP_PPS */
> struct timespec64 ts_real;
> };
>
> No?
I think we should kill struct pps_event_time and just use a
system_time_snapshot anyway.
And I think we can make CONFIG_NTP_PPS work for NOHZ too. If I
understand correctly, the main problem with NOHZ is that without a
tick, the reported CLOCK_REALTIME sawtooths much more around the time
that the core timekeeping *wants* to report. That is, tk->ntp_error
goes much higher and much lower, than when the precise 'mult' rate can
be re-adjusted every tick to keep it on course.
If we add an ntp_error field to the system_time_snapshot, the PPS code
could use that to correct the CLOCK_REALTIME value and the jitter that
NOHZ introduces wouldn't matter.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/1] wifi: mac80211: validate minstrel tx status rates
From: Johannes Berg @ 2026-06-02 13:26 UTC (permalink / raw)
To: Ren Wei, linux-wireless
Cc: nbd, linville, yuantan098, zcliangcn, bird, xuyuqiabc
In-Reply-To: <20260529143446.1374404-1-n05ec@lzu.edu.cn>
On Fri, 2026-05-29 at 22:34 +0800, Ren Wei wrote:
> From: Yuqi Xu <xuyuqiabc@gmail.com>
>
> minstrel_ht_tx_status() accepts both legacy tx status entries and
> rate_info-based status entries, then turns the reported HT/VHT rate
> into a minstrel group and rate index.
>
> The validation helpers only checked that the entry was present and had
> tries recorded. They did not verify that the reported HT stream count,
> VHT NSS, VHT bandwidth encoding, and MCS value were representable by
> minstrel_ht's rate tables. As a result, malformed tx status metadata
> could produce group or rate indices outside the tables that
> minstrel_ht_get_stats() and minstrel_ht_ri_get_stats() index.
>
> Teach the existing tx status validation path to enforce the exact
> constraints used by minstrel HT's tables for both status formats.
> Reject HT rates beyond the supported stream groups, and reject VHT
> rates with unsupported bandwidth encodings, invalid NSS values, or
> MCS values outside the table.
>
> This keeps the fix at the existing trust boundary and leaves the
> stats lookup path unchanged.
So ... I'm not really very happy with this.
First of all, I think it's kind of overblown with the CC stable etc.,
can you actually find a situation where a driver reports such a thing?
Secondly, I don't think it's the right place to be checking, we use the
data a lot for other things in status handling, and might expand that,
so it seems that instead of having specific checks for minstrel, we
should have most of the checks in general (e.g. nss==0 is generally
invalid), and only have the things that matter for minstrel specifically
(say bandwidth) there - if those even matter, because surely we don't
expect a device that supports 80 MHz to start reporting 320 MHz, and if
that really seems important maybe we should just validate that elsewhere
as well.
But I also think that if this stuff really comes from firmware rather
than being built by the driver, it should be the driver's responsibility
to not report nonsense. I doubt we can protect against any driver
nonsense here in mac80211.
> Changes in v2:
> - shorten the subject line
> - align the From/Signed-off-by address
> - drop the Assisted-by tag
Why drop it now, when before you were saying it was?
johannes
^ permalink raw reply
* pull-request: ath-next-20260602
From: Jeff Johnson @ 2026-06-02 14:27 UTC (permalink / raw)
To: linux-wireless, Johannes Berg; +Cc: ath10k, ath11k, ath12k, jjohnson
The following changes since commit e7d6bd24e883bf7c328d73c99bf6bcde19bf5e61:
Merge tag 'wireless-next-2026-05-28' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next (2026-05-28 17:05:23 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git tags/ath-next-20260602
for you to fetch changes up to 565257a857690244211d85593b2cd490ce86783a:
wifi: ath12k: Handle 4-address EAPOL frames from WBM error path (2026-06-01 09:58:06 -0700)
----------------------------------------------------------------
ath.git patches for v7.2 (PR #3)
In ath12k, add driver support for WDS mode.
In ath11k and ath12k, a number of cleanups and minor bug fixes.
----------------------------------------------------------------
Aaradhana Sahu (1):
wifi: ath12k: add hardware parameters for maximum supported clients
Aditya Kumar Singh (1):
wifi: ath12k: Prevent incorrect vif chanctx switch when handling multi-radio contexts
Hangtian Zhu (1):
wifi: ath12k: allow peer_id 0 in dp peer lookup
Kwan Lai Chee Hou (1):
wifi: ath12k: fix incorrect HT/VHT/HE/EHT MCS reporting in monitor mode
Miaoqing Pan (3):
wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi
wifi: ath11k: add MSDU length validation for TKIP MIC error
wifi: ath12k: fix memory leak in ath12k_wifi7_dp_rx_h_verify_tkip_mic()
Rosen Penev (1):
wifi: ath11k: use kzalloc_flex for struct scan_req_params
Tamizh Chelvam Raja (6):
wifi: ath12k: Set WDS vdev parameter for 4-address station interface
wifi: ath12k: Add support for 4-address mode
wifi: ath12k: Add 4-address mode support for eth offload
wifi: ath12k: Add support for 4-address NULL frame handling
wifi: ath12k: Add support for 4-address frame notification
wifi: ath12k: Handle 4-address EAPOL frames from WBM error path
Wei Zhang (3):
wifi: ath11k: raise max vdevs to 4 on hardware with P2P and dual-station support
wifi: ath12k: fix inconsistent arvif state in vdev_create error paths
wifi: ath12k: fix NULL deref in change_sta_links for unready link
drivers/net/wireless/ath/ath11k/core.c | 10 +-
drivers/net/wireless/ath/ath11k/dp_rx.c | 59 +++++-
drivers/net/wireless/ath/ath11k/mac.c | 72 +++----
drivers/net/wireless/ath/ath11k/wmi.h | 2 +-
drivers/net/wireless/ath/ath12k/core.h | 9 +
drivers/net/wireless/ath/ath12k/dp_mon.c | 6 +-
drivers/net/wireless/ath/ath12k/dp_peer.c | 2 +-
drivers/net/wireless/ath/ath12k/dp_peer.h | 2 +
drivers/net/wireless/ath/ath12k/dp_rx.c | 13 +-
drivers/net/wireless/ath/ath12k/dp_rx.h | 3 +-
drivers/net/wireless/ath/ath12k/hal.h | 4 +-
drivers/net/wireless/ath/ath12k/hw.h | 25 ++-
drivers/net/wireless/ath/ath12k/mac.c | 228 ++++++++++++++++++---
drivers/net/wireless/ath/ath12k/mac.h | 3 +
drivers/net/wireless/ath/ath12k/peer.c | 11 +-
drivers/net/wireless/ath/ath12k/wifi7/dp_mon.c | 3 +-
drivers/net/wireless/ath/ath12k/wifi7/dp_rx.c | 95 ++++++++-
drivers/net/wireless/ath/ath12k/wifi7/dp_tx.c | 41 +++-
drivers/net/wireless/ath/ath12k/wifi7/dp_tx.h | 4 +-
.../net/wireless/ath/ath12k/wifi7/hal_qcc2072.c | 16 ++
.../net/wireless/ath/ath12k/wifi7/hal_qcn9274.c | 16 ++
drivers/net/wireless/ath/ath12k/wifi7/hal_tx.c | 4 +-
drivers/net/wireless/ath/ath12k/wifi7/hal_tx.h | 1 +
.../net/wireless/ath/ath12k/wifi7/hal_wcn7850.c | 16 ++
drivers/net/wireless/ath/ath12k/wifi7/hw.c | 48 ++++-
drivers/net/wireless/ath/ath12k/wmi.c | 47 ++++-
drivers/net/wireless/ath/ath12k/wmi.h | 17 ++
27 files changed, 642 insertions(+), 115 deletions(-)
^ permalink raw reply
* Re: [patch V2 16/25] virtio_rtc: Use provided clock ID for history snapshot
From: Peter Hilber @ 2026-06-02 14:44 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
thomas.weissschuh, Arthur Kiyanovski, Rodolfo Giometti,
Vincent Donnefort, Marc Zyngier, Oliver Upton, kvmarm,
Oliver Upton, Richard Cochran, netdev, Takashi Iwai,
Miri Korenblit, Johannes Berg, Jacob Keller, Tony Nguyen,
Saeed Mahameed, Michael S. Tsirkin, virtualization,
linux-wireless, linux-sound, David Woodhouse, Vadim Fedorenko
In-Reply-To: <20260529195557.744271454@kernel.org>
On Fri, May 29, 2026 at 10:00:52PM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner <tglx@kernel.org>
>
> The PTP core indicates in system_device_crosststamp::clock_id the clock ID
> for which the system time stamp should be taken. That allows to utilize
> hardware timestamps with e.g. AUX clocks.
>
> Use ktime_get_snapshot_id() and hand the provided clock ID in.
>
> No functional change.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Tested-by: Arthur Kiyanovski <akiyano@amazon.com>
> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
> ---
> drivers/virtio/virtio_rtc_ptp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> --- a/drivers/virtio/virtio_rtc_ptp.c
> +++ b/drivers/virtio/virtio_rtc_ptp.c
> @@ -139,7 +139,7 @@ static int viortc_ptp_getcrosststamp(str
> if (ret)
> return ret;
>
> - ktime_get_snapshot(&history_begin);
> + ktime_get_snapshot_id(xtstamp->clock_id, &history_begin);
> if (history_begin.cs_id != cs_id)
> return -EOPNOTSUPP;
>
>
^ permalink raw reply
* [PATCH 1/2] tracing: work around -Wmissing-format-attribute warning
From: Arnd Bergmann @ 2026-06-02 15:07 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Andrew Morton, Petr Mladek,
Nathan Chancellor
Cc: Arnd Bergmann, Dennis Dalessandro, Jason Gunthorpe,
Leon Romanovsky, Arend van Spriel, Miri Korenblit,
Mathieu Desnoyers, Andy Shevchenko, Rasmus Villemoes,
Sergey Senozhatsky, Nick Desaulniers, Bill Wendling, Justin Stitt,
Vlastimil Babka, linux-rdma, linux-kernel, linux-wireless,
brcm80211, brcm80211-dev-list.pdl, linux-trace-kernel, llvm
From: Arnd Bergmann <arnd@arndb.de>
A number of tracing headers turn off -Wsuggest-attribute=format for
gcc, but they don't turn it off for clang, so the same warning still
happens on new versions of clang that support the format attribute.
To avoid duplicating the same thing in each tracing header, as well
as changing all of them to also turn it off for clang, add a new
__vsnprintf() helper that is not annotated this way in linux/sprintf.h
but is defined to work the same way as the regular vsprintf.
Aside from tracing, the same thing can be used in va_format(),
which is part of lib/vsprintf.c itself.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
This version is a fairly simplistic way to work around the warning
reliably. I have resent two more patches to address actually
missing annotations in device drivers, but with all of these
out of the way, we can move the warning from the 'make W=1'
into the default set.
I have also prototyped a variant of this patch that passes down
a 'struct va_format' throughout the tracing code. That patch is
a little more invasive and I have no idea if that actually works,
but the result looks simpler.
---
drivers/infiniband/hw/hfi1/trace_dbg.h | 7 -------
.../broadcom/brcm80211/brcmfmac/tracepoint.h | 7 -------
.../brcm80211/brcmsmac/brcms_trace_brcmsmac_msg.h | 7 -------
drivers/net/wireless/intel/iwlwifi/iwl-devtrace.c | 3 ---
include/linux/sprintf.h | 1 +
include/linux/trace_events.h | 2 +-
include/trace/events/qla.h | 7 -------
include/trace/stages/stage6_event_callback.h | 2 +-
lib/vsprintf.c | 12 +++++++-----
samples/trace_events/trace-events-sample.c | 2 --
10 files changed, 10 insertions(+), 40 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/trace_dbg.h b/drivers/infiniband/hw/hfi1/trace_dbg.h
index 58304b91380f..05c4f1354269 100644
--- a/drivers/infiniband/hw/hfi1/trace_dbg.h
+++ b/drivers/infiniband/hw/hfi1/trace_dbg.h
@@ -22,11 +22,6 @@
#define MAX_MSG_LEN 512
-#pragma GCC diagnostic push
-#ifndef __clang__
-#pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
-#endif
-
DECLARE_EVENT_CLASS(hfi1_trace_template,
TP_PROTO(const char *function, struct va_format *vaf),
TP_ARGS(function, vaf),
@@ -41,8 +36,6 @@ DECLARE_EVENT_CLASS(hfi1_trace_template,
__get_str(msg))
);
-#pragma GCC diagnostic pop
-
/*
* It may be nice to macroize the __hfi1_trace but the va_* stuff requires an
* actual function to work and can not be in a macro.
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.h
index 96032322b165..6c4e00e9ccd1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.h
@@ -28,11 +28,6 @@ static inline void trace_ ## name(proto) {}
#define MAX_MSG_LEN 100
-#pragma GCC diagnostic push
-#ifndef __clang__
-#pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
-#endif
-
TRACE_EVENT(brcmf_err,
TP_PROTO(const char *func, struct va_format *vaf),
TP_ARGS(func, vaf),
@@ -128,8 +123,6 @@ TRACE_EVENT(brcmf_sdpcm_hdr,
__entry->len, ((u8 *)__get_dynamic_array(hdr))[4])
);
-#pragma GCC diagnostic pop
-
#ifdef CONFIG_BRCM_TRACING
#undef TRACE_INCLUDE_PATH
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/brcms_trace_brcmsmac_msg.h b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/brcms_trace_brcmsmac_msg.h
index 908ce3c864fe..dc296d8bf775 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/brcms_trace_brcmsmac_msg.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/brcms_trace_brcmsmac_msg.h
@@ -24,11 +24,6 @@
#define MAX_MSG_LEN 100
-#pragma GCC diagnostic push
-#ifndef __clang__
-#pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
-#endif
-
DECLARE_EVENT_CLASS(brcms_msg_event,
TP_PROTO(struct va_format *vaf),
TP_ARGS(vaf),
@@ -77,8 +72,6 @@ TRACE_EVENT(brcms_dbg,
TP_printk("%s: %s", __get_str(func), __get_str(msg))
);
-#pragma GCC diagnostic pop
-
#endif /* __TRACE_BRCMSMAC_MSG_H */
#ifdef CONFIG_BRCM_TRACING
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-devtrace.c b/drivers/net/wireless/intel/iwlwifi/iwl-devtrace.c
index 7e686297963d..49a8196430a7 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-devtrace.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-devtrace.c
@@ -12,9 +12,6 @@
#include "iwl-trans.h"
#define CREATE_TRACE_POINTS
-#ifdef CONFIG_CC_IS_GCC
-#pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
-#endif
#include "iwl-devtrace.h"
EXPORT_TRACEPOINT_SYMBOL(iwlwifi_dev_ucode_event);
diff --git a/include/linux/sprintf.h b/include/linux/sprintf.h
index f06f7b785091..036a247b7c1e 100644
--- a/include/linux/sprintf.h
+++ b/include/linux/sprintf.h
@@ -12,6 +12,7 @@ __printf(2, 3) int sprintf(char *buf, const char * fmt, ...);
__printf(2, 0) int vsprintf(char *buf, const char *, va_list);
__printf(3, 4) int snprintf(char *buf, size_t size, const char *fmt, ...);
__printf(3, 0) int vsnprintf(char *buf, size_t size, const char *fmt, va_list args);
+int __vsnprintf(char *buf, size_t size, const char *fmt, va_list args);
__printf(3, 4) int scnprintf(char *buf, size_t size, const char *fmt, ...);
__printf(3, 0) int vscnprintf(char *buf, size_t size, const char *fmt, va_list args);
__printf(2, 3) __malloc char *kasprintf(gfp_t gfp, const char *fmt, ...);
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index d49338c44014..4715330c7b6b 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -962,7 +962,7 @@ perf_trace_buf_submit(void *raw_data, int size, int rctx, u16 type,
int __ret; \
\
va_copy(__ap, *(va)); \
- __ret = vsnprintf(NULL, 0, fmt, __ap) + 1; \
+ __ret = __vsnprintf(NULL, 0, fmt, __ap) + 1; \
va_end(__ap); \
\
min(__ret, TRACE_EVENT_STR_MAX); \
diff --git a/include/trace/events/qla.h b/include/trace/events/qla.h
index 8800c35525a1..74a7534b99b6 100644
--- a/include/trace/events/qla.h
+++ b/include/trace/events/qla.h
@@ -9,11 +9,6 @@
#define QLA_MSG_MAX 256
-#pragma GCC diagnostic push
-#ifndef __clang__
-#pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
-#endif
-
DECLARE_EVENT_CLASS(qla_log_event,
TP_PROTO(const char *buf,
struct va_format *vaf),
@@ -32,8 +27,6 @@ DECLARE_EVENT_CLASS(qla_log_event,
TP_printk("%s %s", __get_str(buf), __get_str(msg))
);
-#pragma GCC diagnostic pop
-
DEFINE_EVENT(qla_log_event, ql_dbg_log,
TP_PROTO(const char *buf, struct va_format *vaf),
TP_ARGS(buf, vaf)
diff --git a/include/trace/stages/stage6_event_callback.h b/include/trace/stages/stage6_event_callback.h
index 1691676fd858..7d6a6ca6e779 100644
--- a/include/trace/stages/stage6_event_callback.h
+++ b/include/trace/stages/stage6_event_callback.h
@@ -45,7 +45,7 @@
do { \
va_list __cp_va; \
va_copy(__cp_va, *(va)); \
- vsnprintf(__get_str(dst), TRACE_EVENT_STR_MAX, fmt, __cp_va); \
+ __vsnprintf(__get_str(dst), TRACE_EVENT_STR_MAX, fmt, __cp_va); \
va_end(__cp_va); \
} while (0)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index a3017bc58986..3caf0796f54d 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1702,9 +1702,6 @@ char *escaped_string(char *buf, char *end, u8 *addr, struct printf_spec spec,
return buf;
}
-__diag_push();
-__diag_ignore(GCC, all, "-Wsuggest-attribute=format",
- "Not a valid __printf() conversion candidate.");
static char *va_format(char *buf, char *end, struct va_format *va_fmt,
struct printf_spec spec)
{
@@ -1714,12 +1711,11 @@ static char *va_format(char *buf, char *end, struct va_format *va_fmt,
return buf;
va_copy(va, *va_fmt->va);
- buf += vsnprintf(buf, end > buf ? end - buf : 0, va_fmt->fmt, va);
+ buf += __vsnprintf(buf, end > buf ? end - buf : 0, va_fmt->fmt, va);
va_end(va);
return buf;
}
-__diag_pop();
static noinline_for_stack
char *uuid_string(char *buf, char *end, const u8 *addr,
@@ -2979,6 +2975,12 @@ int vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
}
EXPORT_SYMBOL(vsnprintf);
+int __printf(3, 0) __vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
+{
+ return vsnprintf(buf, size, fmt_str, args);
+}
+EXPORT_SYMBOL(__vsnprintf);
+
/**
* vscnprintf - Format a string and place it in a buffer
* @buf: The buffer to place the result into
diff --git a/samples/trace_events/trace-events-sample.c b/samples/trace_events/trace-events-sample.c
index 9993fb5d5f98..ecc7db237f2e 100644
--- a/samples/trace_events/trace-events-sample.c
+++ b/samples/trace_events/trace-events-sample.c
@@ -9,8 +9,6 @@
* creates the handles for the trace points.
*/
#define CREATE_TRACE_POINTS
-__diag_ignore(GCC, all, "-Wsuggest-attribute=format",
- "trace_event_get_offsets_foo_bar can't easily be annotated as __printf");
#include "trace-events-sample.h"
static const char *random_strings[] = {
--
2.39.5
^ permalink raw reply related
* Re: [PATCH 1/2] tracing: work around -Wmissing-format-attribute warning
From: Steven Rostedt @ 2026-06-02 15:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Masami Hiramatsu, Andrew Morton, Petr Mladek, Nathan Chancellor,
Arnd Bergmann, Dennis Dalessandro, Jason Gunthorpe,
Leon Romanovsky, Arend van Spriel, Miri Korenblit,
Mathieu Desnoyers, Andy Shevchenko, Rasmus Villemoes,
Sergey Senozhatsky, Nick Desaulniers, Bill Wendling, Justin Stitt,
Vlastimil Babka, linux-rdma, linux-kernel, linux-wireless,
brcm80211, brcm80211-dev-list.pdl, linux-trace-kernel, llvm
In-Reply-To: <20260602150904.2258624-1-arnd@kernel.org>
On Tue, 2 Jun 2026 17:07:05 +0200
Arnd Bergmann <arnd@kernel.org> wrote:
> @@ -2979,6 +2975,12 @@ int vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
> }
> EXPORT_SYMBOL(vsnprintf);
>
Should add a comment here for why this is needed.
-- Steve
> +int __printf(3, 0) __vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
> +{
> + return vsnprintf(buf, size, fmt_str, args);
> +}
> +EXPORT_SYMBOL(__vsnprintf);
> +
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath9k: improve stability on AR9330/AR9340
From: Jeff Johnson @ 2026-06-02 15:44 UTC (permalink / raw)
To: Rosen Penev, linux-wireless; +Cc: Toke Høiland-Jørgensen, open list
In-Reply-To: <20260521232445.261915-1-rosenp@gmail.com>
On 5/21/2026 4:24 PM, Rosen Penev wrote:
> +static inline void ath9k_hw_disable_pll_lock_detect(struct ath_hw *ah)
> +{
> + /* On AR9330 and AR9340 devices, some PHY registers must be
note that networking code no longer has a different block comment style, so
please follow the common Linux block comment style and have /* on a line by itself
^ permalink raw reply
* [PATCH v6 0/3] PCI: Add d3cold and device-specific reset for Qualcomm devices
From: Jose Ignacio Tornos Martinez @ 2026-06-02 16:00 UTC (permalink / raw)
To: bhelgaas, alex
Cc: jjohnson, mani, linux-pci, linux-wireless, ath11k, ath12k, mhi,
linux-kernel, Jose Ignacio Tornos Martinez
Some PCIe devices lack working reset methods for VFIO passthrough scenarios.
These devices typically have no FLR, advertise NoSoftRst+ (blocking PM reset),
and have broken or unavailable bus reset. When a VM crashes, VFIO cannot reset
the device for reuse without a working reset method.
This series addresses the problem by adding general d3cold infrastructure and
device-specific reset for Qualcomm devices:
**Patch 1/3: d3cold reset method**
Adds D3cold as a general reset method with strict _PR3 requirement. Only
attempts true power cycling via platform control (ACPI _PR3), never falls
back to D3hot. This provides genuine power-off reset on platforms that
support it.
**Patch 2/3: device-specific reset for Qualcomm devices**
Adds device-specific reset entries for Qualcomm ath11k/ath12k WiFi and
SDX62/SDX65 modems using D3cold power cycling with automatic D3hot fallback.
Uses pci_set_power_state(D3cold) which automatically falls back to D3hot on
platforms without _PR3. Extracts shared pci_dev_d3cold_d0_cycle() helper to
avoid code duplication with general d3cold method. Device-specific reset is
position #1 in reset hierarchy, providing immediate working reset for these
Qualcomm devices.
**Patch 3/3: Qualcomm quirk_no_bus_reset**
Disables broken bus reset for Qualcomm devices. Testing proves this is
device-specific: MediaTek MT7925e works correctly with bus reset using the
same passive M.2-to-PCIe adapters where Qualcomm devices fail, confirming
PERST# is properly wired and the issue is not deployment-specific. Acts as
safety net to prevent broken SBR if users override via sysfs.
v6: - Patch 1/3 and 3/3 unchanged from v5
- For patch 2/3, fix double IOMMU handling for device-specific reset:
remove pci_dev_reset_iommu_prepare/done from pci_dev_d3cold_d0_cycle()
helper, keep in pci_d3cold_reset() caller
- Qualcomm maintainers CC'd
v5: https://lore.kernel.org/all/20260521130512.515125-1-jtornosm@redhat.com/
Jose Ignacio Tornos Martinez (3):
PCI: Add d3cold as general reset method
PCI: Add device-specific reset for Qualcomm devices
PCI: Disable broken bus reset on Qualcomm devices
--
2.53.0
^ permalink raw reply
* [PATCH v6 1/3] PCI: Add d3cold as general reset method
From: Jose Ignacio Tornos Martinez @ 2026-06-02 16:00 UTC (permalink / raw)
To: bhelgaas, alex
Cc: jjohnson, mani, linux-pci, linux-wireless, ath11k, ath12k, mhi,
linux-kernel, Jose Ignacio Tornos Martinez
In-Reply-To: <20260602160024.1171949-1-jtornosm@redhat.com>
Add D3cold power cycle as a general PCI reset method for single-function
devices on platforms with ACPI _PR3 power resources. This provides true
power cycle reset capability when the platform can physically cut power
to the device.
The implementation strictly requires _PR3 to be present - the platform
must be able to control device power. This ensures d3cold only attempts
true power cycling, not falling back to D3hot transitions.
D3cold reset is placed at the end of the reset hierarchy since it requires
specific platform support and should be tried after standard methods.
Reset hierarchy with this change:
1. device_specific
2. acpi
3. flr
4. af_flr
5. pm (D3hot via config space, checks NoSoftRst)
6. bus (SBR)
7. cxl_bus
8. d3cold (NEW - true power cycle, requires _PR3)
This benefits:
- Platforms with _PR3 support
- Single-function devices needing true power cycle
- VFIO passthrough scenarios where FLR/PM unavailable
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v6: code unchanged from v5
v5: https://lore.kernel.org/all/20260521130512.515125-2-jtornosm@redhat.com/
drivers/pci/pci.c | 50 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/pci.h | 2 +-
2 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8f7cfcc00090..096868f80cd4 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4491,6 +4491,55 @@ static int pci_pm_reset(struct pci_dev *dev, bool probe)
return ret;
}
+/**
+ * pci_d3cold_reset - Put device into D3cold and back to D0 for reset
+ * @dev: PCI device to reset
+ * @probe: if true, check if D3cold reset is supported; if false, perform reset
+ *
+ * Reset the device by transitioning through D3cold (actual power removal via
+ * platform power control) and back to D0. This requires ACPI _PR3 power
+ * resources to be present - the platform must be able to physically cut power
+ * to the device.
+ *
+ * Only available for single-function devices to avoid affecting other
+ * functions in multi-function devices.
+ *
+ * Returns 0 if device can be/was reset this way, -ENOTTY if not supported,
+ * or other negative error code on failure.
+ */
+static int pci_d3cold_reset(struct pci_dev *dev, bool probe)
+{
+ int ret;
+
+ if (dev->multifunction)
+ return -ENOTTY;
+
+ if (!pci_pr3_present(dev))
+ return -ENOTTY;
+
+ if (probe)
+ return 0;
+
+ if (dev->current_state != PCI_D0)
+ return -EINVAL;
+
+ ret = pci_dev_reset_iommu_prepare(dev);
+ if (ret) {
+ pci_err(dev, "failed to stop IOMMU for a PCI reset: %d\n", ret);
+ return ret;
+ }
+
+ ret = pci_set_power_state(dev, PCI_D3cold);
+ if (ret)
+ goto done;
+
+ ret = pci_set_power_state(dev, PCI_D0);
+
+done:
+ pci_dev_reset_iommu_done(dev);
+ return ret;
+}
+
/**
* pcie_wait_for_link_status - Wait for link status change
* @pdev: Device whose link to wait for.
@@ -5065,6 +5114,7 @@ const struct pci_reset_fn_method pci_reset_fn_methods[] = {
{ pci_pm_reset, .name = "pm" },
{ pci_reset_bus_function, .name = "bus" },
{ cxl_reset_bus_function, .name = "cxl_bus" },
+ { pci_d3cold_reset, .name = "d3cold" },
};
/**
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2c4454583c11..1ca7b880ead7 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -51,7 +51,7 @@
PCI_STATUS_PARITY)
/* Number of reset methods used in pci_reset_fn_methods array in pci.c */
-#define PCI_NUM_RESET_METHODS 8
+#define PCI_NUM_RESET_METHODS 9
#define PCI_RESET_PROBE true
#define PCI_RESET_DO_RESET false
--
2.54.0
^ permalink raw reply related
* [PATCH v6 2/3] PCI: Add device-specific reset for Qualcomm devices
From: Jose Ignacio Tornos Martinez @ 2026-06-02 16:00 UTC (permalink / raw)
To: bhelgaas, alex
Cc: jjohnson, mani, linux-pci, linux-wireless, ath11k, ath12k, mhi,
linux-kernel, Jose Ignacio Tornos Martinez
In-Reply-To: <20260602160024.1171949-1-jtornosm@redhat.com>
Some Qualcomm PCIe devices (ath11k WiFi, ath12k WiFi, SDX62/SDX65 modems)
lack working reset methods for VFIO passthrough scenarios. These devices
have no FLR capability, advertise NoSoftRst+ (blocking PM reset), and have
broken bus reset.
The problem manifests in VFIO passthrough scenarios:
- ath11k WiFi (17cb:1103): Normal VM operation works fine, including
clean shutdown/reboot. However, when the VM terminates uncleanly
(crash, force-off), VFIO attempts to reset the device before it can
be assigned to another VM. Without a working reset method, the device
remains in an undefined state, preventing reuse.
- ath12k WiFi (17cb:1107): Same behavior as ath11k.
- SDX62/SDX65 5G modems (17cb:0308): Never successfully initialize even
on first VM assignment without proper reset capability.
Add device-specific reset entries for these Qualcomm devices using D3cold
power cycling with automatic D3hot fallback. The implementation uses
pci_set_power_state(D3cold) which automatically falls back to D3hot on
platforms without ACPI _PR3 power resources. While not a complete reset
(BARs preserved), testing shows D3hot transition provides sufficient reset
for VFIO reuse.
Extract a shared pci_dev_d3cold_d0_cycle() helper function to avoid code
duplication between pci_d3cold_reset() (strict _PR3 requirement) and the
new reset_d3cold_d3hot() device-specific reset (automaticfallback). The
helper handles IOMMU preparation, performs the power cycle via
pci_set_power_state(), and cleans up IOMMU state.
Device-specific reset is position #1 in the reset hierarchy, so these
Qualcomm devices will use power cycling as their primary reset method,
with the general d3cold method (position #8) available as a fallback on
_PR3-capable platforms if users override via sysfs.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v6: Fix double IOMMU handling for device-specific reset: remove
pci_dev_reset_iommu_prepare/done from pci_dev_d3cold_d0_cycle() helper,
keep in pci_d3cold_reset() caller
v5: https://lore.kernel.org/all/20260521130512.515125-3-jtornosm@redhat.com/
drivers/pci/pci.c | 37 +++++++++++++++++++++++++++----------
drivers/pci/pci.h | 1 +
drivers/pci/quirks.c | 19 +++++++++++++++++++
3 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 096868f80cd4..f7a7443287fd 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4491,6 +4491,32 @@ static int pci_pm_reset(struct pci_dev *dev, bool probe)
return ret;
}
+/**
+ * pci_dev_d3cold_d0_cycle - Perform D3cold->D0 power cycle
+ * @dev: Device to power cycle
+ *
+ * Common helper to perform D3cold->D0 power cycle for reset methods.
+ * Attempts D3cold transition with automatic fallback to D3hot on platforms
+ * without ACPI _PR3 power resources.
+ *
+ * Caller must handle IOMMU preparation/cleanup if needed.
+ *
+ * Returns 0 on success, negative error code on failure.
+ */
+int pci_dev_d3cold_d0_cycle(struct pci_dev *dev)
+{
+ int ret;
+
+ if (dev->current_state != PCI_D0)
+ return -EINVAL;
+
+ ret = pci_set_power_state(dev, PCI_D3cold);
+ if (ret)
+ return ret;
+
+ return pci_set_power_state(dev, PCI_D0);
+}
+
/**
* pci_d3cold_reset - Put device into D3cold and back to D0 for reset
* @dev: PCI device to reset
@@ -4520,22 +4546,13 @@ static int pci_d3cold_reset(struct pci_dev *dev, bool probe)
if (probe)
return 0;
- if (dev->current_state != PCI_D0)
- return -EINVAL;
-
ret = pci_dev_reset_iommu_prepare(dev);
if (ret) {
pci_err(dev, "failed to stop IOMMU for a PCI reset: %d\n", ret);
return ret;
}
- ret = pci_set_power_state(dev, PCI_D3cold);
- if (ret)
- goto done;
-
- ret = pci_set_power_state(dev, PCI_D0);
-
-done:
+ ret = pci_dev_d3cold_d0_cycle(dev);
pci_dev_reset_iommu_done(dev);
return ret;
}
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 4a14f88e543a..a9942787de9e 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -234,6 +234,7 @@ void pci_init_reset_methods(struct pci_dev *dev);
int pci_bridge_secondary_bus_reset(struct pci_dev *dev);
int pci_bus_error_reset(struct pci_dev *dev);
int pci_try_reset_bridge(struct pci_dev *bridge);
+int pci_dev_d3cold_d0_cycle(struct pci_dev *dev);
struct pci_cap_saved_data {
u16 cap_nr;
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index e49136ac5dbf..70f3b0f26799 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4237,6 +4237,22 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
return 0;
}
+/*
+ * Device-specific reset method via D3cold/D3hot power cycle.
+ *
+ * Some devices lack working FLR, advertise NoSoftRst+ (blocking PM reset),
+ * and have broken bus reset. This function provides device-specific reset via
+ * power cycling, attempting D3cold with automatic fallback to D3hot on platforms
+ * without ACPI _PR3 power resources.
+ */
+static int reset_d3cold_d3hot(struct pci_dev *dev, bool probe)
+{
+ if (probe)
+ return 0;
+
+ return pci_dev_d3cold_d0_cycle(dev);
+}
+
static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
reset_intel_82599_sfp_virtfn },
@@ -4252,6 +4268,9 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
reset_chelsio_generic_dev },
{ PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF,
reset_hinic_vf_dev },
+ { PCI_VENDOR_ID_QCOM, 0x1103, reset_d3cold_d3hot }, /* ath11k */
+ { PCI_VENDOR_ID_QCOM, 0x1107, reset_d3cold_d3hot }, /* ath12k */
+ { PCI_VENDOR_ID_QCOM, 0x0308, reset_d3cold_d3hot }, /* SDX62/SDX65 */
{ 0 }
};
--
2.54.0
^ permalink raw reply related
* [PATCH v6 3/3] PCI: Disable broken bus reset on Qualcomm devices
From: Jose Ignacio Tornos Martinez @ 2026-06-02 16:00 UTC (permalink / raw)
To: bhelgaas, alex
Cc: jjohnson, mani, linux-pci, linux-wireless, ath11k, ath12k, mhi,
linux-kernel, Jose Ignacio Tornos Martinez
In-Reply-To: <20260602160024.1171949-1-jtornosm@redhat.com>
Some Qualcomm PCIe devices (ath11k WiFi, ath12k WiFi, SDX62/SDX65 modems)
do not properly support Secondary Bus Reset (SBR).
Testing confirms this is device-specific, not deployment-specific:
MediaTek MT7925e successfully uses bus reset through the same passive
M.2-to-PCIe adapters where Qualcomm devices fail, proving PERST# is
properly wired through the adapters.
This quirk acts as a safety net, preventing the broken bus reset from being
attempted if users override reset methods (device_specific or d3cold when
available) via sysfs.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v6: code unchanged from v5
v5: https://lore.kernel.org/all/20260521130512.515125-4-jtornosm@redhat.com/
drivers/pci/quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 000000000000..111111111111 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3789,6 +3789,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0030, quirk_no_bus_reset);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0032, quirk_no_bus_reset);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x003c, quirk_no_bus_reset);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0033, quirk_no_bus_reset);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0034, quirk_no_bus_reset);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x003e, quirk_no_bus_reset);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_QCOM, 0x1103, quirk_no_bus_reset); /* ath11k */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_QCOM, 0x1107, quirk_no_bus_reset); /* ath12k */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_QCOM, 0x0308, quirk_no_bus_reset); /* SDX62/SDX65 */
/*
* Root port on some Cavium CN8xxx chips do not successfully complete a bus
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v6 2/3] PCI: Add device-specific reset for Qualcomm devices
From: Jeff Johnson @ 2026-06-02 17:10 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, bhelgaas, alex
Cc: jjohnson, mani, linux-pci, linux-wireless, ath11k, ath12k, mhi,
linux-kernel
In-Reply-To: <20260602160024.1171949-3-jtornosm@redhat.com>
On 6/2/2026 9:00 AM, Jose Ignacio Tornos Martinez wrote:
> Some Qualcomm PCIe devices (ath11k WiFi, ath12k WiFi, SDX62/SDX65 modems)
Throughout your series you refer to ath11k and ath12k as if they are devices.
They are not. They are device drivers, each of which supports a large number
of devices.
> lack working reset methods for VFIO passthrough scenarios. These devices
> have no FLR capability, advertise NoSoftRst+ (blocking PM reset), and have
> broken bus reset.
>
> The problem manifests in VFIO passthrough scenarios:
>
> - ath11k WiFi (17cb:1103): Normal VM operation works fine, including
17cb:1103 is WCN6855
> clean shutdown/reboot. However, when the VM terminates uncleanly
> (crash, force-off), VFIO attempts to reset the device before it can
> be assigned to another VM. Without a working reset method, the device
> remains in an undefined state, preventing reuse.
>
> - ath12k WiFi (17cb:1107): Same behavior as ath11k.
17cb:1107 is WCN7850
>
> - SDX62/SDX65 5G modems (17cb:0308): Never successfully initialize even
> on first VM assignment without proper reset capability.
...
> @@ -4252,6 +4268,9 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
> reset_chelsio_generic_dev },
> { PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF,
> reset_hinic_vf_dev },
> + { PCI_VENDOR_ID_QCOM, 0x1103, reset_d3cold_d3hot }, /* ath11k */
s/ath11k/WCN6855/
> + { PCI_VENDOR_ID_QCOM, 0x1107, reset_d3cold_d3hot }, /* ath12k */
s/ath12k/WCN7850/
> + { PCI_VENDOR_ID_QCOM, 0x0308, reset_d3cold_d3hot }, /* SDX62/SDX65 */
> { 0 }
> };
>
same guidance applies to the 3/3 patch
/jeff
^ permalink raw reply
* Re: [patch V2 21/25] ALSA: hda/common: Use system_device_crosststamp::sys_systime
From: Takashi Iwai @ 2026-06-02 17:46 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
thomas.weissschuh, Arthur Kiyanovski, Rodolfo Giometti,
Vincent Donnefort, Marc Zyngier, Oliver Upton, kvmarm,
Oliver Upton, Richard Cochran, netdev, Takashi Iwai,
Miri Korenblit, Johannes Berg, Jacob Keller, Tony Nguyen,
Saeed Mahameed, Peter Hilber, Michael S. Tsirkin, virtualization,
linux-wireless, linux-sound, David Woodhouse, Vadim Fedorenko
In-Reply-To: <20260529195557.995298795@kernel.org>
On Fri, 29 May 2026 22:01:13 +0200,
Thomas Gleixner wrote:
>
> From: Thomas Gleixner <tglx@kernel.org>
>
> sys_systime is an alias for sys_realtime. The latter will be removed so
> switch the code over to the new naming scheme.
>
> No functional change.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Tested-by: Arthur Kiyanovski <akiyano@amazon.com>
> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
thanks,
Takashi
> ---
> sound/hda/common/controller.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> --- a/sound/hda/common/controller.c
> +++ b/sound/hda/common/controller.c
> @@ -525,7 +525,7 @@ static int azx_get_time_info(struct snd_
> break;
>
> default:
> - *system_ts = ktime_to_timespec64(xtstamp.sys_realtime);
> + *system_ts = ktime_to_timespec64(xtstamp.sys_systime);
> break;
>
> }
>
>
>
^ permalink raw reply
* Re: [PATCH 1/2] tracing: work around -Wmissing-format-attribute warning
From: Andy Shevchenko @ 2026-06-02 18:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Steven Rostedt, Masami Hiramatsu, Andrew Morton, Petr Mladek,
Nathan Chancellor, Arnd Bergmann, Dennis Dalessandro,
Jason Gunthorpe, Leon Romanovsky, Arend van Spriel,
Miri Korenblit, Mathieu Desnoyers, Rasmus Villemoes,
Sergey Senozhatsky, Nick Desaulniers, Bill Wendling, Justin Stitt,
Vlastimil Babka, linux-rdma, linux-kernel, linux-wireless,
brcm80211, brcm80211-dev-list.pdl, linux-trace-kernel, llvm
In-Reply-To: <20260602150904.2258624-1-arnd@kernel.org>
On Tue, Jun 02, 2026 at 05:07:05PM +0200, Arnd Bergmann wrote:
>
> A number of tracing headers turn off -Wsuggest-attribute=format for
> gcc, but they don't turn it off for clang, so the same warning still
> happens on new versions of clang that support the format attribute.
>
> To avoid duplicating the same thing in each tracing header, as well
> as changing all of them to also turn it off for clang, add a new
> __vsnprintf() helper that is not annotated this way in linux/sprintf.h
> but is defined to work the same way as the regular vsprintf.
vsprintf()
> Aside from tracing, the same thing can be used in va_format(),
> which is part of lib/vsprintf.c itself.
...
> --- a/include/linux/sprintf.h
> +++ b/include/linux/sprintf.h
> @@ -12,6 +12,7 @@ __printf(2, 3) int sprintf(char *buf, const char * fmt, ...);
> __printf(2, 0) int vsprintf(char *buf, const char *, va_list);
> __printf(3, 4) int snprintf(char *buf, size_t size, const char *fmt, ...);
> __printf(3, 0) int vsnprintf(char *buf, size_t size, const char *fmt, va_list args);
> +int __vsnprintf(char *buf, size_t size, const char *fmt, va_list args);
Why the __printf() annotation is in the C file and not here?
Is this all about headers as the second paragraph in the commit message explains?
I would add a comment to explain it here, otherwise we might see false patches to
"make things consistent" in a wrong way.
> __printf(3, 4) int scnprintf(char *buf, size_t size, const char *fmt, ...);
> __printf(3, 0) int vscnprintf(char *buf, size_t size, const char *fmt, va_list args);
> __printf(2, 3) __malloc char *kasprintf(gfp_t gfp, const char *fmt, ...);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb()
From: Dylan Eskew @ 2026-06-02 18:58 UTC (permalink / raw)
To: Lorenzo Bianconi, Felix Fietkau, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-wireless, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260531-mt7996_tx_prepare_skb-token-leack-v1-1-2b9c9f59ceb1@kernel.org>
Hi Lore,
We have been seeing the token memory leak in our custom kernel. After
pulling your patch in, we are still getting the leak (validated with
kmemleak). How did you figure out where this potential leak was? I want
to determine if we are leaking because of our changes or if there's more
areas for token leakage.
-- Dylan
On 5/31/26 2:10 AM, Lorenzo Bianconi wrote:
> If link_conf or link_sta lookup fails in mt7996_tx_prepare_skb routine,
> mt7996 driver leaks an already allocated tx token. Fix the issue
> releasing the token in case of error.
>
> Fixes: 7ef0c7ad735b0 ("wifi: mt76: mt7996: Implement MLD address translation for EAPOL")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/wireless/mediatek/mt76/mt7996/mac.c | 8 ++++++--
> drivers/net/wireless/mediatek/mt76/tx.c | 2 +-
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
> index c98446057282..8c56344d211b 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
> @@ -1067,11 +1067,11 @@ int mt7996_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
>
> link_conf = rcu_dereference(vif->link_conf[wcid->link_id]);
> if (!link_conf)
> - return -EINVAL;
> + goto error_relase_token;
>
> link_sta = rcu_dereference(sta->link[wcid->link_id]);
> if (!link_sta)
> - return -EINVAL;
> + goto error_relase_token;
>
> dma_sync_single_for_cpu(mdev->dma_dev, tx_info->buf[1].addr,
> tx_info->buf[1].len, DMA_TO_DEVICE);
> @@ -1176,6 +1176,10 @@ int mt7996_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
> tx_info->nbuf = MT_CT_DMA_BUF_NUM;
>
> return 0;
> +
> +error_relase_token:
> + mt76_token_release(mdev, id, NULL);
> + return -EINVAL;
> }
>
> u32 mt7996_wed_init_buf(void *ptr, dma_addr_t phys, int token_id)
> diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
> index 22f9690634c9..f96d9c471853 100644
> --- a/drivers/net/wireless/mediatek/mt76/tx.c
> +++ b/drivers/net/wireless/mediatek/mt76/tx.c
> @@ -933,7 +933,7 @@ mt76_token_release(struct mt76_dev *dev, int token, bool *wake)
> #endif
> }
>
> - if (dev->token_count < dev->token_size - MT76_TOKEN_FREE_THR &&
> + if (wake && dev->token_count < dev->token_size - MT76_TOKEN_FREE_THR &&
> dev->phy.q_tx[0]->blocked)
> *wake = true;
>
>
> ---
> base-commit: 4913f44167cf35a9536e9eec7352e15b2de0c573
> change-id: 20260531-mt7996_tx_prepare_skb-token-leack-82e240d8c66f
>
> Best regards,
^ permalink raw reply
* [syzbot] Monthly wireless report (Jun 2026)
From: syzbot @ 2026-06-02 20:32 UTC (permalink / raw)
To: linux-kernel, linux-wireless, netdev, syzkaller-bugs
Hello wireless maintainers/developers,
This is a 31-day syzbot report for the wireless subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/wireless
During the period, 1 new issues were detected and 1 were fixed.
In total, 31 issues are still open and 176 have already been fixed.
There are also 17 low-priority issues.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 6959 Yes WARNING in __cfg80211_ibss_joined (2)
https://syzkaller.appspot.com/bug?extid=7f064ba1704c2466e36d
<2> 1127 Yes INFO: task hung in reg_process_self_managed_hints
https://syzkaller.appspot.com/bug?extid=1f16507d9ec05f64210a
<3> 628 Yes INFO: task hung in crda_timeout_work (8)
https://syzkaller.appspot.com/bug?extid=d41f74db64598e0b5016
<4> 316 Yes INFO: task hung in ath9k_hif_usb_firmware_cb (3)
https://syzkaller.appspot.com/bug?extid=e9b1ff41aa6a7ebf9640
<5> 48 No WARNING in cfg80211_switch_netns
https://syzkaller.appspot.com/bug?extid=3515319a302224e081b4
<6> 39 Yes WARNING: ODEBUG bug in ieee80211_led_exit (2)
https://syzkaller.appspot.com/bug?extid=e84ecca6d1fa09a9b3d9
<7> 38 Yes KASAN: stack-out-of-bounds Write in carl9170_handle_command_response
https://syzkaller.appspot.com/bug?extid=5c1ca6ccaa1215781cac
<8> 34 Yes INFO: task hung in nl80211_pre_doit (3)
https://syzkaller.appspot.com/bug?extid=da14e8c0ada830335981
<9> 19 Yes WARNING in __cfg80211_bss_update (2)
https://syzkaller.appspot.com/bug?extid=1a797e1c81be78a2ace7
<10> 954 Yes INFO: task hung in reg_check_chans_work (7)
https://syzkaller.appspot.com/bug?extid=a2de4763f84f61499210
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* Re: [PATCH 1/2] tracing: work around -Wmissing-format-attribute warning
From: Arnd Bergmann @ 2026-06-02 20:32 UTC (permalink / raw)
To: Andy Shevchenko, Arnd Bergmann
Cc: Steven Rostedt, Masami Hiramatsu, Andrew Morton, Petr Mladek,
Nathan Chancellor, Dennis Dalessandro, Jason Gunthorpe,
Leon Romanovsky, Arend van Spriel, Miri Korenblit,
Mathieu Desnoyers, Rasmus Villemoes, Sergey Senozhatsky,
Nick Desaulniers, Bill Wendling, Justin Stitt,
Vlastimil Babka (SUSE), linux-rdma, linux-kernel, linux-wireless,
brcm80211, brcm80211-dev-list.pdl, linux-trace-kernel, llvm
In-Reply-To: <ah8n-Nk305S5hRwN@ashevche-desk.local>
On Tue, Jun 2, 2026, at 20:59, Andy Shevchenko wrote:
> On Tue, Jun 02, 2026 at 05:07:05PM +0200, Arnd Bergmann wrote:
>>
>> A number of tracing headers turn off -Wsuggest-attribute=format for
>> gcc, but they don't turn it off for clang, so the same warning still
>> happens on new versions of clang that support the format attribute.
>>
>> To avoid duplicating the same thing in each tracing header, as well
>> as changing all of them to also turn it off for clang, add a new
>> __vsnprintf() helper that is not annotated this way in linux/sprintf.h
>> but is defined to work the same way as the regular vsprintf.
>
> vsprintf()
Fixed now
> Why the __printf() annotation is in the C file and not here?
> Is this all about headers as the second paragraph in the commit message
> explains?
> I would add a comment to explain it here, otherwise we might see false
> patches to "make things consistent" in a wrong way.
I've tried to come up with a kerneldoc comment now, similar to
the one for the vsnprintf() function, and added a separate prototype
in the header. Does this address your concern?
Arnd
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 3caf0796f54d..7c696aea2ed3 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -2975,7 +2975,23 @@ int vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
}
EXPORT_SYMBOL(vsnprintf);
-int __printf(3, 0) __vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
+/**
+ * __vsnprintf - vsnprintf() wrapper without __printf() attribute
+ * @buf: The buffer to place the result into
+ * @size: The size of the buffer, including the trailing null space
+ * @fmt_str: The format string to use
+ * @args: Arguments for the format string
+ *
+ * This has the exact same behavior as vsnprintf() but can be used in call
+ * sites that are missing a __printf() annotation, e.g. because they
+ * get a 'va_format' argument instead of format and varargs.
+ *
+ * For this to work, the attribute is added to the declaration here but
+ * not in the header.
+ */
+int __printf(3, 0) __vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args);
+
+int __vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
{
return vsnprintf(buf, size, fmt_str, args);
}
^ permalink raw reply related
* Re: [PATCH 1/2] tracing: work around -Wmissing-format-attribute warning
From: Andy Shevchenko @ 2026-06-02 21:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Steven Rostedt, Masami Hiramatsu, Andrew Morton,
Petr Mladek, Nathan Chancellor, Dennis Dalessandro,
Jason Gunthorpe, Leon Romanovsky, Arend van Spriel,
Miri Korenblit, Mathieu Desnoyers, Rasmus Villemoes,
Sergey Senozhatsky, Nick Desaulniers, Bill Wendling, Justin Stitt,
Vlastimil Babka (SUSE), linux-rdma, linux-kernel, linux-wireless,
brcm80211, brcm80211-dev-list.pdl, linux-trace-kernel, llvm
In-Reply-To: <35c1ba62-e74d-4abc-aa73-ccd35968ff89@app.fastmail.com>
On Tue, Jun 02, 2026 at 10:32:04PM +0200, Arnd Bergmann wrote:
> On Tue, Jun 2, 2026, at 20:59, Andy Shevchenko wrote:
> > On Tue, Jun 02, 2026 at 05:07:05PM +0200, Arnd Bergmann wrote:
...
> > Why the __printf() annotation is in the C file and not here?
> > Is this all about headers as the second paragraph in the commit message
> > explains?
> > I would add a comment to explain it here, otherwise we might see false
> > patches to "make things consistent" in a wrong way.
>
> I've tried to come up with a kerneldoc comment now, similar to
> the one for the vsnprintf() function, and added a separate prototype
> in the header. Does this address your concern?
Yes, see one nit, though.
> -int __printf(3, 0) __vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
> +/**
> + * __vsnprintf - vsnprintf() wrapper without __printf() attribute
> + * @buf: The buffer to place the result into
> + * @size: The size of the buffer, including the trailing null space
> + * @fmt_str: The format string to use
> + * @args: Arguments for the format string
> + *
> + * This has the exact same behavior as vsnprintf() but can be used in call
> + * sites that are missing a __printf() annotation, e.g. because they
> + * get a 'va_format' argument instead of format and varargs.
> + *
> + * For this to work, the attribute is added to the declaration here but
> + * not in the header.
+ *
+ * Return: ...
> + */
> +int __printf(3, 0) __vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args);
> +
> +int __vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
Something slipped here...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: bus: add brcm,bcm6362-wlan
From: Alessio Ferri @ 2026-06-02 22:18 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rafał Miłecki, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Florian Fainelli, linux-kernel,
linux-wireless, devicetree
In-Reply-To: <20260530-psychedelic-cyber-seagull-140adf@quoll>
Il 30/05/2026 13:50, Krzysztof Kozlowski ha scritto:
> On Fri, May 29, 2026 at 02:06:01AM +0200, Alessio Ferri wrote:
>> Document the binding for the SHIM bridge that gates the on-chip
>> 2.4 GHz WLAN block of the Broadcom BCM6362 SoC. The bridge owns the
>> SHIM peephole, a single clock for the macro, and two resets (the
>> SHIM macro itself and its ubus side). It is also a bus: it carries
>> one brcm,bus-axi child describing the bcma backplane behind the
>> SHIM, with a standard interrupt-map routing the d11 core's IRQ to
>> the SoC interrupt controller.
>>
>> Assisted-by: Claude:claude-4.8-opus
>> Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it>
>> ---
>> .../devicetree/bindings/bus/brcm,bcm6362-wlan.yaml | 106 +++++++++++++++++++++
>> 1 file changed, 106 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/bus/brcm,bcm6362-wlan.yaml b/Documentation/devicetree/bindings/bus/brcm,bcm6362-wlan.yaml
>> new file mode 100644
>> index 000000000000..c8d49ccdd2c1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/bus/brcm,bcm6362-wlan.yaml
>> @@ -0,0 +1,106 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/bus/brcm,bcm6362-wlan.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Broadcom BCM6362 on-chip WLAN SHIM bridge
>> +
>> +maintainers:
>> + - Alessio Ferri <alessio.ferri@mythread.it>
>> +
>> +description: |
>> + The BCM6362 SoC integrates a 2.4 GHz Broadcom WLAN block whose
>> + register backplane uses the Broadcom AMBA (bcma) architecture. The
>> + backplane is gated by a small SHIM bridge that holds the WLAN macro
>> + in reset and disables its clocks until released by software. CFE
>> + does not release this block, so software bring-up is required
>> + before bcma can enumerate the backplane.
>> +
>> + This binding describes the SHIM bridge node. The SHIM driver brings
>
> Do not describe binding. Do not describe driver.
> Describe hardware.
>
>> + the macro up and then populates the brcm,bus-axi child node, which
>> + describes the bcma backplane behind the SHIM and is bound by the
>> + bcma-host-soc driver. The SoC-specific configuration (big-endian
>> + accessors, SHIM-attached topology, SHIM Control register peephole
>> + pointer) is delivered to bcma via platform_data injected at
>> + populate time, so the brcm,bus-axi child stays SoC-agnostic.
>
> How is it relevant?
>
>> +
>> +properties:
>> + compatible:
>> + const: brcm,bcm6362-wlan
>> +
>> + reg:
>> + maxItems: 1
>> + description: SHIM peephole registers.
>
> What is SHIM?
>
>> +
>> + reg-names:
>> + items:
>> + - const: shim
>> +
>> + clocks:
>> + maxItems: 1
>> +
>> + resets:
>> + items:
>> + - description: SHIM macro reset
>> + - description: SHIM ubus reset
>> +
>> + reset-names:
>> + items:
>> + - const: shim
>> + - const: shim-ubus
>> +
>> + '#address-cells':
>> + const: 1
>> +
>> + '#size-cells':
>> + const: 1
>> +
>> + ranges: true
>> +
>> +patternProperties:
>> + "^axi@[0-9a-f]+$":
>
> Use consistent quotes.
>
>> + type: object
>> + description: The bcma AXI backplane behind the SHIM.
>> + $ref: /schemas/types.yaml#
>
> Need proper ref. You could easily check instead of sending Claude slop -
> is there any binding with above syntax?
>
> You don't get subnodes for buses for devices not being the actual
> buses.
>
> Best regards,
> Krzysztof
>
Sorry for letting AI-slop pass through in this patch and excessive
descriptions.
SHIM is just the control block for the integrated wlan. Copied verbatim
from the original broadcom 96362 code.
For the last sentence, how should i map it? At the very least I need to
tell bcma that this is big-endian before it touches anything, otherwise
it will read/write garbage or even cause a panic. If necessary i can
pick up the quirks after reading the chip-id from the bus, skipping the
new driver and the new bindings.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox