* Re: [PATCH 02/17] raid6: remove __KERNEL__ ifdefs
From: Eric Biggers @ 2026-03-25 19:58 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Christoph Hellwig, Andrew Morton, Catalin Marinas, Will Deacon,
Ard Biesheuvel, Huacai Chen, WANG Xuerui, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, Herbert Xu,
Dan Williams, Chris Mason, David Sterba, Arnd Bergmann, Song Liu,
Yu Kuai, Li Nan, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390, linux-crypto, linux-btrfs,
linux-arch, linux-raid
In-Reply-To: <fa11e4d3-1c70-4fa7-9f03-8772c002be6a@zytor.com>
On Wed, Mar 25, 2026 at 09:13:16AM -0700, H. Peter Anvin wrote:
> On 2026-03-25 08:13, H. Peter Anvin wrote:
> > On 2026-03-23 23:40, Christoph Hellwig wrote:
> >> With the test code ported to kernel space, none of this is required.
> >
> > I really *really* don't like this.
> >
> > The ability of running in user space is really useful when it comes to
> > developing new code for new platforms, which happens often enough for this code.
> >
>
> That being said -- and I do say this as the original author of this code --
> this should be reduced to the maximum extent possible to a (minimal) set of
> #ifndef __KERNEL__, which should be localized as much as possible. The actual
> user space components, even such a thing as a simple #include, should be moved
> to a separate user space header.
>
> But pretty please do leave the ability to debug the algorithms in user space.
> This is hard code to write and debug; it is not just about regression testing.
While I do like developing code in userspace as well, I've been doing it
less over time as the kernel's tests and benchmarks have been improved.
Running the KUnit tests is pretty straightforward and fast.
The issues with providing userspace build support in the tree are that:
- It has to be maintained.
- It's fundamentally a bit of a hack that is used only by developers
(who always have the option of doing something locally that is
tailored to the specific function they're working on)
- It diverts effort from the kernel's actual test and benchmark.
So while the faster iteration speed that userspace development enables
is definitely nice, I do think we should be cautious with committing to
maintain it in the kernel tree. If it's causing problems for the
ongoing refactoring, dropping it for now seems reasonable to me.
I would suggest adding a benchmark to the KUnit test similar to the
crypto and CRC ones, though.
- Eric
^ permalink raw reply
* Re: [PATCH RESEND v8 3/6] mfd: max77759: add register bitmasks and modify irq configs for charger
From: Amit Sunil Dhamne @ 2026-03-25 20:06 UTC (permalink / raw)
To: Lee Jones, Amit Sunil Dhamne via B4 Relay
Cc: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
André Draszik, Greg Kroah-Hartman, Badhri Jagan Sridharan,
Heikki Krogerus, Peter Griffin, Tudor Ambarus, Alim Akhtar,
Mark Brown, Matti Vaittinen, Andrew Morton, linux-kernel,
linux-pm, devicetree, linux-usb, linux-arm-kernel,
linux-samsung-soc, RD Babiera, Kyle Tso
In-Reply-To: <20260325151004.GD1141718@google.com>
Hi Lee,
Thanks for the review!
On 3/25/26 8:10 AM, Lee Jones wrote:
> On Sat, 14 Mar 2026, Amit Sunil Dhamne via B4 Relay wrote:
>
>> From: Amit Sunil Dhamne <amitsd@google.com>
>>
>> Add register bitmasks for charger function.
>>
>> In addition split the charger IRQs further such that each bit represents
>> an IRQ downstream of charger regmap irq chip. In addition populate the
>> ack_base to offload irq ack to the regmap irq chip framework.
>>
>> Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
>> Reviewed-by: André Draszik <andre.draszik@linaro.org>
>> ---
>> drivers/mfd/max77759.c | 91 ++++++++++++++++++++--
>> include/linux/mfd/max77759.h | 176 ++++++++++++++++++++++++++++++++++++-------
>> 2 files changed, 230 insertions(+), 37 deletions(-)
>>
>> diff --git a/drivers/mfd/max77759.c b/drivers/mfd/max77759.c
>> index a7efe233ec8c..288746f675b8 100644
>> --- a/drivers/mfd/max77759.c
>> +++ b/drivers/mfd/max77759.c
>> @@ -201,8 +201,24 @@ static const struct regmap_config max77759_regmap_config_charger = {
>> * - SYSUVLO_INT
>> * - FSHIP_NOT_RD
>> * - CHGR_INT: charger
>> - * - CHG_INT
>> - * - CHG_INT2
>> + * - INT1
>> + * - AICL
>> + * - CHGIN
>> + * - WCIN
>> + * - CHG
>> + * - BAT
>> + * - INLIM
>> + * - THM2
>> + * - BYP
>> + * - INT2
>> + * - INSEL
>> + * - SYS_UVLO1
>> + * - SYS_UVLO2
>> + * - BAT_OILO
>> + * - CHG_STA_CC
>> + * - CHG_STA_CV
>> + * - CHG_STA_TO
>> + * - CHG_STA_DONE
>> */
>> enum {
>> MAX77759_INT_MAXQ,
>> @@ -256,8 +286,38 @@ static const struct regmap_irq max77759_topsys_irqs[] = {
>> };
>>
>> static const struct regmap_irq max77759_chgr_irqs[] = {
>> - REGMAP_IRQ_REG(MAX77759_CHARGER_INT_1, 0, GENMASK(7, 0)),
>> - REGMAP_IRQ_REG(MAX77759_CHARGER_INT_2, 1, GENMASK(7, 0)),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_AICL, 0,
>> + MAX77759_CHGR_REG_CHG_INT_AICL),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_CHGIN, 0,
>> + MAX77759_CHGR_REG_CHG_INT_CHGIN),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_WCIN, 0,
>> + MAX77759_CHGR_REG_CHG_INT_WCIN),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_CHG, 0,
>> + MAX77759_CHGR_REG_CHG_INT_CHG),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_BAT, 0,
>> + MAX77759_CHGR_REG_CHG_INT_BAT),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_INLIM, 0,
>> + MAX77759_CHGR_REG_CHG_INT_INLIM),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_THM2, 0,
>> + MAX77759_CHGR_REG_CHG_INT_THM2),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_BYP, 0,
>> + MAX77759_CHGR_REG_CHG_INT_BYP),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_INSEL, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_INSEL),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_SYS_UVLO1, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO1),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_SYS_UVLO2, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO2),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_BAT_OILO, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_BAT_OILO),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_CC, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CC),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_CV, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CV),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_TO, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_CHG_STA_TO),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_DONE, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_CHG_STA_DONE),
>> };
>>
>> static const struct regmap_irq_chip max77759_pmic_irq_chip = {
>> @@ -302,6 +362,7 @@ static const struct regmap_irq_chip max77759_chrg_irq_chip = {
> Minor nit: The new code in this patch consistently uses "chgr" as the prefix
> for charger-related names. To improve consistency, how about we rename this
> struct to `max77759_chgr_irq_chip`?
Sure I can rename it for the goal of maintaining consistency.
>
>> .domain_suffix = "CHGR",
>> .status_base = MAX77759_CHGR_REG_CHG_INT,
>> .mask_base = MAX77759_CHGR_REG_CHG_INT_MASK,
>> + .ack_base = MAX77759_CHGR_REG_CHG_INT,
>> .num_regs = 2,
>> .irqs = max77759_chgr_irqs,
>> .num_irqs = ARRAY_SIZE(max77759_chgr_irqs),
>> @@ -325,8 +386,22 @@ static const struct resource max77759_gpio_resources[] = {
>> };
>>
>> static const struct resource max77759_charger_resources[] = {
>> - DEFINE_RES_IRQ_NAMED(MAX77759_CHARGER_INT_1, "INT1"),
>> - DEFINE_RES_IRQ_NAMED(MAX77759_CHARGER_INT_2, "INT2"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_AICL, "AICL"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_CHGIN, "CHGIN"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_WCIN, "WCIN"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_CHG, "CHG"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_BAT, "BAT"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_INLIM, "INLIM"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_THM2, "THM2"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_BYP, "BYP"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_INSEL, "INSEL"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_SYS_UVLO1, "SYS_UVLO1"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_SYS_UVLO2, "SYS_UVLO2"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_BAT_OILO, "BAT_OILO"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_CC, "CHG_STA_CC"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_CV, "CHG_STA_CV"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_TO, "CHG_STA_TO"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_DONE, "CHG_STA_DONE"),
>> };
>>
>> static const struct mfd_cell max77759_cells[] = {
>> diff --git a/include/linux/mfd/max77759.h b/include/linux/mfd/max77759.h
>> index c6face34e385..fd5aea21ab2e 100644
>> --- a/include/linux/mfd/max77759.h
>> +++ b/include/linux/mfd/max77759.h
>> @@ -59,35 +59,65 @@
>> #define MAX77759_MAXQ_REG_AP_DATAIN0 0xb1
>> #define MAX77759_MAXQ_REG_UIC_SWRST 0xe0
>>
>> -#define MAX77759_CHGR_REG_CHG_INT 0xb0
>> -#define MAX77759_CHGR_REG_CHG_INT2 0xb1
>> -#define MAX77759_CHGR_REG_CHG_INT_MASK 0xb2
>> -#define MAX77759_CHGR_REG_CHG_INT2_MASK 0xb3
>> -#define MAX77759_CHGR_REG_CHG_INT_OK 0xb4
>> -#define MAX77759_CHGR_REG_CHG_DETAILS_00 0xb5
>> -#define MAX77759_CHGR_REG_CHG_DETAILS_01 0xb6
>> -#define MAX77759_CHGR_REG_CHG_DETAILS_02 0xb7
>> -#define MAX77759_CHGR_REG_CHG_DETAILS_03 0xb8
>> -#define MAX77759_CHGR_REG_CHG_CNFG_00 0xb9
>> -#define MAX77759_CHGR_REG_CHG_CNFG_01 0xba
>> -#define MAX77759_CHGR_REG_CHG_CNFG_02 0xbb
>> -#define MAX77759_CHGR_REG_CHG_CNFG_03 0xbc
>> -#define MAX77759_CHGR_REG_CHG_CNFG_04 0xbd
>> -#define MAX77759_CHGR_REG_CHG_CNFG_05 0xbe
>> -#define MAX77759_CHGR_REG_CHG_CNFG_06 0xbf
>> -#define MAX77759_CHGR_REG_CHG_CNFG_07 0xc0
>> -#define MAX77759_CHGR_REG_CHG_CNFG_08 0xc1
>> -#define MAX77759_CHGR_REG_CHG_CNFG_09 0xc2
>> -#define MAX77759_CHGR_REG_CHG_CNFG_10 0xc3
>> -#define MAX77759_CHGR_REG_CHG_CNFG_11 0xc4
>> -#define MAX77759_CHGR_REG_CHG_CNFG_12 0xc5
>> -#define MAX77759_CHGR_REG_CHG_CNFG_13 0xc6
>> -#define MAX77759_CHGR_REG_CHG_CNFG_14 0xc7
>> -#define MAX77759_CHGR_REG_CHG_CNFG_15 0xc8
>> -#define MAX77759_CHGR_REG_CHG_CNFG_16 0xc9
>> -#define MAX77759_CHGR_REG_CHG_CNFG_17 0xca
>> -#define MAX77759_CHGR_REG_CHG_CNFG_18 0xcb
>> -#define MAX77759_CHGR_REG_CHG_CNFG_19 0xcc
>> +#define MAX77759_CHGR_REG_CHG_INT 0xb0
>> +#define MAX77759_CHGR_REG_CHG_INT_AICL BIT(7)
>> +#define MAX77759_CHGR_REG_CHG_INT_CHGIN BIT(6)
>> +#define MAX77759_CHGR_REG_CHG_INT_WCIN BIT(5)
>> +#define MAX77759_CHGR_REG_CHG_INT_CHG BIT(4)
>> +#define MAX77759_CHGR_REG_CHG_INT_BAT BIT(3)
>> +#define MAX77759_CHGR_REG_CHG_INT_INLIM BIT(2)
>> +#define MAX77759_CHGR_REG_CHG_INT_THM2 BIT(1)
>> +#define MAX77759_CHGR_REG_CHG_INT_BYP BIT(0)
>> +#define MAX77759_CHGR_REG_CHG_INT2 0xb1
>> +#define MAX77759_CHGR_REG_CHG_INT2_INSEL BIT(7)
>> +#define MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO1 BIT(6)
>> +#define MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO2 BIT(5)
>> +#define MAX77759_CHGR_REG_CHG_INT2_BAT_OILO BIT(4)
>> +#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CC BIT(3)
>> +#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CV BIT(2)
>> +#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_TO BIT(1)
>> +#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_DONE BIT(0)
>> +#define MAX77759_CHGR_REG_CHG_INT_MASK 0xb2
>> +#define MAX77759_CHGR_REG_CHG_INT2_MASK 0xb3
>> +#define MAX77759_CHGR_REG_CHG_INT_OK 0xb4
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_00 0xb5
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_00_CHGIN_DTLS GENMASK(6, 5)
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_01 0xb6
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_01_BAT_DTLS GENMASK(6, 4)
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_01_CHG_DTLS GENMASK(3, 0)
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_02 0xb7
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_02_CHGIN_STS BIT(5)
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_03 0xb8
>> +#define MAX77759_CHGR_REG_CHG_CNFG_00 0xb9
>> +#define MAX77759_CHGR_REG_CHG_CNFG_00_MODE GENMASK(3, 0)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_01 0xba
>> +#define MAX77759_CHGR_REG_CHG_CNFG_02 0xbb
>> +#define MAX77759_CHGR_REG_CHG_CNFG_02_CHGCC GENMASK(5, 0)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_03 0xbc
>> +#define MAX77759_CHGR_REG_CHG_CNFG_04 0xbd
>> +#define MAX77759_CHGR_REG_CHG_CNFG_04_CHG_CV_PRM GENMASK(5, 0)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_05 0xbe
>> +#define MAX77759_CHGR_REG_CHG_CNFG_06 0xbf
>> +#define MAX77759_CHGR_REG_CHG_CNFG_06_CHGPROT GENMASK(3, 2)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_07 0xc0
>> +#define MAX77759_CHGR_REG_CHG_CNFG_08 0xc1
>> +#define MAX77759_CHGR_REG_CHG_CNFG_09 0xc2
>> +#define MAX77759_CHGR_REG_CHG_CNFG_09_CHGIN_ILIM GENMASK(6, 0)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_10 0xc3
>> +#define MAX77759_CHGR_REG_CHG_CNFG_11 0xc4
>> +#define MAX77759_CHGR_REG_CHG_CNFG_12 0xc5
>> +/* Wireless Charging input channel select */
>> +#define MAX77759_CHGR_REG_CHG_CNFG_12_WCINSEL BIT(6)
>> +/* CHGIN/USB input channel select */
>> +#define MAX77759_CHGR_REG_CHG_CNFG_12_CHGINSEL BIT(5)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_13 0xc6
>> +#define MAX77759_CHGR_REG_CHG_CNFG_14 0xc7
>> +#define MAX77759_CHGR_REG_CHG_CNFG_15 0xc8
>> +#define MAX77759_CHGR_REG_CHG_CNFG_16 0xc9
>> +#define MAX77759_CHGR_REG_CHG_CNFG_17 0xca
>> +#define MAX77759_CHGR_REG_CHG_CNFG_18 0xcb
>> +#define MAX77759_CHGR_REG_CHG_CNFG_18_WDTEN BIT(0)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_19 0xcc
>>
>> /* MaxQ opcodes for max77759_maxq_command() */
>> #define MAX77759_MAXQ_OPCODE_MAXLENGTH (MAX77759_MAXQ_REG_AP_DATAOUT32 - \
>> @@ -101,6 +131,94 @@
>> #define MAX77759_MAXQ_OPCODE_USER_SPACE_READ 0x81
>> #define MAX77759_MAXQ_OPCODE_USER_SPACE_WRITE 0x82
>>
>> +/*
>> + * Charger Input Status
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_UNDERVOLTAGE:
>> + * Charger input voltage (Vchgin) < Under Voltage Threshold (Vuvlo)
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_MARGINAL_VOLTAGE: Vchgin > Vuvlo and
>> + * Vchgin < (Battery Voltage (Vbatt) + system voltage (Vsys))
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_OVERVOLTAGE:
>> + * Vchgin > Over Voltage threshold (Vovlo)
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_VALID:
>> + * Vchgin > Vuvlo, Vchgin < Vovlo and Vchgin > (Vsys + Vbatt)
>> + */
>> +enum max77759_chgr_chgin_dtls_status {
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_UNDERVOLTAGE,
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_MARGINAL_VOLTAGE,
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_OVERVOLTAGE,
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_VALID,
>> +};
>> +
>> +/*
>> + * Battery Details
>> + * @MAX77759_CHGR_BAT_DTLS_NO_BATT_CHG_SUSP:
>> + * No battery and the charger suspended
>> + * @MAX77759_CHGR_BAT_DTLS_DEAD_BATTERY: Vbatt < Vtrickle
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_CHG_TIMER_FAULT:
>> + * Charging suspended due to timer fault
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_OKAY:
>> + * Battery okay and Vbatt > Min Sys Voltage (Vsysmin)
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_UNDERVOLTAGE:
>> + * Battery is okay. Vtrickle < Vbatt < Vsysmin
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_OVERVOLTAGE:
>> + * Battery voltage > Overvoltage threshold
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_OVERCURRENT:
>> + * Battery current exceeds overcurrent threshold
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_ONLY_MODE:
>> + * Battery only mode and battery level not available
>> + */
>> +enum max77759_chgr_bat_dtls_states {
>> + MAX77759_CHGR_BAT_DTLS_NO_BATT_CHG_SUSP,
>> + MAX77759_CHGR_BAT_DTLS_DEAD_BATTERY,
>> + MAX77759_CHGR_BAT_DTLS_BAT_CHG_TIMER_FAULT,
>> + MAX77759_CHGR_BAT_DTLS_BAT_OKAY,
>> + MAX77759_CHGR_BAT_DTLS_BAT_UNDERVOLTAGE,
>> + MAX77759_CHGR_BAT_DTLS_BAT_OVERVOLTAGE,
>> + MAX77759_CHGR_BAT_DTLS_BAT_OVERCURRENT,
>> + MAX77759_CHGR_BAT_DTLS_BAT_ONLY_MODE,
>> +};
>> +
>> +/*
>> + * Charger Details
>> + * @MAX77759_CHGR_CHG_DTLS_PREQUAL: Charger in prequalification mode
>> + * @MAX77759_CHGR_CHG_DTLS_CC: Charger in fast charge const curr mode
>> + * @MAX77759_CHGR_CHG_DTLS_CV: Charger in fast charge const voltage mode
>> + * @MAX77759_CHGR_CHG_DTLS_TO: Charger is in top off mode
>> + * @MAX77759_CHGR_CHG_DTLS_DONE: Charger is done
>> + * @MAX77759_CHGR_CHG_DTLS_RSVD_1: Reserved
>> + * @MAX77759_CHGR_CHG_DTLS_TIMER_FAULT: Charger is in timer fault mode
>> + * @MAX77759_CHGR_CHG_DTLS_SUSP_BATT_THM:
>> + * Charger is suspended as bettery removal detected
> Typo here, s/bettery/battery/.
Will fix.
>
>> + * @MAX77759_CHGR_CHG_DTLS_OFF:
>> + * Charger is off. Input invalid or charger disabled
>> + * @MAX77759_CHGR_CHG_DTLS_RSVD_2: Reserved
>> + * @MAX77759_CHGR_CHG_DTLS_RSVD_3: Reserved
>> + * @MAX77759_CHGR_CHG_DTLS_OFF_WDOG_TIMER:
>> + * Charger is off as watchdog timer expired
>> + * @MAX77759_CHGR_CHG_DTLS_SUSP_JEITA: Charger is in JEITA control mode
>> + */
>> +enum max77759_chgr_chg_dtls_states {
> Just a small style suggestion, could you please align the descriptions in this
> kerneldoc block? It improves readability. Using a consistent number of spaces
> or tabs after the colon helps.
>
> Feel free to use up to 100-chars if it improves readability.
I will try to align the descriptions for enumerators inside each enum.
Since I can use 100 chars I can try to fit the descriptions in a single
line for this and `enum max77759_chgr_bat_dtls_states` as well. Hope
that's okay?
BR,
Amit
^ permalink raw reply
* Re: [PATCH v3 1/2] net: stmmac: provide flag to disable EEE
From: Laurent Pinchart @ 2026-03-25 20:13 UTC (permalink / raw)
To: netdev
Cc: Russell King (Oracle), imx, Andrew Lunn, David S. Miller,
Eric Dumazet, Fabio Estevam, Francesco Dolcini, Frank Li,
Jakub Kicinski, Joy Zou, Kieran Bingham, Marco Felsch,
Paolo Abeni, Pengutronix Kernel Team, Stefan Klug,
linux-arm-kernel
In-Reply-To: <20260323100801.GA1514659@killaraus.ideasonboard.com>
On Mon, Mar 23, 2026 at 12:08:02PM +0200, Laurent Pinchart wrote:
> On Mon, Mar 23, 2026 at 09:55:36AM +0000, Russell King (Oracle) wrote:
> > On Mon, Mar 23, 2026 at 11:39:32AM +0200, Laurent Pinchart wrote:
> > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
> > >
> > > Some platforms have problems when EEE is enabled, and thus need a way
> > > to disable stmmac EEE support. Add a flag before the other LPI related
> > > flags which tells stmmac to avoid populating the phylink LPI
> > > capabilities, which causes phylink to call phy_disable_eee() for any
> > > PHY that is attached to the affected phylink instance.
> > >
> > > iMX8MP is an example - the lpi_intr_o signal is wired to an OR gate
> > > along with the main dwmac interrupts. Since lpi_intr_o is synchronous
> > > to the receive clock domain, and takes four clock cycles to clear, this
> > > leads to interrupt storms as the interrupt remains asserted for some
> > > time after the LPI control and status register is read.
> > >
> > > This problem becomes worse when the receive clock from the PHY stops
> > > when the receive path enters LPI state - which means that lpi_intr_o
> > > can not deassert until the clock restarts. Since the LPI state of the
> > > receive path depends on the link partner, this is out of our control.
> > > We could disable RX clock stop at the PHY, but that doesn't get around
> > > the slow-to-deassert lpi_intr_o mentioned in the above paragraph.
> > >
> > > Previously, iMX8MP worked around this by disabling gigabit EEE, but
> > > this is insufficient - the problem is also visible at 100M speeds,
> > > where the receive clock is slower.
> > >
> > > There is extensive discussion and investigation in the thread linked
> > > below, the result of which is summarised in this commit message.
> > >
> > > Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > Closes: https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com
> > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> >
> > As you are sending this on my behalf, you need to add your s-o-b after
> > mine:
>
> Oops, I'm not sure how I missed that. Sorry.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Should I submit a v4, or can this series be picked for v7.1 with my SoB
added ?
> > Any further SoBs (Signed-off-by:'s) following the author's SoB are from
> > people handling and transporting the patch, but were not involved in its
> > development. SoB chains should reflect the **real** route a patch took
> > as it was propagated to the maintainers and ultimately to Linus, with
> > the first SoB entry signalling primary authorship of a single author.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v10 00/12] barrier: Add smp_cond_load_{relaxed,acquire}_timeout()
From: David Laight @ 2026-03-25 20:23 UTC (permalink / raw)
To: Catalin Marinas
Cc: Ankur Arora, Andrew Morton, linux-kernel, linux-arch,
linux-arm-kernel, linux-pm, bpf, arnd, will, peterz, mark.rutland,
harisokn, cl, ast, rafael, daniel.lezcano, memxor, zhenglifeng1,
xueshuai, rdunlap, joao.m.martins, boris.ostrovsky, konrad.wilk
In-Reply-To: <acQOMZMk0OMfIgFO@arm.com>
On Wed, 25 Mar 2026 16:32:49 +0000
Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Wed, Mar 25, 2026 at 03:42:10PM +0000, David Laight wrote:
...
> > Looking at the code I think the "sevl; wfe" pair should be higher up.
>
> Yes, I replied to your other message. We could move it higher indeed,
> before the condition check, but I can't get my head around the ordering.
> Can need_resched() check be speculated before the WFE? I need to think
> some more.
I don't think speculation can matter.
Both SEVL and WFE must be serialised against any other instructions
that can change the event flag (as well as each other) otherwise
everything is broken.
Apart from that it doesn't matter, what matters is the instruction
boundary the interrupt happens at.
Actually both SEVL and WFE may be synchronising instructions and very slow.
So you may not want to put them in the fast path where the condition
is true on entry (or even true after a retry).
So the code might have to look like:
for (;;) {
VAL = mem;
if (cond(VAL)) return;
SEVL; WFE;
if (cond(VAL)) return;
v1 = LDX(mem);
if (v1 == VAL)
WFE;
}
Definitely needs a comment that both 'return from exception' and
losing the exclusive access set the event flag.
The asm probably ought to have a full "memory" clobber.
Just in case the compiler gets lively with re-ordering.
David
^ permalink raw reply
* Re: [PATCH net-next v8 1/6] Add 25GMAC core type to dwmac_core_type enum
From: Jitendra Vegiraju @ 2026-03-25 20:25 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, alexandre.torgue, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, bcm-kernel-feedback-list, richardcochran, ast,
daniel, hawk, john.fastabend, rmk+kernel, rohan.g.thomas,
linux-kernel, linux-stm32, linux-arm-kernel, bpf, andrew+netdev,
sdf, me, siyanteng, prabhakar.mahadev-lad.rj, weishangjuan, wens,
vladimir.oltean, lizhi2, boon.khai.ng, maxime.chevallier,
chenchuangyu, yangtiezhu, ovidiu.panait.rb, chenhuacai,
florian.fainelli, quic_abchauha
In-Reply-To: <20260323145526.GA94382@horms.kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
On Mon, Mar 23, 2026 at 7:55 AM Simon Horman <horms@kernel.org> wrote:
>
> On Fri, Mar 20, 2026 at 02:19:16PM -0700, Jitendra Vegiraju wrote:
> > From: Jitendra Vegiraju <jitendra.vegiraju@broadcom.com>
> >
> > The DW25GMAC is a newer ethernet MAC IP block from Synopsys that introduced
> > new DMA architecure called Hyper-DMA. Define a new dwmac_core_type
> > enum in include/linux/stmmac.h file.
> >
> > Signed-off-by: Jitendra Vegiraju <jitendra.vegiraju@broadcom.com>
> > ---
> > include/linux/stmmac.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> > index 72febd246bdb..464f4f2e366a 100644
> > --- a/include/linux/stmmac.h
> > +++ b/include/linux/stmmac.h
> > @@ -197,6 +197,7 @@ enum dwmac_core_type {
> > DWMAC_CORE_GMAC,
> > DWMAC_CORE_GMAC4,
> > DWMAC_CORE_XGMAC,
> > + DWMAC_CORE_25GMAC,
> > };
>
> Hi Jitendra,
>
> W=1 builds warn that this new enum value is not handled in
> the switch statement in stmmac_print_actphyif()
>
> This seems to be addressed in patch 2/6.
> And I would suggest squashing this patch into that one.
>
Hi Simon,
Thanks for the suggestion, I will squash patches 1/6 and 2/6.
> --
> pw-bot: changes-requested
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5435 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] net: stmmac: provide flag to disable EEE
From: Russell King (Oracle) @ 2026-03-25 20:40 UTC (permalink / raw)
To: Laurent Pinchart
Cc: netdev, imx, Andrew Lunn, David S. Miller, Eric Dumazet,
Fabio Estevam, Francesco Dolcini, Frank Li, Jakub Kicinski,
Joy Zou, Kieran Bingham, Marco Felsch, Paolo Abeni,
Pengutronix Kernel Team, Stefan Klug, linux-arm-kernel
In-Reply-To: <20260325201332.GA2670326@killaraus.ideasonboard.com>
On Wed, Mar 25, 2026 at 10:13:32PM +0200, Laurent Pinchart wrote:
> On Mon, Mar 23, 2026 at 12:08:02PM +0200, Laurent Pinchart wrote:
> > On Mon, Mar 23, 2026 at 09:55:36AM +0000, Russell King (Oracle) wrote:
> > > On Mon, Mar 23, 2026 at 11:39:32AM +0200, Laurent Pinchart wrote:
> > > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
> > > >
> > > > Some platforms have problems when EEE is enabled, and thus need a way
> > > > to disable stmmac EEE support. Add a flag before the other LPI related
> > > > flags which tells stmmac to avoid populating the phylink LPI
> > > > capabilities, which causes phylink to call phy_disable_eee() for any
> > > > PHY that is attached to the affected phylink instance.
> > > >
> > > > iMX8MP is an example - the lpi_intr_o signal is wired to an OR gate
> > > > along with the main dwmac interrupts. Since lpi_intr_o is synchronous
> > > > to the receive clock domain, and takes four clock cycles to clear, this
> > > > leads to interrupt storms as the interrupt remains asserted for some
> > > > time after the LPI control and status register is read.
> > > >
> > > > This problem becomes worse when the receive clock from the PHY stops
> > > > when the receive path enters LPI state - which means that lpi_intr_o
> > > > can not deassert until the clock restarts. Since the LPI state of the
> > > > receive path depends on the link partner, this is out of our control.
> > > > We could disable RX clock stop at the PHY, but that doesn't get around
> > > > the slow-to-deassert lpi_intr_o mentioned in the above paragraph.
> > > >
> > > > Previously, iMX8MP worked around this by disabling gigabit EEE, but
> > > > this is insufficient - the problem is also visible at 100M speeds,
> > > > where the receive clock is slower.
> > > >
> > > > There is extensive discussion and investigation in the thread linked
> > > > below, the result of which is summarised in this commit message.
> > > >
> > > > Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > Closes: https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com
> > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> > >
> > > As you are sending this on my behalf, you need to add your s-o-b after
> > > mine:
> >
> > Oops, I'm not sure how I missed that. Sorry.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> Should I submit a v4, or can this series be picked for v7.1 with my SoB
> added ?
I don't see it in patchwork's pending queue, so yes please. Don't forget
to specify the tree in the subject line:
[PATCH net-next v4 0/2] net: stmmac: ...
which may be a factor in it not showing up.
It's worth keeping an eye on:
https://patchwork.kernel.org/project/netdevbpf/list/?delegate=123371
about 24h after submission in case of any issues.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net-next v9 2/6] net: stmmac: qcom-ethqos: use generic device properties
From: Russell King (Oracle) @ 2026-03-25 20:46 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Vinod Koul, Giuseppe Cavallaro, Chen-Yu Tsai, Jernej Skrabec,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Shawn Guo,
Fabio Estevam, Jan Petrous, s32, Mohd Ayaan Anwar, Romain Gantois,
Geert Uytterhoeven, Magnus Damm, Maxime Ripard,
Christophe Roullier, Bartosz Golaszewski, Radu Rendec,
linux-arm-msm, devicetree, linux-kernel, netdev, linux-stm32,
linux-arm-kernel, Drew Fustini, linux-sunxi, linux-amlogic,
linux-mips, imx, linux-renesas-soc, linux-rockchip, sophgo,
linux-riscv, Bartosz Golaszewski
In-Reply-To: <20260316-qcom-sa8255p-emac-v9-2-c58934e76ff2@oss.qualcomm.com>
On Mon, Mar 16, 2026 at 01:05:07PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> In order to drop the dependency on CONFIG_OF, convert all device property
> getters from OF-specific to generic device properties and stop pulling
> in any linux/of.h symbols.
Why is this desirable? Please see the recent discussion at
https://lore.kernel.org/r/20260322-remove-device-find-by-of-node-v1-0-b72eb22a1215@gmail.com
specifically replies from Andrew and myself.
Merely wanting to drop a dependency is not a good enough reason for
these kinds of conversions, because they in effect make the DT
properties also apply to ACPI which may not be appropriate (note
for example that MDIO busses are not represented in ACPI.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net-next v9 5/6] net: stmmac: qcom-ethqos: split power management context into a separate struct
From: Russell King (Oracle) @ 2026-03-25 20:52 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Vinod Koul, Giuseppe Cavallaro, Chen-Yu Tsai, Jernej Skrabec,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Shawn Guo,
Fabio Estevam, Jan Petrous, s32, Mohd Ayaan Anwar, Romain Gantois,
Geert Uytterhoeven, Magnus Damm, Maxime Ripard,
Christophe Roullier, Bartosz Golaszewski, Radu Rendec,
linux-arm-msm, devicetree, linux-kernel, netdev, linux-stm32,
linux-arm-kernel, Drew Fustini, linux-sunxi, linux-amlogic,
linux-mips, imx, linux-renesas-soc, linux-rockchip, sophgo,
linux-riscv, Bartosz Golaszewski
In-Reply-To: <20260316-qcom-sa8255p-emac-v9-5-c58934e76ff2@oss.qualcomm.com>
On Mon, Mar 16, 2026 at 01:05:10PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> With match data split into general and power-management sections, let's
> now do the same with runtime device data.
As I've already said, this conflicts with work that I have in progress,
which will remove the serdes support from this driver _if_ we can get
forward progress on the PCS bits from Mohd - that has become dependent
on sorting out the MDIO bus clock which seems to have been totally
broken in this driver for quite some time so that we can have confidence
that any testing that is done is actually being done on a setup which is
running within correct specification (and not running the MDIO bus at
some insane speed that may lead to data corruption.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* [PATCH net-next v4 0/2] net: stmmac: Disable EEE on i.MX
From: Laurent Pinchart @ 2026-03-25 21:00 UTC (permalink / raw)
To: netdev, imx
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Fabio Estevam,
Francesco Dolcini, Frank Li, Jakub Kicinski, Joy Zou,
Kieran Bingham, Marco Felsch, Paolo Abeni,
Pengutronix Kernel Team, Russell King (Oracle), Stefan Klug,
linux-arm-kernel
Hello,
This small patch series fixes a long-standing interrupt storm issue with
stmmac on NXP i.MX platforms.
The initial attempt to fix^Wwork around the problem in DT ([1]) was
painfully but rightfully rejected by Russell, who helped me investigate
the issue in depth. It turned out that the root cause is a mistake in
how interrupts are wired in the SoC, a hardware bug that has been
replicated in all i.MX SoCs that integrate an stmmac. The only viable
solution is to disable EEE on those devices.
Individual patches explain the issue in more details. Patch 1/2,
authored by Russell, adds a new STMMAC_FLAG to disable EEE, and patch
2/2 sets the flag for i.MX platforms.
[1] https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com
Laurent Pinchart (1):
net: stmmac: imx: Disable EEE
Russell King (Oracle) (1):
net: stmmac: provide flag to disable EEE
drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c | 9 +++------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 ++++++-
include/linux/stmmac.h | 13 +++++++------
3 files changed, 16 insertions(+), 13 deletions(-)
base-commit: d1e59a46973719e458bec78d00dd767d7a7ba71f
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH net-next v4 1/2] net: stmmac: provide flag to disable EEE
From: Laurent Pinchart @ 2026-03-25 21:00 UTC (permalink / raw)
To: netdev, imx
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Fabio Estevam,
Francesco Dolcini, Frank Li, Jakub Kicinski, Joy Zou,
Kieran Bingham, Marco Felsch, Paolo Abeni,
Pengutronix Kernel Team, Russell King (Oracle), Stefan Klug,
linux-arm-kernel
In-Reply-To: <20260325210003.2752013-1-laurent.pinchart@ideasonboard.com>
From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
Some platforms have problems when EEE is enabled, and thus need a way
to disable stmmac EEE support. Add a flag before the other LPI related
flags which tells stmmac to avoid populating the phylink LPI
capabilities, which causes phylink to call phy_disable_eee() for any
PHY that is attached to the affected phylink instance.
iMX8MP is an example - the lpi_intr_o signal is wired to an OR gate
along with the main dwmac interrupts. Since lpi_intr_o is synchronous
to the receive clock domain, and takes four clock cycles to clear, this
leads to interrupt storms as the interrupt remains asserted for some
time after the LPI control and status register is read.
This problem becomes worse when the receive clock from the PHY stops
when the receive path enters LPI state - which means that lpi_intr_o
can not deassert until the clock restarts. Since the LPI state of the
receive path depends on the link partner, this is out of our control.
We could disable RX clock stop at the PHY, but that doesn't get around
the slow-to-deassert lpi_intr_o mentioned in the above paragraph.
Previously, iMX8MP worked around this by disabling gigabit EEE, but
this is insufficient - the problem is also visible at 100M speeds,
where the receive clock is slower.
There is extensive discussion and investigation in the thread linked
below, the result of which is summarised in this commit message.
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Closes: https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Tested-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 ++++++-
include/linux/stmmac.h | 13 +++++++------
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 9b6b49331639..ce51b9c22129 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1438,7 +1438,12 @@ static int stmmac_phylink_setup(struct stmmac_priv *priv)
config->supported_interfaces,
pcs->supported_interfaces);
- if (priv->dma_cap.eee) {
+ /* Some platforms, e.g. iMX8MP, wire lpi_intr_o to the same interrupt
+ * used for stmmac's main interrupts, which leads to interrupt storms.
+ * STMMAC_FLAG_EEE_DISABLE allows EEE to be disabled on such platforms.
+ */
+ if (priv->dma_cap.eee &&
+ !(priv->plat->flags & STMMAC_FLAG_EEE_DISABLE)) {
/* The GMAC 3.74a databook states that EEE is only supported
* in MII, GMII, and RGMII interfaces.
*/
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 5b2bece81448..e62d21afd56d 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -207,12 +207,13 @@ enum dwmac_core_type {
#define STMMAC_FLAG_MULTI_MSI_EN BIT(7)
#define STMMAC_FLAG_EXT_SNAPSHOT_EN BIT(8)
#define STMMAC_FLAG_INT_SNAPSHOT_EN BIT(9)
-#define STMMAC_FLAG_RX_CLK_RUNS_IN_LPI BIT(10)
-#define STMMAC_FLAG_EN_TX_LPI_CLOCKGATING BIT(11)
-#define STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP BIT(12)
-#define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY BIT(13)
-#define STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD BIT(14)
-#define STMMAC_FLAG_SERDES_SUPPORTS_2500M BIT(15)
+#define STMMAC_FLAG_EEE_DISABLE BIT(10)
+#define STMMAC_FLAG_RX_CLK_RUNS_IN_LPI BIT(11)
+#define STMMAC_FLAG_EN_TX_LPI_CLOCKGATING BIT(12)
+#define STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP BIT(13)
+#define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY BIT(14)
+#define STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD BIT(15)
+#define STMMAC_FLAG_SERDES_SUPPORTS_2500M BIT(16)
struct mac_device_info;
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* [PATCH net-next v4 2/2] net: stmmac: imx: Disable EEE
From: Laurent Pinchart @ 2026-03-25 21:00 UTC (permalink / raw)
To: netdev, imx
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Fabio Estevam,
Francesco Dolcini, Frank Li, Jakub Kicinski, Joy Zou,
Kieran Bingham, Marco Felsch, Paolo Abeni,
Pengutronix Kernel Team, Russell King (Oracle), Stefan Klug,
linux-arm-kernel
In-Reply-To: <20260325210003.2752013-1-laurent.pinchart@ideasonboard.com>
The i.MX8MP suffers from an interrupt storm related to the stmmac and
EEE. A long and tedious analysis ([1]) concluded that the SoC wires the
stmmac lpi_intr_o signal to an OR gate along with the main dwmac
interrupts, which causes an interrupt storm for two reasons.
First, there's a race condition due to the interrupt deassertion being
synchronous to the RX clock domain:
- When the PHY exits LPI mode, it restarts generating the RX clock
(clk_rx_i input signal to the GMAC).
- The MAC detects exit from LPI, and asserts lpi_intr_o. This triggers
the ENET_EQOS interrupt.
- Before the CPU has time to process the interrupt, the PHY enters LPI
mode again, and stops generating the RX clock.
- The CPU processes the interrupt and reads the GMAC4_LPI_CTRL_STATUS
registers. This does not clear lpi_intr_o as there's no clk_rx_i.
An attempt was made to fixing the issue by not stopping RX_CLK in Rx LPI
state ([2]). This alleviates the symptoms but doesn't fix the issue.
Since lpi_intr_o takes four RX_CLK cycles to clear, an interrupt storm
can still occur during that window. In 1000T mode this is harder to
notice, but slower receive clocks cause hundreds to thousands of
spurious interrupts.
Fix the issue by disabling EEE completely on i.MX8MP.
[1] https://lore.kernel.org/all/20251026122905.29028-1-laurent.pinchart@ideasonboard.com/
[2] https://lore.kernel.org/all/20251123053518.8478-1-laurent.pinchart@ideasonboard.com/
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
Changes since v1:
- Fix | operator placement
---
drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
index 9d1bd72ffb73..01260dbbb698 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
@@ -325,11 +325,7 @@ static int imx_dwmac_probe(struct platform_device *pdev)
return ret;
}
- if (data->flags & STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY)
- plat_dat->flags |= STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY;
-
- if (data->flags & STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD)
- plat_dat->flags |= STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD;
+ plat_dat->flags |= data->flags;
/* Default TX Q0 to use TSO and rest TXQ for TBS */
for (int i = 1; i < plat_dat->tx_queues_to_use; i++)
@@ -366,7 +362,8 @@ static struct imx_dwmac_ops imx8mp_dwmac_data = {
.addr_width = 34,
.mac_rgmii_txclk_auto_adj = false,
.set_intf_mode = imx8mp_set_intf_mode,
- .flags = STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY |
+ .flags = STMMAC_FLAG_EEE_DISABLE |
+ STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY |
STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD,
};
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* Re: [PATCH v3 1/2] media: dt-bindings: rockchip,rk3568-mipi-csi2: add rk3588 compatible
From: Rob Herring @ 2026-03-25 21:06 UTC (permalink / raw)
To: Michael Riesch
Cc: Mauro Carvalho Chehab, Sakari Ailus, Laurent Pinchart, Frank Li,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Collabora Kernel Team, linux-media, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260305-rk3588-csi2rx-v3-1-754473981f39@collabora.com>
On Wed, Mar 25, 2026 at 11:25:34AM +0100, Michael Riesch wrote:
> The RK3588 MIPI CSI-2 receivers are compatible to the ones found in
> the RK3568.
> Introduce a list of compatible variants and add the RK3588 variant to
> it.
>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
> ---
> .../devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
> index 4ac4a3b6f406..3d3b3cd78884 100644
> --- a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
> +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
> @@ -16,9 +16,13 @@ description:
>
> properties:
> compatible:
> - enum:
> - - fsl,imx93-mipi-csi2
> - - rockchip,rk3568-mipi-csi2
> + oneOf:
> + - const: fsl,imx93-mipi-csi2
> + - const: rockchip,rk3568-mipi-csi2
These 2 should be a single enum as they were before.
> + - items:
> + - enum:
> + - rockchip,rk3588-mipi-csi2
> + - const: rockchip,rk3568-mipi-csi2
>
> reg:
> maxItems: 1
>
> --
> 2.39.5
>
^ permalink raw reply
* Re: [PATCH net-next v9 6/6] net: stmmac: qcom-ethqos: add support for sa8255p
From: Russell King (Oracle) @ 2026-03-25 21:09 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Vinod Koul, Giuseppe Cavallaro, Chen-Yu Tsai, Jernej Skrabec,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Shawn Guo,
Fabio Estevam, Jan Petrous, s32, Mohd Ayaan Anwar, Romain Gantois,
Geert Uytterhoeven, Magnus Damm, Maxime Ripard,
Christophe Roullier, Bartosz Golaszewski, Radu Rendec,
linux-arm-msm, devicetree, linux-kernel, netdev, linux-stm32,
linux-arm-kernel, Drew Fustini, linux-sunxi, linux-amlogic,
linux-mips, imx, linux-renesas-soc, linux-rockchip, sophgo,
linux-riscv, Bartosz Golaszewski
In-Reply-To: <20260316-qcom-sa8255p-emac-v9-6-c58934e76ff2@oss.qualcomm.com>
On Mon, Mar 16, 2026 at 01:05:11PM +0100, Bartosz Golaszewski wrote:
> Extend the driver to support a new model - sa8255p. Unlike the
> previously supported variants, this one's power management is done in
> the firmware using SCMI. This is modeled in linux using power domains so
> add support for them.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Shouldn't the SerDes driver be doing the power management rather than
the ethernet driver?
We already have the crappy situation with this driver that the stmmac
clocks are not running when they need to be, which is now causing
warnings with the VLAN code. The platform glue driver itself doesn't
_actually_ have enough information on its own to know when it needs
to ensure that the PCS and SerDes need to be operational which is what
is leading to this problem.
Also note that the core stmmac driver does runtime PM management which
covers both the stmmac MDIO block and the core MAC as well. How does
your implementation interact with those, when e.g. a MDIO bus on one
stmmac instance could be used to access a PHY on a different instance.
> +struct ethqos_emac_pd_ctx {
> + struct dev_pm_domain_list *pd_list;
> + int serdes_level;
I don't think serdes_level is appropriate nor correct (see below.)
> +static void ethqos_configure_sgmii_pd(struct qcom_ethqos *ethqos,
> + phy_interface_t interface, int speed)
> +{
> + switch (speed) {
> + case SPEED_2500:
> + case SPEED_1000:
> + case SPEED_100:
> + case SPEED_10:
> + ethqos->pd.serdes_level = speed;
This is called at mac_link_up(), after mac_finish() has done its
stuff...
> + }
> +
> + ethqos_configure_sgmii(ethqos, interface, speed);
> +}
> +
> static void ethqos_configure(struct qcom_ethqos *ethqos,
> phy_interface_t interface, int speed)
> {
> @@ -710,6 +785,45 @@ static int ethqos_mac_finish_serdes(struct net_device *ndev, void *priv,
> return ret;
> }
>
> +static int ethqos_mac_finish_serdes_pd(struct net_device *ndev, void *priv,
> + unsigned int mode,
> + phy_interface_t interface)
> +{
> + struct qcom_ethqos *ethqos = priv;
> + struct device *dev = ethqos->pd.pd_list->pd_devs[ETHQOS_PD_SERDES];
> + int ret = 0;
> +
> + qcom_ethqos_set_sgmii_loopback(ethqos, false);
> +
> + if (interface == PHY_INTERFACE_MODE_SGMII ||
> + interface == PHY_INTERFACE_MODE_2500BASEX)
> + ret = dev_pm_opp_set_level(dev, ethqos->pd.serdes_level);
... which means this won't get called with anything but a stale speed
from the _previous_ link up event.
> +
> + return ret;
> +}
> +
> +static int qcom_ethqos_pd_serdes_powerup(struct net_device *ndev, void *priv)
> +{
> + struct qcom_ethqos *ethqos = priv;
> + struct device *dev = ethqos->pd.pd_list->pd_devs[ETHQOS_PD_SERDES];
> + int ret;
> +
> + ret = qcom_ethqos_domain_on(ethqos, ETHQOS_PD_SERDES);
> + if (ret < 0)
> + return ret;
> +
> + return dev_pm_opp_set_level(dev, ethqos->pd.serdes_level);
and same here.
The fundamental question arises - why does the power domain need to know
the _media_ speed (which is completely unrelated to the speed at which
the SerDes link operates at) ?
For example, with SGMII, the link operates at 1.25GBaud irrespective of
whether it is operating at an underlying Ethernet data rate of 10M, 100M
or 1G speeds.
To me, the whole "serdes_level" stuff looks completely wrong.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* [PATCH v2] iommu: arm-smmu-qcom: Ensure smmu is powered up in set_ttbr0_cfg
From: Anna Maniscalco @ 2026-03-25 21:11 UTC (permalink / raw)
To: Rob Clark, Will Deacon, Robin Murphy, Joerg Roedel
Cc: iommu, linux-arm-msm, linux-arm-kernel, linux-kernel,
Anna Maniscalco
Previously the device was being accessed while potentially in a
suspended state.
Signed-off-by: Anna Maniscalco <anna.maniscalco2000@gmail.com>
---
Changes in v2:
- Simplify patch by acquiring device just around the call that needs it
- Link to v1: https://lore.kernel.org/r/20260210-qcom_smmu_pmfix-v1-1-78b7143ac053@gmail.com
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 573085349df3..cab7d110aaf5 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -231,6 +231,7 @@ static int qcom_adreno_smmu_set_ttbr0_cfg(const void *cookie,
struct io_pgtable *pgtable = io_pgtable_ops_to_pgtable(smmu_domain->pgtbl_ops);
struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
struct arm_smmu_cb *cb = &smmu_domain->smmu->cbs[cfg->cbndx];
+ int ret;
/* The domain must have split pagetables already enabled */
if (cb->tcr[0] & ARM_SMMU_TCR_EPD1)
@@ -260,8 +261,16 @@ static int qcom_adreno_smmu_set_ttbr0_cfg(const void *cookie,
cb->ttbr[0] |= FIELD_PREP(ARM_SMMU_TTBRn_ASID, cb->cfg->asid);
}
+ ret = pm_runtime_resume_and_get(smmu_domain->smmu->dev);
+ if (ret < 0) {
+ dev_err(smmu_domain->smmu->dev, "failed to get runtime PM: %d\n", ret);
+ return -ENODEV;
+ }
+
arm_smmu_write_context_bank(smmu_domain->smmu, cb->cfg->cbndx);
+ pm_runtime_put_autosuspend(smmu_domain->smmu->dev);
+
return 0;
}
---
base-commit: 50c4a49f7292b33b454ea1a16c4f77d6965405dc
change-id: 20260210-qcom_smmu_pmfix-2aead2ba4e20
Best regards,
--
Anna Maniscalco <anna.maniscalco2000@gmail.com>
^ permalink raw reply related
* Re: [PATCH net-next v10 2/6] net: stmmac: qcom-ethqos: use generic device properties
From: Russell King (Oracle) @ 2026-03-25 21:14 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Vinod Koul, Giuseppe Cavallaro, Chen-Yu Tsai, Jernej Skrabec,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Shawn Guo,
Fabio Estevam, Jan Petrous, s32, Mohd Ayaan Anwar, Romain Gantois,
Geert Uytterhoeven, Magnus Damm, Maxime Ripard,
Christophe Roullier, Bartosz Golaszewski, Radu Rendec,
linux-arm-msm, devicetree, linux-kernel, netdev, linux-stm32,
linux-arm-kernel, Drew Fustini, linux-sunxi, linux-amlogic,
linux-mips, imx, linux-renesas-soc, linux-rockchip, sophgo,
linux-riscv, Bartosz Golaszewski
In-Reply-To: <20260323-qcom-sa8255p-emac-v10-2-79302b238a16@oss.qualcomm.com>
The comments I just gave to v9 (which is incomplete as received) apply
to v10 as well, although I have no idea what the differences are
between v9 and v10 as I never received the cover message. I only
seem to receive patches 2, 4, 5 and 6.
On Mon, Mar 23, 2026 at 02:20:54PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> In order to drop the dependency on CONFIG_OF, convert all device property
> getters from OF-specific to generic device properties and stop pulling
> in any linux/of.h symbols.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/Kconfig | 2 +-
> drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 9 ++++-----
> 2 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> index d3a6ab7383fc1e1b2e4b12c670b12a8ad1606e6c..4148805a82b106471a25f9496b60be5bb9ce5c00 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> @@ -135,7 +135,7 @@ config DWMAC_MESON
> config DWMAC_QCOM_ETHQOS
> tristate "Qualcomm ETHQOS support"
> default ARCH_QCOM
> - depends on OF && (ARCH_QCOM || COMPILE_TEST)
> + depends on ARCH_QCOM || COMPILE_TEST
> help
> Support for the Qualcomm ETHQOS core.
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index 3ccf20fdf52a8ec4649b43ade8ee7b85d613e1c5..66fd2ed2c2c8428694c07d89220d0e1608546791 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -1,8 +1,8 @@
> // SPDX-License-Identifier: GPL-2.0
> // Copyright (c) 2018-19, Linaro Limited
>
> +#include <linux/mod_devicetable.h>
> #include <linux/module.h>
> -#include <linux/of.h>
> #include <linux/of_net.h>
> #include <linux/platform_device.h>
> #include <linux/phy.h>
> @@ -728,7 +728,6 @@ static void ethqos_ptp_clk_freq_config(struct stmmac_priv *priv)
>
> static int qcom_ethqos_probe(struct platform_device *pdev)
> {
> - struct device_node *np = pdev->dev.of_node;
> const struct ethqos_emac_driver_data *data;
> struct plat_stmmacenet_data *plat_dat;
> struct stmmac_resources stmmac_res;
> @@ -778,7 +777,7 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
> return dev_err_probe(dev, PTR_ERR(ethqos->rgmii_base),
> "Failed to map rgmii resource\n");
>
> - data = of_device_get_match_data(dev);
> + data = device_get_match_data(dev);
> ethqos->rgmii_por = data->rgmii_por;
> ethqos->num_rgmii_por = data->num_rgmii_por;
> ethqos->rgmii_config_loopback_en = data->rgmii_config_loopback_en;
> @@ -818,9 +817,9 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
> if (ethqos->has_emac_ge_3)
> plat_dat->dwmac4_addrs = &data->dwmac4_addrs;
> plat_dat->pmt = true;
> - if (of_property_read_bool(np, "snps,tso"))
> + if (device_property_present(dev, "snps,tso"))
> plat_dat->flags |= STMMAC_FLAG_TSO_EN;
> - if (of_device_is_compatible(np, "qcom,qcs404-ethqos"))
> + if (device_is_compatible(dev, "qcom,qcs404-ethqos"))
> plat_dat->flags |= STMMAC_FLAG_RX_CLK_RUNS_IN_LPI;
> if (data->dma_addr_width)
> plat_dat->host_dma_width = data->dma_addr_width;
>
> --
> 2.47.3
>
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v3 1/2] media: dt-bindings: rockchip,rk3568-mipi-csi2: add rk3588 compatible
From: Michael Riesch @ 2026-03-25 21:34 UTC (permalink / raw)
To: Rob Herring
Cc: Mauro Carvalho Chehab, Sakari Ailus, Laurent Pinchart, Frank Li,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Collabora Kernel Team, linux-media, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260325210634.GA3963190-robh@kernel.org>
Hi Rob,
On 3/25/26 22:06, Rob Herring wrote:
> On Wed, Mar 25, 2026 at 11:25:34AM +0100, Michael Riesch wrote:
>> The RK3588 MIPI CSI-2 receivers are compatible to the ones found in
>> the RK3568.
>> Introduce a list of compatible variants and add the RK3588 variant to
>> it.
>>
>> Acked-by: Rob Herring (Arm) <robh@kernel.org>
First of all, apologies for applying your Acked-by tag. I figured
resolving the merged conflict was trivial and impossible to screw up, but...
>> Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
>> ---
>> .../devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml | 10 +++++++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
>> index 4ac4a3b6f406..3d3b3cd78884 100644
>> --- a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
>> +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
>> @@ -16,9 +16,13 @@ description:
>>
>> properties:
>> compatible:
>> - enum:
>> - - fsl,imx93-mipi-csi2
>> - - rockchip,rk3568-mipi-csi2
>> + oneOf:
>> + - const: fsl,imx93-mipi-csi2
>> + - const: rockchip,rk3568-mipi-csi2
>
> These 2 should be a single enum as they were before.
... hm. Well.
First, do you mean
properties:
compatible:
oneOf:
- enum:
- fsl,imx93-mipi-csi2
- rockchip,rk3568-mipi-csi2
- items:
- enum:
- rockchip,rk3588-mipi-csi2
- const: rockchip,rk3568-mipi-csi2
?
If so, what is the practical difference?
Thanks and best regards,
Michael
>
>> + - items:
>> + - enum:
>> + - rockchip,rk3588-mipi-csi2
>> + - const: rockchip,rk3568-mipi-csi2
>>
>> reg:
>> maxItems: 1
>>
>> --
>> 2.39.5
>>
^ permalink raw reply
* Re: [PATCH] soc: brcmstb: consolidate initcall functions
From: Florian Fainelli @ 2026-03-25 21:54 UTC (permalink / raw)
To: justin.chen, linux-arm-kernel; +Cc: kees, bcm-kernel-feedback-list
In-Reply-To: <20260325174619.3761964-1-justin.chen@broadcom.com>
On 3/25/26 10:46, justin.chen@broadcom.com wrote:
> From: Justin Chen <justin.chen@broadcom.com>
>
> Merge the separate early_initcall and arch_initcall functions into a
> single early_initcall. This is possible thanks to commit 6e12db376b60
> ("base: soc: Allow early registration of a single SoC device"), which
> allows soc_device_register() to be called during early_initcall by
> deferring the actual registration until the soc_bus is ready.
>
> Replace static family_id/product_id variables with a dynamically
> allocated brcmstb_soc_info structure.
>
> Signed-off-by: Justin Chen <justin.chen@broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Will wait a couple of days before applying it to the Broadcom SoC tree.
Thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: hwmon: emc2305: Add fan-shutdown-percent property
From: Rob Herring @ 2026-03-25 21:56 UTC (permalink / raw)
To: florin.leotescu
Cc: Guenter Roeck, Krzysztof Kozlowski, Conor Dooley, Michael Shych,
linux-hwmon, devicetree, linux-kernel, daniel.baluta,
viorel.suman, linux-arm-kernel, imx, festevam, Florin Leotescu
In-Reply-To: <20260320152959.1575978-2-florin.leotescu@oss.nxp.com>
On Fri, Mar 20, 2026 at 05:29:58PM +0200, florin.leotescu@oss.nxp.com wrote:
> From: Florin Leotescu <florin.leotescu@nxp.com>
>
> The EMC2305 fan controller supports multiple independent PWM fan
> outputs. Some systems require fans to enter a defined safe state
> during system shutdown or reboot handoff, until firmware or the next
> boot stage reconfigures the controller.
>
> Add an optional "fan-shutdown-percent" property to fan child nodes
> allowing the shutdown fan speed to be configured per fan output.
Why not a common fan property in fan-common.yaml?
We generally specify fan speeds in RPM (and then map RPMs to duty cycle
for PWM).
Also, we have (or can have) cooling levels defined. Perhaps we should
define the cooling level for shutdown? Maybe other things with cooling
levels need a shutdown level too?
Rob
^ permalink raw reply
* Re: [PATCH net-next v9 2/6] net: stmmac: qcom-ethqos: use generic device properties
From: Andrew Lunn @ 2026-03-25 21:59 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Vinod Koul, Giuseppe Cavallaro, Chen-Yu Tsai, Jernej Skrabec,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Shawn Guo,
Fabio Estevam, Jan Petrous, s32, Mohd Ayaan Anwar, Romain Gantois,
Geert Uytterhoeven, Magnus Damm, Maxime Ripard,
Christophe Roullier, Bartosz Golaszewski, Radu Rendec,
linux-arm-msm, devicetree, linux-kernel, netdev, linux-stm32,
linux-arm-kernel, Drew Fustini, linux-sunxi, linux-amlogic,
linux-mips, imx, linux-renesas-soc, linux-rockchip, sophgo,
linux-riscv, Bartosz Golaszewski
In-Reply-To: <20260316-qcom-sa8255p-emac-v9-2-c58934e76ff2@oss.qualcomm.com>
On Mon, Mar 16, 2026 at 01:05:07PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> In order to drop the dependency on CONFIG_OF, convert all device property
> getters from OF-specific to generic device properties and stop pulling
> in any linux/of.h symbols.
Adding to what Russell said, please document your new binding. e.g. in
Documentation/firmware-guide/acpi/dsd.
Andrew
^ permalink raw reply
* Re: [PATCH v4 2/9] dt-bindings: mmc: amlogic: Add compatible for T7 mmc
From: Rob Herring (Arm) @ 2026-03-25 22:08 UTC (permalink / raw)
To: Ronald Claveau
Cc: devicetree, Kevin Hilman, linux-amlogic, linux-kernel, linux-mmc,
Neil Armstrong, linux-arm-kernel, Jerome Brunet, Ulf Hansson,
Krzysztof Kozlowski, Martin Blumenstingl, Conor Dooley,
Johannes Berg, van Spriel, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-2-44c7b4a5e459@aliel.fr>
On Wed, 25 Mar 2026 10:15:20 +0100, Ronald Claveau wrote:
> Add amlogic,t7-mmc compatible string, falling back to amlogic,meson-axg-mmc
> as the T7 MMC controller is compatible with the AXG implementation.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 03/13] wifi: mt76: mt7925: handle 320MHz bandwidth in RXV and TXS
From: Javier Tia @ 2026-03-25 22:10 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Marcin FM, Cristian-Florin Radoi, George Salukvadze,
Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260325-mt7927-wifi-support-v2-v3-0-5ca66c97a755@jetm.me>
The RX vector (RXV) and TX status (TXS) parsing in mac.c lack handling
for 320MHz channel width. When the hardware reports 320MHz in the
bandwidth field, mt7925_mac_fill_rx_rate() returns -EINVAL and
mt7925_mac_add_txs_skb() records no bandwidth stats.
Add IEEE80211_STA_RX_BW_320 cases to both functions. The RXV parser
also handles BW_320+1 since the hardware can report 320MHz in two
adjacent encoding positions.
Tested-by: Marcin FM <marcin@lgic.pl>
Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
Tested-by: George Salukvadze <giosal90@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Thibaut François <tibo@humeurlibre.fr>
Tested-by: 张旭涵 <Loong.0x00@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
index caaf71c31480..ad03fc554b69 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
@@ -339,6 +339,11 @@ mt7925_mac_fill_rx_rate(struct mt792x_dev *dev,
case IEEE80211_STA_RX_BW_160:
status->bw = RATE_INFO_BW_160;
break;
+ /* RXV can report 320 in two positions */
+ case IEEE80211_STA_RX_BW_320:
+ case IEEE80211_STA_RX_BW_320 + 1:
+ status->bw = RATE_INFO_BW_320;
+ break;
default:
return -EINVAL;
}
@@ -992,6 +997,10 @@ mt7925_mac_add_txs_skb(struct mt792x_dev *dev, struct mt76_wcid *wcid,
stats->tx_mode[mode]++;
switch (FIELD_GET(MT_TXS0_BW, txs)) {
+ case IEEE80211_STA_RX_BW_320:
+ rate.bw = RATE_INFO_BW_320;
+ stats->tx_bw[4]++;
+ break;
case IEEE80211_STA_RX_BW_160:
rate.bw = RATE_INFO_BW_160;
stats->tx_bw[3]++;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 01/13] wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links
From: Javier Tia @ 2026-03-25 22:10 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Marcin FM, Cristian-Florin Radoi, George Salukvadze,
Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260325-mt7927-wifi-support-v2-v3-0-5ca66c97a755@jetm.me>
In the error path of mt7925_change_vif_links(), the free: label iterates
over link_ids to clean up, but compares against `mconf` and `mlink`
which hold stale values from the last loop iteration rather than the
current link_id being freed.
Use array-indexed access (mconfs[link_id] / mlinks[link_id]) to compare
against the correct per-link pointers.
Fixes: 69acd6d910b0 ("wifi: mt76: mt7925: add mt7925_change_vif_links")
Tested-by: Marcin FM <marcin@lgic.pl>
Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
Tested-by: George Salukvadze <giosal90@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Thibaut François <tibo@humeurlibre.fr>
Tested-by: 张旭涵 <Loong.0x00@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt7925/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
index 2d358a96640c..f128a198f81d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
@@ -2047,9 +2047,9 @@ mt7925_change_vif_links(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
rcu_assign_pointer(mvif->link_conf[link_id], NULL);
rcu_assign_pointer(mvif->sta.link[link_id], NULL);
- if (mconf != &mvif->bss_conf)
+ if (mconfs[link_id] != &mvif->bss_conf)
devm_kfree(dev->mt76.dev, mconfs[link_id]);
- if (mlink != &mvif->sta.deflink)
+ if (mlinks[link_id] != &mvif->sta.deflink)
devm_kfree(dev->mt76.dev, mlinks[link_id]);
}
--
2.53.0
^ permalink raw reply related
* [PATCH v3 02/13] wifi: mt76: mt7925: add 320MHz bandwidth to bss_rlm_tlv
From: Javier Tia @ 2026-03-25 22:10 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
张旭涵, Marcin FM, Cristian-Florin Radoi,
George Salukvadze, Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld,
Chapuis Dario, Thibaut François
In-Reply-To: <20260325-mt7927-wifi-support-v2-v3-0-5ca66c97a755@jetm.me>
bss_rlm_tlv() in mt7925_mcu_bss_rlm_tlv() has no case for
NL80211_CHAN_WIDTH_320. When associated to a 320MHz BSS, the switch
falls through to default and sends bw=0 (CMD_CBW_20MHZ) to firmware
via BSS_RLM TLV. Firmware then configures the RX radio for 20MHz
and cannot decode the AP's 320MHz frames, resulting in complete data
path failure at 320MHz.
Add the missing NL80211_CHAN_WIDTH_320 case with CMD_CBW_320MHZ and
center_chan2.
Tested on ASUS RT-BE92U: 320MHz throughput goes from 0 Mbps to
841 Mbps (iperf3 -t30 -P8), PHY 4803 Mbps EHT-MCS11.
Reported-by: 张旭涵 <Loong.0x00@gmail.com>
Closes: https://github.com/openwrt/mt76/issues/927
Tested-by: 张旭涵 <Loong.0x00@gmail.com>
Tested-by: Marcin FM <marcin@lgic.pl>
Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
Tested-by: George Salukvadze <giosal90@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Thibaut François <tibo@humeurlibre.fr>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
index cf0fdea45cf7..dd5ecb07947b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
@@ -2331,6 +2331,10 @@ void mt7925_mcu_bss_rlm_tlv(struct sk_buff *skb, struct mt76_phy *phy,
case NL80211_CHAN_WIDTH_160:
req->bw = CMD_CBW_160MHZ;
break;
+ case NL80211_CHAN_WIDTH_320:
+ req->bw = CMD_CBW_320MHZ;
+ req->center_chan2 = ieee80211_frequency_to_channel(freq2);
+ break;
case NL80211_CHAN_WIDTH_5:
req->bw = CMD_CBW_5MHZ;
break;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 00/13] This series adds support for the MediaTek MT7927 (Filogic 380) combo
From: Javier Tia @ 2026-03-25 22:10 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Marcin FM, Cristian-Florin Radoi, George Salukvadze,
Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
WiFi 7 + BT 5.4 module to the mt7925 driver. The MT7927 uses PCI ID
14c3:7927 (some hardware reports 14c3:6639) and shares the mt7925
firmware interface but requires different DMA ring layout, IRQ mapping,
chip initialization, and power management handling.
Tested hardware:
- ASUS ROG Crosshair X870E Hero (BT 0489:e13a, WiFi 14c3:6639)
- ASUS ProArt X870E-Creator WiFi (BT 0489:e13a / 13d3:3588, WiFi 14c3:6639)
- ASUS ROG Strix X870-I (WiFi 14c3:7927)
- ASUS ROG Strix X870-F Gaming WiFi (BT 0489:e13a, WiFi 14c3:7927)
- ASUS ROG Strix X870E-E (BT 13d3:3588, WiFi 14c3:7927)
- Gigabyte X870E Aorus Master X3D (BT 0489:e10f, WiFi 14c3:7927)
- Gigabyte Z790 AORUS MASTER X (BT 0489:e10f, WiFi 14c3:7927)
- Gigabyte Z790 AORUS ELITE X WiFi7 (BT 0489:e10f, WiFi 14c3:7927)
- MSI MEG X870E ACE MAX (BT 0489:e110, WiFi 14c3:7927)
- Lenovo Legion Pro 7 16ARX9 (BT 0489:e0fa, WiFi 14c3:7927)
- Lenovo Legion Pro 7 16AFR10H (BT 0489:e0fa, WiFi 14c3:7927)
- TP-Link Archer TBE550E PCIe (BT 0489:e116, WiFi 14c3:7927)
- EDUP EP-MT7927BE M.2 card (WiFi 14c3:7927)
- Foxconn/Azurewave M.2 modules (WiFi 14c3:6639)
- AMD RZ738 reference design (WiFi 14c3:0738)
Tested on Arch Linux, CachyOS, EndeavourOS, Fedora (Bazzite), NixOS,
openSUSE Tumbleweed, and Ubuntu across kernels 6.13-6.19.
What works:
- WiFi 7 with EHT 320MHz on 2.4/5/6 GHz bands
- 320MHz data path verified at 841 Mbps (iperf3 -t30 -P8)
- PCIe initialization with CBTOP remap and MT7927-specific DMA layout
- System suspend/resume (S3)
- DBDC (dual-band concurrent) mode
- Explicit band_idx assignment for stable 5GHz/6GHz operation
- ASPM and runtime PM disabled for MT7927 (see below)
Known limitations (planned as follow-up series):
- Runtime PM: disabled for MT7927 because the combo chip shares a
CONNINFRA power domain between WiFi (PCIe) and BT (USB).
SET_OWN/CLR_OWN transitions on the LPCTL register crash the BT
firmware, requiring a full power cycle to recover. PM enablement
will be addressed once safe power state transitions are determined.
- mac_reset returns -EOPNOTSUPP (DMA recovery not yet implemented)
- MLO (Multi-Link Operation): tested working on 5GHz+2.4GHz STR
(776 Mbps) but requires additional patches for link lifetime
and error handling. Sean Wang's series [1] addresses these;
MLO support will be submitted as a follow-up on top of that.
- TX retransmissions: elevated retry rate on all bands, firmware-side
rate adaptation issue not addressable in the driver.
[1] https://lore.kernel.org/linux-wireless/20260306232238.2039675-1-sean.wang@kernel.org/
Patches 1-5 add generic 320MHz EHT support (no MT7927 references).
Patches 6-7 introduce MT7927 chip ID helpers and firmware paths.
Patch 8 adds per-chip IRQ map handling.
Patch 9 introduces mt792x_dma_config struct for chip-specific DMA.
Patch 10 combines CBTOP remap, chip init, DBDC, CNM, and mac_reset.
Patch 11 adds mt7925_band_idx() helper for stable 5/6 GHz operation.
Patch 12 disables ASPM and runtime PM for MT7927.
Patch 13 enables the MT7927 PCI device table entries.
The WiFi firmware path and filename in linux-firmware have not been
finalized yet. The driver currently requests mediatek/mt6639/ (the
mobile SoC codename), but this may change based on the linux-firmware
review.
Changes since v2 (suggested by Sean Wang):
- Fixed is_320mhz_supported() to check for MT7927 only, not the
entire mt7925 family. MT7925 does not support 320MHz (patch 5).
- Dropped phy_cap_info[7] 320MHz additions (NON_OFDMA_UL_MU_MIMO
and MU_BEAMFORMER) to keep capabilities conservative (patch 5).
- Disabled runtime PM for MT7927 (patch 12). The combo chip shares a
CONNINFRA power domain between WiFi and BT; SET_OWN/CLR_OWN
transitions crash BT firmware. Discovered via user reports of BT
lockups after enabling power_save=1 (Reported-by: Nitin Gurram).
- Added tested hardware: MSI MEG X870E ACE MAX, Gigabyte Z790 AORUS
ELITE X WiFi7, Lenovo Legion Pro 7 16AFR10H.
Changes since v1 (suggested by Sean Wang):
- Reorganized from 18 patches into 13 across 8 logical groups
- Common 320MHz patches first, chip-specific changes later
- Introduced mt792x_dma_config struct to reuse mt7925_dma_init()
instead of duplicating as mt7927_dma_init()
- Replaced is_mt7927() with is_320mhz_supported() in common patches
- Added mt7925_band_idx() helper replacing scattered if/else patterns
- Renamed MT7927-specific registers with MT7927_ prefix
- Added PCI ID 0x0738 for AMD RZ738 hardware
- Moved GLO_CFG_EXT1 register address into dma_config struct to
eliminate is_mt7927() from shared mt792x_dma.c
Link to v2: https://lore.kernel.org/linux-wireless/20260319-mt7927-wifi-support-v2-v2-0-d627a7fad70d@jetm.me/
Link to v1: https://lore.kernel.org/linux-wireless/20260306-mt7927-wifi-support-v1-0-c77e7445511d@jetm.me/
Assisted-by: Claude (Anthropic)
Signed-off-by: Javier Tia <floss@jetm.me>
---
Javier Tia (13):
wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links
wifi: mt76: mt7925: add 320MHz bandwidth to bss_rlm_tlv
wifi: mt76: mt7925: handle 320MHz bandwidth in RXV and TXS
wifi: mt76: mt7925: populate EHT 320MHz MCS map in sta_rec
wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band
wifi: mt76: mt7925: add MT7927 chip ID helpers
wifi: mt76: mt7925: add MT7927 firmware paths
wifi: mt76: mt7925: use irq_map for chip-specific interrupt handling
wifi: mt76: mt7925: add chip-specific DMA configuration
wifi: mt76: mt7925: add MT7927 hardware initialization
wifi: mt76: mt7925: fix band_idx for stable 5GHz/6GHz operation
wifi: mt76: mt7925: disable ASPM and runtime PM for MT7927
wifi: mt76: mt7925: enable MT7927 PCI device IDs
drivers/net/wireless/mediatek/mt76/mt76_connac.h | 13 +-
drivers/net/wireless/mediatek/mt76/mt7925/init.c | 19 +-
drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 9 +
drivers/net/wireless/mediatek/mt76/mt7925/main.c | 61 ++++-
drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 55 +++-
drivers/net/wireless/mediatek/mt76/mt7925/mt7925.h | 7 +
drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 277 +++++++++++++++++++--
.../net/wireless/mediatek/mt76/mt7925/pci_mac.c | 14 +-
.../net/wireless/mediatek/mt76/mt7925/pci_mcu.c | 20 +-
drivers/net/wireless/mediatek/mt76/mt792x.h | 27 ++
drivers/net/wireless/mediatek/mt76/mt792x_dma.c | 68 ++---
drivers/net/wireless/mediatek/mt76/mt792x_regs.h | 33 +++
12 files changed, 528 insertions(+), 75 deletions(-)
---
base-commit: 9ac76f3d0bb2940db3a9684d596b9c8f301ef315
change-id: 20260319-mt7927-wifi-support-v2-e89d779b28f4
Best regards,
--
Javier Tia <floss@jetm.me>
^ permalink raw reply
* [PATCH v3 04/13] wifi: mt76: mt7925: populate EHT 320MHz MCS map in sta_rec
From: Javier Tia @ 2026-03-25 22:10 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Marcin FM, Cristian-Florin Radoi, George Salukvadze,
Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260325-mt7927-wifi-support-v2-v3-0-5ca66c97a755@jetm.me>
The sta_rec_eht structure has a mcs_map_bw320 field, and the channel
width mapping includes NL80211_CHAN_WIDTH_320, but the 320MHz MCS/NSS
map was never copied from the station's EHT capabilities to the MCU TLV.
This prevents negotiation of 320MHz channel width even when both the
hardware and firmware advertise support for it.
Add the missing memcpy for the 320MHz MCS map, matching the existing
pattern for BW20, BW80, and BW160.
Tested-by: Marcin FM <marcin@lgic.pl>
Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
Tested-by: George Salukvadze <giosal90@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Thibaut François <tibo@humeurlibre.fr>
Tested-by: 张旭涵 <Loong.0x00@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
index dd5ecb07947b..a7f27c5014d5 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
@@ -1683,6 +1683,7 @@ mt7925_mcu_sta_eht_tlv(struct sk_buff *skb, struct ieee80211_link_sta *link_sta)
memcpy(eht->mcs_map_bw20, &mcs_map->only_20mhz, sizeof(eht->mcs_map_bw20));
memcpy(eht->mcs_map_bw80, &mcs_map->bw._80, sizeof(eht->mcs_map_bw80));
memcpy(eht->mcs_map_bw160, &mcs_map->bw._160, sizeof(eht->mcs_map_bw160));
+ memcpy(eht->mcs_map_bw320, &mcs_map->bw._320, sizeof(eht->mcs_map_bw320));
}
static void
--
2.53.0
^ permalink raw reply related
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