* RE: [PATCH 1/1] dt-bindings: net: wireless: intel,iwlwifi: add binding
From: Bhatt, Avinash @ 2026-04-30 12:50 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
robh@kernel.org, krzk+dt@kernel.org, devicetree@vger.kernel.org,
conor+dt@kernel.org, johannes@sipsolutions.net,
Korenblit, Miriam Rachel, Guetta, Kobi, Grumbach, Emmanuel
In-Reply-To: <4fda911e-df77-43bd-9248-e55ed587d040@kernel.org>
Hi Krzysztof,
Thank you for the review. Responses inline.
On 29/04/2026 10:14, Krzysztof Kozlowski wrote:
> 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 driver implementation consuming these properties exists and will be
submitted as a companion series together with v2 of this binding.
>> + - linux-wireless@vger.kernel.org
>
> Drop this one.
Ack. Will address in PATCH v2.
>> +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).
Ack. Will address in PATCH v2.
>> + These bindings provide OEM platform configuration for platforms that
>> + use Device Tree.
>
> Drop. Describe hardware.
Ack. Will address in PATCH v2.
>> + intel,activate-channel:
>> ...
>> + 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...
These properties describe how the WiFi NIC was integrated into the
system by the OEM — specifically, which regulatory certifications were
obtained for this hardware SKU at manufacturing time. That is a fixed
hardware property of the board, no different from describing antenna
configuration or RF front-end capabilities.
To clarify the travel analogy: the regulatory domain (which country the
device is currently operating in) is determined at runtime by the kernel
regulatory subsystem, independently of these properties. What these
properties encode is what the hardware itself has been certified for.
For example, bit 0 of intel,activate-channel means "the OEM of this
board obtained EU indoor channel certification for this SKU." That
certification does not change when the device travels — it is a property
of the hardware, not of its location.
The per-country granularity exists because regulatory certifications are
issued independently by each country's agency (FCC for the USA, ISED
for Canada, etc.), so each country's enablement is a separate OEM
decision reflected in the board design.
Best regards,
Avinash
-----Original Message-----
From: Krzysztof Kozlowski <krzk@kernel.org>
Sent: 29 April 2026 13:49
To: Bhatt, Avinash <avinash.bhatt@intel.com>; devicetree@vger.kernel.org
Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org; johannes@sipsolutions.net; Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com>; Guetta, Kobi <kobi.guetta@intel.com>; Grumbach, Emmanuel <emmanuel.grumbach@intel.com>
Subject: Re: [PATCH 1/1] dt-bindings: net: wireless: intel,iwlwifi: add binding
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.yam
> +++ l
> @@ -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 0/1] dt-bindings: net: wireless: intel,iwlwifi: add binding
From: Bhatt, Avinash @ 2026-04-30 12:58 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
robh@kernel.org, krzk+dt@kernel.org, devicetree@vger.kernel.org,
conor+dt@kernel.org, johannes@sipsolutions.net,
Korenblit, Miriam Rachel, Guetta, Kobi, Grumbach, Emmanuel
In-Reply-To: <f8351134-c421-49ce-a314-8731c9d1cf02@kernel.org>
Hi Krzysztof,
Apologies for both issues.
On 29/04/2026 10:14, Krzysztof Kozlowski wrote:
> On 29/04/2026 10:14, Avinash Bhatt wrote:
>> Link to RFC:
>> https://patchwork.kernel.org/project/devicetree/patch/20260408055709.1
>> 1579-2-avinash.bhatt@intel.com/
>
> So that's a v2. Please version your patches correctly.
Acknowledged. RFC counts as v1 so the next revision should have been
[PATCH v2] — missed that convention. The next submission will be sent
as [PATCH v2] as it should be.
> Also, I don't understand how could you claim that RFC passes tests but
> this obviously was not tested.
I validated locally with dtschema 2025.12; the CI bot uses 2026.4
which added stricter enforcement of the items/minItems rule. We have
upgraded to 2026.4, fixed all errors, and all checks now pass clean.
Will send [PATCH v2] shortly.
Best regards,
Avinash
-----Original Message-----
From: Krzysztof Kozlowski <krzk@kernel.org>
Sent: 30 April 2026 13:21
To: Bhatt, Avinash <avinash.bhatt@intel.com>; devicetree@vger.kernel.org
Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org; johannes@sipsolutions.net; Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com>; Guetta, Kobi <kobi.guetta@intel.com>; Grumbach, Emmanuel <emmanuel.grumbach@intel.com>
Subject: Re: [PATCH 0/1] dt-bindings: net: wireless: intel,iwlwifi: add binding
On 29/04/2026 10:14, Avinash Bhatt wrote:
> 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.1
> 1579-2-avinash.bhatt@intel.com/
So that's a v2. Please version your patches correctly.
Also, I don't understand how could you claim that RFC passes tests but this obviously was not tested.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next] net: Consistently define pci_device_ids using named initializers
From: Uwe Kleine-König (The Capable Hub) @ 2026-04-30 13:13 UTC (permalink / raw)
To: Jijie Shao
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, Manish Chopra, Potnuri Bharat Teja,
Denis Kirjanov, 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, Yonglong Liu, Andy Shevchenko,
Yicong Hui, Randy Dunlap, MD Danish Anwar, Nathan Chancellor,
Sai Krishna, Ethan Nelson-Moore, Larysa Zaremba, Joe Damato,
Double Lo, 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: <814632c8-070b-4b21-adbb-5a01a62d52f2@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 2618 bytes --]
Hello,
On Thu, Apr 30, 2026 at 02:53:29PM +0800, Jijie Shao wrote:
> on 2026/4/29 1:18, 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.
> >
> > Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
>
> ...
>
> > diff --git a/drivers/net/ethernet/hisilicon/hibmcge/hbg_main.c b/drivers/net/ethernet/hisilicon/hibmcge/hbg_main.c
> > index 068da2fd1fea..b3e01b2f8319 100644
> > --- a/drivers/net/ethernet/hisilicon/hibmcge/hbg_main.c
> > +++ b/drivers/net/ethernet/hisilicon/hibmcge/hbg_main.c
> > @@ -489,7 +489,7 @@ static void hbg_shutdown(struct pci_dev *pdev)
> > }
> > static const struct pci_device_id hbg_pci_tbl[] = {
> > - {PCI_VDEVICE(HUAWEI, 0x3730), 0},
> > + { PCI_VDEVICE(HUAWEI, 0x3730) },
> > { }
> > };
>
> Reviewed-by: Jijie Shao <shaojijie@huawei.com>
Thanks.
> > + {
> > + PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_GE),
> > + .driver_data = 0,
> > + }, {
> > + PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_25GE),
> > + .driver_data = 0,
>
> Thanks for your work.
>
> If .driver_data = 0, is it possible to delete it to be consistent with other parts, for example:
>
> { PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_GE) }
>
> > + }, {
> > + PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_25GE_RDMA),
> > + .driver_data = HNAE3_DEV_SUPPORT_ROCE_DCB_BITS,
However keeping the explicit .driver_data = 0 to have a contrast to
other `pci_device_id`s having a non-zero .driver_data in the same driver
is also a good reason to keep the (technically redundant) assignment.
For other drivers I dropped these assignments if this is possible for
all array members.
Having said that I don't intend to rework the patch for this suggestion.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: mmc: Document support for nvmem-layout
From: Loic Poulain @ 2026-04-30 13:13 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: 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, linux-mmc, devicetree, linux-kernel, linux-arm-msm,
linux-block, linux-wireless, ath10k, linux-bluetooth, netdev,
daniel
In-Reply-To: <20260430-bird-of-sheer-ampleness-744e7f@quoll>
Hi Krzysztof,
On Thu, Apr 30, 2026 at 11:59 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Tue, Apr 28, 2026 at 04:23:06PM +0200, Loic Poulain wrote:
>
> > + compatible = "fixed-layout";
> > +
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + mac-addr@4400 {
> > + reg = <0x4400 0x6>;
>
> This looks incomplete. Why isn't this mac-base type of entry? And how do
> you address it from NVMEM consumer?
This indeed falls under the fixed-cell/mac-base type, thanks for
pointing that out.
NVMEM consumers reference these entries using the nvmem-cells
property, via the corresponding label/phandle.
>
> > + };
> > +
> > + bd-addr@5400 {
> > + reg = <0x5400 0x6>;
> > + };
> > + };
> > + };
> > };
> > };
> >
> >
> > --
> > 2.34.1
> >
^ permalink raw reply
* Re: [PATCH net-next] net: Consistently define pci_device_ids using named initializers
From: Uwe Kleine-König (The Capable Hub) @ 2026-04-30 13:15 UTC (permalink / raw)
To: Markus Schneider-Pargmann
Cc: Michael Grzeschik, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Marc Kleine-Budde, Vincent Mailhol,
Krzysztof Halasa, Johannes Berg, Steffen Klassert, David Dillow,
Ion Badulescu, Mark Einon, Rasesh Mody, GR-Linux-NIC-Dev,
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, Yonglong Liu, Andy Shevchenko,
Yicong Hui, Randy Dunlap, MD Danish Anwar, Nathan Chancellor,
Sai Krishna, Ethan Nelson-Moore, Larysa Zaremba, Joe Damato,
Double Lo, 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: <DI6D3JVJ6JG6.8V4XUVGJA2D4@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]
Hello Markus,
On Thu, Apr 30, 2026 at 10:55:14AM +0200, Markus Schneider-Pargmann wrote:
> On Tue Apr 28, 2026 at 7:18 PM CEST, Uwe Kleine-König (The Capable Hub) wrote:
> > diff --git a/drivers/net/can/m_can/m_can_pci.c b/drivers/net/can/m_can/m_can_pci.c
> > index eb31ed1f9644..cb9335c1d3ea 100644
> > --- a/drivers/net/can/m_can/m_can_pci.c
> > +++ b/drivers/net/can/m_can/m_can_pci.c
> > @@ -183,9 +183,9 @@ static SIMPLE_DEV_PM_OPS(m_can_pci_pm_ops,
> > m_can_pci_suspend, m_can_pci_resume);
> >
> > static const struct pci_device_id m_can_pci_id_table[] = {
> > - { PCI_VDEVICE(INTEL, 0x4bc1), M_CAN_CLOCK_FREQ_EHL, },
> > - { PCI_VDEVICE(INTEL, 0x4bc2), M_CAN_CLOCK_FREQ_EHL, },
> > - { } /* Terminating Entry */
> > + { PCI_VDEVICE(INTEL, 0x4bc1), .driver_data = M_CAN_CLOCK_FREQ_EHL, },
> > + { PCI_VDEVICE(INTEL, 0x4bc2), .driver_data = M_CAN_CLOCK_FREQ_EHL, },
> > + { } /* terminating entry */
>
> M_CAN_CLOCK_FREQ_EHL is basically hardcoded for all PCI devices since
> 2020. I don't think we need this driver data at all and can just drop it
> and use M_CAN_CLOCK_FREQ_EHL directly in the code for the frequency.
> Once a real new PCI device gets added we can see if and what driver_data
> is needed.
Sounds like a nice *separate* change, right?
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [wireless-next:main] BUILD SUCCESS 7baf5857e15d722776898510a10546d6b2f18645
From: kernel test robot @ 2026-04-30 13:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
branch HEAD: 7baf5857e15d722776898510a10546d6b2f18645 wifi: brcmsmac: phy_lcn: Remove dead code in wlc_lcnphy_radio_2064_channel_tune_4313()
elapsed time: 2629m
configs tested: 191
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001 gcc-8.5.0
arc randconfig-001-20260430 gcc-8.5.0
arc randconfig-002 gcc-8.5.0
arc randconfig-002-20260430 gcc-8.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001 gcc-8.5.0
arm randconfig-001-20260430 gcc-8.5.0
arm randconfig-002 gcc-8.5.0
arm randconfig-002-20260430 gcc-8.5.0
arm randconfig-003 gcc-8.5.0
arm randconfig-003-20260430 gcc-8.5.0
arm randconfig-004 gcc-8.5.0
arm randconfig-004-20260430 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260430 clang-23
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260430 clang-23
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260430 clang-23
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260430 clang-23
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001 clang-23
csky randconfig-001-20260430 clang-23
csky randconfig-002 clang-23
csky randconfig-002-20260430 clang-23
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260430 gcc-14.3.0
hexagon randconfig-002-20260430 gcc-14.3.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260430 gcc-14
i386 buildonly-randconfig-002-20260430 gcc-14
i386 buildonly-randconfig-003-20260430 gcc-14
i386 buildonly-randconfig-004-20260430 gcc-14
i386 buildonly-randconfig-005-20260430 gcc-14
i386 buildonly-randconfig-006-20260430 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260430 clang-20
i386 randconfig-002-20260430 clang-20
i386 randconfig-003-20260430 clang-20
i386 randconfig-004-20260430 clang-20
i386 randconfig-005-20260430 clang-20
i386 randconfig-006-20260430 clang-20
i386 randconfig-007-20260430 clang-20
i386 randconfig-011 clang-20
i386 randconfig-011-20260430 clang-20
i386 randconfig-012 clang-20
i386 randconfig-012-20260430 clang-20
i386 randconfig-013 clang-20
i386 randconfig-013-20260430 clang-20
i386 randconfig-014 clang-20
i386 randconfig-014-20260430 clang-20
i386 randconfig-015 clang-20
i386 randconfig-015-20260430 clang-20
i386 randconfig-016 clang-20
i386 randconfig-016-20260430 clang-20
i386 randconfig-017 clang-20
i386 randconfig-017-20260430 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260430 gcc-14.3.0
loongarch randconfig-002-20260430 gcc-14.3.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips xway_defconfig clang-23
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260430 gcc-14.3.0
nios2 randconfig-002-20260430 gcc-14.3.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
openrisc simple_smp_defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260430 gcc-13.4.0
parisc randconfig-002-20260430 gcc-13.4.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc mvme5100_defconfig gcc-15.2.0
powerpc pasemi_defconfig clang-23
powerpc randconfig-001-20260430 gcc-13.4.0
powerpc randconfig-002-20260430 gcc-13.4.0
powerpc64 randconfig-001-20260430 gcc-13.4.0
powerpc64 randconfig-002-20260430 gcc-13.4.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001 clang-23
riscv randconfig-001-20260430 clang-23
riscv randconfig-002 clang-23
riscv randconfig-002-20260430 clang-23
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001 clang-23
s390 randconfig-001-20260430 clang-23
s390 randconfig-002 clang-23
s390 randconfig-002-20260430 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001 clang-23
sh randconfig-001-20260430 clang-23
sh randconfig-002 clang-23
sh randconfig-002-20260430 clang-23
sh se7206_defconfig gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260430 gcc-12.5.0
sparc randconfig-002-20260430 gcc-12.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260430 gcc-12.5.0
sparc64 randconfig-002-20260430 gcc-12.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260430 gcc-12.5.0
um randconfig-002-20260430 gcc-12.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260430 gcc-14
x86_64 buildonly-randconfig-002-20260430 gcc-14
x86_64 buildonly-randconfig-003-20260430 gcc-14
x86_64 buildonly-randconfig-004-20260430 gcc-14
x86_64 buildonly-randconfig-005-20260430 gcc-14
x86_64 buildonly-randconfig-006-20260430 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-011-20260430 clang-20
x86_64 randconfig-012-20260430 clang-20
x86_64 randconfig-013-20260430 clang-20
x86_64 randconfig-014-20260430 clang-20
x86_64 randconfig-015-20260430 clang-20
x86_64 randconfig-016-20260430 clang-20
x86_64 randconfig-071-20260430 gcc-14
x86_64 randconfig-072-20260430 gcc-14
x86_64 randconfig-073-20260430 gcc-14
x86_64 randconfig-074-20260430 gcc-14
x86_64 randconfig-075-20260430 gcc-14
x86_64 randconfig-076-20260430 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260430 gcc-12.5.0
xtensa randconfig-002-20260430 gcc-12.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [GIT PULL] wireless-2026-04-30
From: Jakub Kicinski @ 2026-04-30 14:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-wireless
In-Reply-To: <20260430111831.219242-6-johannes@sipsolutions.net>
On Thu, 30 Apr 2026 13:17:52 +0200 Johannes Berg wrote:
> So the LLM floodgates are starting to open ;-) But I'm somewhat
> happy that so far we haven't gotten any really critical reports.
> Here's a couple of first fixes though.
>
> Please pull and let us know if there's any problem.
Looks like this breaks kunit:
ok 70 mac80211-tpe
KTAP version 1
# Subtest: mac80211-mlme-chan-mode
# module: mac80211_tests
1..1
KTAP version 1
# Subtest: test_determine_chan_mode
ok 1 Normal case, EHT is working
ok 2 Requiring EHT support is fine
ok 3 Lowering the mode limits us
kunit: required basic rate or BSS membership selectors not supported or disabled, rejecting connection
ok 4 Requesting a basic rate/selector that we do not support
ok 5 As before, but userspace says it is taking care of it
# test_determine_chan_mode: ASSERTION FAILED at net/mac80211/tests/chan-mode.c:258
Expected conn.mode == params->expected_mode, but
conn.mode == 5 (0x5)
params->expected_mode == 1 (0x1)
not ok 6 Masking out a supported rate in HT capabilities
kunit: Missing mandatory rates for 4 Nss, rx 0, tx 2 oper 2, disable VHT
kunit: required MCSes not supported, disabling VHT
ok 7 Masking out a RX rate in VHT capabilities
kunit: Missing mandatory rates for 4 Nss, rx 2, tx 0 oper 2, disable VHT
kunit: required MCSes not supported, disabling VHT
ok 8 Masking out a TX rate in VHT capabilities
kunit: Missing mandatory rates for 5 Nss, rx 0, tx 0 oper 2, disable VHT
kunit: required MCSes not supported, disabling VHT
ok 9 AP has higher VHT requirement than client
ok 10 all zero VHT basic rates are ignored (many APs broken)
kunit: Invalid rates for 3 Nss, rx 3, tx 3 oper 0, disable HE
kunit: required MCSes not supported, disabling HE
ok 11 AP requires 3 HE streams but client only has two
ok 12 all zero HE basic rates are ignored (iPhone workaround)
kunit: required MCSes not supported, disabling EHT
ok 13 AP requires too many RX streams with EHT MCS 7
kunit: required MCSes not supported, disabling EHT
ok 14 AP requires too many TX streams with EHT MCS 7
kunit: required MCSes not supported, disabling EHT
kunit: required basic rate or BSS membership selectors not supported or disabled, rejecting connection
ok 15 AP requires too many RX streams with EHT MCS 7 and EHT is required
kunit: regulatory prevented using AP config, downgraded
kunit: required bandwidth not supported, disabling EHT
ok 16 80 MHz EHT is downgraded to 40 MHz HE due to puncturing
# test_determine_chan_mode: pass:15 fail:1 skip:0 total:16
not ok 1 test_determine_chan_mode
# Totals: pass:15 fail:1 skip:0 total:16
^ permalink raw reply
* [wireless:for-next] BUILD SUCCESS d997c32157d2ca06e9f3f00ba6c4bf06593b49e7
From: kernel test robot @ 2026-04-30 14:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git for-next
branch HEAD: d997c32157d2ca06e9f3f00ba6c4bf06593b49e7 Merge tag 'ath-current-20260427' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
elapsed time: 2653m
configs tested: 191
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001 gcc-8.5.0
arc randconfig-001-20260430 gcc-8.5.0
arc randconfig-002 gcc-8.5.0
arc randconfig-002-20260430 gcc-8.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001 gcc-8.5.0
arm randconfig-001-20260430 gcc-8.5.0
arm randconfig-002 gcc-8.5.0
arm randconfig-002-20260430 gcc-8.5.0
arm randconfig-003 gcc-8.5.0
arm randconfig-003-20260430 gcc-8.5.0
arm randconfig-004 gcc-8.5.0
arm randconfig-004-20260430 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260430 clang-23
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260430 clang-23
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260430 clang-23
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260430 clang-23
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001 clang-23
csky randconfig-001-20260430 clang-23
csky randconfig-002 clang-23
csky randconfig-002-20260430 clang-23
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260430 gcc-14.3.0
hexagon randconfig-002-20260430 gcc-14.3.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260430 gcc-14
i386 buildonly-randconfig-002-20260430 gcc-14
i386 buildonly-randconfig-003-20260430 gcc-14
i386 buildonly-randconfig-004-20260430 gcc-14
i386 buildonly-randconfig-005-20260430 gcc-14
i386 buildonly-randconfig-006-20260430 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260430 clang-20
i386 randconfig-002-20260430 clang-20
i386 randconfig-003-20260430 clang-20
i386 randconfig-004-20260430 clang-20
i386 randconfig-005-20260430 clang-20
i386 randconfig-006-20260430 clang-20
i386 randconfig-007-20260430 clang-20
i386 randconfig-011 clang-20
i386 randconfig-011-20260430 clang-20
i386 randconfig-012 clang-20
i386 randconfig-012-20260430 clang-20
i386 randconfig-013 clang-20
i386 randconfig-013-20260430 clang-20
i386 randconfig-014 clang-20
i386 randconfig-014-20260430 clang-20
i386 randconfig-015 clang-20
i386 randconfig-015-20260430 clang-20
i386 randconfig-016 clang-20
i386 randconfig-016-20260430 clang-20
i386 randconfig-017 clang-20
i386 randconfig-017-20260430 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260430 gcc-14.3.0
loongarch randconfig-002-20260430 gcc-14.3.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips xway_defconfig clang-23
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260430 gcc-14.3.0
nios2 randconfig-002-20260430 gcc-14.3.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
openrisc simple_smp_defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260430 gcc-13.4.0
parisc randconfig-002-20260430 gcc-13.4.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc mvme5100_defconfig gcc-15.2.0
powerpc pasemi_defconfig clang-23
powerpc randconfig-001-20260430 gcc-13.4.0
powerpc randconfig-002-20260430 gcc-13.4.0
powerpc64 randconfig-001-20260430 gcc-13.4.0
powerpc64 randconfig-002-20260430 gcc-13.4.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001 clang-23
riscv randconfig-001-20260430 clang-23
riscv randconfig-002 clang-23
riscv randconfig-002-20260430 clang-23
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001 clang-23
s390 randconfig-001-20260430 clang-23
s390 randconfig-002 clang-23
s390 randconfig-002-20260430 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001 clang-23
sh randconfig-001-20260430 clang-23
sh randconfig-002 clang-23
sh randconfig-002-20260430 clang-23
sh se7206_defconfig gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260430 gcc-12.5.0
sparc randconfig-002-20260430 gcc-12.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260430 gcc-12.5.0
sparc64 randconfig-002-20260430 gcc-12.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260430 gcc-12.5.0
um randconfig-002-20260430 gcc-12.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260430 gcc-14
x86_64 buildonly-randconfig-002-20260430 gcc-14
x86_64 buildonly-randconfig-003-20260430 gcc-14
x86_64 buildonly-randconfig-004-20260430 gcc-14
x86_64 buildonly-randconfig-005-20260430 gcc-14
x86_64 buildonly-randconfig-006-20260430 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-011-20260430 clang-20
x86_64 randconfig-012-20260430 clang-20
x86_64 randconfig-013-20260430 clang-20
x86_64 randconfig-014-20260430 clang-20
x86_64 randconfig-015-20260430 clang-20
x86_64 randconfig-016-20260430 clang-20
x86_64 randconfig-071-20260430 gcc-14
x86_64 randconfig-072-20260430 gcc-14
x86_64 randconfig-073-20260430 gcc-14
x86_64 randconfig-074-20260430 gcc-14
x86_64 randconfig-075-20260430 gcc-14
x86_64 randconfig-076-20260430 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260430 gcc-12.5.0
xtensa randconfig-002-20260430 gcc-12.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 3/3 omap] ARM: dts: omap2: add stlc4560 spi-wireless node
From: Bartosz Golaszewski @ 2026-04-30 14:19 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, devicetree, linux-kernel, linux-arm-kernel,
linux-gpio, linux-omap, Krzysztof Kozlowski, netdev
In-Reply-To: <20260430081242.3686993-4-arnd@kernel.org>
On Thu, 30 Apr 2026 10:12:42 +0200, Arnd Bergmann <arnd@kernel.org> said:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Converted from the platform_device creation in board-n8x0.c.
>
> Link: https://lore.kernel.org/all/20230314163201.955689-1-arnd@kernel.org/
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH net-next] net: Consistently define pci_device_ids using named initializers
From: Arend van Spriel @ 2026-04-30 15:14 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: Markus Schneider-Pargmann, Steffen Klassert, David Dillow,
Ion Badulescu, Mark Einon, Rasesh Mody, GR-Linux-NIC-Dev,
Ido Schimmel, 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, Petr Machata,
Yibo Dong, Simon Horman, Heiner Kallweit, nic_swsd, Jiri Pirko,
Francois Romieu, Daniele Venzano, Samuel Chessman, Jiawen Wu,
Mengyuan Lou, Kevin Curtis, 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>
On 28/04/2026 19:18, 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.
for brcmfmac change...
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
[...]
> .../broadcom/brcm80211/brcmfmac/pcie.c | 17 +-
> drivers/net/wireless/intel/ipw2x00/ipw2200.c | 52 +-
> 69 files changed, 1308 insertions(+), 1101 deletions(-)
^ permalink raw reply
* Re: [GIT PULL] wireless-2026-04-30
From: Johannes Berg @ 2026-04-30 15:51 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, linux-wireless
In-Reply-To: <20260430071239.36b0e5f0@kernel.org>
On Thu, 2026-04-30 at 07:12 -0700, Jakub Kicinski wrote:
> On Thu, 30 Apr 2026 13:17:52 +0200 Johannes Berg wrote:
> > So the LLM floodgates are starting to open ;-) But I'm somewhat
> > happy that so far we haven't gotten any really critical reports.
> > Here's a couple of first fixes though.
> >
> > Please pull and let us know if there's any problem.
>
> Looks like this breaks kunit:
>
> ok 70 mac80211-tpe
> KTAP version 1
> # Subtest: mac80211-mlme-chan-mode
> # module: mac80211_tests
> 1..1
> KTAP version 1
> # Subtest: test_determine_chan_mode
> ok 1 Normal case, EHT is working
> ok 2 Requiring EHT support is fine
> ok 3 Lowering the mode limits us
> kunit: required basic rate or BSS membership selectors not supported or disabled, rejecting connection
> ok 4 Requesting a basic rate/selector that we do not support
> ok 5 As before, but userspace says it is taking care of it
> # test_determine_chan_mode: ASSERTION FAILED at net/mac80211/tests/chan-mode.c:258
> Expected conn.mode == params->expected_mode, but
> conn.mode == 5 (0x5)
> params->expected_mode == 1 (0x1)
> not ok 6 Masking out a supported rate in HT capabilities
>
D'oh. Yeah, that's the AP workaround, we'll need to adjust the test. I'm
on my way out right now, so I guess that'll have to wait for next week.
johannes
^ permalink raw reply
* Re: [GIT PULL] wireless-2026-04-30
From: Jakub Kicinski @ 2026-04-30 16:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-wireless
In-Reply-To: <027691e6472079e06f816462a8049308a1bea908.camel@sipsolutions.net>
On Thu, 30 Apr 2026 17:51:15 +0200 Johannes Berg wrote:
> On Thu, 2026-04-30 at 07:12 -0700, Jakub Kicinski wrote:
> > On Thu, 30 Apr 2026 13:17:52 +0200 Johannes Berg wrote:
> > > So the LLM floodgates are starting to open ;-) But I'm somewhat
> > > happy that so far we haven't gotten any really critical reports.
> > > Here's a couple of first fixes though.
> > >
> > > Please pull and let us know if there's any problem.
> >
> > Looks like this breaks kunit:
> >
> > ok 70 mac80211-tpe
> > KTAP version 1
> > # Subtest: mac80211-mlme-chan-mode
> > # module: mac80211_tests
> > 1..1
> > KTAP version 1
> > # Subtest: test_determine_chan_mode
> > ok 1 Normal case, EHT is working
> > ok 2 Requiring EHT support is fine
> > ok 3 Lowering the mode limits us
> > kunit: required basic rate or BSS membership selectors not supported or disabled, rejecting connection
> > ok 4 Requesting a basic rate/selector that we do not support
> > ok 5 As before, but userspace says it is taking care of it
> > # test_determine_chan_mode: ASSERTION FAILED at net/mac80211/tests/chan-mode.c:258
> > Expected conn.mode == params->expected_mode, but
> > conn.mode == 5 (0x5)
> > params->expected_mode == 1 (0x1)
> > not ok 6 Masking out a supported rate in HT capabilities
> >
>
> D'oh. Yeah, that's the AP workaround, we'll need to adjust the test. I'm
> on my way out right now, so I guess that'll have to wait for next week.
SG, Paolo already submitted our PR so from Linus tree's perspective
later today or early next week doesn't matter..
^ permalink raw reply
* [PATCH] wifi: cw1200: Revert "Fix locking in error paths"
From: Bart Van Assche @ 2026-04-30 17:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Bart Van Assche, Ben Hutchings, Kees Cook
Revert commit d98c24617a83 ("wifi: cw1200: Fix locking in error paths")
because it introduces a locking bug instead of fixing a locking bug.
cw1200_wow_resume() unlocks priv->conf_mutex. Hence, adding
mutex_unlock(&priv->conf_mutex) just after cw1200_wow_resume() is wrong.
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Closes: https://lore.kernel.org/all/408661f69f263266b028713e1412ba36d457e63d.camel@decadent.org.uk/
Fixes: d98c24617a83 ("wifi: cw1200: Fix locking in error paths")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/net/wireless/st/cw1200/pm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/st/cw1200/pm.c b/drivers/net/wireless/st/cw1200/pm.c
index 84eb15d729c7..120f0379f81d 100644
--- a/drivers/net/wireless/st/cw1200/pm.c
+++ b/drivers/net/wireless/st/cw1200/pm.c
@@ -264,14 +264,12 @@ int cw1200_wow_suspend(struct ieee80211_hw *hw, struct cfg80211_wowlan *wowlan)
wiphy_err(priv->hw->wiphy,
"PM request failed: %d. WoW is disabled.\n", ret);
cw1200_wow_resume(hw);
- mutex_unlock(&priv->conf_mutex);
return -EBUSY;
}
/* Force resume if event is coming from the device. */
if (atomic_read(&priv->bh_rx)) {
cw1200_wow_resume(hw);
- mutex_unlock(&priv->conf_mutex);
return -EAGAIN;
}
^ permalink raw reply related
* Re: [PATCH v2 0/7] Enable Bluetooth and WiFi on Fairphone (Gen. 6)
From: patchwork-bot+bluetooth @ 2026-04-30 17:55 UTC (permalink / raw)
To: Luca Weiss
Cc: andersson, konradybcio, robh, krzk+dt, conor+dt, AKoskovich,
lgirdwood, broonie, brgl, marcel, luiz.dentz, quic_bgodavar,
quic_rjliao, johannes, jjohnson, ~postmarketos/upstreaming,
phone-devel, linux-arm-msm, linux-kernel, devicetree,
linux-bluetooth, linux-wireless, ath11k, dmitry.baryshkov
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
Hello:
This series was applied to bluetooth/bluetooth-next.git (master)
by Mark Brown <broonie@kernel.org>:
On Fri, 03 Apr 2026 15:52:46 +0200 you wrote:
> Add the required bits to enable Bluetooth and WiFi on the Milos
> SoC-based Fairphone (Gen. 6) smartphone.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> Changes in v2:
> - Drop applied pd-mapper patch
> - Add compatibles for wcn6755 with fallback to wcn6750 (wifi & bt)
> - Rebase on linux-next
> - Pick up one tag (discard the rest due to addition of wcn6755
> compatibles)
> - Link to v1: https://lore.kernel.org/r/20260116-milos-fp6-bt-wifi-v1-0-27b4fbb77e9c@fairphone.com
>
> [...]
Here is the summary with links:
- [v2,1/7] regulator: dt-bindings: qcom,qca6390-pmu: Document WCN6755 PMU
https://git.kernel.org/bluetooth/bluetooth-next/c/b043657c35e5
- [v2,2/7] dt-bindings: bluetooth: qcom,wcn6750-bt: Document WCN6755 Bluetooth
(no matching commit)
- [v2,3/7] dt-bindings: net: wireless: ath11k: Document WCN6755 WiFi
(no matching commit)
- [v2,4/7] arm64: dts: qcom: milos: Split up uart11 pinctrl
(no matching commit)
- [v2,5/7] arm64: dts: qcom: milos: Add WCN6755 WiFi node
(no matching commit)
- [v2,6/7] arm64: dts: qcom: milos-fairphone-fp6: Enable Bluetooth
(no matching commit)
- [v2,7/7] arm64: dts: qcom: milos-fairphone-fp6: Enable WiFi
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: (subset) [PATCH v3 00/14] Remove redundant rcu_read_lock/unlock() in spin_lock
From: Jeff Johnson @ 2026-04-30 21:30 UTC (permalink / raw)
To: tj, tony.luck, jani.nikula, ap420073, jv, freude, bcrl, trondmy,
longman, kees, pengdonglin
Cc: bigeasy, hdanton, paulmck, linux-kernel, linux-rt-devel,
linux-nfs, linux-aio, linux-fsdevel, linux-security-module,
netdev, intel-gfx, linux-wireless, linux-acpi, linux-s390,
cgroups
In-Reply-To: <20250916044735.2316171-1-dolinux.peng@gmail.com>
On Tue, 16 Sep 2025 12:47:21 +0800, pengdonglin wrote:
> Since commit a8bb74acd8efe ("rcu: Consolidate RCU-sched update-side function definitions")
> there is no difference between rcu_read_lock(), rcu_read_lock_bh() and
> rcu_read_lock_sched() in terms of RCU read section and the relevant grace
> period. That means that spin_lock(), which implies rcu_read_lock_sched(),
> also implies rcu_read_lock().
>
> There is no need no explicitly start a RCU read section if one has already
> been started implicitly by spin_lock().
>
> [...]
Applied, thanks!
[14/14] wifi: ath9k: Remove redundant rcu_read_lock/unlock() in spin_lock
commit: c4f518736472c8cfbf1d304e01c631babd2bbf34
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath9k: use non devm for nvmem_cell_get
From: Jeff Johnson @ 2026-04-30 21:30 UTC (permalink / raw)
To: linux-wireless, Rosen Penev
Cc: Toke Høiland-Jørgensen, linux-kernel
In-Reply-To: <20260223025021.19008-1-rosenp@gmail.com>
On Sun, 22 Feb 2026 18:50:20 -0800, Rosen Penev wrote:
> There's absolutely no need to extend the lifetime of cell to post
> removal of the driver. It's only used in this function.
>
>
Applied, thanks!
[1/1] wifi: ath9k: use non devm for nvmem_cell_get
commit: 22e8b91d18972f5e1de13af7f55555e550ad1818
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath9k: owl: move name into owl_nvmem_probe
From: Jeff Johnson @ 2026-04-30 21:30 UTC (permalink / raw)
To: linux-wireless, Rosen Penev
Cc: Toke Høiland-Jørgensen, Andreas Färber,
Manivannan Sadhasivam, linux-arm-kernel, linux-actions,
linux-kernel
In-Reply-To: <20260223224254.27081-1-rosenp@gmail.com>
On Mon, 23 Feb 2026 14:42:54 -0800, Rosen Penev wrote:
> There is no need for dynamic allocation for a simple string.
> request_firmware_nowait copies the string internally anyway.
>
> The error message on failure is also wrong. It's an allocation failure,
> not a find failure.
>
>
> [...]
Applied, thanks!
[1/1] wifi: ath9k: owl: move name into owl_nvmem_probe
commit: 7b2338d5ec6fee29f92fae791219ab9fbd206567
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath9k: use kmemdup and kcalloc
From: Jeff Johnson @ 2026-04-30 21:30 UTC (permalink / raw)
To: linux-wireless, Rosen Penev
Cc: Toke Høiland-Jørgensen, linux-kernel
In-Reply-To: <20260223224445.27352-1-rosenp@gmail.com>
On Mon, 23 Feb 2026 14:44:45 -0800, Rosen Penev wrote:
> Simplifies the code slightly by removing temporary variables.
> multiplication overflow is also gained for free.
>
>
Applied, thanks!
[1/1] wifi: ath9k: use kmemdup and kcalloc
commit: 3042a9d403b9ead7c35b55e697eeae7974e04653
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2] wifi: ath9k: fix OOB access from firmware tx status queue ID
From: Jeff Johnson @ 2026-04-30 21:30 UTC (permalink / raw)
To: Toke Hoiland-Jorgensen, Tristan Madani
Cc: Johannes Berg, linux-wireless, linux-kernel
In-Reply-To: <20260415222343.1540564-1-tristmd@gmail.com>
On Wed, 15 Apr 2026 22:23:43 +0000, Tristan Madani wrote:
> ath_tx_edma_tasklet() accesses sc->tx.txq[ts.qid] where ts.qid is a
> 4-bit hardware field (0-15), but the txq array only has
> ATH9K_NUM_TX_QUEUES (10) entries. A qid >= 10 causes an OOB array
> access.
>
> Add a bounds check on ts.qid before using it as an array index.
>
> [...]
Applied, thanks!
[1/1] wifi: ath9k: fix OOB access from firmware tx status queue ID
commit: 7ce2f118a2389e8f0a64068c6fe7cc7d40639be0
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: (subset) [PATCH v2 0/4] Use the QMI service IDs from the QMI header
From: Jeff Johnson @ 2026-04-30 21:30 UTC (permalink / raw)
To: konradybcio, andersson, Daniel Lezcano
Cc: linux-kernel, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jeff Johnson,
Mathieu Poirier, Srinivas Kandagatla, Jaroslav Kysela,
Takashi Iwai, Kees Cook, Greg Kroah-Hartman, Arnd Bergmann,
Mark Brown, Wesley Cheng, netdev, linux-wireless, ath10k, ath11k,
ath12k, linux-arm-msm, linux-remoteproc, linux-sound
In-Reply-To: <20260316171419.2619620-1-daniel.lezcano@oss.qualcomm.com>
On Mon, 16 Mar 2026 18:14:10 +0100, Daniel Lezcano wrote:
> The different subsystems implementing the QMI service protocol are
> using their own definition of the service id. It is not a problem but
> it results on having those duplicated with different names but the
> same value and without consistency in their name.
>
> The QMI service IDs are defined in the qmi.h header file. Use those
> instead of defining the IDs in the protocol implementation file. It
> will result in unifying and providing a consistent way to represent
> the supported protocols.
>
> [...]
Applied, thanks!
[2/4] wifi: ath: Use the unified QMI service ID instead of defining it locally
commit: 0e39eea57626e545c596734c0d250c1735f1a7e5
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] wifi: ath: Unify user-visible "Qualcomm" name
From: Jeff Johnson @ 2026-04-30 21:30 UTC (permalink / raw)
To: Jeff Johnson, linux-wireless, ath11k, linux-kernel, ath12k,
Krzysztof Kozlowski
Cc: =Bjorn Andersson, Konrad Dybcio, linux-arm-msm
In-Reply-To: <20260427070040.17928-2-krzysztof.kozlowski@oss.qualcomm.com>
On Mon, 27 Apr 2026 09:00:41 +0200, Krzysztof Kozlowski wrote:
> Various names for Qualcomm as a company are used in user-visible config
> options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified
> "Qualcomm" so it will be easier for users to identify the options when
> for example running menuconfig.
>
>
Applied, thanks!
[1/1] wifi: ath: Unify user-visible "Qualcomm" name
commit: 2419d92ad387ff34376e7c3afc300cff651038da
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: Handle DP_RX_DECAP_TYPE_8023 type in Rx path
From: Jeff Johnson @ 2026-04-30 21:30 UTC (permalink / raw)
To: ath12k, Tamizh Chelvam Raja; +Cc: linux-wireless
In-Reply-To: <20260418163620.3633959-1-tamizh.raja@oss.qualcomm.com>
On Sat, 18 Apr 2026 22:06:20 +0530, Tamizh Chelvam Raja wrote:
> The driver does not currently set any rx_flag for frames received with
> decap type DP_RX_DECAP_TYPE_8023. When the hardware reports
> LLC-encapsulated packets whose length field is below 0x0600, the MSDU_END
> descriptor may indicate decap type DP_RX_DECAP_TYPE_8023.
>
> These frames are effectively equivalent to Ethernet-II (DIX) packets,
> similar to those decoded as DP_RX_DECAP_TYPE_ETHERNET2_DIX. If the
> driver does not set RX_FLAG_8023 for these frames, mac80211 will
> misinterpret them as 802.11 frames. This causes valid frames such as
> Bridge Protocol Data Units (BPDUs) to be dropped. BPDUs are exchanged
> between switches to maintain and manage network topology, and must
> be treated as Ethernet frames.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: Handle DP_RX_DECAP_TYPE_8023 type in Rx path
commit: c4aa897fe234a7bbfc0ba246df34137e3a88beb8
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCHv2 ath-next] wifi: ath12k: use kzalloc_flex
From: Jeff Johnson @ 2026-04-30 21:30 UTC (permalink / raw)
To: linux-wireless, Rosen Penev
Cc: Jeff Johnson, Kees Cook, Gustavo A. R. Silva, ath12k,
linux-kernel, linux-hardening
In-Reply-To: <20260421213544.6238-1-rosenp@gmail.com>
On Tue, 21 Apr 2026 14:35:44 -0700, Rosen Penev wrote:
> Convert kzalloc_obj + kcalloc to kzalloc_flex to save an allocation.
>
> Add __counted_by to get extra runtime analysis. Move counting variable
> assignment immediately after allocation before any potential accesses.
> kzalloc_flex does this anyway for GCC >= 15.
>
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: use kzalloc_flex
commit: d88c3a5117c58e1d93c20a7c723a6ad23136a430
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath11k: cancel SSR work items during PCI shutdown
From: Jeff Johnson @ 2026-04-30 21:30 UTC (permalink / raw)
To: Wei Zhang; +Cc: ath11k, linux-wireless, linux-kernel
In-Reply-To: <20260404043050.3433754-1-wei.zhang@oss.qualcomm.com>
On Fri, 03 Apr 2026 21:30:50 -0700, Wei Zhang wrote:
> A reboot can crash the kernel if it overlaps with WLAN firmware crash
> recovery (SSR). The crash is a NULL pointer dereference in the MHI teardown
> path while freeing DMA-backed MHI contexts.
>
> Simplified trace:
> dma_free_attrs
> mhi_deinit_dev_ctxt [mhi]
> ath11k_pci_power_down [ath11k_pci]
> ath11k_pci_shutdown [ath11k_pci]
> device_shutdown
> kernel_restart
>
> [...]
Applied, thanks!
[1/1] wifi: ath11k: cancel SSR work items during PCI shutdown
commit: 8c79aac429b583301f387374ff37c59be671df87
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: unify error handling in some ath12k_wmi_xxx() functions
From: Jeff Johnson @ 2026-04-30 21:30 UTC (permalink / raw)
To: ath12k, Nicolas Escande; +Cc: linux-wireless
In-Reply-To: <20260422163208.3013496-1-nico.escande@gmail.com>
On Wed, 22 Apr 2026 18:32:07 +0200, Nicolas Escande wrote:
> This is purely cosmetic changes that simplifies & standardizes error
> handling for functions that ends with a ath12k_wmi_cmd_send() followed
> by trivial error handling. Saves a few lines of code too.
>
> Compile tested only.
>
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: unify error handling in some ath12k_wmi_xxx() functions
commit: 31d4f8d427f2b9e423d7e177fb15f934cf0e37dd
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ 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