* [PATCH wireless-next v2] wifi: cfg80211: indicate (Re)Association frame encryption to userspace
From: Kavita Kavita @ 2026-04-29 6:25 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, kavita.kavita
In SME-in-driver mode, the driver handles the entire (re)association
exchange. Userspace (e.g., wpa_supplicant) currently has no explicit
indication of whether the (re)association exchange was encrypted,
making it difficult to distinguish EPP (Enhanced Privacy Protection,
IEEE 802.11bi) associations from non-EPP associations.
When (Re)Association frame encryption is used, the (Re)Association
Response frame must contain a Key Delivery element as specified in
IEEE P802.11bi/D4.0, Table 9-65. Userspace must process this element
only when the (Re)Association Response frame is actually encrypted.
Processing it unconditionally for unencrypted frames leads to incorrect
behavior. Without an explicit indication from the driver, userspace
cannot determine whether encryption was used and whether the Key
Delivery element is valid.
Add a new flag attribute NL80211_ATTR_ASSOC_ENCRYPTED and a
corresponding field "assoc_encrypted" in cfg80211_connect_resp_params.
The driver sets this flag to indicate that the (Re)Association
Request/Response frames are transmitted encrypted over the air.
Pass the flag to userspace via NL80211_CMD_CONNECT event.
Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com>
---
Changes in v2:
- This is a continuation of the previous series:
"[PATCH wireless-next 0/2] wifi: cfg80211/mac80211: indicate
(Re)Association frame encryption in SME-in-driver mode".
Now sending as a single patch.
- Dropped the patch 2/2, as there is no current use case for passing
assoc_encrypted when both NL80211_CMD_ASSOCIATE and
NL80211_CMD_CONNECT are indicated.
- Removed redundant NLA_REJECT entry and Updated commit message.
---
include/net/cfg80211.h | 4 ++++
include/uapi/linux/nl80211.h | 9 +++++++++
net/wireless/nl80211.c | 4 +++-
net/wireless/sme.c | 1 +
4 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index a40ab36b8edb..2fa8c1132bfb 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -8838,6 +8838,9 @@ struct cfg80211_fils_resp_params {
* @links.status: per-link status code, to report a status code that's not
* %WLAN_STATUS_SUCCESS for a given link, it must also be in the
* @valid_links bitmap and may have a BSS pointer (which is then released)
+ * @assoc_encrypted: The driver should set this flag to indicate that the
+ * (Re)Association Request/Response frames are transmitted encrypted over
+ * the air.
*/
struct cfg80211_connect_resp_params {
int status;
@@ -8847,6 +8850,7 @@ struct cfg80211_connect_resp_params {
size_t resp_ie_len;
struct cfg80211_fils_resp_params fils;
enum nl80211_timeout_reason timeout_reason;
+ bool assoc_encrypted;
const u8 *ap_mld_addr;
u16 valid_links;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 072b383d7d3c..e26d65c1b737 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -3142,6 +3142,13 @@ enum nl80211_commands {
* association response etc., since it's abridged in the beacon. Used
* for START_AP etc.
*
+ * @NL80211_ATTR_ASSOC_ENCRYPTED: Flag attribute, used only with the
+ * %NL80211_CMD_CONNECT event in SME-in-driver mode. The driver should
+ * set this flag to indicate that both the (Re)Association Request frame
+ * and the corresponding (Re)Association Response frame are transmitted
+ * encrypted over the air. Enhanced Privacy Protection (EPP), as defined
+ * in IEEE P802.11bi/D4.0, mandates this encryption.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -3735,6 +3742,8 @@ enum nl80211_attrs {
NL80211_ATTR_NAN_MAX_CHAN_SWITCH_TIME,
NL80211_ATTR_NAN_PEER_MAPS,
+ NL80211_ATTR_ASSOC_ENCRYPTED,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index cf236307cca9..b96f2f7f67d2 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -20660,7 +20660,9 @@ void nl80211_send_connect_result(struct cfg80211_registered_device *rdev,
(cr->fils.pmk &&
nla_put(msg, NL80211_ATTR_PMK, cr->fils.pmk_len, cr->fils.pmk)) ||
(cr->fils.pmkid &&
- nla_put(msg, NL80211_ATTR_PMKID, WLAN_PMKID_LEN, cr->fils.pmkid)))))
+ nla_put(msg, NL80211_ATTR_PMKID, WLAN_PMKID_LEN, cr->fils.pmkid)))) ||
+ (cr->assoc_encrypted &&
+ nla_put_flag(msg, NL80211_ATTR_ASSOC_ENCRYPTED)))
goto nla_put_failure;
if (cr->valid_links) {
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 86e2ccaa678c..b451df3096dd 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -1066,6 +1066,7 @@ void cfg80211_connect_done(struct net_device *dev,
}
ev->cr.status = params->status;
ev->cr.timeout_reason = params->timeout_reason;
+ ev->cr.assoc_encrypted = params->assoc_encrypted;
spin_lock_irqsave(&wdev->event_lock, flags);
list_add_tail(&ev->list, &wdev->event_list);
base-commit: 7baf5857e15d722776898510a10546d6b2f18645
--
2.34.1
^ permalink raw reply related
* Re: [PATCH wireless-next 2/2] wifi: cfg80211/mac80211: extend cfg80211_rx_assoc_resp_data() for assoc encryption
From: Johannes Berg @ 2026-04-29 6:29 UTC (permalink / raw)
To: Kavita Kavita; +Cc: linux-wireless
In-Reply-To: <d5932baa-7770-4de9-aee0-c51c59294d83@oss.qualcomm.com>
Hi,
Sorry I didn't get back to this yesterday. I see you now just sent
another patch.
> The attribute is intended to indicate that the entire exchange was encrypted,
> not just the Response. For the Response frame, checking ieee80211_has_protected()
> is possible since the full frame is available in data->buf, but for the Request
> frame only IEs are stored in ifmgd->assoc_req_ies, the MAC header is not preserved,
> so I cannot check the Protected bit for the Request.
I guess that makes sense, fair enough.
> While an unencrypted Request paired with an encrypted Response is unlikely in practice,
> we did not want to leave that gap, so I used the epp_peer flag. That said, if you think
> checking the Protected bit on the Response frame alone is sufficient, we are fine with
> that approach too.
It's actually also something wpa_s could check, but I suppose it's
plausible that non-wpa_s observers of these events might be interested.
> In the wireless-next tip, there are already commits that combine both cfg80211
> and mac80211 changes together,
True, but that's usually if the whole thing is small enough I guess?
> so since the assoc_encrypted field addition in
> cfg80211 and the mac80211 epp_peer lookup that sets it are tightly dependent on
> each other, I kept them in the same commit. If you prefer them split into two
> separate commits, I can do that. Will update the commit as well.
I think in this case I might have just preferred to have the first
commit add *all* the infrastructure, and indicate that it's done for
assoc for the reasons above, and then have the second just be mac80211
to fill it?
Not super important though I guess.
johannes
^ permalink raw reply
* Re: [PATCH ath-current] wifi: ath12k: fix peer_id usage in normal RX path
From: Rameshkumar Sundaram @ 2026-04-29 6:44 UTC (permalink / raw)
To: Baochen Qiang, Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260427-ath12k-fix-peer-id-source-v1-1-b5f701fb8e88@oss.qualcomm.com>
On 4/27/2026 11:21 AM, Baochen Qiang wrote:
> ath12k_dp_rx_deliver_msdu() currently uses hal_rx_desc_data::peer_id
> parsed from mpdu_start descriptor to do peer lookup. However In an A-MSDU
> aggregation scenario, hardware only populates mpdu_start descriptor for
> the first sub-msdu, but not the following ones. In that case peer_id could
> be invalid, leading to peer lookup failure:
>
> ath12k_wifi7_pci 0000:06:00.0: rx skb 00000000c391c041 len 1532 peer (null) 0 ucast sn 0 eht320 rate_idx 12 vht_nss 2 freq 6105 band 3 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0
>
> As a result pubsta is NULL and parts of ieee80211_rx_status structure are
> left uninitialized, which may cause unexpected behavior.
>
> Fix it by switching the normal RX path to use ath12k_skb_rxcb::peer_id
> which is parsed from REO ring's rx_mpdu_desc and is always valid.
>
> hal_rx_desc_data::peer_id is still used in
> ath12k_wifi7_dp_rx_frag_h_mpdu(), which is safe since A-MSDU
> aggregation does not occur for fragmented frames. Similarly,
> ath12k_skb_rxcb::peer_id may be overwritten by hal_rx_desc_data::peer_id
> in ath12k_wifi7_dp_rx_h_mpdu(), which only handles non-aggregated
> multicast/broadcast traffic.
>
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
>
> Fixes: 11157e0910fd ("wifi: ath12k: Use ath12k_dp_peer in per packet Tx & Rx paths")
> Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH wireless-next 2/2] wifi: cfg80211/mac80211: extend cfg80211_rx_assoc_resp_data() for assoc encryption
From: Kavita Kavita @ 2026-04-29 6:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <a894a1e0b556ba910e7fad040210f9d531dcf99a.camel@sipsolutions.net>
On 4/29/2026 11:59 AM, Johannes Berg wrote:
> Hi,
>
> Sorry I didn't get back to this yesterday. I see you now just sent
> another patch.
It's fine. Thank you for the review.
>
>> The attribute is intended to indicate that the entire exchange was encrypted,
>> not just the Response. For the Response frame, checking ieee80211_has_protected()
>> is possible since the full frame is available in data->buf, but for the Request
>> frame only IEs are stored in ifmgd->assoc_req_ies, the MAC header is not preserved,
>> so I cannot check the Protected bit for the Request.
>
> I guess that makes sense, fair enough.
>
>> While an unencrypted Request paired with an encrypted Response is unlikely in practice,
>> we did not want to leave that gap, so I used the epp_peer flag. That said, if you think
>> checking the Protected bit on the Response frame alone is sufficient, we are fine with
>> that approach too.
>
> It's actually also something wpa_s could check, but I suppose it's
> plausible that non-wpa_s observers of these events might be interested.
>
>> In the wireless-next tip, there are already commits that combine both cfg80211
>> and mac80211 changes together,
>
> True, but that's usually if the whole thing is small enough I guess?
Yes, it's usually for small changes. This patch is also small.
>
>> so since the assoc_encrypted field addition in
>> cfg80211 and the mac80211 epp_peer lookup that sets it are tightly dependent on
>> each other, I kept them in the same commit. If you prefer them split into two
>> separate commits, I can do that. Will update the commit as well.
>
> I think in this case I might have just preferred to have the first
> commit add *all* the infrastructure, and indicate that it's done for
> assoc for the reasons above, and then have the second just be mac80211
> to fill it?
Well, I have already dropped this patch. I was thinking from a wpa_supplicant perspective,
where NL80211_CMD_ASSOCIATE will be preferred over NL80211_CMD_CONNECT when both are available,
so the assoc_encrypted field in the mac80211 case seemed redundant. However, if there are use
cases with non-wpa_supplicant applications that might prefer NL80211_CMD_CONNECT even when both
events are sent, then there might be value in keeping this patch.
I am not entirely sure about such use cases. Do you think this patch really matters?
If yes, I can bring it back. I think we can keep it as a single patch. Thank you.
>
> Not super important though I guess.
>
> johannes
^ permalink raw reply
* Re: [PATCH net-next] net: Consistently define pci_device_ids using named initializers
From: Andy Shevchenko @ 2026-04-29 6:54 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Michael Grzeschik, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Marc Kleine-Budde, Vincent Mailhol,
Krzysztof Halasa, Johannes Berg, Markus Schneider-Pargmann,
Steffen Klassert, David Dillow, Ion Badulescu, Mark Einon,
Rasesh Mody, GR-Linux-NIC-Dev, Sudarsana Kalluru, Manish Chopra,
Potnuri Bharat Teja, Denis Kirjanov, Jijie Shao, Jian Shen,
Cai Huoqing, Fan Gong, Tony Nguyen, Przemek Kitszel, Tariq Toukan,
Saeed Mahameed, Leon Romanovsky, Mark Bloch, Ido Schimmel,
Petr Machata, Yibo Dong, Simon Horman, Heiner Kallweit, nic_swsd,
Jiri Pirko, Francois Romieu, Daniele Venzano, Samuel Chessman,
Jiawen Wu, Mengyuan Lou, Kevin Curtis, Arend van Spriel,
Stanislav Yakovlev, Richard Cochran, Kees Cook, Thomas Gleixner,
Thomas Fourier, Ingo Molnar, Kory Maincent, Zilin Guan,
Marco Crivellari, Vadim Fedorenko, Jacob Keller, Philipp Stanner,
Bjorn Helgaas, Yeounsu Moon, Denis Benato, Peiyang Wang,
Yonglong Liu, Yicong Hui, Randy Dunlap, MD Danish Anwar,
Nathan Chancellor, Sai Krishna, Ethan Nelson-Moore,
Larysa Zaremba, Joe Damato, Double Lo, Chi-hsien Lin,
Colin Ian King, netdev, linux-kernel, linux-can, linux-parisc,
intel-wired-lan, linux-rdma, oss-drivers, linux-wireless,
brcm80211, brcm80211-dev-list.pdl
In-Reply-To: <20260428171845.2288395-2-u.kleine-koenig@baylibre.com>
On Tue, Apr 28, 2026 at 07:18:44PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> ... and PCI device helpers.
>
> The various struct pci_device_id arrays were initialized mostly by one
> the PCI_DEVICE macros and then list expressions. The latter isn't easily
> readable if you're not into PCI. Using named initializers is more
> explicit and thus easier to parse.
>
> Also use PCI_DEVICE* helper macros to assign .vendor, .device,
> .subvendor and .subdevice where appropriate and skip explicit
> assignments of 0 (which the compiler takes care of).
>
> The secret plan is to make struct pci_device_id::driver_data an
> anonymous union (similar to
> https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/)
> and that requires named initializers. But it's also a nice cleanup on
> its own.
>
> This change doesn't introduce changes to the compiled pci_device_id
> arrays. Tested on x86 and arm64.
...
> - {0,} /* 0 terminated list. */
> + { } /* 0 terminated list. */
The comments like these are just noises. The rule of thumb is to play with a
trailing comma:
- always drop it in the terminator entry
- always keep it in the normal initialisers when semantically it's not a
terminator
...
> static const struct pci_device_id liquidio_pci_tbl[] = {
> { /* 68xx */
> - PCI_VENDOR_ID_CAVIUM, 0x91, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0
> + PCI_VDEVICE(CAVIUM, 0x91)
Use full fixed-width device id value(s). 0x0091 here and so on...
> },
Also seems that you may decrease number of LoC here putting it as
{ PCI_VDEVICE(CAVIUM, 0x0091) }, /* 68xx */
and so on...
> { /* 66xx */
> - PCI_VENDOR_ID_CAVIUM, 0x92, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0
> + PCI_VDEVICE(CAVIUM, 0x92)
> },
> { /* 23xx pf */
> - PCI_VENDOR_ID_CAVIUM, 0x9702, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0
> + PCI_VDEVICE(CAVIUM, 0x9702)
> },
> - {
> - 0, 0, 0, 0, 0, 0, 0
> - }
> + { }
> };
...
> #define CH_PCI_DEVICE_ID_TABLE_DEFINE_END \
> - { 0, } \
> + { } \
> }
Why do we have this macro at all?
> -#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END { 0, } }
> +#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END { } }
Ditto.
...
> static const struct pci_device_id de_pci_tbl[] = {
> - { PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_TULIP,
> - PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> - { PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_TULIP_PLUS,
> - PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1 },
> + { PCI_VDEVICE(DEC, PCI_DEVICE_ID_DEC_TULIP), .driver_data = 0 },
> + { PCI_VDEVICE(DEC, PCI_DEVICE_ID_DEC_TULIP_PLUS), .driver_data = 1 },
> { },
Drop comma. I.o.w. please make sure you also unify the style of the ID tables,
including terminator entries.
> };
...
> static const struct pci_device_id sis190_pci_tbl[] = {
> - { PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0190), 0, 0, 0 },
> - { PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0191), 0, 0, 1 },
> - { 0, },
> + { PCI_VDEVICE(SI, 0x0190), .driver_data = 0 },
> + { PCI_VDEVICE(SI, 0x0191), .driver_data = 1 },
> + { },
Ditto and so on...
> };
...
Also I somehow managed to remove, but I remember you had an inner comma in some
cases after the .driver_data, when the full ID entry is located on a single
line. I.o.w. do
{ PCI_...(), .driver_data = ... // no trailing comma here! },
When it's a single line trailing comma inside helps nothing and just makes
lines longer and harder to read.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: net: add st,stlc45xx/p54spi binding
From: Krzysztof Kozlowski @ 2026-04-29 6:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Aaro Koskinen, Andreas Kemnade,
Bartosz Golaszewski, Benoît Cousson, David S. Miller,
Dmitry Torokhov, Eric Dumazet, Felipe Balbi, Jakub Kicinski,
Johannes Berg, Kevin Hilman, Krzysztof Kozlowski, Linus Walleij,
Paolo Abeni, Rob Herring, Roger Quadros, Tony Lindgren,
linux-wireless, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-gpio, linux-omap, Christian Lamparter
In-Reply-To: <20260427142355.2532714-2-arnd@kernel.org>
On Mon, Apr 27, 2026 at 04:23:53PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The SPI version of Prism54 was sold under a couple of different
> names and supported by the Linux p54spi driver, but there was
> never a DT binding for it.
>
> Document the four known names of this device and the properties
> that are sufficient for its use on the Nokia N8x0 tablet.
>
> As I don't have this hardware or documentation for it, this is
> purely based on existing usage in the driver.
>
> Link: https://lore.kernel.org/all/e8dc9acb-6f85-e0a9-a145-d101ca6da201@gmail.com/
> Acked-by: Christian Lamparter <chunkeey@gmail.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> .../bindings/net/wireless/st,stlc45xx.yaml | 58 +++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/st,stlc45xx.yaml
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 00/15] firmware: qcom: Add OP-TEE PAS service support
From: Mukesh Ojha @ 2026-04-29 6:59 UTC (permalink / raw)
To: Sumit Garg
Cc: andersson, konradybcio, linux-arm-msm, devicetree, dri-devel,
freedreno, linux-media, netdev, linux-wireless, ath12k,
linux-remoteproc, 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, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260427095603.1157963-1-sumit.garg@kernel.org>
On Mon, Apr 27, 2026 at 03:25:48PM +0530, 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-#13: migrates all client drivers to generic PAS service.
> - Patch #14: drops legacy PAS SCM exported APIs.
Gave it a try to test the series on Lemans with Gunyah as well as KVM
hypervisor and all the remote processor are coming up successfully.
Feel free to carry
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
for the Series.
> The patch-set is based on v7.1-rc1 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
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h=qcom-pas-v4
>
> ---
> 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 (14):
> 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
> 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 | 19 +
> drivers/firmware/qcom/Makefile | 2 +
> drivers/firmware/qcom/qcom_pas.c | 288 +++++++++++
> drivers/firmware/qcom/qcom_pas.h | 50 ++
> drivers/firmware/qcom/qcom_pas_tee.c | 479 ++++++++++++++++++
> 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 | 8 +-
> drivers/remoteproc/Kconfig | 1 +
> 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, 1115 insertions(+), 317 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
>
> --
> 2.51.0
>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH] wifi: ath11k: fix warning when unbinding
From: Baochen Qiang @ 2026-04-29 7:23 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez
Cc: ath11k, jjohnson, linux-kernel, linux-wireless, stable
In-Reply-To: <20260429051414.6625-1-jtornosm@redhat.com>
On 4/29/2026 1:14 PM, Jose Ignacio Tornos Martinez wrote:
> Hello Baochen,
>
> As I try to comment in the commit description, the warning is not at
> the intialization, but comes up when the device is unbinded after a
> problem at the initialization stage, because due to the problem the
> buffers were released (probe). Later after the problem, if the unbinding
> is commanded the buffers are released again.
> Setting to NUll after releasing avoids the double free.
>
OK, seems the first release happens during the error handling path of
ath11k_core_qmi_firmware_ready().
> The easiest way to reproduce it is to run in a VM the default upstream
> kernel (that is always failing on VMs) and just unbind the device
> (ath11k_pci).
>
> The same problem was fixed by me for ath12k driver here ca68ce0d9f4b
> ("wifi: ath12k: fix warning when unbinding"), and I have seen the same problem
> is also happening for ath11k driver.
>
> Thanks
>
> Best regards
> José Ignacio
>
^ permalink raw reply
* Re: [PATCH wireless-next 1/2] wifi: cfg80211/mac80211: change memory allocation for link_sinfo structure
From: Sarika Sharma @ 2026-04-29 7:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <eb8474cd25dd12541557afecf3434e58a69a322b.camel@sipsolutions.net>
On 29-04-2026 11:46, Johannes Berg wrote:
> On Wed, 2026-04-29 at 11:38 +0530, Sarika Sharma wrote:
>>
>> On 28-04-2026 15:01, Johannes Berg wrote:
>>> On Tue, 2026-04-28 at 14:39 +0530, Sarika Sharma wrote:
>>>>
>>>> +int cfg80211_alloc_link_sinfo_stats(struct link_station_info **link_sinfo,
>>>
>>> really?
>>>
>>> johannes
>>
>> So, this helper API I introduced in cfg80211 since struct
>> link_station_info is defined and primarily used
>> there. Keeping allocation and lifetime management in cfg80211 ensures
>> consistent ownership and cleanup once the link_station_info is consumed.
>>
>> Please let me know if I understood your concern correctly, or if you
>> were referring to something else in this patch.
>
> Hah, right. I was merely thinking of returning an error and using a
> double-pointer for assignment. There are better ways of doing that.
>
> johannes
Thanks for the clarification. I can rework this to use a simpler pattern.
^ permalink raw reply
* Re: [PATCH v4] wifi: ath11k: fix peer resolution on rx path when peer_id=0
From: Baochen Qiang @ 2026-04-29 7:36 UTC (permalink / raw)
To: Matthew Leach, Jeff Johnson
Cc: Rameshkumar Sundaram, linux-wireless, ath11k, linux-kernel,
kernel
In-Reply-To: <20260424-ath11k-null-peerid-workaround-v4-1-252b224d3cf6@collabora.com>
On 4/24/2026 5:50 PM, Matthew Leach wrote:
> It has been observed that on certain chipsets a peer can be assigned
> peer_id=0. For reception of non-aggregated MPDUs this is fine as
> ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer
> based upon the source MAC address. On an aggregated link, the mpdu_start
> header is only populated by hardware on the first sub-MSDU. This causes
> the peer resolution to be skipped for the subsequent MSDUs and the
> encryption type of these frames to be set to an incorrect value,
> resulting in these MSDUs being dropped by ieee80211.
>
> ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0
> ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1
>
> Remove the null peer_id checks in ath11k_dp_rx_h_find_peer() and
> ath11k_hal_rx_parse_mon_status_tlv(), allowing peers with an assigned ID
> of 0 to be resolved.
>
> Fixes: 2167fa606c0f ("ath11k: Add support for RX decapsulation offload")
> Tested-on: QCA2066 hw2.1 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.9
Tested-on: is not an official tag but is ath driver specific, so generally it is put above
all official tags:
Tested-on: ...
<blank line>
Fixes: ...
s-o-b: ...
But since this is trivial I think Jeff can make the change when he merges it, so no need
to respin just for it.
> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> Signed-off-by: Matthew Leach <matthew.leach@collabora.com>
> ---
> Changes in v4:
> - Prefix subsystem with 'wifi:'.
> - Added the 'Tested-by' and 'Fixes' trailers.
> - Link to v3: https://patch.msgid.link/20260417-ath11k-null-peerid-workaround-v3-1-d04302284486@collabora.com
>
> Changes in v3:
> - Clarified that the mpdu_start header isn't populated by the h/w for
> all sub-MSDUs in the commit message.
> - Fix second null-peer check in ath11k_hal_rx_parse_mon_status_tlv().
> - Link to v2: https://patch.msgid.link/20260415-ath11k-null-peerid-workaround-v2-1-2abae3bbac16@collabora.com
>
> Changes in v2:
>
> - Since peer_id=0 is a valid condition on some chips, remove the guard
> that prevented the peer lookup.
> - Link to v1: https://patch.msgid.link/20260326-ath11k-null-peerid-workaround-v1-1-0c2fd53202f8@collabora.com
>
> To: Jeff Johnson <jjohnson@kernel.org>
> Cc: linux-wireless@vger.kernel.org
> Cc: ath11k@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/net/wireless/ath/ath11k/dp_rx.c | 3 +--
> drivers/net/wireless/ath/ath11k/hal_rx.c | 5 +----
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
> index 49d959b2e148..ff2c78a4e5f3 100644
> --- a/drivers/net/wireless/ath/ath11k/dp_rx.c
> +++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
> @@ -2215,8 +2215,7 @@ ath11k_dp_rx_h_find_peer(struct ath11k_base *ab, struct sk_buff *msdu)
>
> lockdep_assert_held(&ab->base_lock);
>
> - if (rxcb->peer_id)
> - peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
> + peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
>
> if (peer)
> return peer;
> diff --git a/drivers/net/wireless/ath/ath11k/hal_rx.c b/drivers/net/wireless/ath/ath11k/hal_rx.c
> index 753bd93f0212..51e0840bc0d1 100644
> --- a/drivers/net/wireless/ath/ath11k/hal_rx.c
> +++ b/drivers/net/wireless/ath/ath11k/hal_rx.c
> @@ -1467,11 +1467,8 @@ ath11k_hal_rx_parse_mon_status_tlv(struct ath11k_base *ab,
> case HAL_RX_MPDU_START: {
> struct hal_rx_mpdu_info *mpdu_info =
> (struct hal_rx_mpdu_info *)tlv_data;
> - u16 peer_id;
>
> - peer_id = ath11k_hal_rx_mpduinfo_get_peerid(ab, mpdu_info);
> - if (peer_id)
> - ppdu_info->peer_id = peer_id;
> + ppdu_info->peer_id = ath11k_hal_rx_mpduinfo_get_peerid(ab, mpdu_info);
> break;
> }
> case HAL_RXPCU_PPDU_END_INFO: {
>
> ---
> base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
> change-id: 20260326-ath11k-null-peerid-workaround-625a129781b1
>
> Best regards,
> --
> Matt
>
^ permalink raw reply
* Re: [PATCH wireless] wifi: ath11k: fix monitor mode frame length by using correct descriptor size
From: Rameshkumar Sundaram @ 2026-04-29 7:38 UTC (permalink / raw)
To: Joshua Klinesmith, linux-wireless; +Cc: ath11k
In-Reply-To: <20260407024836.53871-1-joshuaklinesmith@gmail.com>
On 4/7/2026 8:18 AM, Joshua Klinesmith wrote:
> The monitor mode RX path in ath11k_dp_rx_mon_mpdu_pop() and
> ath11k_dp_rx_full_mon_mpdu_pop() uses sizeof(struct hal_rx_desc) to
> compute the packet buffer offset. This is the size of the union of all
> chip-specific descriptors (the maximum), not the actual descriptor size
> for the running chip. The later ath11k_dp_rx_msdus_set_payload() then
> strips only hw_params.hal_desc_sz bytes (the chip-specific size) from
> the front of the skb.
>
> On IPQ8074 and QCN9074, sizeof(struct hal_rx_desc) is 392 but
> hal_desc_sz is 384, leaving 8 extra bytes of descriptor data at the
> end of every monitor mode frame delivered to userspace. On WCN6855 the
> sizes happen to match so the bug is not visible.
>
> The same mismatch in ath11k_dp_mon_set_frag_len() causes incorrect
> fragment length calculation for multi-buffer MSDUs, under-counting
> intermediate fragments by 8 bytes and over-counting the last fragment.
>
> Fix by using ar->ab->hw_params.hal_desc_sz consistently in both
> monitor mpdu_pop functions and passing it through to set_frag_len.
It would be useful to add a Tested-on: tag if this was validated on
affected hardware, as suggested in the ath11k submission guidelines.
>
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Since the full_mon side was added later by 7e2ea2e94704, it may be worth
adding that as a second Fixes: tag for completeness.
> Link: https://github.com/openwrt/openwrt/issues/16183
> Signed-off-by: Joshua Klinesmith <joshuaklinesmith@gmail.com>
> ---
> drivers/net/wireless/ath/ath11k/dp_rx.c | 27 ++++++++++++++-----------
> 1 file changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
> index 85defe11750d..c86ffc203f15 100644
> --- a/drivers/net/wireless/ath/ath11k/dp_rx.c
> +++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
> @@ -4511,10 +4511,11 @@ int ath11k_dp_rx_pdev_alloc(struct ath11k_base *ab, int mac_id)
> return 0;
> }
>
> -static void ath11k_dp_mon_set_frag_len(u32 *total_len, u32 *frag_len)
> +static void ath11k_dp_mon_set_frag_len(u32 *total_len, u32 *frag_len,
> + u32 hal_desc_sz)
> {
> - if (*total_len >= (DP_RX_BUFFER_SIZE - sizeof(struct hal_rx_desc))) {
> - *frag_len = DP_RX_BUFFER_SIZE - sizeof(struct hal_rx_desc);
> + if (*total_len >= (DP_RX_BUFFER_SIZE - hal_desc_sz)) {
> + *frag_len = DP_RX_BUFFER_SIZE - hal_desc_sz;
> *total_len -= *frag_len;
> } else {
> *frag_len = *total_len;
> @@ -4658,19 +4659,19 @@ static u32 ath11k_dp_rx_mon_comp_ppduid(u32 msdu_ppdu_id, u32 *ppdu_id,
>
> static void ath11k_dp_mon_get_buf_len(struct hal_rx_msdu_desc_info *info,
> bool *is_frag, u32 *total_len,
> - u32 *frag_len, u32 *msdu_cnt)
> + u32 *frag_len, u32 *msdu_cnt,
> + u32 hal_desc_sz)
> {
> if (info->msdu_flags & RX_MSDU_DESC_INFO0_MSDU_CONTINUATION) {
> if (!*is_frag) {
> *total_len = info->msdu_len;
> *is_frag = true;
> }
> - ath11k_dp_mon_set_frag_len(total_len,
> - frag_len);
> + ath11k_dp_mon_set_frag_len(total_len, frag_len, hal_desc_sz);
> } else {
> if (*is_frag) {
> - ath11k_dp_mon_set_frag_len(total_len,
> - frag_len);
> + ath11k_dp_mon_set_frag_len(total_len, frag_len,
> + hal_desc_sz);
> } else {
> *frag_len = info->msdu_len;
> }
> @@ -4792,7 +4793,7 @@ u32 ath11k_dp_rx_mon_mpdu_pop(struct ath11k *ar, int mac_id,
>
> rx_desc = (struct hal_rx_desc *)msdu->data;
>
> - rx_pkt_offset = sizeof(struct hal_rx_desc);
> + rx_pkt_offset = ar->ab->hw_params.hal_desc_sz;
> l2_hdr_offset = ath11k_dp_rx_h_msdu_end_l3pad(ar->ab, rx_desc);
>
> if (is_first_msdu) {
> @@ -4823,7 +4824,8 @@ u32 ath11k_dp_rx_mon_mpdu_pop(struct ath11k *ar, int mac_id,
> }
> ath11k_dp_mon_get_buf_len(&msdu_list.msdu_info[i],
> &is_frag, &total_len,
> - &frag_len, &msdu_cnt);
> + &frag_len, &msdu_cnt,
> + rx_pkt_offset);
> rx_buf_size = rx_pkt_offset + l2_hdr_offset + frag_len;
>
> ath11k_dp_pkt_set_pktlen(msdu, rx_buf_size);
> @@ -5424,7 +5426,7 @@ ath11k_dp_rx_full_mon_mpdu_pop(struct ath11k *ar,
>
> rx_desc = (struct hal_rx_desc *)msdu->data;
>
> - rx_pkt_offset = sizeof(struct hal_rx_desc);
> + rx_pkt_offset = ar->ab->hw_params.hal_desc_sz;
> l2_hdr_offset = ath11k_dp_rx_h_msdu_end_l3pad(ar->ab, rx_desc);
>
> if (is_first_msdu) {
> @@ -5439,7 +5441,8 @@ ath11k_dp_rx_full_mon_mpdu_pop(struct ath11k *ar,
>
> ath11k_dp_mon_get_buf_len(&msdu_list.msdu_info[i],
> &is_frag, &total_len,
> - &frag_len, &msdu_cnt);
> + &frag_len, &msdu_cnt,
> + rx_pkt_offset);
>
> rx_buf_size = rx_pkt_offset + l2_hdr_offset + frag_len;
>
The code change itself looks correct to me.
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v3 3/3] p54spi: convert to devicetree
From: Krzysztof Kozlowski @ 2026-04-29 8:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Aaro Koskinen, Andreas Kemnade,
Bartosz Golaszewski, Benoît Cousson, David S. Miller,
Dmitry Torokhov, Eric Dumazet, Felipe Balbi, Jakub Kicinski,
Johannes Berg, Kevin Hilman, Krzysztof Kozlowski, Linus Walleij,
Paolo Abeni, Rob Herring, Roger Quadros, Tony Lindgren,
linux-wireless, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-gpio, linux-omap, Christian Lamparter
In-Reply-To: <20260427142355.2532714-4-arnd@kernel.org>
On 27/04/2026 16:23, Arnd Bergmann wrote:
>
> - ret = gpio_request(p54spi_gpio_power, "p54spi power");
> - if (ret < 0) {
> - dev_err(&priv->spi->dev, "power GPIO request failed: %d", ret);
> + priv->gpio_powerdown = gpiod_get(&spi->dev, "powerdown", GPIOD_OUT_HIGH);
> + if (IS_ERR(priv->gpio_powerdown)) {
> + ret = PTR_ERR(priv->gpio_powerdown);
> + dev_err(&priv->spi->dev, "powerdown GPIO request failed: %d", ret);
Binding said it is optional, so this cannot be a failure.
Also, please use ret = dev_err_probe syntax.
> goto err_free;
> }
>
> - ret = gpio_request(p54spi_gpio_irq, "p54spi irq");
> - if (ret < 0) {
> - dev_err(&priv->spi->dev, "irq GPIO request failed: %d", ret);
> - goto err_free_gpio_power;
> - }
> -
> - gpio_direction_output(p54spi_gpio_power, 0);
> - gpio_direction_input(p54spi_gpio_irq);
> -
> - ret = request_irq(gpio_to_irq(p54spi_gpio_irq),
> - p54spi_interrupt, IRQF_NO_AUTOEN, "p54spi",
> - priv->spi);
> + ret = request_irq(spi->irq, p54spi_interrupt, IRQF_NO_AUTOEN, "p54spi", priv->spi);
> if (ret < 0) {
> dev_err(&priv->spi->dev, "request_irq() failed");
> - goto err_free_gpio_irq;
> + goto err_free_gpio_power;
> }
>
> - irq_set_irq_type(gpio_to_irq(p54spi_gpio_irq), IRQ_TYPE_EDGE_RISING);
>
> INIT_WORK(&priv->work, p54spi_work);
> init_completion(&priv->fw_comp);
> @@ -659,11 +636,9 @@ static int p54spi_probe(struct spi_device *spi)
>
> err_free_common:
> release_firmware(priv->firmware);
> - free_irq(gpio_to_irq(p54spi_gpio_irq), spi);
> -err_free_gpio_irq:
> - gpio_free(p54spi_gpio_irq);
> + free_irq(priv->irq, spi);
> err_free_gpio_power:
> - gpio_free(p54spi_gpio_power);
> + gpiod_put(priv->gpio_powerdown);
> err_free:
> p54_free_common(priv->hw);
> return ret;
> @@ -675,10 +650,8 @@ static void p54spi_remove(struct spi_device *spi)
>
> p54_unregister_common(priv->hw);
>
> - free_irq(gpio_to_irq(p54spi_gpio_irq), spi);
> -
> - gpio_free(p54spi_gpio_power);
> - gpio_free(p54spi_gpio_irq);
> + free_irq(priv->irq, spi);
> + gpiod_put(priv->gpio_powerdown);
> release_firmware(priv->firmware);
>
> mutex_destroy(&priv->mutex);
> @@ -686,10 +659,19 @@ static void p54spi_remove(struct spi_device *spi)
> p54_free_common(priv->hw);
> }
>
> +struct of_device_id p54spi_of_ids[] = {
static const
> + { .compatible = "cnxt,3110x", },
> + { .compatible = "isil,p54spi", },
> + { .compatible = "st,stlc4550", },
> + { .compatible = "st,stlc4560", },
At least last two devices are then compatible, so this should be
expressed in the binding with fallback and drop stlc4560 here. Maybe all
of them are compatible.
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, p54spi_of_ids);
>
> static struct spi_driver p54spi_driver = {
> .driver = {
> .name = "p54spi",
> + .of_match_table = p54spi_of_ids,
> },
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 3/3] p54spi: convert to devicetree
From: Johannes Berg @ 2026-04-29 8:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Aaro Koskinen, Andreas Kemnade,
Bartosz Golaszewski, Benoît Cousson, David S. Miller,
Dmitry Torokhov, Eric Dumazet, Felipe Balbi, Jakub Kicinski,
Kevin Hilman, Krzysztof Kozlowski, Linus Walleij, Paolo Abeni,
Rob Herring, Roger Quadros, Tony Lindgren, linux-wireless, netdev,
devicetree, linux-kernel, linux-arm-kernel, linux-gpio,
linux-omap, Christian Lamparter
In-Reply-To: <20260427142355.2532714-4-arnd@kernel.org>
Since you got comments anyway...
> }
>
> - irq_set_irq_type(gpio_to_irq(p54spi_gpio_irq), IRQ_TYPE_EDGE_RISING);
>
> INIT_WORK(&priv->work, p54spi_work);
This leaves two adjacent blank lines.
johannes
^ permalink raw reply
* [PATCH 0/1] dt-bindings: net: wireless: intel,iwlwifi: add binding
From: Avinash Bhatt @ 2026-04-29 8:14 UTC (permalink / raw)
To: devicetree
Cc: linux-wireless, linux-kernel, robh, krzk+dt, conor+dt, johannes,
miriam.rachel.korenblit, kobi.guetta, emmanuel.grumbach,
Avinash Bhatt
Add Device Tree binding schema for Intel discrete Wi-Fi 7 BE200 PCIe
adapters. The binding documents optional OEM platform configuration
properties for platforms using Device Tree instead of ACPI/UEFI firmware
methods.
Link to RFC: https://patchwork.kernel.org/project/devicetree/patch/20260408055709.11579-2-avinash.bhatt@intel.com/
Avinash Bhatt (1):
dt-bindings: net: wireless: intel,iwlwifi: add binding
.../bindings/net/wireless/intel,iwlwifi.yaml | 445 ++++++++++++++++++
1 file changed, 445 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml
--
2.34.1
^ permalink raw reply
* [PATCH 1/1] dt-bindings: net: wireless: intel,iwlwifi: add binding
From: Avinash Bhatt @ 2026-04-29 8:14 UTC (permalink / raw)
To: devicetree
Cc: linux-wireless, linux-kernel, robh, krzk+dt, conor+dt, johannes,
miriam.rachel.korenblit, kobi.guetta, emmanuel.grumbach,
Avinash Bhatt
In-Reply-To: <20260429081403.46087-1-avinash.bhatt@intel.com>
Add a devicetree schema binding for Intel discrete Wi-Fi 7 BE200 PCIe
adapters.
The binding documents OEM platform configuration properties for
platforms that use Device Tree instead of platform firmware
methods. All properties mirror the existing equivalents in
structure and semantics, covering SAR power limits (intel,wrds),
6 GHz AP type support (intel,uats), static power limit
(intel,splc), channel puncturing (intel,wcpe), 320 MHz per-MCC
enablement (intel,wbem), ETSI SRD channel configuration
(intel,srd), 6-7 GHz UHB country enable bitmask (intel,6e-uhb),
and additional regulatory override properties.
Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
---
.../bindings/net/wireless/intel,iwlwifi.yaml | 445 ++++++++++++++++++
1 file changed, 445 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml
diff --git a/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml b/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml
new file mode 100644
index 000000000000..d97be6cc35d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml
@@ -0,0 +1,445 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2026 Intel Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/wireless/intel,iwlwifi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel iwlwifi PCIe Wi-Fi devices
+
+maintainers:
+ - Avinash Bhatt <avinash.bhatt@intel.com>
+ - linux-wireless@vger.kernel.org
+
+description:
+ Intel iwlwifi IEEE 802.11be discrete Wi-Fi adapters connected over PCIe.
+ These bindings provide OEM platform configuration for platforms that use Device Tree.
+
+properties:
+ compatible:
+ enum:
+ - pci8086,272b
+
+ reg:
+ maxItems: 1
+
+ intel,wrds:
+ description: |
+ Wi-Fi Regulatory Domain Settings (WRDS). SAR (Specific Absorption Rate)
+ transmit power limits per antenna chain and frequency subband. Values
+ are 8-bit unsigned in units of 0.125 dBm.
+
+ Revision 3 layout: 4 chains x 12 subbands = 50 cells total.
+ Chain A and Chain B are the two physical antenna paths; CDB Chain A
+ and CDB Chain B carry separate limits for simultaneous dual-band
+ operation.
+
+ Header (2 cells):
+ [0] revision - structure revision, must be 0x03
+ [1] mode - bit 0: 0 = SAR disabled, 1 = SAR enabled; bits [8:1]: set to 0
+
+ Followed by 4 chains in order: chain_a, chain_b, cdb_chain_a,
+ cdb_chain_b, each containing 12 subband values:
+
+ Subband index to frequency range mapping:
+ [0] 2.4 GHz ch 1-13 (2412-2472 MHz)
+ [1] 5 GHz ch 36-64 (5180-5320 MHz, UNII-1/2)
+ [2] 5 GHz ch 68-96 (5340-5480 MHz, UNII-2)
+ [3] 5 GHz ch 100-144 (5500-5720 MHz, UNII-2e)
+ [4] 5 GHz ch 149-188 (5745-5940 MHz, UNII-3/4)
+ [5] 6 GHz ch 1-45 (5955-6175 MHz, UNII-5 lower)
+ [6] 6 GHz ch 49-93 (6195-6415 MHz, UNII-5 upper)
+ [7] 6 GHz ch 97-115 (6435-6525 MHz, UNII-6)
+ [8] 6 GHz ch 117-151 (6535-6705 MHz, UNII-7 lower)
+ [9] 6 GHz ch 153-183 (6715-6865 MHz, UNII-7 upper)
+ [10] 6 GHz ch 185-233 (6875-7115 MHz, UNII-8)
+ [11] 6 GHz ch 237-253 (7135-7215 MHz, UNII-9)
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - minItems: 50
+ maxItems: 50
+ items:
+ - const: 3
+
+ intel,uats:
+ description: |
+ UHB (Ultra High Band / 6 GHz) AP Type Support (UATS). Per-country
+ enablement matrix for 6 GHz AP types. Uses byte array format
+ (DTS [ ... ] notation).
+
+ In the 6 GHz band, regulatory rules differ per country and per AP
+ type: AFC (Standard Power), LPI (Low Power Indoor), and VLP (Very
+ Low Power). This matrix encodes which AP types are permitted to
+ operate in each country.
+
+ Revision 1 layout (339 bytes total):
+ [0] revision - structure revision, must be 0x01
+ [1+] country_map - 338-byte matrix encoding AP type allowances
+ per country.
+
+ Countries are identified by their ISO 3166-1
+ alpha-2 code (two letters, A-Z each). The
+ matrix covers all 26x26 = 676 possible
+ two-letter combinations (AA..ZZ), most of
+ which are unused (set to 0x0).
+
+ Each country entry is 4 bits (a nibble). Two
+ entries are packed per byte: the low nibble
+ holds the even-indexed entry, the high nibble
+ holds the odd-indexed entry. For example,
+ byte value 0x53 means: entry[even]=0x3,
+ entry[odd]=0x5.
+
+ The matrix is stored column-major by first
+ letter: all 26 second-letter variants for
+ first letter 'A' occupy bytes [0..12], then
+ first letter 'B' occupies bytes [13..25],
+ and so on for all 26 first letters.
+ 26 columns x 13 bytes = 338 bytes total.
+
+ Each 4-bit nibble encodes AP type allowances
+ for one country:
+ bit 0: AFC (Standard Power AP) allowed
+ bit 1: VLP (Very Low Power AP) allowed
+ bit 2: LPI (Low Power Indoor AP) allowed
+ bit 3: reserved, must be 0
+
+ Note: each bit is only effective when the
+ corresponding control bit in intel,6e-uhb
+ is also set (bit 30 for AFC, bit 29
+ for VLP, bit 31 for LPI country-by-country
+ mode).
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint8-array
+ - minItems: 339
+ maxItems: 339
+ items:
+ - const: 1
+
+ intel,srd:
+ description: |
+ ETSI 5.8 GHz SRD (Short Range Device) channel configuration.
+ Controls how the driver handles the 5725-5875 MHz (5.8 GHz) SRD
+ channels in ETSI regulatory domains.
+
+ Layout (2 cells):
+ [0] revision - structure revision, must be 0x00
+ [1] value - channel configuration:
+ 0 = active scan permitted (default behaviour)
+ 1 = passive scan only; device may associate and
+ transfer data but must not transmit probe
+ requests on SRD channels
+ 2 = SRD channels fully disabled; the device must
+ not scan, associate, or operate on any of the
+ 5725-5875 MHz SRD channels
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - minItems: 2
+ maxItems: 2
+ items:
+ - const: 0
+ - enum: [0, 1, 2]
+
+ intel,6e-uhb:
+ description: |
+ 6-7 GHz Ultra-High Band (UHB) per-country enable bitmask.
+
+ Layout (2 cells):
+ [0] revision - structure revision, must be 0x00
+ [1] bitmap - UHB enablement control:
+ bit 0: override control; 0 = use device defaults,
+ 1 = force-disable all countries not
+ explicitly enabled in bits 1-25
+ bits 1-25: per-country/region enable flags:
+ bit 1 = USA
+ bit 2 = Rest of World (ROW)
+ bit 3 = EU
+ bit 4 = South Korea
+ bit 5 = Brazil
+ bit 6 = Chile
+ bit 7 = Japan
+ bit 8 = Canada
+ bit 9 = Morocco
+ bit 10 = Mongolia
+ bit 11 = Malaysia
+ bit 12 = Saudi Arabia
+ bit 13 = Mexico
+ bit 14 = Nigeria
+ bit 15 = Thailand
+ bit 16 = Singapore
+ bit 17 = Taiwan
+ bit 18 = South Africa
+ bit 19 = Philippines
+ bit 20 = Serbia
+ bit 21 = Indonesia
+ bit 22 = Azerbaijan
+ bit 23 = Paraguay
+ bit 24 = Vietnam
+ bit 25 = India
+ bit 26: reserved, must be 0
+ bit 27: enable VLP active scan, SoftAP, and
+ P2P-GO operation in Japan
+ bit 28: reserved, must be 0
+ bit 29: enable VLP (Very Low Power) mode per
+ country-by-country table
+ bit 30: enable AFC (Standard Power) mode per
+ country-by-country table
+ bit 31: LPI override mode; 0 = use grouping
+ mechanism, 1 = use country-by-country table
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - minItems: 2
+ maxItems: 2
+ items:
+ - const: 0
+
+ intel,regulatory-special:
+ description: |
+ Regulatory Special Configurations.
+
+ Layout (2 cells):
+ [0] revision - structure revision, must be 0x00
+ [1] bitmap - configuration flags:
+ bits 0-3: reserved, must be 0
+ bit 4 = Australia UHB extension
+ bits 5-31: reserved, must be 0
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - minItems: 2
+ maxItems: 2
+ items:
+ - const: 0
+
+ intel,activate-channel:
+ description: |
+ Indoor channel activation bitmask. Sets specific frequency bands to
+ active (rather than passive or disabled) when the platform is
+ confirmed to be operating indoors.
+
+ Layout (2 cells):
+ [0] revision - structure revision, must be 0x00
+ [1] bitmap - per-region indoor activation flags:
+ bit 0 = enable EU U-NII-1 (5.2 GHz) for indoors only
+ bit 1 = enable Japan U-NII-1 (5.2 GHz) for indoors only
+ bit 2 = enable China Mainland U-NII-1 (5.2 GHz) for indoors only
+ bit 3 = enable USA U-NII-4 (5.9 GHz) for indoors only
+ bit 4 = enable WW U-NII-1 (5.2 GHz) for indoors in any
+ country where the band is permitted
+ bit 5 = enable Canada U-NII-4 (5.9 GHz) for indoors only
+ bit 6 = enable USA + Canada + WW U-NII-4 (5.9 GHz) for
+ indoors only
+ bits 7-31: reserved, must be 0
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - minItems: 2
+ maxItems: 2
+ items:
+ - const: 0
+
+ intel,force-disable-channels:
+ description: |
+ Selective Wi-Fi band force-disable bitmask. Allows the platform to
+ permanently disable specific frequency bands regardless of regulatory
+ domain.
+
+ Layout (2 cells):
+ [0] revision - structure revision, must be 0x00
+ [1] bitmap - per-band force-disable flags:
+ bit 0 = force disable 2.4 GHz (channels 1-13)
+ bit 1 = force disable 5.2 GHz (channels 36-48)
+ bit 2 = force disable 5.3 GHz (channels 52-64)
+ bit 3 = force disable 5.5 GHz (channels 100-144)
+ bit 4 = force disable 5.8 GHz (channels 149-165)
+ bit 5 = force disable 5.9 GHz (channels 169-177)
+ bit 6 = force disable 6.2 GHz (channels 1-93)
+ bit 7 = force disable 6.5 GHz (channels 97-113)
+ bit 8 = force disable 6.6 GHz (channels 117-153)
+ bit 9 = force disable 6.8 GHz (channels 157-185)
+ bit 10 = force disable 7.0 GHz (channels 185-233)
+ bits 11-31: reserved, must be 0
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - minItems: 2
+ maxItems: 2
+ items:
+ - const: 0
+
+ intel,11be:
+ description: |
+ 802.11be (Wi-Fi 7) per-country enable bitmask. Controls whether
+ 802.11be operation is permitted in specific countries.
+
+ Layout (2 cells):
+ [0] revision - structure revision, must be 0x00
+ [1] bitmap - per-country enable flags:
+ bit 0 = enable 802.11be in China (CB/CN)
+ bit 1 = enable 802.11be in South Korea
+ bits 2-31: reserved, must be 0
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - minItems: 2
+ maxItems: 2
+ items:
+ - const: 0
+
+ intel,splc:
+ description: |
+ Wi-Fi Static Power Limit Capabilities (SPLC). Sets the platform thermal
+ power limit for the Wi-Fi core in mW. Omit this property entirely if
+ no platform power limit applies; the device will use its certified
+ maximum in that case.
+
+ Layout (2 cells):
+ [0] revision - structure revision, must be 0x00
+ [1] power_limit - maximum platform power budget in mW, must be
+ non-zero (a zero value is equivalent to omitting
+ the property)
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - minItems: 2
+ maxItems: 2
+ items:
+ - const: 0
+ - minimum: 1
+
+ intel,wcpe:
+ description: |
+ Wi-Fi Channel Puncturing Enablement (WCPE). Enables 802.11be channel
+ puncturing for specific regulatory domains.
+
+ Layout (2 cells):
+ [0] revision - structure revision, must be 0x00
+ [1] puncturing - per-country enable bitmask:
+ bit 0: 1 = channel puncturing enabled for USA
+ bit 1: 1 = channel puncturing enabled for Canada
+ bits 2-31: reserved, must be 0
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - minItems: 2
+ maxItems: 2
+ items:
+ - const: 0
+
+ intel,wbem:
+ description: |
+ Wi-Fi 320 MHz Bandwidth Enablement per MCC (WBEM). Controls whether
+ 320 MHz operation is permitted in specific countries.
+
+ Layout (2 cells):
+ [0] revision - structure revision, must be 0x00
+ [1] wifi320mhz_mcc - per-country enable bitmask:
+ bit 0: 1 = 320 MHz enabled for Japan
+ bit 1: 1 = 320 MHz enabled for South Korea
+ bits 2-31: reserved, must be 0
+
+ Each bit takes effect only if the installed
+ module is certified for 320 MHz in that country.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - minItems: 2
+ maxItems: 2
+ items:
+ - const: 0
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ /* ARM64 platform with Intel Wi-Fi 7 BE200 as discrete PCIe device */
+ pcie {
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ bus-range = <0x01 0xff>;
+
+ wifi@0 {
+ compatible = "pci8086,272b";
+ reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+ /*
+ * Wi-Fi Regulatory Domain Settings (SAR power limits).
+ * Revision 3: 4 chains x 12 subbands = 50 cells total.
+ * Layout: revision, mode, then 4 x chain[12].
+ */
+ intel,wrds = <
+ 0x03 0x01
+ /* Chain A: 12 subbands */
+ 0x38 0x38 0x38 0x38 0x38 0x38 0x38 0x38 0x38 0x38 0x38 0x38
+ /* Chain B: 12 subbands */
+ 0x38 0x38 0x38 0x38 0x38 0x38 0x38 0x38 0x38 0x38 0x38 0x38
+ /* CDB Chain A: 12 subbands */
+ 0x3c 0x3c 0x3c 0x3c 0x3c 0x3c 0x3c 0x3c 0x3c 0x3c 0x3c 0x3c
+ /* CDB Chain B: 12 subbands */
+ 0x3c 0x3c 0x3c 0x3c 0x3c 0x3c 0x3c 0x3c 0x3c 0x3c 0x3c 0x3c
+ >;
+
+ /*
+ * Static Power Limit: 4500 mW cap on this platform.
+ * 2 u32 cells: revision, power_limit_mw.
+ */
+ intel,splc = <0x00 0x1194>;
+
+ /*
+ * Channel Puncturing: enabled for USA and Canada.
+ * 2 u32 cells: revision, puncturing bitmask (bits 0+1).
+ */
+ intel,wcpe = <0x00 0x03>;
+
+ /*
+ * 320 MHz per MCC: Japan and South Korea enabled.
+ * 2 u32 cells: revision, wifi320mhz_mcc.
+ */
+ intel,wbem = <0x00 0x03>;
+
+ /* OEM regulatory configuration properties. */
+ intel,srd = <0x00 1>; /* revision=0, passive scan only */
+ intel,activate-channel = <0x00 0x01>; /* revision=0, EU 5.2 GHz indoors */
+ intel,force-disable-channels = <0x00 0x00>; /* revision=0, no bands disabled */
+ intel,6e-uhb = <0x00 0x06>; /* revision=0, USA (bit1) + Rest-of-World (bit2) */
+
+ /*
+ * UHB AP Type Support (6 GHz country matrix).
+ * Byte array: revision (0x01), then
+ * 338 bytes of the 26x13 country enable map (all zeros
+ * in this example = no countries enabled).
+ */
+ intel,uats = [01
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00 00 00 00 00 00];
+ };
+ };
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 1/1] dt-bindings: net: wireless: intel,iwlwifi: add binding
From: Krzysztof Kozlowski @ 2026-04-29 8:19 UTC (permalink / raw)
To: Avinash Bhatt, devicetree
Cc: linux-wireless, linux-kernel, robh, krzk+dt, conor+dt, johannes,
miriam.rachel.korenblit, kobi.guetta, emmanuel.grumbach
In-Reply-To: <20260429081403.46087-2-avinash.bhatt@intel.com>
On 29/04/2026 10:14, Avinash Bhatt wrote:
> Add a devicetree schema binding for Intel discrete Wi-Fi 7 BE200 PCIe
> adapters.
Why? Where is any user of that?
>
> The binding documents OEM platform configuration properties for
> platforms that use Device Tree instead of platform firmware
> methods. All properties mirror the existing equivalents in
> structure and semantics, covering SAR power limits (intel,wrds),
> 6 GHz AP type support (intel,uats), static power limit
> (intel,splc), channel puncturing (intel,wcpe), 320 MHz per-MCC
> enablement (intel,wbem), ETSI SRD channel configuration
> (intel,srd), 6-7 GHz UHB country enable bitmask (intel,6e-uhb),
> and additional regulatory override properties.
>
> Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
> ---
> .../bindings/net/wireless/intel,iwlwifi.yaml | 445 ++++++++++++++++++
> 1 file changed, 445 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml b/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml
> new file mode 100644
> index 000000000000..d97be6cc35d8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml
> @@ -0,0 +1,445 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (c) 2026 Intel Corporation
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/wireless/intel,iwlwifi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Intel iwlwifi PCIe Wi-Fi devices
> +
> +maintainers:
> + - Avinash Bhatt <avinash.bhatt@intel.com>
> + - linux-wireless@vger.kernel.org
Drop this one.
> +
> +description:
> + Intel iwlwifi IEEE 802.11be discrete Wi-Fi adapters connected over PCIe.
Please wrap code according to the preferred limit expressed in Kernel
coding style (checkpatch is not a coding style description, but only a
tool). However don't wrap blindly (see Kernel coding style).
> + These bindings provide OEM platform configuration for platforms that use Device Tree.
Drop. Describe hardware.
> +
> +properties:
> + compatible:
> + enum:
> + - pci8086,272b
> +
...
> +
> + intel,activate-channel:
> + description: |
> + Indoor channel activation bitmask. Sets specific frequency bands to
> + active (rather than passive or disabled) when the platform is
> + confirmed to be operating indoors.
> +
> + Layout (2 cells):
> + [0] revision - structure revision, must be 0x00
> + [1] bitmap - per-region indoor activation flags:
> + bit 0 = enable EU U-NII-1 (5.2 GHz) for indoors only
> + bit 1 = enable Japan U-NII-1 (5.2 GHz) for indoors only
> + bit 2 = enable China Mainland U-NII-1 (5.2 GHz) for indoors only
> + bit 3 = enable USA U-NII-4 (5.9 GHz) for indoors only
> + bit 4 = enable WW U-NII-1 (5.2 GHz) for indoors in any
> + country where the band is permitted
> + bit 5 = enable Canada U-NII-4 (5.9 GHz) for indoors only
> + bit 6 = enable USA + Canada + WW U-NII-4 (5.9 GHz) for
> + indoors only
> + bits 7-31: reserved, must be 0
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - minItems: 2
> + maxItems: 2
> + items:
> + - const: 0
> +
> + intel,force-disable-channels:
I don't see how this is a DT property. Actually most of the properties
do not look either. Do you want to say, that if I go with my device from
EU to US on a business trip, I will need to recompile DTB? Obviously no...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next] net: Consistently define pci_device_ids using named initializers
From: Petr Machata @ 2026-04-29 8:48 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Michael Grzeschik, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Marc Kleine-Budde, Vincent Mailhol,
Krzysztof Halasa, Johannes Berg, Markus Schneider-Pargmann,
Steffen Klassert, David Dillow, Ion Badulescu, Mark Einon,
Rasesh Mody, GR-Linux-NIC-Dev, Sudarsana Kalluru, Manish Chopra,
Potnuri Bharat Teja, Denis Kirjanov, Jijie Shao, Jian Shen,
Cai Huoqing, Fan Gong, Tony Nguyen, Przemek Kitszel, Tariq Toukan,
Saeed Mahameed, Leon Romanovsky, Mark Bloch, Ido Schimmel,
Petr Machata, Yibo Dong, Simon Horman, Heiner Kallweit, nic_swsd,
Jiri Pirko, Francois Romieu, Daniele Venzano, Samuel Chessman,
Jiawen Wu, Mengyuan Lou, Kevin Curtis, Arend van Spriel,
Stanislav Yakovlev, Richard Cochran, Kees Cook, Thomas Gleixner,
Thomas Fourier, Ingo Molnar, Kory Maincent, Zilin Guan,
Marco Crivellari, Vadim Fedorenko, Jacob Keller, Philipp Stanner,
Bjorn Helgaas, Yeounsu Moon, Denis Benato, Peiyang Wang,
Yonglong Liu, Andy Shevchenko, Yicong Hui, Randy Dunlap,
MD Danish Anwar, Nathan Chancellor, Sai Krishna,
Ethan Nelson-Moore, Larysa Zaremba, Joe Damato, Double Lo,
Chi-hsien Lin, Colin Ian King, netdev, linux-kernel, linux-can,
linux-parisc, intel-wired-lan, linux-rdma, oss-drivers,
linux-wireless, brcm80211, brcm80211-dev-list.pdl
In-Reply-To: <20260428171845.2288395-2-u.kleine-koenig@baylibre.com>
Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> writes:
> .../net/ethernet/mellanox/mlxsw/spectrum.c | 16 +-
Reviewed-by: Petr Machata <petrm@nvidia.com> # for mlxsw
^ permalink raw reply
* Re: [PATCH 7/9] Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval
From: Bartosz Golaszewski @ 2026-04-29 8:53 UTC (permalink / raw)
To: Loic Poulain
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, linux-mmc, devicetree,
linux-kernel, linux-arm-msm, linux-block, linux-wireless, ath10k,
linux-bluetooth, netdev, daniel
In-Reply-To: <20260428-block-as-nvmem-v1-7-6ad23e75190a@oss.qualcomm.com>
On Tue, Apr 28, 2026 at 4:23 PM Loic Poulain
<loic.poulain@oss.qualcomm.com> wrote:
>
> Some devices store the Bluetooth BD address in non-volatile
> memory, which can be accessed through the NVMEM framework.
> Similar to Ethernet or WiFi MAC addresses, add support for
> reading the BD address from a 'local-bd-address' NVMEM cell.
>
> As with the device-tree provided BD address, add a quirk to
> indicate whether a device or platform should attempt to read
> the address from NVMEM when no valid in-chip address is present.
> Also add a quirk to indicate if the address is stored in
> big-endian byte order.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Is there any reason why we can't extend the existing
of_get_mac_address() with another property name and use it here? It
already has support for mac addresses from nvmem.
Bart
^ permalink raw reply
* Re: [PATCH net-next] net: Consistently define pci_device_ids using named initializers
From: Marc Kleine-Budde @ 2026-04-29 9:10 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Michael Grzeschik, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vincent Mailhol, Krzysztof Halasa,
Johannes Berg, Markus Schneider-Pargmann, Steffen Klassert,
David Dillow, Ion Badulescu, Mark Einon, Rasesh Mody,
GR-Linux-NIC-Dev, Sudarsana Kalluru, Manish Chopra,
Potnuri Bharat Teja, Denis Kirjanov, Jijie Shao, Jian Shen,
Cai Huoqing, Fan Gong, Tony Nguyen, Przemek Kitszel, Tariq Toukan,
Saeed Mahameed, Leon Romanovsky, Mark Bloch, Ido Schimmel,
Petr Machata, Yibo Dong, Simon Horman, Heiner Kallweit, nic_swsd,
Jiri Pirko, Francois Romieu, Daniele Venzano, Samuel Chessman,
Jiawen Wu, Mengyuan Lou, Kevin Curtis, Arend van Spriel,
Stanislav Yakovlev, Richard Cochran, Kees Cook, Thomas Gleixner,
Thomas Fourier, Ingo Molnar, Kory Maincent, Zilin Guan,
Marco Crivellari, Vadim Fedorenko, Jacob Keller, Philipp Stanner,
Bjorn Helgaas, Yeounsu Moon, Denis Benato, Peiyang Wang,
Yonglong Liu, Andy Shevchenko, Yicong Hui, Randy Dunlap,
MD Danish Anwar, Nathan Chancellor, Sai Krishna,
Ethan Nelson-Moore, Larysa Zaremba, Joe Damato, Double Lo,
Chi-hsien Lin, Colin Ian King, netdev, linux-kernel, linux-can,
linux-parisc, intel-wired-lan, linux-rdma, oss-drivers,
linux-wireless, brcm80211, brcm80211-dev-list.pdl
In-Reply-To: <20260428171845.2288395-2-u.kleine-koenig@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 8338 bytes --]
On 28.04.2026 19:18:44, Uwe Kleine-König (The Capable Hub) wrote:
> drivers/net/can/m_can/m_can_pci.c | 6 +-
> drivers/net/can/sja1000/plx_pci.c | 167 +++----
[...]
> diff --git a/drivers/net/can/sja1000/plx_pci.c b/drivers/net/can/sja1000/plx_pci.c
> index 08183833c9bc..a03553b80a5d 100644
> --- a/drivers/net/can/sja1000/plx_pci.c
> +++ b/drivers/net/can/sja1000/plx_pci.c
> @@ -272,124 +272,89 @@ static struct plx_pci_card_info plx_pci_card_info_asem_dual_can = {
> static const struct pci_device_id plx_pci_tbl[] = {
> {
> /* Adlink PCI-7841/cPCI-7841 */
> - ADLINK_PCI_VENDOR_ID, ADLINK_PCI_DEVICE_ID,
> - PCI_ANY_ID, PCI_ANY_ID,
> - PCI_CLASS_NETWORK_OTHER << 8, ~0,
> - (kernel_ulong_t)&plx_pci_card_info_adlink
> - },
> - {
> + PCI_DEVICE(ADLINK_PCI_VENDOR_ID, ADLINK_PCI_DEVICE_ID),
> + .class = PCI_CLASS_NETWORK_OTHER << 8,
> + .class_mask = ~0,
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_adlink,
> + }, {
> /* Adlink PCI-7841/cPCI-7841 SE */
> - ADLINK_PCI_VENDOR_ID, ADLINK_PCI_DEVICE_ID,
> - PCI_ANY_ID, PCI_ANY_ID,
> - PCI_CLASS_COMMUNICATION_OTHER << 8, ~0,
> - (kernel_ulong_t)&plx_pci_card_info_adlink_se
> - },
> - {
> + PCI_DEVICE(ADLINK_PCI_VENDOR_ID, ADLINK_PCI_DEVICE_ID),
> + .class = PCI_CLASS_COMMUNICATION_OTHER << 8,
> + .class_mask = ~0,
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_adlink_se,
> + }, {
> /* esd CAN-PCI/200 */
> - PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9050,
> - PCI_VENDOR_ID_ESDGMBH, ESD_PCI_SUB_SYS_ID_PCI200,
> - 0, 0,
> - (kernel_ulong_t)&plx_pci_card_info_esd200
> - },
> - {
> + PCI_VDEVICE_SUB(PLX, PCI_DEVICE_ID_PLX_9050,
> + PCI_VENDOR_ID_ESDGMBH, ESD_PCI_SUB_SYS_ID_PCI200),
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_esd200,
> + }, {
> /* esd CAN-CPCI/200 */
> - PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9030,
> - PCI_VENDOR_ID_ESDGMBH, ESD_PCI_SUB_SYS_ID_CPCI200,
> - 0, 0,
> - (kernel_ulong_t)&plx_pci_card_info_esd200
> - },
> - {
> + PCI_VDEVICE_SUB(PLX, PCI_DEVICE_ID_PLX_9030,
> + PCI_VENDOR_ID_ESDGMBH, ESD_PCI_SUB_SYS_ID_CPCI200),
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_esd200,
> + }, {
> /* esd CAN-PCI104/200 */
> - PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9030,
> - PCI_VENDOR_ID_ESDGMBH, ESD_PCI_SUB_SYS_ID_PCI104200,
> - 0, 0,
> - (kernel_ulong_t)&plx_pci_card_info_esd200
> - },
> - {
> + PCI_VDEVICE_SUB(PLX, PCI_DEVICE_ID_PLX_9030,
> + PCI_VENDOR_ID_ESDGMBH, ESD_PCI_SUB_SYS_ID_PCI104200),
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_esd200,
> + }, {
> /* esd CAN-PCI/266 */
> - PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9056,
> - PCI_VENDOR_ID_ESDGMBH, ESD_PCI_SUB_SYS_ID_PCI266,
> - 0, 0,
> - (kernel_ulong_t)&plx_pci_card_info_esd266
> - },
> - {
> + PCI_VDEVICE_SUB(PLX, PCI_DEVICE_ID_PLX_9056,
> + PCI_VENDOR_ID_ESDGMBH, ESD_PCI_SUB_SYS_ID_PCI266),
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_esd266,
> + }, {
> /* esd CAN-PMC/266 */
> - PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9056,
> - PCI_VENDOR_ID_ESDGMBH, ESD_PCI_SUB_SYS_ID_PMC266,
> - 0, 0,
> - (kernel_ulong_t)&plx_pci_card_info_esd266
> - },
> - {
> + PCI_VDEVICE_SUB(PLX, PCI_DEVICE_ID_PLX_9056,
> + PCI_VENDOR_ID_ESDGMBH, ESD_PCI_SUB_SYS_ID_PMC266),
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_esd266,
> + }, {
> /* esd CAN-PCIE/2000 */
> - PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9056,
> - PCI_VENDOR_ID_ESDGMBH, ESD_PCI_SUB_SYS_ID_PCIE2000,
> - 0, 0,
> - (kernel_ulong_t)&plx_pci_card_info_esd2000
> - },
> - {
> + PCI_VDEVICE_SUB(PLX, PCI_DEVICE_ID_PLX_9056,
> + PCI_VENDOR_ID_ESDGMBH, ESD_PCI_SUB_SYS_ID_PCIE2000),
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_esd2000,
> + }, {
> /* IXXAT PC-I 04/PCI card */
> - IXXAT_PCI_VENDOR_ID, IXXAT_PCI_DEVICE_ID,
> - PCI_ANY_ID, IXXAT_PCI_SUB_SYS_ID,
> - 0, 0,
> - (kernel_ulong_t)&plx_pci_card_info_ixxat
> - },
> - {
> + PCI_DEVICE_SUB(IXXAT_PCI_VENDOR_ID, IXXAT_PCI_DEVICE_ID,
> + PCI_ANY_ID, IXXAT_PCI_SUB_SYS_ID),
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_ixxat,
> + }, {
> /* Marathon CAN-bus-PCI card */
> - PCI_VENDOR_ID_PLX, MARATHON_PCI_DEVICE_ID,
> - PCI_ANY_ID, PCI_ANY_ID,
> - 0, 0,
> - (kernel_ulong_t)&plx_pci_card_info_marathon_pci
> - },
> - {
> + PCI_VDEVICE(PLX, MARATHON_PCI_DEVICE_ID),
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_marathon_pci,
> + }, {
> /* Marathon CAN-bus-PCIe card */
> - PCI_VENDOR_ID_PLX, MARATHON_PCIE_DEVICE_ID,
> - PCI_ANY_ID, PCI_ANY_ID,
> - 0, 0,
> - (kernel_ulong_t)&plx_pci_card_info_marathon_pcie
> - },
> - {
> + PCI_VDEVICE(PLX, MARATHON_PCIE_DEVICE_ID),
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_marathon_pcie,
> + }, {
> /* TEWS TECHNOLOGIES TPMC810 card */
> - TEWS_PCI_VENDOR_ID, TEWS_PCI_DEVICE_ID_TMPC810,
> - PCI_ANY_ID, PCI_ANY_ID,
> - 0, 0,
> - (kernel_ulong_t)&plx_pci_card_info_tews
> - },
> - {
> + PCI_DEVICE(TEWS_PCI_VENDOR_ID, TEWS_PCI_DEVICE_ID_TMPC810),
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_tews,
> + }, {
> /* Connect Tech Inc. CANpro/104-Plus Opto (CRG001) card */
> - PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9030,
> - PCI_SUBVENDOR_ID_CONNECT_TECH, CTI_PCI_DEVICE_ID_CRG001,
> - 0, 0,
> - (kernel_ulong_t)&plx_pci_card_info_cti
> - },
> - {
> + PCI_VDEVICE_SUB(PLX, PCI_DEVICE_ID_PLX_9030,
> + PCI_SUBVENDOR_ID_CONNECT_TECH, CTI_PCI_DEVICE_ID_CRG001),
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_cti,
> + }, {
> /* Elcus CAN-200-PCI */
> - CAN200PCI_VENDOR_ID, CAN200PCI_DEVICE_ID,
> - CAN200PCI_SUB_VENDOR_ID, CAN200PCI_SUB_DEVICE_ID,
> - 0, 0,
> - (kernel_ulong_t)&plx_pci_card_info_elcus
> - },
> - {
> + PCI_DEVICE_SUB(CAN200PCI_VENDOR_ID, CAN200PCI_DEVICE_ID,
> + CAN200PCI_SUB_VENDOR_ID, CAN200PCI_SUB_DEVICE_ID),
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_elcus,
> + }, {
> /* moxa */
> - MOXA_PCI_VENDOR_ID, MOXA_PCI_DEVICE_ID,
> - PCI_ANY_ID, PCI_ANY_ID,
> - 0, 0,
> - (kernel_ulong_t)&plx_pci_card_info_moxa
> - },
> - {
> + PCI_DEVICE(MOXA_PCI_VENDOR_ID, MOXA_PCI_DEVICE_ID),
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_moxa,
> + }, {
> /* ASEM Dual CAN raw */
> - ASEM_RAW_CAN_VENDOR_ID, ASEM_RAW_CAN_DEVICE_ID,
> - ASEM_RAW_CAN_SUB_VENDOR_ID, ASEM_RAW_CAN_SUB_DEVICE_ID,
> - 0, 0,
> - (kernel_ulong_t)&plx_pci_card_info_asem_dual_can
> - },
> - {
> + PCI_DEVICE_SUB(ASEM_RAW_CAN_VENDOR_ID, ASEM_RAW_CAN_DEVICE_ID,
> + ASEM_RAW_CAN_SUB_VENDOR_ID, ASEM_RAW_CAN_SUB_DEVICE_ID),
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_asem_dual_can,
> + }, {
> /* ASEM Dual CAN raw -new model */
> - ASEM_RAW_CAN_VENDOR_ID, ASEM_RAW_CAN_DEVICE_ID,
> - ASEM_RAW_CAN_SUB_VENDOR_ID, ASEM_RAW_CAN_SUB_DEVICE_ID_BIS,
> - 0, 0,
> - (kernel_ulong_t)&plx_pci_card_info_asem_dual_can
> + PCI_DEVICE_SUB(ASEM_RAW_CAN_VENDOR_ID, ASEM_RAW_CAN_DEVICE_ID,
> + ASEM_RAW_CAN_SUB_VENDOR_ID, ASEM_RAW_CAN_SUB_DEVICE_ID_BIS),
> + .driver_data = (kernel_ulong_t)&plx_pci_card_info_asem_dual_can,
> },
> - { 0,}
> + { }
Nitpick: can you convert the terminating entry to follow the same style
as the rest of the driver:
diff --git a/drivers/net/can/sja1000/plx_pci.c b/drivers/net/can/sja1000/plx_pci.c
index a03553b80a5d..d69ff0ccfd94 100644
--- a/drivers/net/can/sja1000/plx_pci.c
+++ b/drivers/net/can/sja1000/plx_pci.c
@@ -353,8 +353,8 @@ static const struct pci_device_id plx_pci_tbl[] = {
PCI_DEVICE_SUB(ASEM_RAW_CAN_VENDOR_ID, ASEM_RAW_CAN_DEVICE_ID,
ASEM_RAW_CAN_SUB_VENDOR_ID, ASEM_RAW_CAN_SUB_DEVICE_ID_BIS),
.driver_data = (kernel_ulong_t)&plx_pci_card_info_asem_dual_can,
- },
- { }
+ }, {
+ }
};
MODULE_DEVICE_TABLE(pci, plx_pci_tbl);
> };
> MODULE_DEVICE_TABLE(pci, plx_pci_tbl);
>
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply related
* RE: [Intel-wired-lan] [PATCH net-next] net: Consistently define pci_device_ids using named initializers
From: Loktionov, Aleksandr @ 2026-04-29 9:19 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub), Michael Grzeschik,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Marc Kleine-Budde, Vincent Mailhol, Krzysztof Halasa,
Johannes Berg
Cc: Richard Cochran, Yonglong Liu, Kees Cook,
linux-wireless@vger.kernel.org, Zaremba, Larysa,
brcm80211@lists.linux.dev, Daniele Venzano,
oss-drivers@corigine.com, Nguyen, Anthony L, MD Danish Anwar,
Samuel Chessman, Fan Gong, Marco Crivellari, Kevin Curtis,
Ingo Molnar, Ion Badulescu, Shevchenko, Andriy, Leon Romanovsky,
Colin Ian King, Kitszel, Przemyslaw, Peiyang Wang, Thomas Fourier,
Sai Krishna, Denis Kirjanov, intel-wired-lan@lists.osuosl.org,
linux-parisc@vger.kernel.org, Keller, Jacob E, Mengyuan Lou,
Steffen Klassert, Stanislav Yakovlev, linux-rdma@vger.kernel.org,
Arend van Spriel, nic_swsd@realtek.com, Jiri Pirko,
Philipp Stanner, Chi-hsien Lin, Ido Schimmel, Potnuri Bharat Teja,
Double Lo, Markus Schneider-Pargmann, Nathan Chancellor,
Jiawen Wu, Cai Huoqing, Bjorn Helgaas, Zilin Guan,
linux-can@vger.kernel.org, Yibo Dong, Joe Damato, Petr Machata,
Kory Maincent, brcm80211-dev-list.pdl@broadcom.com,
GR-Linux-NIC-Dev@marvell.com, Vadim Fedorenko, Manish Chopra,
Denis Benato, Rasesh Mody, netdev@vger.kernel.org, Randy Dunlap,
Mark Bloch, linux-kernel@vger.kernel.org, Tariq Toukan, Jian Shen,
Jijie Shao, Yeounsu Moon, Thomas Gleixner, Simon Horman,
Yicong Hui, Mark Einon, Ethan Nelson-Moore, Saeed Mahameed,
Sudarsana Kalluru, Heiner Kallweit
In-Reply-To: <20260428171845.2288395-2-u.kleine-koenig@baylibre.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Uwe Kleine-König (The Capable Hub)
> Sent: Tuesday, April 28, 2026 7:19 PM
> To: Michael Grzeschik <m.grzeschik@pengutronix.de>; Andrew Lunn
> <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; Marc Kleine-Budde <mkl@pengutronix.de>;
> Vincent Mailhol <mailhol@kernel.org>; Krzysztof Halasa
> <khc@pm.waw.pl>; Johannes Berg <johannes@sipsolutions.net>
> Cc: Richard Cochran <richardcochran@gmail.com>; Yonglong Liu
> <liuyonglong@huawei.com>; Kees Cook <kees@kernel.org>; linux-
> wireless@vger.kernel.org; Zaremba, Larysa <larysa.zaremba@intel.com>;
> brcm80211@lists.linux.dev; Daniele Venzano <venza@brownhat.org>; oss-
> drivers@corigine.com; Nguyen, Anthony L <anthony.l.nguyen@intel.com>;
> MD Danish Anwar <danishanwar@ti.com>; Samuel Chessman
> <chessman@tux.org>; Fan Gong <gongfan1@huawei.com>; Marco Crivellari
> <marco.crivellari@suse.com>; Kevin Curtis
> <kevin.curtis@farsite.co.uk>; Ingo Molnar <mingo@kernel.org>; Ion
> Badulescu <ionut@badula.org>; Shevchenko, Andriy
> <andriy.shevchenko@intel.com>; Leon Romanovsky <leon@kernel.org>;
> Colin Ian King <colin.i.king@gmail.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Peiyang Wang
> <wangpeiyang1@huawei.com>; Thomas Fourier <fourier.thomas@gmail.com>;
> Sai Krishna <saikrishnag@marvell.com>; Denis Kirjanov
> <kirjanov@gmail.com>; intel-wired-lan@lists.osuosl.org; linux-
> parisc@vger.kernel.org; Keller, Jacob E <jacob.e.keller@intel.com>;
> Mengyuan Lou <mengyuanlou@net-swift.com>; Steffen Klassert
> <klassert@kernel.org>; Stanislav Yakovlev <stas.yakovlev@gmail.com>;
> linux-rdma@vger.kernel.org; Arend van Spriel
> <arend.vanspriel@broadcom.com>; nic_swsd@realtek.com; Jiri Pirko
> <jiri@resnulli.us>; Philipp Stanner <phasta@kernel.org>; Chi-hsien Lin
> <chi-hsien.lin@cypress.com>; Ido Schimmel <idosch@nvidia.com>; Potnuri
> Bharat Teja <bharat@chelsio.com>; Double Lo <double.lo@cypress.com>;
> Markus Schneider-Pargmann <msp@baylibre.com>; Nathan Chancellor
> <nathan@kernel.org>; Jiawen Wu <jiawenwu@trustnetic.com>; Cai Huoqing
> <cai.huoqing@linux.dev>; Bjorn Helgaas <bhelgaas@google.com>; Zilin
> Guan <zilin@seu.edu.cn>; linux-can@vger.kernel.org; Yibo Dong
> <dong100@mucse.com>; Joe Damato <joe@dama.to>; Petr Machata
> <petrm@nvidia.com>; Kory Maincent <kory.maincent@bootlin.com>;
> brcm80211-dev-list.pdl@broadcom.com; GR-Linux-NIC-Dev@marvell.com;
> Vadim Fedorenko <vadim.fedorenko@linux.dev>; Manish Chopra
> <manishc@marvell.com>; Denis Benato <benato.denis96@gmail.com>; Rasesh
> Mody <rmody@marvell.com>; netdev@vger.kernel.org; Randy Dunlap
> <rdunlap@infradead.org>; Mark Bloch <mbloch@nvidia.com>; linux-
> kernel@vger.kernel.org; Tariq Toukan <tariqt@nvidia.com>; Jian Shen
> <shenjian15@huawei.com>; Jijie Shao <shaojijie@huawei.com>; Yeounsu
> Moon <yyyynoom@gmail.com>; Thomas Gleixner <tglx@kernel.org>; Simon
> Horman <horms@kernel.org>; Yicong Hui <yiconghui@gmail.com>; Mark
> Einon <mark.einon@gmail.com>; Ethan Nelson-Moore
> <enelsonmoore@gmail.com>; Saeed Mahameed <saeedm@nvidia.com>;
> Sudarsana Kalluru <skalluru@marvell.com>; Heiner Kallweit
> <hkallweit1@gmail.com>
> Subject: [Intel-wired-lan] [PATCH net-next] net: Consistently define
> pci_device_ids using named initializers
>
> ... and PCI device helpers.
>
> The various struct pci_device_id arrays were initialized mostly by one
> the PCI_DEVICE macros and then list expressions. The latter isn't
> easily
> readable if you're not into PCI. Using named initializers is more
> explicit and thus easier to parse.
>
> Also use PCI_DEVICE* helper macros to assign .vendor, .device,
> .subvendor and .subdevice where appropriate and skip explicit
> assignments of 0 (which the compiler takes care of).
>
> The secret plan is to make struct pci_device_id::driver_data an
> anonymous union (similar to
> https://lore.kernel.org/all/cover.1776579304.git.u.kleine-
> koenig@baylibre.com/)
> and that requires named initializers. But it's also a nice cleanup on
> its own.
>
> This change doesn't introduce changes to the compiled pci_device_id
> arrays. Tested on x86 and arm64.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-
> koenig@baylibre.com>
> ---
> Hello,
>
> the mentioned follow-up quest allows to do
>
> PCI_DEVICE(0x1571, 0xa203),
> + .driver_data = (kernel_ulong_t)&card_info_10mbit,
> - .driver_data_ptr = &card_info_10mbit,
>
> which gets rid of a bunch of casts and so brings a little bit more
> type
> safety. This patch is a preparation for that.
>
> I handled all of drivers/net/ in a single patch, please tell me if I
> should split by subsystem.
>
> Best regards
> Uwe
> ---
> drivers/net/arcnet/com20020-pci.c | 242 +++------
> drivers/net/can/m_can/m_can_pci.c | 6 +-
> drivers/net/can/sja1000/plx_pci.c | 167 +++----
> drivers/net/ethernet/3com/3c59x.c | 80 +--
> drivers/net/ethernet/3com/typhoon.c | 75 ++-
> drivers/net/ethernet/8390/ne2k-pci.c | 24 +-
> drivers/net/ethernet/adaptec/starfire.c | 4 +-
> drivers/net/ethernet/agere/et131x.c | 6 +-
> drivers/net/ethernet/broadcom/bnx2.c | 62 ++-
> .../net/ethernet/broadcom/bnx2x/bnx2x_main.c | 50 +-
> .../net/ethernet/cavium/liquidio/lio_main.c | 10 +-
> .../ethernet/cavium/liquidio/lio_vf_main.c | 7 +-
> drivers/net/ethernet/chelsio/cxgb/common.h | 2 +-
> drivers/net/ethernet/chelsio/cxgb/subr.c | 2 +-
> .../net/ethernet/chelsio/cxgb3/cxgb3_main.c | 4 +-
> .../net/ethernet/chelsio/cxgb4/cxgb4_main.c | 4 +-
> .../ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 4 +-
> drivers/net/ethernet/dec/tulip/de2104x.c | 6 +-
> drivers/net/ethernet/dec/tulip/dmfe.c | 12 +-
> drivers/net/ethernet/dec/tulip/tulip_core.c | 78 +--
> drivers/net/ethernet/dec/tulip/uli526x.c | 6 +-
> drivers/net/ethernet/dec/tulip/winbond-840.c | 13 +-
> drivers/net/ethernet/dlink/dl2k.h | 12 +-
> drivers/net/ethernet/dlink/sundance.c | 14 +-
> drivers/net/ethernet/fealnx.c | 8 +-
> .../net/ethernet/hisilicon/hibmcge/hbg_main.c | 2 +-
> .../net/ethernet/hisilicon/hns3/hns3_enet.c | 50 +-
> .../hisilicon/hns3/hns3pf/hclge_main.c | 18 +-
> .../hisilicon/hns3/hns3vf/hclgevf_main.c | 12 +-
> .../net/ethernet/huawei/hinic/hinic_main.c | 12 +-
> .../net/ethernet/huawei/hinic3/hinic3_lld.c | 7 +-
> drivers/net/ethernet/intel/e100.c | 4 +-
> drivers/net/ethernet/intel/e1000e/netdev.c | 471 +++++++++++++----
> -
> drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 10 +-
> drivers/net/ethernet/intel/i40e/i40e_main.c | 59 +--
> drivers/net/ethernet/intel/iavf/iavf_main.c | 10 +-
> drivers/net/ethernet/intel/igb/igb_main.c | 66 +--
> drivers/net/ethernet/intel/igbvf/netdev.c | 4 +-
> drivers/net/ethernet/intel/igc/igc_main.c | 34 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 106 ++--
> .../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 49 +-
> drivers/net/ethernet/mellanox/mlx4/main.c | 6 +-
> .../net/ethernet/mellanox/mlx5/core/main.c | 26 +-
> .../net/ethernet/mellanox/mlxsw/spectrum.c | 16 +-
> drivers/net/ethernet/micrel/ksz884x.c | 8 +-
> .../net/ethernet/mucse/rnpgbe/rnpgbe_main.c | 10 +-
> drivers/net/ethernet/natsemi/natsemi.c | 4 +-
> drivers/net/ethernet/netronome/nfp/nfp_main.c | 81 +--
> .../ethernet/netronome/nfp/nfp_netvf_main.c | 41 +-
> drivers/net/ethernet/qlogic/qede/qede_main.c | 20 +-
> drivers/net/ethernet/realtek/8139too.c | 52 +-
> drivers/net/ethernet/realtek/r8169_main.c | 8 +-
> drivers/net/ethernet/rocker/rocker_main.c | 4 +-
> drivers/net/ethernet/sis/sis190.c | 6 +-
> drivers/net/ethernet/sis/sis900.c | 10 +-
> drivers/net/ethernet/smsc/epic100.c | 18 +-
> drivers/net/ethernet/sun/cassini.c | 8 +-
> drivers/net/ethernet/sun/sungem.c | 26 +-
> drivers/net/ethernet/ti/tlan.c | 41 +-
> drivers/net/ethernet/wangxun/ngbe/ngbe_main.c | 26 +-
> .../net/ethernet/wangxun/ngbevf/ngbevf_main.c | 26 +-
> .../net/ethernet/wangxun/txgbe/txgbe_main.c | 18 +-
> .../ethernet/wangxun/txgbevf/txgbevf_main.c | 18 +-
> drivers/net/wan/farsync.c | 24 +-
> drivers/net/wan/pc300too.c | 14 +-
> drivers/net/wan/pci200syn.c | 6 +-
> drivers/net/wan/wanxl.c | 11 +-
> .../broadcom/brcm80211/brcmfmac/pcie.c | 17 +-
> drivers/net/wireless/intel/ipw2x00/ipw2200.c | 52 +-
> 69 files changed, 1308 insertions(+), 1101 deletions(-)
>
> diff --git a/drivers/net/arcnet/com20020-pci.c
> b/drivers/net/arcnet/com20020-pci.c
> index dbadda08dce2..6474c7be2992 100644
> --- a/drivers/net/arcnet/com20020-pci.c
> +++ b/drivers/net/arcnet/com20020-pci.c
> @@ -459,168 +459,88 @@ static struct com20020_pci_card_info
> card_info_eae_fb2 = {
>
> static const struct pci_device_id com20020pci_id_table[] = {
> {
...
> };
>
> MODULE_DEVICE_TABLE(pci, card_ids);
>
> base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
> --
> 2.47.3
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [PATCH 5/9] arm64: dts: qcom: arduino-imola: Get WiFi MAC from NVMEM
From: Konrad Dybcio @ 2026-04-29 9:30 UTC (permalink / raw)
To: Loic Poulain, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Jens Axboe,
Johannes Berg, Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel
In-Reply-To: <20260428-block-as-nvmem-v1-5-6ad23e75190a@oss.qualcomm.com>
On 4/28/26 4:23 PM, Loic Poulain wrote:
> On Arduino Uno-Q, the WiFi MAC address is stored in the eMMC
> boot1 partition. Point to the appropriate NVMEM cell to
> retrieve it.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 4/9] dt-bindings: net: wireless: qcom,ath10k: Add NVMEM MAC address cell
From: Konrad Dybcio @ 2026-04-29 9:31 UTC (permalink / raw)
To: Loic Poulain, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Jens Axboe,
Johannes Berg, Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel
In-Reply-To: <20260428-block-as-nvmem-v1-4-6ad23e75190a@oss.qualcomm.com>
On 4/28/26 4:23 PM, Loic Poulain wrote:
> Add support for an NVMEM cell provider with the standard "mac-address"
> cell name. This allows the ath10k device to retrieve its MAC address
> from non-volatile storage such as an EEPROM or an eMMC partition.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> .../devicetree/bindings/net/wireless/qcom,ath10k.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> index c21d66c7cd558ab792524be9afec8b79272d1c87..7155d8b15cc145c3a7d703db0c9c3e056a54c07e 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> @@ -92,6 +92,16 @@ properties:
>
> ieee80211-freq-limit: true
>
> + nvmem-cells:
> + maxItems: 1
> + description:
> + Nvmem data cell that contains a 6 byte MAC address with the most
> + significant byte first (big-endian).
> +
> + nvmem-cell-names:
> + items:
> + - const: mac-address
This can just be "const: mac-address" if you don't expect any additional
entries
Konrad
^ permalink raw reply
* Re: [PATCH 9/9] arm64: dts: qcom: arduino-imola: Get Bluetooth BD address from NVMEM
From: Konrad Dybcio @ 2026-04-29 9:32 UTC (permalink / raw)
To: Loic Poulain, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Jens Axboe,
Johannes Berg, Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel
In-Reply-To: <20260428-block-as-nvmem-v1-9-6ad23e75190a@oss.qualcomm.com>
On 4/28/26 4:23 PM, Loic Poulain wrote:
> On Arduino Uno-Q, the Bluetooth Device address is stored in the eMMC
> boot1 partition. Point to the appropriate NVMEM cell to retrieve it.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 1/1] dt-bindings: net: wireless: intel,iwlwifi: add binding
From: Rob Herring (Arm) @ 2026-04-29 9:34 UTC (permalink / raw)
To: Avinash Bhatt
Cc: miriam.rachel.korenblit, devicetree, krzk+dt, emmanuel.grumbach,
linux-wireless, conor+dt, johannes, kobi.guetta, linux-kernel
In-Reply-To: <20260429081403.46087-2-avinash.bhatt@intel.com>
On Wed, 29 Apr 2026 11:14:03 +0300, Avinash Bhatt wrote:
> Add a devicetree schema binding for Intel discrete Wi-Fi 7 BE200 PCIe
> adapters.
>
> The binding documents OEM platform configuration properties for
> platforms that use Device Tree instead of platform firmware
> methods. All properties mirror the existing equivalents in
> structure and semantics, covering SAR power limits (intel,wrds),
> 6 GHz AP type support (intel,uats), static power limit
> (intel,splc), channel puncturing (intel,wcpe), 320 MHz per-MCC
> enablement (intel,wbem), ETSI SRD channel configuration
> (intel,srd), 6-7 GHz UHB country enable bitmask (intel,6e-uhb),
> and additional regulatory override properties.
>
> Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
> ---
> .../bindings/net/wireless/intel,iwlwifi.yaml | 445 ++++++++++++++++++
> 1 file changed, 445 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,splc:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}, {'minimum': 1}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,splc:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}, {'minimum': 1}] is too long
[{'const': 0}, {'minimum': 1}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,splc:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}, {'minimum': 1}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,splc:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}, {'minimum': 1}] is too long
[{'const': 0}, {'minimum': 1}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,wcpe:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,wcpe:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,wcpe:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,wcpe:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,6e-uhb:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,6e-uhb:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,6e-uhb:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,6e-uhb:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,regulatory-special:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,regulatory-special:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,regulatory-special:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,regulatory-special:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,uats:allOf:1: {'minItems': 339, 'maxItems': 339, 'items': [{'const': 1}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,uats:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 339
[{'const': 1}] is too short
1 was expected
339 is greater than the maximum of 2
339 is greater than the maximum of 3
339 is greater than the maximum of 4
339 is greater than the maximum of 5
339 is greater than the maximum of 6
339 is greater than the maximum of 7
339 is greater than the maximum of 8
339 is greater than the maximum of 9
339 is greater than the maximum of 10
339 is greater than the maximum of 11
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,uats:allOf:1: {'minItems': 339, 'maxItems': 339, 'items': [{'const': 1}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,uats:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 339
[{'const': 1}] is too short
1 was expected
339 is greater than the maximum of 2
339 is greater than the maximum of 3
339 is greater than the maximum of 4
339 is greater than the maximum of 5
339 is greater than the maximum of 6
339 is greater than the maximum of 7
339 is greater than the maximum of 8
339 is greater than the maximum of 9
339 is greater than the maximum of 10
339 is greater than the maximum of 11
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,force-disable-channels:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,force-disable-channels:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,force-disable-channels:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,force-disable-channels:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,wrds:allOf:1: {'minItems': 50, 'maxItems': 50, 'items': [{'const': 3}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,wrds:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 50
[{'const': 3}] is too short
1 was expected
50 is greater than the maximum of 2
50 is greater than the maximum of 3
50 is greater than the maximum of 4
50 is greater than the maximum of 5
50 is greater than the maximum of 6
50 is greater than the maximum of 7
50 is greater than the maximum of 8
50 is greater than the maximum of 9
50 is greater than the maximum of 10
50 is greater than the maximum of 11
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,wrds:allOf:1: {'minItems': 50, 'maxItems': 50, 'items': [{'const': 3}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,wrds:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 50
[{'const': 3}] is too short
1 was expected
50 is greater than the maximum of 2
50 is greater than the maximum of 3
50 is greater than the maximum of 4
50 is greater than the maximum of 5
50 is greater than the maximum of 6
50 is greater than the maximum of 7
50 is greater than the maximum of 8
50 is greater than the maximum of 9
50 is greater than the maximum of 10
50 is greater than the maximum of 11
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,activate-channel:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,activate-channel:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,activate-channel:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,activate-channel:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,wbem:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,wbem:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,wbem:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,wbem:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,srd:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}, {'enum': [0, 1, 2]}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,srd:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}, {'enum': [0, 1, 2]}] is too long
[{'const': 0}, {'enum': [0, 1, 2]}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,srd:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}, {'enum': [0, 1, 2]}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,srd:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}, {'enum': [0, 1, 2]}] is too long
[{'const': 0}, {'enum': [0, 1, 2]}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,11be:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,11be:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,11be:allOf:1: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 0}]} should not be valid under {'required': ['maxItems']}
hint: "maxItems" is not needed with an "items" list
from schema $id: http://devicetree.org/meta-schemas/items.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml: properties:intel,11be:allOf:1: 'oneOf' conditional failed, one must be fixed:
False schema does not allow 2
[{'const': 0}] is too short
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260429081403.46087-2-avinash.bhatt@intel.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH wireless] wifi: ath11k: fix monitor mode frame length by using correct descriptor size
From: Praneesh P @ 2026-04-29 9:52 UTC (permalink / raw)
To: Joshua Klinesmith, linux-wireless; +Cc: ath11k
In-Reply-To: <20260407024836.53871-1-joshuaklinesmith@gmail.com>
On 4/7/2026 8:18 AM, Joshua Klinesmith wrote:
> The monitor mode RX path in ath11k_dp_rx_mon_mpdu_pop() and
> ath11k_dp_rx_full_mon_mpdu_pop() uses sizeof(struct hal_rx_desc) to
> compute the packet buffer offset. This is the size of the union of all
> chip-specific descriptors (the maximum), not the actual descriptor size
> for the running chip. The later ath11k_dp_rx_msdus_set_payload() then
> strips only hw_params.hal_desc_sz bytes (the chip-specific size) from
> the front of the skb.
>
> On IPQ8074 and QCN9074, sizeof(struct hal_rx_desc) is 392 but
> hal_desc_sz is 384, leaving 8 extra bytes of descriptor data at the
> end of every monitor mode frame delivered to userspace. On WCN6855 the
> sizes happen to match so the bug is not visible.
>
> The same mismatch in ath11k_dp_mon_set_frag_len() causes incorrect
> fragment length calculation for multi-buffer MSDUs, under-counting
> intermediate fragments by 8 bytes and over-counting the last fragment.
>
> Fix by using ar->ab->hw_params.hal_desc_sz consistently in both
> monitor mpdu_pop functions and passing it through to set_frag_len.
>
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Link: https://github.com/openwrt/openwrt/issues/16183
> Signed-off-by: Joshua Klinesmith <joshuaklinesmith@gmail.com>
> ---
> drivers/net/wireless/ath/ath11k/dp_rx.c | 27 ++++++++++++++-----------
> 1 file changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
> index 85defe11750d..c86ffc203f15 100644
> --- a/drivers/net/wireless/ath/ath11k/dp_rx.c
> +++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
> @@ -4511,10 +4511,11 @@ int ath11k_dp_rx_pdev_alloc(struct ath11k_base *ab, int mac_id)
> return 0;
> }
>
> -static void ath11k_dp_mon_set_frag_len(u32 *total_len, u32 *frag_len)
> +static void ath11k_dp_mon_set_frag_len(u32 *total_len, u32 *frag_len,
> + u32 hal_desc_sz)
> {
> - if (*total_len >= (DP_RX_BUFFER_SIZE - sizeof(struct hal_rx_desc))) {
> - *frag_len = DP_RX_BUFFER_SIZE - sizeof(struct hal_rx_desc);
> + if (*total_len >= (DP_RX_BUFFER_SIZE - hal_desc_sz)) {
> + *frag_len = DP_RX_BUFFER_SIZE - hal_desc_sz;
> *total_len -= *frag_len;
> } else {
> *frag_len = *total_len;
> @@ -4658,19 +4659,19 @@ static u32 ath11k_dp_rx_mon_comp_ppduid(u32 msdu_ppdu_id, u32 *ppdu_id,
>
> static void ath11k_dp_mon_get_buf_len(struct hal_rx_msdu_desc_info *info,
> bool *is_frag, u32 *total_len,
> - u32 *frag_len, u32 *msdu_cnt)
> + u32 *frag_len, u32 *msdu_cnt,
> + u32 hal_desc_sz)
> {
> if (info->msdu_flags & RX_MSDU_DESC_INFO0_MSDU_CONTINUATION) {
> if (!*is_frag) {
> *total_len = info->msdu_len;
> *is_frag = true;
> }
> - ath11k_dp_mon_set_frag_len(total_len,
> - frag_len);
> + ath11k_dp_mon_set_frag_len(total_len, frag_len, hal_desc_sz);
> } else {
> if (*is_frag) {
> - ath11k_dp_mon_set_frag_len(total_len,
> - frag_len);
> + ath11k_dp_mon_set_frag_len(total_len, frag_len,
> + hal_desc_sz);
> } else {
> *frag_len = info->msdu_len;
> }
> @@ -4792,7 +4793,7 @@ u32 ath11k_dp_rx_mon_mpdu_pop(struct ath11k *ar, int mac_id,
>
> rx_desc = (struct hal_rx_desc *)msdu->data;
>
> - rx_pkt_offset = sizeof(struct hal_rx_desc);
> + rx_pkt_offset = ar->ab->hw_params.hal_desc_sz;
> l2_hdr_offset = ath11k_dp_rx_h_msdu_end_l3pad(ar->ab, rx_desc);
>
> if (is_first_msdu) {
> @@ -4823,7 +4824,8 @@ u32 ath11k_dp_rx_mon_mpdu_pop(struct ath11k *ar, int mac_id,
> }
> ath11k_dp_mon_get_buf_len(&msdu_list.msdu_info[i],
> &is_frag, &total_len,
> - &frag_len, &msdu_cnt);
> + &frag_len, &msdu_cnt,
> + rx_pkt_offset);
> rx_buf_size = rx_pkt_offset + l2_hdr_offset + frag_len;
>
> ath11k_dp_pkt_set_pktlen(msdu, rx_buf_size);
> @@ -5424,7 +5426,7 @@ ath11k_dp_rx_full_mon_mpdu_pop(struct ath11k *ar,
>
> rx_desc = (struct hal_rx_desc *)msdu->data;
>
> - rx_pkt_offset = sizeof(struct hal_rx_desc);
> + rx_pkt_offset = ar->ab->hw_params.hal_desc_sz;
> l2_hdr_offset = ath11k_dp_rx_h_msdu_end_l3pad(ar->ab, rx_desc);
>
> if (is_first_msdu) {
> @@ -5439,7 +5441,8 @@ ath11k_dp_rx_full_mon_mpdu_pop(struct ath11k *ar,
>
> ath11k_dp_mon_get_buf_len(&msdu_list.msdu_info[i],
> &is_frag, &total_len,
> - &frag_len, &msdu_cnt);
> + &frag_len, &msdu_cnt,
> + rx_pkt_offset);
>
> rx_buf_size = rx_pkt_offset + l2_hdr_offset + frag_len;
Thanks for fixing the offset handling in the monitor Rx path, but still
there is another instance that still relies on sizeof(struct hal_rx_desc).
ath11k_dp_rx_h_ppdu(), which is also invoked from the monitor path, uses:
ath11k_dbg_dump(ab, ATH11K_DBG_DATA, NULL, "", rx_desc, sizeof(struct
hal_rx_desc));
This should likewise be converted to use hw_params.hal_desc_sz to avoid
dumping beyond the chip-specific descriptor size on platforms where they
differ.
^ 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