[PATCH wireless-next] wifi: cfg80211: add fw_version device attribute for sysfs

[PATCH wireless-next] wifi: cfg80211: add fw_version device attribute for sysfs

[Rory Little]

The firmware version is already exposed via ethtool, but is not
accessible without an attached interface to create a netdev. Expose this
info in sysfs to allow users to query it without the use of ethtool.

Signed-off-by: Rory Little <roryl@candelatech.com>
---
 Documentation/ABI/testing/sysfs-class-ieee80211 |  7 +++++++
 MAINTAINERS                                     |  1 +
 net/wireless/sysfs.c                            | 14 ++++++++++++++
 3 files changed, 22 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-ieee80211

diff --git a/Documentation/ABI/testing/sysfs-class-ieee80211 b/Documentation/ABI/testing/sysfs-class-ieee80211
new file mode 100644
index 000000000000..caaf4f3fd4b4
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-ieee80211
@@ -0,0 +1,7 @@
+What:		/sys/class/ieee80211/<phyname>/fw_version
+Date:		July 2026
+Contact:	linux-wireless@vger.kernel.org
+Description:	Read-only firmware version string provided by the driver for
+		this wireless device. The read data will match the information
+		provided by ethtool get_drvinfo. As drivers are not required to
+		provide this information, reading may yield no data.
diff --git a/MAINTAINERS b/MAINTAINERS
index 2d420d40782e..56181edb718f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -117,6 +117,7 @@ W:	https://wireless.wiki.kernel.org/
 Q:	https://patchwork.kernel.org/project/linux-wireless/list/
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git
+F:	Documentation/ABI/testing/sysfs-class-ieee80211
 F:	Documentation/driver-api/80211/cfg80211.rst
 F:	Documentation/networking/regulatory.rst
 F:	include/linux/ieee80211.h
diff --git a/net/wireless/sysfs.c b/net/wireless/sysfs.c
index 3ec25d3f004e..e63b6d1fa411 100644
--- a/net/wireless/sysfs.c
+++ b/net/wireless/sysfs.c
@@ -65,12 +65,26 @@ static ssize_t addresses_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(addresses);
 
+static ssize_t fw_version_show(struct device *dev,
+			       struct device_attribute *attr,
+			       char *buf)
+{
+	struct wiphy *wiphy = &dev_to_rdev(dev)->wiphy;
+
+	if (!wiphy->fw_version[0])
+		return 0;
+
+	return sysfs_emit(buf, "%s\n", wiphy->fw_version);
+}
+static DEVICE_ATTR_RO(fw_version);
+
 static struct attribute *ieee80211_attrs[] = {
 	&dev_attr_index.attr,
 	&dev_attr_macaddress.attr,
 	&dev_attr_address_mask.attr,
 	&dev_attr_addresses.attr,
 	&dev_attr_name.attr,
+	&dev_attr_fw_version.attr,
 	NULL,
 };
 ATTRIBUTE_GROUPS(ieee80211);
-- 
2.52.0

Re: [PATCH wireless-next] wifi: cfg80211: add fw_version device attribute for sysfs

[Jeff Johnson]

On 7/28/2026 4:47 PM, Rory Little wrote:
> The firmware version is already exposed via ethtool, but is not
> accessible without an attached interface to create a netdev. Expose this
> info in sysfs to allow users to query it without the use of ethtool.

Curious what is the value?

It looks like many drivers, including ath11k and ath12k, do not populate this.

And this attribute is pointless for Wi-Fi 7 drivers supporting MLO with
multiple underlying hardware running different firmware images. I suspect
there are a few wiphy attributes that have this issue.

You'd need to instantiate these attribute on a per-radio basis to properly
handle the new multi-radio wiphy model.

/jeff

Re: [PATCH wireless-next] wifi: cfg80211: add fw_version device attribute for sysfs

[Rory Little]

On 7/28/26 18:34, Jeff Johnson wrote:
> On 7/28/2026 4:47 PM, Rory Little wrote:
>> The firmware version is already exposed via ethtool, but is not
>> accessible without an attached interface to create a netdev. Expose this
>> info in sysfs to allow users to query it without the use of ethtool.
> Curious what is the value?

Here are some that I have seen:

10.4-ct-9984-xtH-011-33ec52c8
____000000-20251118163234
____000000-20251015213023
DEV_000000-20240823172837
DEV_000000-20220929104205
89.7207fc64.0 ty-a0-gf-a0-89.uc

Top one is ath10k with CT firmware, next four are an assortment of 
Mediatek radios, bottom is Intel.

> It looks like many drivers, including ath11k and ath12k, do not populate this.
> 
> And this attribute is pointless for Wi-Fi 7 drivers supporting MLO with
> multiple underlying hardware running different firmware images. I suspect
> there are a few wiphy attributes that have this issue.
> 
> You'd need to instantiate these attribute on a per-radio basis to properly
> handle the new multi-radio wiphy model.

Hm, good point. It seems like it would either need a fw_version member 
on the wiphy_radio struct, or something similar to the addresses field 
off the wiphy. Would either of those be acceptable solutions?

- Rory

> 
> /jeff
> 

Re: [PATCH wireless-next] wifi: cfg80211: add fw_version device attribute for sysfs

[Rory Little]

On 7/28/26 10:32 PM, Rory Little wrote:
> On 7/28/26 18:34, Jeff Johnson wrote:
>> On 7/28/2026 4:47 PM, Rory Little wrote:
>>> The firmware version is already exposed via ethtool, but is not
>>> accessible without an attached interface to create a netdev. Expose this
>>> info in sysfs to allow users to query it without the use of ethtool.
>> Curious what is the value?
> 
> Here are some that I have seen:
> 
> 10.4-ct-9984-xtH-011-33ec52c8
> ____000000-20251118163234
> ____000000-20251015213023
> DEV_000000-20240823172837
> DEV_000000-20220929104205
> 89.7207fc64.0 ty-a0-gf-a0-89.uc
> 
> Top one is ath10k with CT firmware, next four are an assortment of 
> Mediatek radios, bottom is Intel.

I just realized that I misinterpreted what you were asking about here. 
Sorry about that.

The value of an interface to query fw_version for us is to keep track of 
system info and generate valuable bug reports (we do our own firmware 
packaging, and certain issues that we encounter can be solved by 
changing firmware version). This particular commit was motivated by the 
desire to be able to query it in any system configuration, as we were 
hitting a case where it needed to be queried while no interfaces were 
attached to the phy (thereby preventing ethtool use).

- Rory