* Re: [PATCH v3] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Johannes Berg @ 2026-05-19 7:02 UTC (permalink / raw)
To: Devin Wittmayer, linux-wireless
Cc: Felix Fietkau, Lorenzo Bianconi, linux-kernel, stable,
Oscar Alfonso Diaz, fjhhz1997
In-Reply-To: <20260518170147.13885-2-lucid_duck@justthetip.ca>
Hi Devin,
Please don't nest the threads - it gets confusing quickly.
> + } else if (local->emulate_chanctx) {
> chandef = &local->hw.conf.chandef;
> - else
> - goto fail_rcu;
> + } else {
> + struct ieee80211_chanctx *ctx;
> +
> + ctx = list_first_or_null_rcu(&local->chanctx_list,
> + struct ieee80211_chanctx, list);
> + if (!ctx ||
> + rcu_access_pointer(ctx->list.next) != &local->chanctx_list)
> + goto fail_rcu;
> + chandef = &ctx->conf.def;
> + }
I'm sure we can basically get rid of the "emulate" check now, because
emulation will always lead to exactly (zero or) one channel context(s)
being present.
And then it's equivalent to my original v2 patch:
https://lore.kernel.org/linux-wireless/20251216111909.25076-2-johannes@sipsolutions.net/
(even if that expressed the logic somewhat differently)
And that version was _definitely_ reported to crash. So what changed?
Could you do some investigation if mt76 got bugfixes in this area
perhaps? Or are you just using slightly different devices than Oscar?
johannes
^ permalink raw reply
* Re: [PATCH] wireless-regdb: add regulatory rules for Iraq (IQ)
From: Chen-Yu Tsai @ 2026-05-19 7:14 UTC (permalink / raw)
To: Mohammed.Al-Obaidi, Johannes Berg
Cc: wireless-regdb, linux-wireless, mnewiraq2000, mnew_iraq
In-Reply-To: <dc91809a60874f87a5e9d67f0c4696e5@badraproject.com>
Hi,
On Sat, May 16, 2026 at 3:43 PM <Mohammed.Al-Obaidi@badraproject.com> wrote:
>
> Kind reminder, any update on the subject?
Please send the patch directly to the mailing list, not as an attachment.
Otherwise there is no way to review the patch on the mailing list.
`git send-email` should do that for you.
About the commit message:
The section "Notes on the encoding chosen below" is really not needed,
unless something is not a direct translation from text to the standard
rules for wireless-regdb, or if other materials were referenced.
So talking about "Indoor" encoded as "NO-OUTDOOR" is redundant. Mentioning
DFS is also not needed, since it is obvious from the table you provided.
AUTO-BW for 5150-5350 MHz is also quite standard.
Things that are worth mentioning:
1. TPC requirements in the regulation and what was done to make the rule
compliant (as we don't support TPC)
2. Choice between indoor-only and indoor+outdoor rules when both exist
but with different requirements (database and Linux support only one
rule per band)
3. unique 5.8 GHz figure as you gave
Also:
* 5725-5875 MHz uses the higher of the two stated EIRP figures
(4000 mW for 20 MHz channels) since wireless-regdb expresses a
per-band ceiling, not a per-channel-width ceiling.
This is slightly wrong. wireless-regdb expresses a ceiling that makes
devices compliant with all regulations in all configurations. So if
there is a power spectral density that allows the maximum EIRP at
a wider channel, but a reduced EIRP at 20 MHz, we will use the reduced
number.
As for 10 MHz, I don't think it is supported, so we don't really consider
that case. I could be wrong though.
Johannes, could you shed some light on 10 MHz channel width support?
Thanks
ChenYu
> Mohammed
>
> From: Mohammed Abdalla [mailto:mnew_iraq@yahoo.com]
> Sent: Tuesday, May 5, 2026 7:12 PM
> To: wireless-regdb@lists.infradead.org; linux-wireless@vger.kernel.org
> Cc: Mohammed Abdullah Ali Al-Obaidi <Mohammed.Al-Obaidi@badraproject.com>
> Subject: [PATCH] wireless-regdb: add regulatory rules for Iraq (IQ)
>
> ## 1. Why this patch exists
>
> Iraq is currently absent from `wireless-regdb/db.txt`. As a
> consequence, every OpenWrt and Linux device set to `country=IQ`
> falls back to the world domain (`00`), which marks most of the
> 5 GHz spectrum as `no IR` and limits 2.4 GHz EIRP to 20 dBm. A
> public OpenWrt forum thread on the Archer AX23 in Iraq concluded
> with the maintainers' standard answer:
>
> > *"IQ is the correct code for the place; once an engineer shares
> > the local radio laws with regdb maintainers it will be added."*
>
> This patch is that contribution.
>
> ## 2. The primary source
>
> The Iraqi Communications and Media Commission (CMC), the national
> regulator, has issued a numerical regulation specifically governing
> unlicensed Wi-Fi, SRD, and UWB devices:
>
> - **Title:** Regulation on short-range radio communication devices
> (SRD) and devices using ultra-broadband (UWB) technology
> - **Issuer:** Republic of Iraq, CMC, Telecommunications Regulatory
> Department, International Relations Section
> - **Decree:** Council of Commissioners decision No. 122/q-2025
> - **In force from:** 2025-09-22
> - **Edition:** First edition, 2025; 26 pages
> - **Direct PDF:**
> <https://cmc.iq/wp-content/uploads/2025/09/Regulation-on-short-range-radio-communication-devices-SRD-and-devices-using-ultra-broadband-UWB-technology.pdf>
>
> Article 4-1-13 of that regulation, titled "Wireless Access Systems
> (WAS)", contains a full numerical table for every Wi-Fi band. This
> patch reproduces that table directly. Nothing in the proposed
> `country IQ:` block is inferred or extrapolated.
>
> ## 3. The Article 4-1-13 table, verbatim
>
> | Band | Use | Max EIRP | Required mitigations | Cited standard |
> |---|---|---|---|---|
> | 2400 – 2483.5 MHz | Indoor and outdoor | 100 mW | LBT and DAA | EN 300 328, ERC/REC 70-03 |
> | 5150 – 5250 MHz | Indoor | 200 mW | — | EN 301 893, ITU Res. 229 (Rev. WRC-19) |
> | 5250 – 5350 MHz | Indoor | 200 mW | — (DFS implied via EN 301 893) | EN 301 893 |
> | 5470 – 5725 MHz | Indoor | 1000 mW | DFS and TPC (stated explicitly) | EN 301 893 |
> | 5725 – 5875 MHz | Indoor and outdoor | 2000 mW (10 MHz ch) / 4000 mW (20 MHz ch) | — | EN 302 502 |
> | 5945 – 6425 MHz | Indoor | 200 mW | — | EN 303 687, ECC Report 75 |
> | 57000 – 66000 MHz | Indoor | 10000 mW | LBT and DAA | EN 302 567 |
>
> The proposed `country IQ:` block encodes this table line for line.
>
> ## 4. The Iraqi regulation also defines its own glossary terms
>
> For the avoidance of doubt, the regulation's Annex A explicitly
> defines `Wi-Fi` as *"802.11 Local Area Networking in 2.4 and 5 GHz
> ISM bands"*. So when the maintainers ask whether this regulation
> in fact covers Wi-Fi, the answer from the regulator is yes,
> in writing, in the regulation itself.
>
> The same annex defines DFS, TPC, LBT, DAA, EIRP and AFA in the
> exact wireless-regdb sense.
>
> ## 5. Encoding choices and where they came from
>
> A few wireless-regdb encoding details require explanation, because
> they are interpretations of the regulation's wording rather than
> direct copies of numerical limits:
>
> 1. **NO-OUTDOOR on 5150–5725 MHz.** The regulation labels these
> rows simply as "Indoor". The wireless-regdb idiom for that is
> the `NO-OUTDOOR` flag.
>
> 2. **No NO-OUTDOOR on 5725–5875 MHz.** The regulation explicitly
> labels this row "Indoor and outdoor".
>
> 3. **DFS on 5250–5350 MHz.** The regulation's own column for this
> row is empty for mitigations, but the cited standard
> (EN 301 893) requires DFS in this sub-band, and the corresponding
> row for 5470–5725 in the same table does state DFS+TPC. Reading
> the regulation as a whole, DFS for 5250–5350 is required by the
> incorporated standard.
>
> 4. **Single EIRP figure for 5725–5875 MHz.** The regulation gives
> two figures (2000 mW for 10 MHz channels, 4000 mW for 20 MHz
> channels). The wireless-regdb format expresses one ceiling per
> band; the 4000 mW figure is used because it is the higher value
> that the regulation explicitly permits.
>
> 5. **6 GHz channel width set to 80 MHz.** The regulation does not
> explicitly distinguish standard-power from low-power indoor
> (LPI) operation, nor does it mention AFC. The conservative
> choice is to encode the 6 GHz block at 80 MHz (the widest
> non-AFC option in current practice) and leave a follow-up patch
> for a wider channelisation once CMC clarifies AFC requirements.
>
> 6. **AUTO-BW on the 5 GHz RLAN rows.** Standard practice for
> EN 301 893–compliant entries; no AUTO-BW is set on the 6 GHz
> row pending the AFC question above.
>
> If the maintainers prefer a different encoding for any of these
> six points, please push back; the underlying regulatory text is
> clear and any of these can be re-encoded without changing what is
> actually permitted under Iraqi law.
>
> ## 6. The 5.8 GHz figure looks unusually high — it is intentional
>
> `(5725 - 5875 @ 80), (4000 mW)` with no NO-OUTDOOR is not a typo.
> This is what Iraq's own regulation states for this sub-band, citing
> EN 302 502. It is the BFWA value, not the Non-Specific SRD value.
> This choice puts Iraq at the high end of the regional spectrum
> policy for the 5.8 GHz band. It is included verbatim because the
> purpose of wireless-regdb is to reflect what each country's
> regulator actually permits.
>
> ## 7. What is not in the patch
>
> - **5850–5925 MHz ITS / V2X bands.** Article 4-1-8 of the same
> regulation covers ITS at 5855–5925 MHz with 2 W EIRP, but this
> is a non-Wi-Fi RLAN application and is outside the scope of
> what wireless-regdb usually encodes for `country` blocks.
>
> - **All non-Wi-Fi SRD bands.** The regulation also covers RFID,
> inductive applications, alarms, model control, automotive radar,
> level probing radar, hearing aids, active medical implants, and
> the full UWB regime (Articles 4-2-1 through 4-2-6). None of these
> is a wireless-regdb concern.
>
> - **6 GHz beyond 6425 MHz.** The Iraqi regulation only addresses
> 5945–6425 MHz at 6 GHz; the 6425–7125 MHz upper portion is not
> covered, and the patch therefore does not include it.
>
> ## 8. Submission checklist
>
> - [ ] Verify the patch applies cleanly against the current
> `wireless-regdb` master; the IQ block must be inserted in
> alphabetical order, between `IN` and `IR`.
> - [ ] Build `regulatory.db` locally and confirm with
> `regdbdump regulatory.db | grep -A8 'country IQ'` that the
> output matches the proposed table exactly.
> - [ ] Post the cover letter and patch on the OpenWrt forum thread
> (231380) for community review by Iraqi engineers before
> sending upstream.
> - [ ] Send to `linux-wireless@vger.kernel.org` with cc to
> `wireless-regdb@lists.infradead.org`.
>
> ## 9. A note on responsibility
>
> The numerical content of this patch is taken verbatim from a public
> Iraqi government regulation. The encoding choices listed in §5 are
> the patch author's, and they are reversible.
>
> Author: Mohammed Abdullah Ali Al-Obaidi (mnew_iraq@yahoo.com),
> OpenWrt forum handle `mnewiraq`. Any objection to the encoding
> choices should be raised to that author or in the upstream review
> thread, not to the CMC.
>
>
> CONFIDENTIALITY. This communication is intended exclusively for use by the addressee and may contain confidential and/or privileged information. If you receive this communication unintentionally please inform the sender by reply immediately and permanently delete it from your system; you should not copy this communication or disclose its contents to anyone.
^ permalink raw reply
* Re: [PATCH v2] wireless-regdb: Update regulatory info for Brunei Darussalam (BN) for 2022
From: Chen-Yu Tsai @ 2026-05-19 7:18 UTC (permalink / raw)
To: linux-wireless, hfzz7; +Cc: wireless-regdb
In-Reply-To: <17568FCB-64AC-4CF8-9766-51FEE44EF7B8.1@smtp-inbound1.duck.com>
On Fri, 01 May 2026 13:25:08 -0400, hfzz7@duck.com wrote:
> In 2022, Authority for Info-communications Technology Industry of Brunei
> Darussalam (AITI) updated The Brunei Darussalam Radio Spectrum Plan. [1]
>
> * 2400-2483.5 MHz
> - 200 mW
>
> * 5150-5350 MHz
> - 1000 mW
> (For 5250-5.350 MHz, DFS and TPC are required)
>
> [...]
Applied to master in wens/wireless-regdb.git, thanks!
[1/1] wireless-regdb: Update regulatory info for Brunei Darussalam (BN) for 2022
https://git.kernel.org/wens/wireless-regdb/c/0c24afb228db
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH v3] wireless-regdb: Update regulatory rules for Sri Lanka (LK)
From: Chen-Yu Tsai @ 2026-05-19 7:18 UTC (permalink / raw)
To: linux-wireless, Mohamed Aashif; +Cc: wireless-regdb, pkshih
In-Reply-To: <20260518074743.179402-1-maashif011@gmail.com>
On Mon, 18 May 2026 13:17:43 +0530, Mohamed Aashif wrote:
> Update Sri Lanka regulatory domain based on the RTTE Type Approval
> Rules 2020 from the Telecommunications Regulatory Commission of
> Sri Lanka (TRC).
>
> Source: https://www.trc.gov.lk/content/files/licensing/RTTE_GAZETTE-English.pdf
>
> Key changes:
> - Change DFS region from FCC to ETSI (document references ETSI
> standards EN 300 328 and EN 301 893 as the applicable radio
> interface standards)
> - 2.4 GHz: expand to 2400-2483.5 MHz at 23 dBm
> - 5150-5250 MHz: 23 dBm
> - 5250-5350 MHz: 20 dBm with DFS (no TPC, 3 dB reduction per EN 301 893)
> - 5470-5725 MHz: 27 dBm with DFS (no TPC, per EN 301 893)
> - 5725-5875 MHz: 24 dBm with DFS (per ETSI EN 302 502)
>
> [...]
Applied to master in wens/wireless-regdb.git, thanks!
[1/1] wireless-regdb: Update regulatory rules for Sri Lanka (LK)
https://git.kernel.org/wens/wireless-regdb/c/63d0d6b6aa47
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute
From: Ping-Ke Shih @ 2026-05-19 7:24 UTC (permalink / raw)
To: linux-wireless; +Cc: wenjie.tsai
From: Johnson Tsai <wenjie.tsai@realtek.com>
Expose the device's Serial Number (SN) and UUID from EFUSE through a
read-only `hw_info` sysfs attribute on the USB interface device.
This hardware identification information is essential for user-space
applications to uniquely identify, track, and manage specific Wi-Fi
adapters. For example, in automated factory provisioning or device
management systems, user-space tools rely on the EFUSE SN and UUID
to bind specific configurations to a physical adapter. Currently,
standard wireless APIs do not expose this low-level hardware
information, making this sysfs node the only viable and necessary
solution for user space to extract this data.
Relying on debugfs or setuid binaries is unviable for production
environments, as explicitly requested by Valve (Steam). Steam frequently
runs inside unprivileged containers (e.g., Flatpak) where debugfs and
setuid binaries are inaccessible. Furthermore, many end-user systems
disable debugfs in their kernel configs, and strict access controls
(SELinux, AppArmor) block it regardless of permissions. Since Steam
installs as an unprivileged user, setuid deployments are impossible.
Consequently, exposing this data via a world-readable (0444) sysfs
node is the only functional approach to ensure reliable, unprivileged
access across diverse customer systems.
Example usage from user-space:
$ cat /sys/bus/usb/devices/2-3.1.2:1.0/hw_info
SN: 36 42 00 01 23
UUID: aa ec 2b 7c 0a 55 47 27 8d e0 b3 0f eb cc bb aa
User-space scripts can easily iterate over bound devices to extract
this information:
for dev in /sys/bus/usb/drivers/rtw89_8852cu/[0-9]*:*; do
dev_id=$(basename "$dev")
echo "--- Device: /sys/bus/usb/devices/$dev_id ---"
cat "$dev/hw_info"
done
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
Hi maintainers,
We are submitting this RFC to discuss the most appropriate upstream path for
exposing hardware-specific IDs to unprivileged container environments.
1. Given the strict environment limitations (Flatpak, missing debugfs, LSMs),
is a read-only sysfs attribute acceptable for this specific hardware data?
2. If exposing this globally via sysfs is not preferred, would it be acceptable
to restrict the creation of this node to specific vendor VID/PIDs only?
3. If sysfs is strictly a no-go for this use case, what is the upstream-recommended
method for an unprivileged, sandboxed application to retrieve eFuse data?
---
drivers/net/wireless/realtek/rtw89/usb.c | 51 +++++++++++++++++++++++-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw89/usb.c b/drivers/net/wireless/realtek/rtw89/usb.c
index c6d55e669776..53dcb84af5c0 100644
--- a/drivers/net/wireless/realtek/rtw89/usb.c
+++ b/drivers/net/wireless/realtek/rtw89/usb.c
@@ -1059,6 +1059,41 @@ static void rtw89_usb_intf_deinit(struct rtw89_dev *rtwdev,
usb_set_intfdata(intf, NULL);
}
+static ssize_t hw_info_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct usb_interface *intf = to_usb_interface(dev);
+ struct ieee80211_hw *hw;
+ struct rtw89_dev *rtwdev;
+ struct rtw89_efuse *efuse;
+ ssize_t ret;
+
+ device_lock(dev);
+
+ hw = usb_get_intfdata(intf);
+ if (!hw) {
+ device_unlock(dev);
+ return -ENODEV;
+ }
+
+ rtwdev = hw->priv;
+ efuse = &rtwdev->efuse;
+
+ ret = sysfs_emit(buf, "SN: %*ph\nUUID: %*ph\n",
+ (int)sizeof(efuse->sn), efuse->sn,
+ (int)sizeof(efuse->uuid), efuse->uuid);
+
+ device_unlock(dev);
+ return ret;
+}
+static DEVICE_ATTR_RO(hw_info);
+
+static struct attribute *rtw89_usb_attrs[] = {
+ &dev_attr_hw_info.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(rtw89_usb);
+
int rtw89_usb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
@@ -1118,10 +1153,16 @@ int rtw89_usb_probe(struct usb_interface *intf,
goto err_core_deinit;
}
+ ret = sysfs_create_groups(&intf->dev.kobj, rtw89_usb_groups);
+ if (ret) {
+ rtw89_err(rtwdev, "failed to create sysfs groups: %d\n", ret);
+ goto err_core_deinit;
+ }
+
ret = rtw89_core_register(rtwdev);
if (ret) {
rtw89_err(rtwdev, "failed to register core\n");
- goto err_core_deinit;
+ goto err_remove_sysfs;
}
rtw89_usb_start_rx(rtwdev);
@@ -1130,6 +1171,8 @@ int rtw89_usb_probe(struct usb_interface *intf,
return 0;
+err_remove_sysfs:
+ sysfs_remove_groups(&intf->dev.kobj, rtw89_usb_groups);
err_core_deinit:
rtw89_core_deinit(rtwdev);
err_deinit_rx:
@@ -1154,12 +1197,18 @@ void rtw89_usb_disconnect(struct usb_interface *intf)
if (!hw)
return;
+ /* Clear intfdata immediately so any concurrent sysfs show waiting on
+ * device_lock will see NULL and bail out safely.
+ */
+ usb_set_intfdata(intf, NULL);
+
rtwdev = hw->priv;
rtwusb = rtw89_usb_priv(rtwdev);
rtw89_usb_cancel_rx_bufs(rtwusb);
rtw89_usb_cancel_tx_bufs(rtwusb);
+ sysfs_remove_groups(&intf->dev.kobj, rtw89_usb_groups);
rtw89_core_unregister(rtwdev);
rtw89_core_deinit(rtwdev);
rtw89_usb_deinit_rx(rtwdev);
base-commit: 7076af642955693935e60bc94546d105fb0395ca
--
2.25.1
^ permalink raw reply related
* [RFC rtw-next 2/2] wifi: rtw89: usb: add sysfs write example
From: Ping-Ke Shih @ 2026-05-19 7:24 UTC (permalink / raw)
To: linux-wireless; +Cc: wenjie.tsai
In-Reply-To: <20260519072415.25746-1-pkshih@realtek.com>
From: Johnson Tsai <wenjie.tsai@realtek.com>
Add a simple echo_sum sysfs attribute on the USB interface device as
an RFC example for discussing whether a writable sysfs interface is
acceptable for this driver.
The attribute accepts two integers from userspace, stores their sum in
driver private data, and exposes the result.
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/usb.c | 38 ++++++++++++++++++++++++
drivers/net/wireless/realtek/rtw89/usb.h | 2 ++
2 files changed, 40 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw89/usb.c b/drivers/net/wireless/realtek/rtw89/usb.c
index 53dcb84af5c0..566618e9f3b8 100644
--- a/drivers/net/wireless/realtek/rtw89/usb.c
+++ b/drivers/net/wireless/realtek/rtw89/usb.c
@@ -1059,6 +1059,43 @@ static void rtw89_usb_intf_deinit(struct rtw89_dev *rtwdev,
usb_set_intfdata(intf, NULL);
}
+static ssize_t echo_sum_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct usb_interface *intf = to_usb_interface(dev);
+ struct ieee80211_hw *hw = usb_get_intfdata(intf);
+ struct rtw89_usb *rtwusb;
+
+ if (!hw)
+ return -ENODEV;
+
+ rtwusb = rtw89_usb_priv(hw->priv);
+
+ return sysfs_emit(buf, "%u\n", rtwusb->echo_sum);
+}
+
+static ssize_t echo_sum_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct usb_interface *intf = to_usb_interface(dev);
+ struct ieee80211_hw *hw = usb_get_intfdata(intf);
+ struct rtw89_usb *rtwusb;
+ int a, b;
+
+ if (!hw)
+ return -ENODEV;
+
+ if (sscanf(buf, "%d %d", &a, &b) != 2)
+ return -EINVAL;
+
+ rtwusb = rtw89_usb_priv(hw->priv);
+ rtwusb->echo_sum = a + b;
+
+ return count;
+}
+static DEVICE_ATTR_ADMIN_RW(echo_sum);
+
static ssize_t hw_info_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -1089,6 +1126,7 @@ static ssize_t hw_info_show(struct device *dev,
static DEVICE_ATTR_RO(hw_info);
static struct attribute *rtw89_usb_attrs[] = {
+ &dev_attr_echo_sum.attr,
&dev_attr_hw_info.attr,
NULL,
};
diff --git a/drivers/net/wireless/realtek/rtw89/usb.h b/drivers/net/wireless/realtek/rtw89/usb.h
index bdf312559743..9eba6264a9a2 100644
--- a/drivers/net/wireless/realtek/rtw89/usb.h
+++ b/drivers/net/wireless/realtek/rtw89/usb.h
@@ -87,6 +87,8 @@ struct rtw89_usb {
struct sk_buff_head tx_queue[RTW89_TXCH_NUM];
atomic_t tx_inflight[RTW89_TXCH_NUM];
+
+ u32 echo_sum;
};
static inline struct rtw89_usb *rtw89_usb_priv(struct rtw89_dev *rtwdev)
--
2.25.1
^ permalink raw reply related
* RE: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute
From: Ping-Ke Shih @ 2026-05-19 7:37 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, johannes@sipsolutions.net; +Cc: Johnson Tsai
In-Reply-To: <20260519072415.25746-1-pkshih@realtek.com>
Hi Johannes,
Need your comments on usage of sysfs.
Ping-Ke Shih <pkshih@realtek.com> wrote:
> From: Johnson Tsai <wenjie.tsai@realtek.com>
>
> Expose the device's Serial Number (SN) and UUID from EFUSE through a
> read-only `hw_info` sysfs attribute on the USB interface device.
>
> This hardware identification information is essential for user-space
> applications to uniquely identify, track, and manage specific Wi-Fi
> adapters. For example, in automated factory provisioning or device
> management systems, user-space tools rely on the EFUSE SN and UUID
> to bind specific configurations to a physical adapter. Currently,
> standard wireless APIs do not expose this low-level hardware
> information, making this sysfs node the only viable and necessary
> solution for user space to extract this data.
>
> Relying on debugfs or setuid binaries is unviable for production
> environments, as explicitly requested by Valve (Steam). Steam frequently
> runs inside unprivileged containers (e.g., Flatpak) where debugfs and
> setuid binaries are inaccessible. Furthermore, many end-user systems
> disable debugfs in their kernel configs, and strict access controls
> (SELinux, AppArmor) block it regardless of permissions. Since Steam
> installs as an unprivileged user, setuid deployments are impossible.
> Consequently, exposing this data via a world-readable (0444) sysfs
> node is the only functional approach to ensure reliable, unprivileged
> access across diverse customer systems.
>
> Example usage from user-space:
> $ cat /sys/bus/usb/devices/2-3.1.2:1.0/hw_info
> SN: 36 42 00 01 23
> UUID: aa ec 2b 7c 0a 55 47 27 8d e0 b3 0f eb cc bb aa
>
> User-space scripts can easily iterate over bound devices to extract
> this information:
> for dev in /sys/bus/usb/drivers/rtw89_8852cu/[0-9]*:*; do
> dev_id=$(basename "$dev")
> echo "--- Device: /sys/bus/usb/devices/$dev_id ---"
> cat "$dev/hw_info"
> done
>
> Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> ---
> Hi maintainers,
>
> We are submitting this RFC to discuss the most appropriate upstream path for
> exposing hardware-specific IDs to unprivileged container environments.
>
> 1. Given the strict environment limitations (Flatpak, missing debugfs, LSMs),
> is a read-only sysfs attribute acceptable for this specific hardware data?
> 2. If exposing this globally via sysfs is not preferred, would it be acceptable
> to restrict the creation of this node to specific vendor VID/PIDs only?
> 3. If sysfs is strictly a no-go for this use case, what is the upstream-recommended
> method for an unprivileged, sandboxed application to retrieve eFuse data?
I also looked up lore.kernel.org and only found a thread commented by Kalle [1].
However, it is not clear to us if sysfs is suitable to read efuse SN/UUID.
[1] https://lore.kernel.org/linux-wireless/87ziib3da5.fsf@kamboji.qca.qualcomm.com/
> ---
> drivers/net/wireless/realtek/rtw89/usb.c | 51 +++++++++++++++++++++++-
> 1 file changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw89/usb.c b/drivers/net/wireless/realtek/rtw89/usb.c
> index c6d55e669776..53dcb84af5c0 100644
> --- a/drivers/net/wireless/realtek/rtw89/usb.c
> +++ b/drivers/net/wireless/realtek/rtw89/usb.c
> @@ -1059,6 +1059,41 @@ static void rtw89_usb_intf_deinit(struct rtw89_dev *rtwdev,
> usb_set_intfdata(intf, NULL);
> }
>
> +static ssize_t hw_info_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct usb_interface *intf = to_usb_interface(dev);
> + struct ieee80211_hw *hw;
> + struct rtw89_dev *rtwdev;
> + struct rtw89_efuse *efuse;
> + ssize_t ret;
> +
> + device_lock(dev);
I think it isn't necessary to do lock/unlock in show ops. We will revise
it by v2.
[...]
Thanks
Ping-Ke
^ permalink raw reply
* [PATCH] wifi: mt76: Drop unneeded mt76_register_debugfs_fops() return checks
From: Ingyu Jang @ 2026-05-19 8:52 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee
Cc: Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, linux-wireless, linux-arm-kernel,
linux-mediatek, linux-kernel
In-Reply-To: <20260514193243.2518979-1-ingyujang25@korea.ac.kr>
mt76_register_debugfs_fops() returns the dentry from
debugfs_create_dir(), which yields an error pointer on failure
(notably ERR_PTR(-ENODEV) when CONFIG_DEBUG_FS=n), never NULL. Per
commit ff9fb72bc077 ("debugfs: return error values, not NULL"),
callers do not need to check the return value.
Drop the dead !dir checks in mt7615/mt7915/mt7921/mt7925/mt7996
_init_debugfs(). Converting them to IS_ERR() instead would have
exposed a probe abort on CONFIG_DEBUG_FS=n, since each
*_init_debugfs() caller propagates the helper's return value.
This patch supersedes an earlier proposal that converted the checks
to IS_ERR().
Link: https://lore.kernel.org/all/20260514193243.2518979-1-ingyujang25@korea.ac.kr
Signed-off-by: Ingyu Jang <ingyujang25@korea.ac.kr>
---
drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c | 2 --
drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c | 3 +--
drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c | 2 --
drivers/net/wireless/mediatek/mt76/mt7925/debugfs.c | 2 --
drivers/net/wireless/mediatek/mt76/mt7996/debugfs.c | 2 --
5 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c
index 0f7b20152279c..6a1475e3c8999 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c
@@ -550,8 +550,6 @@ int mt7615_init_debugfs(struct mt7615_dev *dev)
struct dentry *dir;
dir = mt76_register_debugfs_fops(&dev->mphy, &fops_regval);
- if (!dir)
- return -ENOMEM;
if (is_mt7615(&dev->mt76))
debugfs_create_devm_seqfile(dev->mt76.dev, "xmit-queues", dir,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c
index 26ed3745af43e..4d0854fe785bd 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c
@@ -1296,8 +1296,7 @@ int mt7915_init_debugfs(struct mt7915_phy *phy)
struct dentry *dir;
dir = mt76_register_debugfs_fops(phy->mt76, NULL);
- if (!dir)
- return -ENOMEM;
+
debugfs_create_file("muru_debug", 0600, dir, dev, &fops_muru_debug);
debugfs_create_file("muru_stats", 0400, dir, phy,
&mt7915_muru_stats_fops);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c
index 4333005b3ad95..a5a70d8e8544a 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c
@@ -266,8 +266,6 @@ int mt7921_init_debugfs(struct mt792x_dev *dev)
struct dentry *dir;
dir = mt76_register_debugfs_fops(&dev->mphy, &fops_regval);
- if (!dir)
- return -ENOMEM;
if (mt76_is_mmio(&dev->mt76))
debugfs_create_devm_seqfile(dev->mt76.dev, "xmit-queues",
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7925/debugfs.c
index e2498659c884e..d01ff49de47af 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/debugfs.c
@@ -291,8 +291,6 @@ int mt7925_init_debugfs(struct mt792x_dev *dev)
struct dentry *dir;
dir = mt76_register_debugfs_fops(&dev->mphy, &fops_regval);
- if (!dir)
- return -ENOMEM;
if (mt76_is_mmio(&dev->mt76))
debugfs_create_devm_seqfile(dev->mt76.dev, "xmit-queues",
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7996/debugfs.c
index 76d623b2cafb4..327fc2032c8da 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/debugfs.c
@@ -856,8 +856,6 @@ int mt7996_init_debugfs(struct mt7996_dev *dev)
struct dentry *dir;
dir = mt76_register_debugfs_fops(&dev->mphy, NULL);
- if (!dir)
- return -ENOMEM;
debugfs_create_file("hw-queues", 0400, dir, dev,
&mt7996_hw_queues_fops);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] wireless-regdb: add regulatory rules for Iraq (IQ)
From: Johannes Berg @ 2026-05-19 8:55 UTC (permalink / raw)
To: wens, Mohammed.Al-Obaidi
Cc: wireless-regdb, linux-wireless, mnewiraq2000, mnew_iraq
In-Reply-To: <CAGb2v66mCBP8KiMF3nRTix_zYDhsb_o4KNj-7-enB0+ULvh0_A@mail.gmail.com>
Hi,
> As for 10 MHz, I don't think it is supported, so we don't really consider
> that case. I could be wrong though.
>
> Johannes, could you shed some light on 10 MHz channel width support?
It's ... complicated?
We support a _very_ limited set of 5/10 MHz operation, but I think most
of it is fairly much unreachable from userspace. I asked about removing
it entirely a few years ago, and some people were opposed, but said
people also haven't actually helped take care of it or anything ... I
was just tempted again a little while back to remove it due to the rates
issues.
Ever since my commit 5add321c329b ("wifi: cfg80211: remove scan_width
support") I believe it has been unreachable on the *client* side, but
given that we still have some support in _nl80211_parse_chandef() and
chandef functions, I expect that it would be possible to still configure
an AP or monitor interface with 5/10 MHz, though only with drivers that
have WIPHY_FLAG_SUPPORTS_5_10_MHZ, i.e. ath5k, ath9k and hwsim. I
wouldn't mind removing it all though.
Is this a concern from a regulatory POV right now, due to say power
density by channel width? This feels somewhat familiar even with higher
channel widths - maybe it's time to add such an attribute to the regdb?
johannes
^ permalink raw reply
* Re: [PATCH] wireless-regdb: add regulatory rules for Iraq (IQ)
From: Chen-Yu Tsai @ 2026-05-19 8:59 UTC (permalink / raw)
To: Johannes Berg
Cc: Mohammed.Al-Obaidi, wireless-regdb, linux-wireless, mnewiraq2000,
mnew_iraq
In-Reply-To: <21a4cc48403b338311ea0ff76d757893b1f765cd.camel@sipsolutions.net>
On Tue, May 19, 2026 at 4:55 PM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Hi,
>
> > As for 10 MHz, I don't think it is supported, so we don't really consider
> > that case. I could be wrong though.
> >
> > Johannes, could you shed some light on 10 MHz channel width support?
>
> It's ... complicated?
>
> We support a _very_ limited set of 5/10 MHz operation, but I think most
> of it is fairly much unreachable from userspace. I asked about removing
> it entirely a few years ago, and some people were opposed, but said
> people also haven't actually helped take care of it or anything ... I
> was just tempted again a little while back to remove it due to the rates
> issues.
>
> Ever since my commit 5add321c329b ("wifi: cfg80211: remove scan_width
> support") I believe it has been unreachable on the *client* side, but
> given that we still have some support in _nl80211_parse_chandef() and
> chandef functions, I expect that it would be possible to still configure
> an AP or monitor interface with 5/10 MHz, though only with drivers that
> have WIPHY_FLAG_SUPPORTS_5_10_MHZ, i.e. ath5k, ath9k and hwsim. I
> wouldn't mind removing it all though.
>
>
> Is this a concern from a regulatory POV right now, due to say power
> density by channel width? This feels somewhat familiar even with higher
> channel widths - maybe it's time to add such an attribute to the regdb?
There are some regulations that say X dBm for 10 MHz or X*2 dBm for 20 MHz.
I've mostly been ignoring 10 MHz since that doesn't seem to be a thing
in modern WiFi. This is slightly different from the newer PSD rules we
are seeing with 6 GHz, since it only gives two points instead of an
actual density value.
ChenYu
^ permalink raw reply
* Re: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute
From: Johannes Berg @ 2026-05-19 12:11 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless@vger.kernel.org; +Cc: Johnson Tsai, driver-core
In-Reply-To: <efb61959e14e4f57b78fbd49a563398e@realtek.com>
Hi,
> > Example usage from user-space:
> > $ cat /sys/bus/usb/devices/2-3.1.2:1.0/hw_info
> > SN: 36 42 00 01 23
> > UUID: aa ec 2b 7c 0a 55 47 27 8d e0 b3 0f eb cc bb aa
Sysfs has a "one value per file" rule (soft rule according to the docs,
but harder in practice, I believe), so seems if anything that should be
two files. Maybe a UUID should also be formatted as such with %pU or
similar.
> I also looked up lore.kernel.org and only found a thread commented by Kalle [1].
> However, it is not clear to us if sysfs is suitable to read efuse SN/UUID.
>
> [1] https://lore.kernel.org/linux-wireless/87ziib3da5.fsf@kamboji.qca.qualcomm.com/
It seems to me this was more in the context of _writable_ files to do
some operations.
I don't think I have a problem with this, but sysfs also has
documentation requirements, and we should probably ask
driver-core@lists.linux.dev.
I'm not really quite sure I see the _point_ of identifying the serial
number of a wifi device in a container, but I guess you do.
johannes
^ permalink raw reply
* Re: [RFC rtw-next 1/2] wifi: rtw89: usb: add hw_info sysfs attribute
From: Greg KH @ 2026-05-19 12:22 UTC (permalink / raw)
To: Johannes Berg
Cc: Ping-Ke Shih, linux-wireless@vger.kernel.org, Johnson Tsai,
driver-core
In-Reply-To: <83ddb427597663b947c49afd835014f2bc1033f2.camel@sipsolutions.net>
On Tue, May 19, 2026 at 02:11:32PM +0200, Johannes Berg wrote:
> Hi,
>
> > > Example usage from user-space:
> > > $ cat /sys/bus/usb/devices/2-3.1.2:1.0/hw_info
> > > SN: 36 42 00 01 23
> > > UUID: aa ec 2b 7c 0a 55 47 27 8d e0 b3 0f eb cc bb aa
>
> Sysfs has a "one value per file" rule (soft rule according to the docs,
> but harder in practice, I believe), so seems if anything that should be
> two files. Maybe a UUID should also be formatted as such with %pU or
> similar.
That should be 2 separate sysfs files please.
And yes, use %pU.
And be careful about exposing serial numbers to userspace, some systems
don't like normal users to read them so be sure to get the permissions
correct. We had to add some USB code for ALLOW_SERIAL_NUMBER to make it
so that systems can handle this if they want to.
And shouldn't this just be the USB serial number to start with? Why is
there a different string here? We already have a sysfs file for this
value.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7996: avoid memset overwriting tx_info->control.flags
From: Lorenzo Bianconi @ 2026-05-19 12:24 UTC (permalink / raw)
To: Roy Luo
Cc: Lorenzo Bianconi, Ryder Lee, Felix Fietkau, linux-mediatek,
linux-wireless, Shayne Chen, Roy Luo
In-Reply-To: <CAHoxojKeXCCnJoO7yBBmTM9euiTf38orujOhOK00X8bb3ctWuA@mail.gmail.com>
>
> On Mon, May 18, 2026 at 5:31 AM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> >
> > On May 15, Cheng Hao Luo wrote:
> > > > struct ieee80211_tx_info {
> > > > u32 flags; /* 0 4 */
> > > > u32 band:3; /* 4: 0 4 */
> > > > u32 status_data_idr:1; /* 4: 3 4 */
> > > > u32 status_data:13; /* 4: 4 4 */
> > > > u32 hw_queue:4; /* 4:17 4 */
> > > > u32 tx_time_est:10; /* 4:21 4 */
> > > >
> > > > /* XXX 1 bit hole, try to pack */
> > > >
> > > > union {
> > > > struct {
> > > > union {
> > > > struct {
> > > > struct ieee80211_tx_rate rates[4]; /* 8 12 */
> > > > s8 rts_cts_rate_idx; /* 20 1 */
> > > > u8 use_rts:1; /* 21: 0 1 */
> > > > u8 use_cts_prot:1; /* 21: 1 1 */
> > > > u8 short_preamble:1; /* 21: 2 1 */
> > > > u8 skip_table:1; /* 21: 3 1 */
> > > > u8 antennas:2; /* 21: 4 1 */
> > > > }; /* 8 14 */
> > > > long unsigned int jiffies; /* 8 8 */
> > > > }; /* 8 16 */
> > > > struct ieee80211_vif * vif; /* 24 8 */
> > > > struct ieee80211_key_conf * hw_key; /* 32 8 */
> > > > u32 flags; /* 40 4 */
> > > > codel_time_t enqueue_time; /* 44 4 */
> > > > } control; /* 8 40 */
> > > > struct {
> > > > u64 cookie; /* 8 8 */
> > > > } ack; /* 8 8 */
> > > > struct {
> > > > struct ieee80211_tx_rate rates[4]; /* 8 12 */
> > > > s32 ack_signal; /* 20 4 */
> > > > u8 ampdu_ack_len; /* 24 1 */
> > > > u8 ampdu_len; /* 25 1 */
> > > > u8 antenna; /* 26 1 */
> > > > u8 pad; /* 27 1 */
> > > > u16 tx_time; /* 28 2 */
> > > > u8 flags; /* 30 1 */
> > > > u8 pad2; /* 31 1 */
> > > > void * status_driver_data[2]; /* 32 16 */
> > > > } status; /* 8 40 */
> > > > struct {
> > > > struct ieee80211_tx_rate driver_rates[4]; /* 8 12 */
> > > > u8 pad[4]; /* 20 4 */
> > > > void * rate_driver_data[3]; /* 24 24 */
> > > > }; /* 8 40 */
> > > > void * driver_data[5]; /* 8 40 */
> > > > }; /* 8 40 */
> > > >
> > > > /* size: 48, cachelines: 1, members: 7 */
> > > > /* sum members: 44 */
> > > > /* sum bitfield members: 31 bits, bit holes: 1, sum bit holes: 1 bits */
> > > > /* last cacheline: 48 bytes */
> > > > };
> > > >
> > > > According to pahole, the size of the control inner union is actually 16 bytes
> > > > since the compiler adds 2 bytes of padding. Since mt76_tx_status_skb_add()
> > > > meset to 0 just mt76_tx_cb size (that is 16 bytes) I can't see how
> > > > control.flags is overwritten. Am I missing something?
> > > >
> > > > struct mt76_tx_cb {
> > > > long unsigned int jiffies; /* 0 8 */
> > > > u16 wcid; /* 8 2 */
> > > > u8 pktid; /* 10 1 */
> > > > u8 flags; /* 11 1 */
> > > >
> > > > /* size: 16, cachelines: 1, members: 4 */
> > > > /* padding: 4 */
> > > > /* last cacheline: 16 bytes */
> > > > };
> > >
> > > Hi Lorenzo,
> > >
> > > The mt76_tx_cb is placed at status.status_driver_data (offset 32).
> > > It overlaps with hw_key, flags and enqueue_time in the control union.
> > >
> > > static inline struct mt76_tx_cb *mt76_tx_skb_cb(struct sk_buff *skb)
> > > {
> > > BUILD_BUG_ON(sizeof(struct mt76_tx_cb) >
> > > sizeof(IEEE80211_SKB_CB(skb)->status.status_driver_data));
> > > return ((void *)IEEE80211_SKB_CB(skb)->status.status_driver_data);
> > > }
> >
> > Hi Roy,
> >
> > I still do not understand since mt76_tx_status_skb_add() sets to 0 just sizeof
> > of mt76_tx_cb, that according to pahole is 16 bytes, so it can't overwrite
> > hw_key pointer (whose offset respect to the beginning of the control struct is
> > 24, 32 - 8).
> >
> > Regards,
> > Lorenzo
> >
> > >
> > > Regards,
> > > Roy Luo
>
> Hi Lorenzo,
>
> The mt76_tx_status_skb_add() memset zero the 16 bytes starting from
> status.status_driver_data (please see the above inline function shared
> in my last response) whose offset with respect to the beginning of
> the control/status union is exactly 24 (32 - 8) instead of 0.
>
> Regards,
> Roy Luo
Hi Roy,
I can see the issue now, I was confusing status.status_driver_data
with
driver_data. You are right, we have an issue here. However, copying
all the
ieee80211_tx_info struct seems a bit overkill, what do you think?
Moreover, we have the same issue for various chipsets (e.g. mt7925 and
mt7915). I guess we should try to find a global solution for the
problem.
Regards,
Lorenzo
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: Fix phandle-array constraints, again
From: Manivannan Sadhasivam @ 2026-05-19 13:27 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Maxime Ripard, Krzysztof Kozlowski, Conor Dooley, Wolfram Sang,
Andi Shyti, Ulf Hansson, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Johannes Berg,
Jeff Johnson, Bjorn Helgaas, Lorenzo Pieralisi,
Krzysztof Wilczyński, Bjorn Andersson, Mathieu Poirier,
Sylwester Nawrocki, Mark Brown, Greg Kroah-Hartman, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-i2c, linux-mmc,
netdev, linux-wireless, ath10k, ath11k, linux-pci,
linux-remoteproc, linux-sound, linux-spi, linux-usb
In-Reply-To: <20260507201749.2605365-1-robh@kernel.org>
On Thu, May 07, 2026 at 03:16:00PM -0500, Rob Herring (Arm) wrote:
> The unfortunately named 'phandle-array' property type is really a matrix
> with phandle and fixed arg cells entries. A matrix property should have 2
> levels of items constraints.
>
> Acked-by: Mark Brown <broonie@kernel.org>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org> # PCI
- Mani
> ---
> v2:
> - Add proper descriptions for 'qcom,smem-states'. Thanks Krzysztof!
> - Fix i2c-parent warning
> - Fix extra blank lines
> ---
> .../rockchip/rockchip,rk3399-cdn-dp.yaml | 2 ++
> .../bindings/i2c/i2c-demux-pinctrl.yaml | 1 +
> .../mmc/hisilicon,hi3798cv200-dw-mshc.yaml | 7 ++++---
> .../devicetree/bindings/net/qcom,bam-dmux.yaml | 12 ++++++++++++
> .../devicetree/bindings/net/qcom,ipa.yaml | 12 ++++++++++++
> .../bindings/net/wireless/qcom,ath10k.yaml | 8 +++++++-
> .../bindings/net/wireless/qcom,ath11k.yaml | 8 +++++++-
> .../net/wireless/qcom,ipq5332-wifi.yaml | 18 ++++++++++++++++++
> .../bindings/pci/toshiba,tc9563.yaml | 5 +++--
> .../remoteproc/qcom,msm8916-mss-pil.yaml | 6 ++++++
> .../remoteproc/qcom,msm8996-mss-pil.yaml | 7 +++++++
> .../bindings/remoteproc/qcom,pas-common.yaml | 6 ++++++
> .../remoteproc/qcom,qcs404-cdsp-pil.yaml | 6 ++++++
> .../remoteproc/qcom,sc7180-mss-pil.yaml | 6 ++++++
> .../remoteproc/qcom,sc7280-adsp-pil.yaml | 6 ++++++
> .../remoteproc/qcom,sc7280-mss-pil.yaml | 6 ++++++
> .../remoteproc/qcom,sc7280-wpss-pil.yaml | 6 ++++++
> .../remoteproc/qcom,sdm845-adsp-pil.yaml | 6 ++++++
> .../bindings/remoteproc/qcom,wcnss-pil.yaml | 6 ++++++
> .../devicetree/bindings/sound/samsung,tm2.yaml | 8 ++++++--
> .../bindings/spi/st,stm32mp25-ospi.yaml | 5 +++--
> .../bindings/usb/chipidea,usb2-common.yaml | 2 ++
> .../devicetree/bindings/usb/ci-hdrc-usb2.yaml | 7 ++++---
> 23 files changed, 142 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml
> index 1a33128e77f5..195f665970bf 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml
> @@ -41,7 +41,9 @@ properties:
> minItems: 1
> items:
> - description: Extcon device providing the cable state for DP PHY device 0
> + maxItems: 1
> - description: Extcon device providing the cable state for DP PHY device 1
> + maxItems: 1
> description:
> List of phandle to the extcon device providing the cable state for the DP PHY.
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml
> index 1eaf00b90a77..deca72bfc8cf 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml
> @@ -40,6 +40,7 @@ properties:
>
> i2c-parent:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> + minItems: 2
> items:
> maxItems: 1
> description:
> diff --git a/Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml
> index 41c9b22523e7..e447579e0f22 100644
> --- a/Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml
> +++ b/Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml
> @@ -39,10 +39,11 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> description: |
> DWMMC core on Hi3798MV2x SoCs has a delay-locked-loop(DLL) attached to card data input path.
> - It is integrated into CRG core on the SoC and has to be controlled during tuning.
> + It is integrated into CRG core on the SoC and has to be controlled during tuning
> items:
> - - description: A phandle pointed to the CRG syscon node
> - - description: Sample DLL register offset in CRG address space
> + - items:
> + - description: A phandle pointed to the CRG syscon node
> + - description: Sample DLL register offset in CRG address space
>
> required:
> - compatible
> diff --git a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> index b30544410d09..33746c238513 100644
> --- a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> +++ b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> @@ -42,7 +42,19 @@ properties:
> description: State bits used by the AP to signal the modem.
> items:
> - description: Power control
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
> - description: Power control acknowledgment
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: Names for the state bits used by the AP to signal the modem.
> diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
> index fdeaa81b9645..68ec76fe4473 100644
> --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml
> +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
> @@ -128,7 +128,19 @@ properties:
> description: State bits used in by the AP to signal the modem.
> items:
> - description: Whether the "ipa-clock-enabled" state bit is valid
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
> - description: Whether the IPA clock is enabled (if valid)
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> index c21d66c7cd55..d4f4d72ee0d3 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> @@ -158,7 +158,13 @@ properties:
> description: State bits used by the AP to signal the WLAN Q6.
> items:
> - description: Signal bits used to enable/disable low power mode
> - on WCN in the case of WoW (Wake on Wireless).
> + on WCN in the case of WoW (Wake on Wireless).
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output.
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
> index 0cc1dbf2beef..d4aa56e2f823 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
> @@ -80,7 +80,13 @@ properties:
> description: State bits used by the AP to signal the WLAN Q6.
> items:
> - description: Signal bits used to enable/disable low power mode
> - on WCN6750 in the case of WoW (Wake on Wireless).
> + on WCN6750 in the case of WoW (Wake on Wireless).
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output.
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
> index 37d8a0da7780..18cd91e2728c 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
> @@ -168,8 +168,26 @@ properties:
> description: States used by the AP to signal the remote processor
> items:
> - description: Shutdown WCSS pd
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
> - description: Stop WCSS pd
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
> - description: Spawn WCSS pd
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description:
> diff --git a/Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml b/Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
> index fae466064780..b3ad05d90201 100644
> --- a/Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
> +++ b/Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
> @@ -49,8 +49,9 @@ properties:
> A phandle to the parent I2C node and the slave address of the device
> used to configure tc9563 to change FTS, tx amplitude etc.
> items:
> - - description: Phandle to the I2C controller node
> - - description: I2C slave address
> + - items:
> + - description: Phandle to the I2C controller node
> + - description: I2C slave address
>
> patternProperties:
> "^pcie@[1-3],0$":
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> index faf2712e3d27..4049157dd83d 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> @@ -108,6 +108,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: Names of the states used by the AP to signal the Hexagon core
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
> index 1b65813cc8ad..4a1b439f985e 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
> @@ -101,6 +101,13 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point or Shared
> + Memory Manager device handling the communication with a remote
> + processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: Names of the states used by the AP to signal the Hexagon core
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> index 68c17bf18987..4607b459131b 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> @@ -60,6 +60,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml
> index bca59394aef4..e5f5f92987e1 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml
> @@ -92,6 +92,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml
> index 7c9accac92d0..21c82cd3be03 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml
> @@ -133,6 +133,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml
> index 94ca7a0cc203..23b8e3079f3b 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml
> @@ -91,6 +91,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml
> index f349c303fa07..43dfb90ac18d 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml
> @@ -147,6 +147,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml
> index f4118b2da5f6..f3f3432948ed 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml
> @@ -104,6 +104,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml
> index a3c74871457f..9666ebf1e7b6 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml
> @@ -92,6 +92,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> index 117fb4d0c4ad..a55e55f5f014 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> @@ -84,6 +84,12 @@ properties:
> States used by the AP to signal the WCNSS core that it should shutdown
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml
> index 67586ba3e0a0..985b7d29cd33 100644
> --- a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml
> +++ b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml
> @@ -45,8 +45,12 @@ properties:
> description: Phandles to the I2S controllers.
> $ref: /schemas/types.yaml#/definitions/phandle-array
> items:
> - - description: Phandle to I2S0.
> - - description: Phandle to I2S1.
> + - items:
> + - description: Phandle to I2S0
> + - description: Unused
> + - items:
> + - description: Phandle to I2S1
> + - description: Unused
>
> mic-bias-gpios:
> description: GPIO pin that enables the Main Mic bias regulator.
> diff --git a/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml b/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml
> index 272bc308726b..b6be47f67fcb 100644
> --- a/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml
> +++ b/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml
> @@ -49,8 +49,9 @@ properties:
> description: configure OCTOSPI delay block.
> $ref: /schemas/types.yaml#/definitions/phandle-array
> items:
> - - description: phandle to syscfg
> - - description: register offset within syscfg
> + - items:
> + - description: phandle to syscfg
> + - description: register offset within syscfg
>
> access-controllers:
> description: phandle to the rifsc device to check access right
> diff --git a/Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml b/Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml
> index 10020af15afc..e6a5e79df348 100644
> --- a/Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml
> +++ b/Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml
> @@ -97,7 +97,9 @@ properties:
> minItems: 1
> items:
> - description: vbus extcon
> + maxItems: 1
> - description: id extcon
> + maxItems: 1
>
> phy-clkgate-delay-us:
> description:
> diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> index 691d6cf02c27..fec04702f530 100644
> --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> @@ -61,9 +61,10 @@ properties:
> offset, and phy index
> $ref: /schemas/types.yaml#/definitions/phandle-array
> items:
> - - description: phandle to TCSR node
> - - description: register offset
> - - description: phy index
> + - items:
> + - description: phandle to TCSR node
> + - description: register offset
> + - description: phy index
>
> nvidia,phy:
> description: phandle of usb phy that connects to the port. Use "phys" instead.
> --
> 2.53.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: pull-request: ath-current-20260512
From: Jeff Johnson @ 2026-05-19 14:21 UTC (permalink / raw)
To: linux-wireless, Johannes Berg; +Cc: ath10k, ath11k, ath12k, jjohnson
In-Reply-To: <8756e3ff-52bc-4003-99ed-cda3170f118c@oss.qualcomm.com>
On 5/12/2026 7:28 AM, Jeff Johnson wrote:
> The following changes since commit 7666dbb1bacc4ba522b96740cba7283d243d16e1:
>
> wifi: cfg80211: advance loop vars in cfg80211_merge_profile() (2026-05-08 09:20:03 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git tags/ath-current-20260512
>
> for you to fetch changes up to 54a5b38e4396530e5b2f12b54d3844e860ab6784:
>
> wifi: ath10k: skip WMI and beacon transmission when device is wedged (2026-05-12 07:00:00 -0700)
>
> ----------------------------------------------------------------
> ath.git update for v7.1-rc5
>
> In ath10k, avoid sending any commands to firmware when it is wedged.
> In ath11k, fix WMI buffer leaks on error conditions.
>
> ----------------------------------------------------------------
> Kang Yang (1):
> wifi: ath10k: skip WMI and beacon transmission when device is wedged
>
> Nicolas Escande (3):
> wifi: ath11k: fix error path leaks in some WMI WOW calls
> wifi: ath11k: fix error path leaks in some WMI calls
> wifi: ath11k: fix error path leak in ath11k_tm_cmd_wmi_ftm()
>
> drivers/net/wireless/ath/ath10k/wmi.c | 15 ++--
> drivers/net/wireless/ath/ath11k/testmode.c | 1 +
> drivers/net/wireless/ath/ath11k/wmi.c | 131 ++++++++++++++++++++++++-----
> 3 files changed, 120 insertions(+), 27 deletions(-)
Johannes, since this hasn't been processed, please drop it.
I have some additional patches in ath-current and I'll send an updated PR.
/jeff
^ permalink raw reply
* Re: pull-request: ath-current-20260512
From: Johannes Berg @ 2026-05-19 14:23 UTC (permalink / raw)
To: Jeff Johnson, linux-wireless; +Cc: ath10k, ath11k, ath12k, jjohnson
In-Reply-To: <d88a1d9b-853b-476c-8f01-22fe24590892@oss.qualcomm.com>
On Tue, 2026-05-19 at 07:21 -0700, Jeff Johnson wrote:
> On 5/12/2026 7:28 AM, Jeff Johnson wrote:
> > The following changes since commit 7666dbb1bacc4ba522b96740cba7283d243d16e1:
> >
> > wifi: cfg80211: advance loop vars in cfg80211_merge_profile() (2026-05-08 09:20:03 +0200)
> >
> > are available in the Git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git tags/ath-current-20260512
> >
> > for you to fetch changes up to 54a5b38e4396530e5b2f12b54d3844e860ab6784:
> >
> > wifi: ath10k: skip WMI and beacon transmission when device is wedged (2026-05-12 07:00:00 -0700)
> >
> > ----------------------------------------------------------------
> > ath.git update for v7.1-rc5
> >
> > In ath10k, avoid sending any commands to firmware when it is wedged.
> > In ath11k, fix WMI buffer leaks on error conditions.
> >
> > ----------------------------------------------------------------
> > Kang Yang (1):
> > wifi: ath10k: skip WMI and beacon transmission when device is wedged
> >
> > Nicolas Escande (3):
> > wifi: ath11k: fix error path leaks in some WMI WOW calls
> > wifi: ath11k: fix error path leaks in some WMI calls
> > wifi: ath11k: fix error path leak in ath11k_tm_cmd_wmi_ftm()
> >
> > drivers/net/wireless/ath/ath10k/wmi.c | 15 ++--
> > drivers/net/wireless/ath/ath11k/testmode.c | 1 +
> > drivers/net/wireless/ath/ath11k/wmi.c | 131 ++++++++++++++++++++++++-----
> > 3 files changed, 120 insertions(+), 27 deletions(-)
>
> Johannes, since this hasn't been processed, please drop it.
OK, done. Sorry about that, had a holiday last Thursday, kids were off
school Friday, and I haven't really fully caught up.
johannes
^ permalink raw reply
* Re: [RESEND PATCH 1/2] genirq: export irq_can_set_affinity() for module drivers
From: Thomas Gleixner @ 2026-05-19 14:30 UTC (permalink / raw)
To: Hangtian Zhu, jjohnson; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260519011627.713068-2-hangtian.zhu@oss.qualcomm.com>
eviewed-by: Thomas Gleixner <tglx@kernel.org>
On Tue, May 19 2026 at 09:16, Hangtian Zhu wrote:
> Export irq_can_set_affinity() for loadable drivers that need a runtime
> check for IRQ affinity capability.
>
> In hierarchical IRQ setups where the effective irqchip path lacks
> .irq_set_affinity(), drivers may need to switch to a fallback policy.
> Without this export, module drivers cannot use the core helper and have
> to open-code equivalent checks.
>
> Signed-off-by: Hangtian Zhu <hangtian.zhu@oss.qualcomm.com>
Assuming this goes through the wireless tree:
Acked-by: Thomas Gleixner <tglx@kernel.org>
If not, please let me know and I pick it up.
^ permalink raw reply
* pull-request: ath-current-20260519
From: Jeff Johnson @ 2026-05-19 14:34 UTC (permalink / raw)
To: linux-wireless, Johannes Berg; +Cc: ath10k, ath11k, ath12k, jjohnson
The following changes since commit 7666dbb1bacc4ba522b96740cba7283d243d16e1:
wifi: cfg80211: advance loop vars in cfg80211_merge_profile() (2026-05-08 09:20:03 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git tags/ath-current-20260519
for you to fetch changes up to 60fb2cf51e77bb1c0261160b4be44209d68956b1:
wifi: ath12k: fix EHT TX MCS limitation due to wrong 20 MHz-only parsing (2026-05-18 06:47:03 -0700)
----------------------------------------------------------------
ath.git update for v7.1-rc5
ath10k:
- avoid sending any commands to firmware when it is wedged
ath11k:
- fix WMI buffer leaks on error conditions
- fix UAF in RX MSDU coalesce path
- allow peer ID 0 on RX path (legal for mobile devices)
- reinitialize shared SRNG pointers on restart
ath12k:
- fix 20 MHz-only parsing of EHT-MCS map
----------------------------------------------------------------
Baochen Qiang (1):
wifi: ath12k: fix EHT TX MCS limitation due to wrong 20 MHz-only parsing
Kang Yang (1):
wifi: ath10k: skip WMI and beacon transmission when device is wedged
Kyle Farnung (1):
wifi: ath11k: clear shared SRNG pointer state on restart
Matthew Leach (1):
wifi: ath11k: fix peer resolution on rx path when peer_id=0
Nicolas Escande (3):
wifi: ath11k: fix error path leaks in some WMI WOW calls
wifi: ath11k: fix error path leaks in some WMI calls
wifi: ath11k: fix error path leak in ath11k_tm_cmd_wmi_ftm()
Willmar Knikker (1):
wifi: ath11k: fix use after free in ath11k_dp_rx_msdu_coalesce()
drivers/net/wireless/ath/ath10k/wmi.c | 15 ++--
drivers/net/wireless/ath/ath11k/dp_rx.c | 9 +-
drivers/net/wireless/ath/ath11k/hal.c | 14 ++-
drivers/net/wireless/ath/ath11k/hal_rx.c | 5 +-
drivers/net/wireless/ath/ath11k/testmode.c | 1 +
drivers/net/wireless/ath/ath11k/wmi.c | 131 ++++++++++++++++++++++++-----
drivers/net/wireless/ath/ath12k/mac.c | 8 +-
7 files changed, 143 insertions(+), 40 deletions(-)
^ permalink raw reply
* Re: [PATCH rtw-next v3] wifi: rtw89: usb: Support switching to USB 3 mode
From: Bitterblue Smith @ 2026-05-19 15:34 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless@vger.kernel.org
In-Reply-To: <5fc263787831471f87585fb90a9b0fcb@realtek.com>
On 18/05/2026 10:51, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>> The Realtek wifi 6/7 devices which support USB 3 are weird: when first
>> plugged in, they pretend to be USB 2. The driver needs to send some
>> commands to the device, which make it disappear and come back as a
>> USB 3 device.
>>
>> Implement the required commands in rtw89.
>>
>> Add a new function rtw89_usb_write32_quiet() to avoid the warnings
>> when writing to R_{AX,BE}_PAD_CTRL2. Even though the write succeeds,
>> usb_control_msg() returns -EPROTO, probably because the USB device
>> disappears immediately. This results in some confusing warnings in
>> the kernel log.
>>
>> When a USB 3 device is plugged into a USB 2 port, rtw89 will try to
>> switch it to USB 3 mode only once. The device will disappear and come
>> back still in USB 2 mode, of course.
>
> As we always try to switch USB 3, is it needed to add a hint to users
> to plug USB 2 port if he has a bad performance on 2GHz band?
>
I can add a message like "2.4 GHz performance may be better in a USB 2
port".
>>
>> Tested with RTL8832AU, RTL8832BU, RTL8832CU, and RTL8912AU.
>>
>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
>
> Some minor suggestions. Otherwise,
>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
>
> [...]
>
>> diff --git a/drivers/net/wireless/realtek/rtw89/usb.c b/drivers/net/wireless/realtek/rtw89/usb.c
>> index c6d55e669776..bfe004a49ccc 100644
>> --- a/drivers/net/wireless/realtek/rtw89/usb.c
>> +++ b/drivers/net/wireless/realtek/rtw89/usb.c
>> @@ -12,7 +12,7 @@
>> static void rtw89_usb_read_port_complete(struct urb *urb);
>>
>> static void rtw89_usb_vendorreq(struct rtw89_dev *rtwdev, u32 addr,
>> - void *data, u16 len, u8 reqtype)
>> + void *data, u16 len, u8 reqtype, bool warn)
>> {
>> struct rtw89_usb *rtwusb = rtw89_usb_priv(rtwdev);
>> struct usb_device *udev = rtwusb->udev;
>> @@ -52,7 +52,7 @@ static void rtw89_usb_vendorreq(struct rtw89_dev *rtwdev, u32 addr,
>>
>> if (ret == -ESHUTDOWN || ret == -ENODEV)
>> set_bit(RTW89_FLAG_UNPLUGGED, rtwdev->flags);
>> - else if (ret < 0)
>> + else if (ret < 0 && warn)
>> rtw89_warn(rtwdev,
>> "usb %s%u 0x%x fail ret=%d value=0x%x attempt=%d\n",
>> str_read_write(reqtype == RTW89_USB_VENQT_READ),
>> @@ -80,7 +80,7 @@ static u32 rtw89_usb_read_cmac(struct rtw89_dev *rtwdev, u32 addr)
>>
>> for (count = 0; ; count++) {
>> rtw89_usb_vendorreq(rtwdev, addr32, &data, 4,
>> - RTW89_USB_VENQT_READ);
>> + RTW89_USB_VENQT_READ, true);
>
> Not sure if you like to implement a __rtw89_usb_vendorreq(), and
> preserve rtw89_usb_vendorreq() as a wrapper with original prototype.
> Then, no need to stir here.
>
> I mean:
>
> __rtw89_usb_vendorreq(..., bool warn);
>
> static void rtw89_usb_vendorreq(struct rtw89_dev *rtwdev, u32 addr,
> void *data, u16 len, u8 reqtype)
> {
> __rtw89_usb_vendorreq(rtwdev, addr, data, len, reqtype, true);
> }
>
> (just a soft suggestion)
>
Yes, that looks good.
>>
>> val32 = le32_to_cpu(data);
>> if (val32 != RTW89_R32_DEAD)
>
> [...]
>
^ permalink raw reply
* Re: ath12k: QCN9274 hw2.0 single-band cards on IPQ9574 — firmware RDDM after WMI_INIT_CMD (WLAN.WBE.1.6-01243)
From: Jeff Johnson @ 2026-05-19 15:50 UTC (permalink / raw)
To: insalata.fresca, jjohnson, quic_rajkbhag
Cc: ath12k, linux-wireless, quic_bqiang
In-Reply-To: <6a0b9e39.87c5160c.1d1e38.353c@mx.google.com>
On 5/18/2026 4:18 PM, insalata.fresca@gmail.com wrote:
> Fix B -- DMA ring capability parser must tolerate unknown module IDs:
>
> Without: "Invalid module id 3" -> "failed to parse tlv -22" -> WMI ready timeout
> Cause : WBE.1.6 sends capability entries for module_id 3 (and possibly
> others) the host enum does not know. ath12k_dp_get_ring_num()
> returns -EINVAL for unknown IDs, breaking TLV parsing entirely.
> Fix : warn-and-skip on unknown module_id instead of returning -EINVAL.
There is already a public patch for this issue:
https://patch.msgid.link/20260505172415.566328-3-nazar@mokrynskyi.com
I've pinged the development team to look at the other issues.
What would be best is if you could create a Bugzilla ticket for tracking.
https://wireless.docs.kernel.org/en/latest/en/users/drivers/ath12k/bugreport.html
/jeff
^ permalink raw reply
* Re: [PATCH 0/6] b43: complete N-PHY rev 8 + radio 2057 rev 8 support
From: Michael Büsch @ 2026-05-19 15:58 UTC (permalink / raw)
To: Alessio Ferri; +Cc: linux-wireless, b43-dev, kvalo, linux-kernel
In-Reply-To: <8c0a07d2-9ec9-43d6-bdf7-f625bbb4a38a@mythread.it>
[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]
On Mon, 18 May 2026 03:49:33 +0200
Alessio Ferri <alessio.ferri@mythread.it> wrote:
> This series completes b43 support for the Broadcom N-PHY revision 8
> paired with radio 2057 revision 8. b43 already supports the surrounding
> PHY family - N-PHY rev 8 with radio 2057 rev 5 and rev 7 are handled,
> and rev 16 with radio 2057 rev 9 is handled - but the rev 8 + rev 8
> combination falls through four dispatcher gaps:
> Alessio Ferri (6):
> b43: add d11 core revision 0x16 to id table
> b43: route d11 corerev 22 to 24-bit indirect radio access
> b43: support radio 2057 rev 8
> b43: add IPA TX gain table for N-PHY r8 + radio 2057 r8
> b43: add channel info table for N-PHY r8 + radio 2057 r8
> b43: add RF power offset for N-PHY r8 + radio 2057 r8
In general this looks Ok.
From the style I assume that this is AI generated, right?
If so, can you tell us a bit more about the inputs used for the AI?
What information is this implementation based on?
--
Michael Büsch
https://bues.ch/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH rtw-next] wifi: rtw88: Add more validation for the RX descriptor
From: Bitterblue Smith @ 2026-05-19 17:59 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless@vger.kernel.org
Cc: LB F, Martin Blumenstingl, Fiona Klute,
andrej.skvortzov@gmail.com, anarsoul@gmail.com, Zhen XIN
In-Reply-To: <1d0efa51a4214ee8b65d7f3ff9d52097@realtek.com>
On 18/05/2026 11:14, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>> Some RTL8821CE cards can return frames with corrupted RX descriptor,
>> causing warnings and crashes if they are passed to the upper layers.
>
> Not sure if this is the reason Larry uploaded a copy of vendor driver
> to his repository [1].
>
He added it for someone whose wifi card sometimes wasn't powering on:
https://github.com/lwfinger/rtw88/issues/98#issuecomment-1263962943
> Recently, we received vulnerability report of rtw_mp_efuse_set() in
> vendor driver. I'd like to know if people are still using the vendor
> driver [1]. If not, is it possible to remove it? If people still need it,
> I will share the fix made by our internal later.
>
> [1] https://github.com/lwfinger/rtw88/tree/master/alt_rtl8821ce
>
We haven't been updating it for the kernel API changes, so I think we
can remove it.
>>
>> The PHY status size field is 4 bits wide, but in rtw88 its value should
>> only be 0 or 4. Checking this catches most of the corrupt frames.
>>
>> If a PHY status is present, the PHY status size should not be 0.
>>
>> The frame size should not be less than or equal to 4 and should not
>> exceed 11454.
>>
>> Discard the frame if any of these checks fail.
>>
>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221286
>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
>
> [...]
>
>> diff --git a/drivers/net/wireless/realtek/rtw88/rx.c b/drivers/net/wireless/realtek/rtw88/rx.c
>> index d9e11343d498..65f6db3d7fcb 100644
>> --- a/drivers/net/wireless/realtek/rtw88/rx.c
>> +++ b/drivers/net/wireless/realtek/rtw88/rx.c
>> @@ -3,6 +3,7 @@
>> */
>>
>> #include "main.h"
>> +#include "mac.h"
>> #include "rx.h"
>> #include "ps.h"
>> #include "debug.h"
>> @@ -261,9 +262,9 @@ static void rtw_rx_fill_rx_status(struct rtw_dev *rtwdev,
>> }
>> }
>>
>> -void rtw_rx_query_rx_desc(struct rtw_dev *rtwdev, void *rx_desc8,
>> - struct rtw_rx_pkt_stat *pkt_stat,
>> - struct ieee80211_rx_status *rx_status)
>> +int rtw_rx_query_rx_desc(struct rtw_dev *rtwdev, void *rx_desc8,
>> + struct rtw_rx_pkt_stat *pkt_stat,
>> + struct ieee80211_rx_status *rx_status)
>> {
>> u32 desc_sz = rtwdev->chip->rx_pkt_desc_sz;
>> struct rtw_rx_desc *rx_desc = rx_desc8;
>> @@ -303,12 +304,25 @@ void rtw_rx_query_rx_desc(struct rtw_dev *rtwdev, void *rx_desc8,
>> pkt_stat->bw = RTW_CHANNEL_WIDTH_20;
>
> Do you think if we should return -EINVAL for this case too?
>
Yes. What do we do with the debug message? Should the other
conditions also have a debug message?
>> }
>>
>> + if (unlikely(pkt_stat->drv_info_sz &&
>> + pkt_stat->drv_info_sz != PHY_STATUS_SIZE))
>> + return -EINVAL;
>> +
>> + if (unlikely(pkt_stat->phy_status && !pkt_stat->drv_info_sz))
>> + return -EINVAL;
>> +
>> + if (unlikely(pkt_stat->pkt_len > IEEE80211_MAX_MPDU_LEN_VHT_11454))
>> + return -EINVAL;
>> +
>> /* drv_info_sz is in unit of 8-bytes */
>> pkt_stat->drv_info_sz *= 8;
>>
>> /* c2h cmd pkt's rx/phy status is not interested */
>> if (pkt_stat->is_c2h)
>> - return;
>> + return 0;
>> +
>> + if (unlikely(pkt_stat->pkt_len <= FCS_LEN))
>> + return -EINVAL;
>>
>> phy_status = rx_desc8 + desc_sz + pkt_stat->shift;
>> hdr = phy_status + pkt_stat->drv_info_sz;
>
> [...]
>
^ permalink raw reply
* Re: [PATCH ath-next v2 0/2] wifi: ath12k: Add support for handling incumbent signal interference in 6 GHz
From: Jeff Johnson @ 2026-05-19 19:15 UTC (permalink / raw)
To: ath12k, Amith A; +Cc: linux-wireless
In-Reply-To: <20260511040242.1351792-1-amith.a@oss.qualcomm.com>
On Mon, 11 May 2026 09:32:40 +0530, Amith A wrote:
> This patch series adds the implementation of handling of interferences
> due to incumbent signals in 6 GHz channels. When an interference is
> detected, the firmware indicates it to the host using the
> WMI_DCS_INTERFERENCE_EVENT.
>
> The driver is expected to parse the new WMI event to retrieve the
> interference information, validate the interference detected channel and
> bitmap, and indicate the interference to mac80211, which then notifies
> this interference to the userspace.
>
> [...]
Applied, thanks!
[1/2] wifi: ath12k: Add support for handling incumbent signal interference in 6 GHz
commit: e7f9be2c7bfff07b5aba1e6eac3452cd729ad214
[2/2] wifi: ath12k: Add debugfs support to simulate incumbent signal interference
commit: afa1bd86eddd9f395bfa3d5cb3c7b5158e1383e0
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* [PATCH ath-next] wifi: ath12k: fix error unwind on arch_init() failure in PCI probe
From: Ripan Deuri @ 2026-05-19 19:28 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless
From: Ripan Deuri <ripan.deuri@oss.qualcomm.com>
When arch_init() fails in ath12k_pci_probe(), the code jumps to
err_pci_msi_free, leaking resources in teardown.
Redirect the failure path to err_free_irq so teardown matches the setup order.
Compile-tested only.
Fixes: 614c23e24ee8 ("wifi: ath12k: Support arch-specific DP device allocation")
Signed-off-by: Ripan Deuri <ripan.deuri@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath12k/pci.c b/drivers/net/wireless/ath/ath12k/pci.c
index 375277ca2b89..d9a22d6afbb0 100644
--- a/drivers/net/wireless/ath/ath12k/pci.c
+++ b/drivers/net/wireless/ath/ath12k/pci.c
@@ -1639,7 +1639,7 @@ static int ath12k_pci_probe(struct pci_dev *pdev,
ret = ab_pci->device_family_ops->arch_init(ab);
if (ret) {
ath12k_err(ab, "PCI arch_init failed %d\n", ret);
- goto err_pci_msi_free;
+ goto err_free_irq;
}
ret = ath12k_core_init(ab);
base-commit: 7b25796f571fc09a7aa6fe7efb23edccd326917d
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v6 00/16] firmware: qcom: Add OP-TEE PAS service support
From: Vignesh Viswanathan @ 2026-05-19 19:29 UTC (permalink / raw)
To: Sumit Garg, andersson
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
jorge.ramirez, tonyh, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260518072856.22790-1-sumit.garg@kernel.org>
On 5/18/2026 12:58 PM, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Qcom platforms has the legacy of using non-standard SCM calls
> splintered over the various kernel drivers. These SCM calls aren't
> compliant with the standard SMC calling conventions which is a
> prerequisite to enable migration to the FF-A specifications from Arm.
>
> OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't
> support these non-standard SCM calls. And even for newer architectures
> using S-EL2 with Hafnium support, QTEE won't be able to support SCM
> calls either with FF-A requirements coming in. And with both OP-TEE
> and QTEE drivers well integrated in the TEE subsystem, it makes further
> sense to reuse the TEE bus client drivers infrastructure.
>
> The added benefit of TEE bus infrastructure is that there is support
> for discoverable/enumerable services. With that client drivers don't
> have to manually invoke a special SCM call to know the service status.
>
> So enable the generic Peripheral Authentication Service (PAS) provided
> by the firmware. It acts as the common layer with different TZ
> backends plugged in whether it's an SCM implementation or a proper
> TEE bus based PAS service implementation.
>
> The TEE PAS service ABI is designed to be extensible with additional API
> as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future
> extensions of the PAS service needed while still maintaining backwards
> compatibility.
>
> Currently OP-TEE support is being added to provide the backend PAS
> service implementation which can be found as part of this PR [1].
> This implementation has been tested on Kodiak/RB3Gen2 board with lemans
> EVK board being the next target. In addition to that WIN/IPQ targets
> planning to use OP-TEE will use this service too. Surely the backwards
> compatibility is maintained and tested for SCM backend.
>
> Note that kernel PAS service support while running in EL2 is at parity
> among OP-TEE vs QTEE. Especially the media (venus/iris) support depends
> on proper IOMMU support being worked out on the PAS client end.
>
> Patch summary:
> - Patch #1: adds Kodiak EL2 overlay since boot stack with TF-A/OP-TEE
> only allow UEFI and Linux to boot in EL2.
> - Patch #2: adds generic PAS service.
> - Patch #3: migrates SCM backend to generic PAS service.
> - Patch #4: adds TEE/OP-TEE backend for generic PAS service.
> - Patch #5-#14: migrates all client drivers to generic PAS service.
> - Patch #15: drops legacy PAS SCM exported APIs.
Testing this on IPQ9650, which uses OP-TEE backend for PAS service.
Feel free to carry below tag for this series.
Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650
Thanks,
Vignesh
>
> The patch-set is based on v7.1-rc4 tag and can be found in git tree here
> [2].
>
> Merge strategy:
>
> It is expected due to APIs dependency, the entire patch-set to go via
> the Qcom tree. All other subsystem maintainers, it will be great if I
> can get acks for the corresponding subsystem patches.
>
> [1] https://github.com/OP-TEE/optee_os/pull/7721 (already merged)
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h=qcom-pas-v6
>
> ---
> Changes in v6:
> - Rebased to v7.1-rc4 tag.
> - Patch #14: fixed ret error print.
> - Add Kconfig descriptions for PAS symbols such that they are visible
> in menuconfig to update.
>
> Changes in v5:
> - Incorporated misc. comments from Mukesh.
> - Split up patch #11 into 2 to add an independent commit for passing
> proper PAS ID to set_remote_state API.
> - Picked up tags.
>
> Changes in v4:
> - Incorporate misc. comments on patch #4.
> - Picked up an ack for patch #10.
> - Clarify in cover letter about state of media support.
>
> Changes in v3:
> - Incorporated some style and misc. comments for patch #2, #3 and #4.
> - Add QCOM_PAS Kconfig dependency for various subsystems.
> - Switch from pseudo TA to proper TA invoke commands.
>
> Changes in v2:
> - Fixed kernel doc warnings.
> - Polish commit message and comments for patch #2.
> - Pass proper PAS ID in set_remote_state API for media firmware drivers.
> - Added Maintainer entry and dropped MODULE_AUTHOR.
>
> Mukesh Ojha (1):
> arm64: dts: qcom: kodiak: Add EL2 overlay
>
> Sumit Garg (15):
> firmware: qcom: Add a generic PAS service
> firmware: qcom_scm: Migrate to generic PAS service
> firmware: qcom: Add a PAS TEE service
> remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs
> remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs
> soc: qcom: mdtloader: Switch to generic PAS TZ APIs
> remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs
> remoteproc: qcom: Select QCOM_PAS generic service
> drm/msm: Switch to generic PAS TZ APIs
> media: qcom: Switch to generic PAS TZ APIs
> media: qcom: Pass proper PAS ID to set_remote_state API
> net: ipa: Switch to generic PAS TZ APIs
> wifi: ath12k: Switch to generic PAS TZ APIs
> firmware: qcom_scm: Remove SCM PAS wrappers
> MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service
>
> MAINTAINERS | 9 +
> arch/arm64/boot/dts/qcom/Makefile | 2 +
> arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++
> drivers/firmware/qcom/Kconfig | 21 +-
> drivers/firmware/qcom/Makefile | 2 +
> drivers/firmware/qcom/qcom_pas.c | 291 +++++++++++
> drivers/firmware/qcom/qcom_pas.h | 50 ++
> drivers/firmware/qcom/qcom_pas_tee.c | 476 ++++++++++++++++++
> drivers/firmware/qcom/qcom_scm.c | 302 ++++-------
> drivers/gpu/drm/msm/Kconfig | 1 +
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +-
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +-
> drivers/media/platform/qcom/iris/Kconfig | 25 +-
> .../media/platform/qcom/iris/iris_firmware.c | 9 +-
> drivers/media/platform/qcom/venus/Kconfig | 1 +
> drivers/media/platform/qcom/venus/firmware.c | 11 +-
> drivers/net/ipa/Kconfig | 2 +-
> drivers/net/ipa/ipa_main.c | 13 +-
> drivers/net/wireless/ath/ath12k/Kconfig | 2 +-
> drivers/net/wireless/ath/ath12k/ahb.c | 10 +-
> drivers/remoteproc/Kconfig | 4 +-
> drivers/remoteproc/qcom_q6v5_mss.c | 5 +-
> drivers/remoteproc/qcom_q6v5_pas.c | 51 +-
> drivers/remoteproc/qcom_wcnss.c | 12 +-
> drivers/soc/qcom/mdt_loader.c | 12 +-
> include/linux/firmware/qcom/qcom_pas.h | 43 ++
> include/linux/firmware/qcom/qcom_scm.h | 29 --
> include/linux/soc/qcom/mdt_loader.h | 6 +-
> 28 files changed, 1119 insertions(+), 320 deletions(-)
> create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> create mode 100644 drivers/firmware/qcom/qcom_pas.c
> create mode 100644 drivers/firmware/qcom/qcom_pas.h
> create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c
> create mode 100644 include/linux/firmware/qcom/qcom_pas.h
>
^ 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