* Re: [PATCH] ACPI: arm64: cpuidle: Tolerate platforms with no deep PSCI idle states
From: Sudeep Holla @ 2026-04-20 15:12 UTC (permalink / raw)
To: Breno Leitao
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Len Brown, Huisong Li,
Rafael J. Wysocki, linux-acpi, linux-arm-kernel, linux-kernel,
pjaroszynski, rmikey, kernel-team, stable
In-Reply-To: <20260420-ffh-v1-1-6b4c10fec442@debian.org>
On Mon, Apr 20, 2026 at 02:27:13AM -0700, Breno Leitao wrote:
> Commit cac173bea57d ("ACPI: processor: idle: Rework the handling of
> acpi_processor_ffh_lpi_probe()") moved the acpi_processor_ffh_lpi_probe()
> call from acpi_processor_setup_cpuidle_dev(), where its return value was
> ignored, to acpi_processor_get_power_info(), where it is now treated as
> a hard failure. As a result, platforms where psci_acpi_cpu_init_idle()
> returned -ENODEV stopped registering any cpuidle states, forcing CPUs to
> busy-poll when idle.
>
> On NVIDIA Grace (aarch64) systems with PSCIv1.1, pr->power.count is 1
> (only WFI, no deep PSCI states beyond it), so the previous
> "count = pr->power.count - 1; if (count <= 0) return -ENODEV;" check
> returned -ENODEV for all 72 CPUs and disabled cpuidle entirely.
>
> The lpi_states count is already validated in acpi_processor_get_lpi_info(),
> so the check here is redundant. Simplify the loop to iterate over
> lpi_states[1..power.count). When only WFI is present, the loop body
> simply does not execute and the function returns 0, which is the correct
> outcome: there is nothing to validate for FFH and no error to report.
>
> Suggested-by: Huisong Li <lihuisong@huawei.com>
> Cc: stable@vger.kernel.org
> Fixes: cac173bea57d ("ACPI: processor: idle: Rework the handling of acpi_processor_ffh_lpi_probe()")
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> drivers/acpi/arm64/cpuidle.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/acpi/arm64/cpuidle.c b/drivers/acpi/arm64/cpuidle.c
> index 801f9c4501425..c68a5db8ebba8 100644
> --- a/drivers/acpi/arm64/cpuidle.c
> +++ b/drivers/acpi/arm64/cpuidle.c
> @@ -16,7 +16,7 @@
>
> static int psci_acpi_cpu_init_idle(unsigned int cpu)
> {
> - int i, count;
> + int i;
> struct acpi_lpi_state *lpi;
> struct acpi_processor *pr = per_cpu(processors, cpu);
>
> @@ -30,14 +30,10 @@ static int psci_acpi_cpu_init_idle(unsigned int cpu)
> if (!psci_ops.cpu_suspend)
> return -EOPNOTSUPP;
>
> - count = pr->power.count - 1;
> - if (count <= 0)
> - return -ENODEV;
> -
Does it make sense to retain this check like
if (pr->power.count < 1)
return -EINVAL;
Though I see the assignment to pr->power.count in drivers/acpi/processor_idle.c
is through unsigned int. So I am fine even without the above check.
Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 00/40] arm64: dts: rockchip: Wire up frl-enable-gpios for RK3576/RK3588 boards
From: Heiko Stuebner @ 2026-04-20 15:08 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cristian Ciocaltea
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <66f9574c-8dff-4de2-bf54-20f1c1e64c24@collabora.com>
Hi Cristian,
Am Montag, 20. April 2026, 13:10:27 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> On 4/18/26 2:18 AM, Heiko Stuebner wrote:
> > Am Freitag, 17. April 2026, 19:55:17 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> >> On 4/17/26 2:34 PM, Heiko Stuebner wrote:
> >>> Am Freitag, 17. April 2026, 11:24:34 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> >>>
> >>> [...]
> >>>
> >>>> Cristian Ciocaltea (40):
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-100ask-dshanpi-a1
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-armsom-sige5
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb1-v10
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb2-v10
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-m5
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-r76s
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-roc-pc
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-rock-4d
> >>>
> >>> I do think one patch per SoC (rk3576, rk3588, rk3588s) would make more
> >>> sense, because these patches really are mostly identical :-)
> >>
> >> Yeah, apologies for the large number of patches, I went this way to allow
> >> per-board reviews. As previously noted, I tried to identify the GPIO pins from
> >> multiple sources, so I'm not entirely sure about the accuracy in every case.
> >>
> >> Would it be preferable to squash the patches per SoC and board vendor, instead?
> >
> > I really would just do it per soc .. so 3 patches. That is a size that is
> > still reviewable for people, who can then check for their board.
> >
> > If the patch is labeled "Add frl-enable-gpios for all RK3588s boards", I
> > do expect people to notice it the same as "oh _my_ board gets changed".
> > ("all" could also be "most" :-) ).
>
> Ack.
>
> I would still keep the more invasive changes — such as those touching
> the regulator hacks — in separate patches, though.
sure, that sounds perfectly reasonable :-) .
Heiko
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Yeoreum Yun @ 2026-04-20 15:04 UTC (permalink / raw)
To: Sebastian Ene
Cc: Marc Zyngier, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm, paul, jmorris, serge,
zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe,
jarkko, jgg, sudeep.holla, oupton, joey.gouly, suzuki.poulose,
yuzenghui, catalin.marinas, will
In-Reply-To: <aeY2M3v97c00JjFe@google.com>
On Mon, Apr 20, 2026 at 02:20:35PM +0000, Sebastian Ene wrote:
> On Mon, Apr 20, 2026 at 01:46:47PM +0100, Marc Zyngier wrote:
> > On Mon, 20 Apr 2026 13:32:32 +0100,
> > Sebastian Ene <sebastianene@google.com> wrote:
> > >
> > > On Fri, Apr 17, 2026 at 06:57:59PM +0100, Yeoreum Yun wrote:
> > >
> > > Hello Yeoreum,
> > >
> > >
> > > > When pKVM is enabled, the FF-A driver must be initialized after pKVM.
> > > > Otherwise, pKVM cannot negotiate the FF-A version or
> > > > obtain RX/TX buffer information, leading to failures in FF-A calls.
> > >
> > > At the moment this already happens after you move back ffa_init() to
> > > device_initcall().
> >
> > But relying on this sort of ordering is just making things more
> > fragile.
> >
>
> Thanks for letting me know. Since this is not a solid construct we will have
> to change the driver init code to come after pKVM in this case.
>
> > >
> > > >
> > > > During FF-A driver initialization, check whether pKVM has been initialized.
> > > > If not, defer probing of the FF-A driver.
> > > >
> > >
> > > I don't think you need to add this dependency. pKVM is
> > > installed through KVM's module_init() which ends up calling hyp_ffa_init() to
> > > do the proxy initialization. The ARM-FFA driver comes after it (since
> > > pKVM is arch specific code). We don't have to call finalize_pkvm(..) to
> > > be able to handle smc(FF-A) calls in the hyp-proxy.
> >
> > You do. Without the finalisation, SMCs are not trapped by EL2.
> >
> > And even if it did, relying on such hack is just wrong.
> >
>
> That makes it an even stronger argument to move the driver init at a
> later stage. I was relying on this to trap early ff-a when the
> ARM FF-A driver was used.
I don’t think moving the FF-A driver initialization to a later stage is
a viable solution. For example, even if it is moved to device_initcall_sync,
it still relies on fragile ordering.
Similarly, moving it to late_initcall is problematic.
Since deferred_probe_initcall() runs at the same level, if it is invoked first,
devices that depend on FF-A (e.g. tpm_ffa_crb) may not be probed correctly,
leading to deferred devices not being handled properly.
Therefore, the FF-A driver should be able to detect when pKVM has been
initialized and perform its initialization accordingly otherwise,
just relying on the trap after kvm_arm_initialised.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos850: Add syscon-poweroff node
From: Alexey Klimov @ 2026-04-20 15:04 UTC (permalink / raw)
To: Sam Protsenko, Krzysztof Kozlowski
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, linux-kernel,
Rob Herring, Conor Dooley, Alim Akhtar
In-Reply-To: <20260325-exynos850-poweroff-v1-1-34c19c06e74d@linaro.org>
On Wed Mar 25, 2026 at 12:26 AM GMT, Alexey Klimov wrote:
> Without poweroff node Exynos850-based board continue to draw current
> (around ~60 mA with my test setup) after poweroff. Kernel also reports
> different lockup problems and RCU stalls warnings continuosly after
> last kernel messages about hardware being switched off.
> Turns out we missed a write to PMU's PS_HOLD_CONTROL (PMU + 0x30c)
> register that actually switches the SoC off.
>
> Add poweroff node that implements this.
>
> With this change the current draw after power off is in range of few
> milliampers and lockup messages are no more.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/exynos850.dtsi | 7 +++++++
Any feedback on this?
BR,
Alexey
^ permalink raw reply
* Re: [PATCH v5 4/4] Input: charlieplex_keypad: add GPIO charlieplex keypad
From: Hugo Villeneuve @ 2026-04-20 15:01 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: robin, andy, geert, robh, krzk+dt, conor+dt, hvilleneuve,
mkorpershoek, matthias.bgg, angelogioacchino.delregno, lee,
alexander.sverdlin, marek.vasut, akurz, devicetree, linux-kernel,
linux-input, linux-arm-kernel, linux-mediatek
In-Reply-To: <aeWtDA7snjJmiF9K@google.com>
Hi Dmitry,
On Sun, 19 Apr 2026 21:47:40 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> Hi Hugo,
>
> On Thu, Mar 12, 2026 at 02:00:58PM -0400, Hugo Villeneuve wrote:
> > +
> > +static void charlieplex_keypad_report_key(struct input_dev *input)
> > +{
> > + struct charlieplex_keypad *keypad = input_get_drvdata(input);
> > + const unsigned short *keycodes = input->keycode;
> > +
> > + if (keypad->current_code > 0) {
> > + input_event(input, EV_MSC, MSC_SCAN, keypad->current_code);
> > + input_report_key(input, keycodes[keypad->current_code], 0);
>
> This needs input_sync() as otherwise userspace is free to only recognize
> the last MSC_SCAN event.
Ok, now I get it, my code would have been be working only if it was an
if/else.
>
> > + }
> > +
> > + if (keypad->debounce_code) {
> > + input_event(input, EV_MSC, MSC_SCAN, keypad->debounce_code);
> > + input_report_key(input, keycodes[keypad->debounce_code], 1);
> > + }
> > +
> > + input_sync(input);
> > + keypad->current_code = keypad->debounce_code;
> > +}
> > +
> > +static void charlieplex_keypad_check_switch_change(struct input_dev *input,
> > + int code)
> > +{
> > + struct charlieplex_keypad *keypad = input_get_drvdata(input);
> > +
> > + if (code != keypad->debounce_code) {
> > + keypad->debounce_count = 0;
> > + keypad->debounce_code = code;
> > + } else if (keypad->debounce_count < keypad->debounce_threshold) {
>
> This does not work if debouncing is disabled (debounce threshold is 0).
Yes.
>
> > + keypad->debounce_count++;
> > +
> > + if (keypad->debounce_count >= keypad->debounce_threshold &&
> > + keypad->debounce_code != keypad->current_code)
> > + charlieplex_keypad_report_key(input);
> > + }
> > +}
> > +
> > +static void charlieplex_keypad_poll(struct input_dev *input)
> > +{
> > + struct charlieplex_keypad *keypad = input_get_drvdata(input);
> > + int code;
> > +
> > + code = 0;
> > + for (unsigned int oline = 0; oline < keypad->nlines; oline++) {
> > + DECLARE_BITMAP(values, MATRIX_MAX_ROWS);
> > + int err;
> > +
> > + /* Activate only one line as output at a time. */
> > + gpiod_direction_output(keypad->line_gpios->desc[oline], 1);
> > +
> > + if (keypad->settling_time_us)
> > + fsleep(keypad->settling_time_us);
> > +
> > + /* Read input on all other lines. */
> > + err = gpiod_get_array_value_cansleep(keypad->line_gpios->ndescs,
> > + keypad->line_gpios->desc,
> > + keypad->line_gpios->info, values);
> > + if (err)
> > + return;
>
> We need to deactivate the line on error too.
Yer, good catch.
>
> > +
> > + for (unsigned int iline = 0; iline < keypad->nlines; iline++) {
> > + if (iline == oline)
> > + continue; /* Do not read active output line. */
> > +
> > + /* Check if GPIO is asserted. */
> > + if (test_bit(iline, values)) {
> > + code = MATRIX_SCAN_CODE(oline, iline,
> > + get_count_order(keypad->nlines));
> > + /*
> > + * Exit loop immediately since we cannot detect
> > + * more than one key press at a time.
> > + */
> > + break;
> > + }
> > + }
> > +
> > + gpiod_direction_input(keypad->line_gpios->desc[oline]);
> > +
> > + if (code)
> > + break;
> > + }
> > +
> > + charlieplex_keypad_check_switch_change(input, code);
> > +}
> > +
> > +static int charlieplex_keypad_init_gpio(struct platform_device *pdev,
> > + struct charlieplex_keypad *keypad)
> > +{
> > + char **pin_names;
> > + char label[32];
> > +
> > + snprintf(label, sizeof(label), "%s-pin", pdev->name);
> > +
> > + keypad->line_gpios = devm_gpiod_get_array(&pdev->dev, "line", GPIOD_IN);
> > + if (IS_ERR(keypad->line_gpios))
> > + return PTR_ERR(keypad->line_gpios);
> > +
> > + keypad->nlines = keypad->line_gpios->ndescs;
> > +
> > + if (keypad->nlines > MATRIX_MAX_ROWS)
> > + return -EINVAL;
> > +
> > + pin_names = devm_kasprintf_strarray(&pdev->dev, label, keypad->nlines);
> > + if (IS_ERR(pin_names))
> > + return PTR_ERR(pin_names);
> > +
> > + for (unsigned int i = 0; i < keypad->line_gpios->ndescs; i++)
> > + gpiod_set_consumer_name(keypad->line_gpios->desc[i], pin_names[i]);
> > +
> > + return 0;
> > +}
> > +
> > +static int charlieplex_keypad_probe(struct platform_device *pdev)
> > +{
> > + struct charlieplex_keypad *keypad;
> > + unsigned int debounce_interval_ms;
> > + unsigned int poll_interval_ms;
> > + struct input_dev *input_dev;
> > + int err;
> > +
> > + keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad), GFP_KERNEL);
> > + if (!keypad)
> > + return -ENOMEM;
> > +
> > + input_dev = devm_input_allocate_device(&pdev->dev);
> > + if (!input_dev)
> > + return -ENOMEM;
> > +
> > + keypad->input_dev = input_dev;
> > +
> > + device_property_read_u32(&pdev->dev, "poll-interval", &poll_interval_ms);
> > + device_property_read_u32(&pdev->dev, "debounce-delay-ms", &debounce_interval_ms);
> > + device_property_read_u32(&pdev->dev, "settling-time-us", &keypad->settling_time_us);
>
> Not all of these are required properties. If they are missing the driver
> will operate on garbage values.
Yes.
>
> > +
> > + keypad->current_code = -1;
> > + keypad->debounce_code = -1;
> > + keypad->debounce_threshold = DIV_ROUND_UP(debounce_interval_ms, poll_interval_ms);
>
> This will bomb if poll interval is 0.
Yes.
>
> > +
> > + err = charlieplex_keypad_init_gpio(pdev, keypad);
> > + if (err)
> > + return err;
> > +
> > + input_dev->name = pdev->name;
> > + input_dev->id.bustype = BUS_HOST;
> > +
> > + err = matrix_keypad_build_keymap(NULL, NULL, keypad->nlines,
> > + keypad->nlines, NULL, input_dev);
> > + if (err)
> > + dev_err_probe(&pdev->dev, -ENOMEM, "failed to build keymap\n");
>
> Missing "return".
>
> > +
> > + if (device_property_read_bool(&pdev->dev, "autorepeat"))
> > + __set_bit(EV_REP, input_dev->evbit);
> > +
> > + input_set_capability(input_dev, EV_MSC, MSC_SCAN);
> > +
> > + err = input_setup_polling(input_dev, charlieplex_keypad_poll);
> > + if (err)
> > + dev_err_probe(&pdev->dev, err, "unable to set up polling\n");
>
> Missing "return".
Ok for both.
> I fixed it up and applied, please take a look in my 'next' branch and
> tell me if I messed up.
Thank you for the review and the fixes.
I tested it on the real hardware and all is good.
So I imagine that it can still go into 7.1 since it is a new driver
and not a modification of an existing one?
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Daniel Golle @ 2026-04-20 14:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <e747a3c5-1c43-412b-8ff6-f447ee33995c@kernel.org>
On Mon, Apr 20, 2026 at 04:43:00PM +0200, Krzysztof Kozlowski wrote:
> On 20/04/2026 16:24, Daniel Golle wrote:
> > On Mon, Apr 20, 2026 at 04:07:33PM +0200, Krzysztof Kozlowski wrote:
> >> On Sun, Apr 19, 2026 at 01:05:01PM +0100, Daniel Golle wrote:
> >>> + rng {
> >>> + compatible = "mediatek,mt7981-rng";
> >>
> >> I asked at v1. Reminded at v2. Nothing serious, but repeating myself is
> >> pointless and kind of waste of time.
> >
> > Replying *once* telling what you would actually want, or replying to
> > me asking back would have helped enormously:
> > https://patchwork.kernel.org/comment/26880354/
> >
> > All I can see is that you concluded "no improvements" without telling
> > *what it is you would like to see improved*.
> >
>
> Yes, and then you should go to v1 and read the review. There was only
> single comment in this spot, so trivial to find.
>
> AGAIN:
>
> Use four spaces for indentation.
Thank you, that IS helpful.
I've read the "no improvements" statement as an overall conclusion and
not even considered it to be specific to any *place* without further
context.
Is that the only remaining problem you see in the binding right now?
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Yeoreum Yun @ 2026-04-20 14:47 UTC (permalink / raw)
To: Sebastian Ene
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe, jarkko,
jgg, sudeep.holla, maz, oupton, joey.gouly, suzuki.poulose,
yuzenghui, catalin.marinas, will
In-Reply-To: <aeYypF4lv6LMH2ch@google.com>
Hi Sebastian,
> On Mon, Apr 20, 2026 at 02:00:57PM +0100, Yeoreum Yun wrote:
>
> Hi,
>
> >
> > Hi Sebastian,
> > > On Fri, Apr 17, 2026 at 06:57:59PM +0100, Yeoreum Yun wrote:
> > >
> > > Hello Yeoreum,
> > >
> > >
> > > > When pKVM is enabled, the FF-A driver must be initialized after pKVM.
> > > > Otherwise, pKVM cannot negotiate the FF-A version or
> > > > obtain RX/TX buffer information, leading to failures in FF-A calls.
> > >
> > > At the moment this already happens after you move back ffa_init() to
> > > device_initcall().
> >
> > How? the kvm_arm_init() is device_initcall() if both built as built-in.
> >
> > >
> > > >
> > > > During FF-A driver initialization, check whether pKVM has been initialized.
> > > > If not, defer probing of the FF-A driver.
> > > >
> > >
> > > I don't think you need to add this dependency. pKVM is
> > > installed through KVM's module_init() which ends up calling hyp_ffa_init() to
> > > do the proxy initialization. The ARM-FFA driver comes after it (since
> > > pKVM is arch specific code). We don't have to call finalize_pkvm(..) to
> > > be able to handle smc(FF-A) calls in the hyp-proxy.
> > >
> >
> > As Marc said, the before finalised_pkvm(), smc wouldn't be trapped
> > to pKVM. IOW, in case when both built as built-in,
>
> They are, I tested before replying to this thread. The HCR_EL2 is
> 0x480080000 so HCR_EL2 TSC bit is set so SMC/FF-A and trapping is enabled.
Oh. I've missed cpu_init_hyp_mode() sets up HCR_EL2. So you're right.
Thanks to correct me ;)
>
> In __pkvm_prot_finalize it sets the HCR_VM bit which enables stage-2 and
> then write the HCR_EL2 from params->hcr_el2. However I wasn't sure that
> this is seen as a 'hack' and not expected to work.
>
> > if ffa_init() is called before finalised_pkvm(),
> > it couldn't proxy the FFA_VERSION, FFA_RXTX_MAP and FFA_PARTITION_INFO_GET
> > called by ffa_init().
> >
> > How can you gurantee hyp_ffa_init() which is called by kvm_arm_init()
> > comes first even kvm_arm_init() and ffa_init() are on device_initcall?
> >
>
> While they are both on device_initcall, the only difference is that
> kvm_arm_init is arch code which appears before the driver/ code in the
> linker. That's why Marc said it is not a solid construct to rely on
> this.
Then I think the origin one -- just check kvm_arm_initialised
is enough to check in ffa_driver. since I misunderstood TSC bit
is setup after finalised_pkvm().
or Am I missing something?
Thanks.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Krzysztof Kozlowski @ 2026-04-20 14:43 UTC (permalink / raw)
To: Daniel Golle
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <aeY3HuP01VYl5x6X@makrotopia.org>
On 20/04/2026 16:24, Daniel Golle wrote:
> On Mon, Apr 20, 2026 at 04:07:33PM +0200, Krzysztof Kozlowski wrote:
>> On Sun, Apr 19, 2026 at 01:05:01PM +0100, Daniel Golle wrote:
>>> + rng {
>>> + compatible = "mediatek,mt7981-rng";
>>
>> I asked at v1. Reminded at v2. Nothing serious, but repeating myself is
>> pointless and kind of waste of time.
>
> Replying *once* telling what you would actually want, or replying to
> me asking back would have helped enormously:
> https://patchwork.kernel.org/comment/26880354/
>
> All I can see is that you concluded "no improvements" without telling
> *what it is you would like to see improved*.
>
Yes, and then you should go to v1 and read the review. There was only
single comment in this spot, so trivial to find.
AGAIN:
Use four spaces for indentation.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RFC] arm64/irqflags: force inline of arch_local_irq_enable()
From: Breno Leitao @ 2026-04-20 14:37 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, Will Deacon, leo.bras, leo.yan, linux-arm-kernel,
linux-kernel, palmer, paulmck, puranjay, usama.arif, kernel-team
In-Reply-To: <aeY02X5MDWPhGPCK@J2N7QTR9R3>
On Mon, Apr 20, 2026 at 03:14:49PM +0100, Mark Rutland wrote:
> On Mon, Apr 20, 2026 at 06:15:24AM -0700, Breno Leitao wrote:
> > On Mon, Apr 20, 2026 at 02:06:23PM +0100, Mark Rutland wrote:
> > >
> > > Are you happy to try that?
> >
> > Absolutely, I'll work on testing it that and put together a patch
> > addressing all of them.
> >
> > Should this be targeted for stable backports as well? If so, which
> > commit should I reference in the Fixes tag?
>
> I don't think we need to worry about backporting, and can do this as a
> cleanup for now unless someone shouts that they're seeing brokenness in
> a stable kernel.
>
> There's no specific commit for a fixes tag; this has always been a bit
> dodgy, but we've evidently been getting away with it in practice.
Ack. I'll run this through production testing for approximately 24
hours, then submit the patch.
Thanks,
--breno
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Alexis Lothoré @ 2026-04-20 14:27 UTC (permalink / raw)
To: Alexei Starovoitov, Andrey Konovalov
Cc: Alexis Lothoré, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
John Fastabend, David S. Miller, David Ahern, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, X86 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CAADnVQKuptG_opA12O=Xb9_+cHf3f=ycAZdfUp17P2HBYQzdsg@mail.gmail.com>
On Mon Apr 20, 2026 at 12:51 AM CEST, Alexei Starovoitov wrote:
> On Sun, Apr 19, 2026 at 2:49 PM Andrey Konovalov <andreyknvl@gmail.com> wrote:
>>
>> On Tue, Apr 14, 2026 at 5:58 PM Alexei Starovoitov
>> <alexei.starovoitov@gmail.com> wrote:
>> >
>> > I think we're talking past each other.
>> > We're not interested in KASAN_SW_TAGS or KASAN_HW_TAGS.
>> > We're not going to modify arm64 JIT at all.
>> >
>> > This is purely KASAN_GENRIC and only on x86-64.
>> > JIT will emit exactly what compilers emit for generic
>> > which is __asan_load/store. This is as stable ABI as it can get
>> > and we don't want to deviate from it.
>>
>> OK, I supposed that's fair. You did throw me off point with your
>> performance comment. But if you decide to add SW_TAGS support at some
>> point, I think this discussion needs to be revisited.
>>
>> But please add a comment saying that those functions are only exposed
>> for BPF JIT and they are not supposed to be used by other parts of the
>> kernel. And in case you do end up adding a new config option, guard
>> the public declarations by a corresponding ifdef.
>
> I feel concerns of misuse are overblown.
> Being in include/linux/kasan.h doesn't make them free-for-all
> all of a sudden, but if you prefer we can just copy paste:
> +void __asan_load1(void *p);
> +void __asan_store1(void *p);
> into bpf_jit_comp.c
That's actually what I initially went with when working on this, but it
did look a bit fragile, and suspected that I would rather be asked to export
them properly through a dedicated header. I'm fine with putting back the
manual declarations in jit comp, though.
>
>> > The goal here is to find bugs in the verifier.
>> > If something got past it, that shouldn't have,
>> > kasan generic on x86-64 is enough.
>>
>> FWIW, I suspect HW_TAGS KASAN already just works with JITed BPF code.
>
> Ohh. Good point. Looks like modern arm64 cpus in public clouds
> don't have that enabled, so one would need pixel phone to
> catch verifier bugs via hw_tags.
> So we still need this x86-specific jit kasan.
> I guess eventually it can be removed when hw_tags support is widespread.
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Daniel Golle @ 2026-04-20 14:24 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260420-flat-rook-of-hail-bbede5@quoll>
On Mon, Apr 20, 2026 at 04:07:33PM +0200, Krzysztof Kozlowski wrote:
> On Sun, Apr 19, 2026 at 01:05:01PM +0100, Daniel Golle wrote:
> > + rng {
> > + compatible = "mediatek,mt7981-rng";
>
> I asked at v1. Reminded at v2. Nothing serious, but repeating myself is
> pointless and kind of waste of time.
Replying *once* telling what you would actually want, or replying to
me asking back would have helped enormously:
https://patchwork.kernel.org/comment/26880354/
All I can see is that you concluded "no improvements" without telling
*what it is you would like to see improved*.
You want me to drop the whole example? Drop the compatible?
I did drop (and replace) the negative list with a positive list, and
thought that was what you have asked me for
https://patchwork.kernel.org/comment/26817847/
This binding is dead simple: It's a compatible, describing the identical
hardware now hidden behind and SMC call.
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Sebastian Ene @ 2026-04-20 14:20 UTC (permalink / raw)
To: Marc Zyngier
Cc: Yeoreum Yun, linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe, jarkko,
jgg, sudeep.holla, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <86mryx2408.wl-maz@kernel.org>
On Mon, Apr 20, 2026 at 01:46:47PM +0100, Marc Zyngier wrote:
> On Mon, 20 Apr 2026 13:32:32 +0100,
> Sebastian Ene <sebastianene@google.com> wrote:
> >
> > On Fri, Apr 17, 2026 at 06:57:59PM +0100, Yeoreum Yun wrote:
> >
> > Hello Yeoreum,
> >
> >
> > > When pKVM is enabled, the FF-A driver must be initialized after pKVM.
> > > Otherwise, pKVM cannot negotiate the FF-A version or
> > > obtain RX/TX buffer information, leading to failures in FF-A calls.
> >
> > At the moment this already happens after you move back ffa_init() to
> > device_initcall().
>
> But relying on this sort of ordering is just making things more
> fragile.
>
Thanks for letting me know. Since this is not a solid construct we will have
to change the driver init code to come after pKVM in this case.
> >
> > >
> > > During FF-A driver initialization, check whether pKVM has been initialized.
> > > If not, defer probing of the FF-A driver.
> > >
> >
> > I don't think you need to add this dependency. pKVM is
> > installed through KVM's module_init() which ends up calling hyp_ffa_init() to
> > do the proxy initialization. The ARM-FFA driver comes after it (since
> > pKVM is arch specific code). We don't have to call finalize_pkvm(..) to
> > be able to handle smc(FF-A) calls in the hyp-proxy.
>
> You do. Without the finalisation, SMCs are not trapped by EL2.
>
> And even if it did, relying on such hack is just wrong.
>
That makes it an even stronger argument to move the driver init at a
later stage. I was relying on this to trap early ff-a when the
ARM FF-A driver was used.
> M.
>
> --
> Without deviation from the norm, progress is not possible.
Thanks,
Sebastian
^ permalink raw reply
* Re: [PATCH 0/4] Add hstimer support for H616 and T113-S3
From: Andre Przywara @ 2026-04-20 14:14 UTC (permalink / raw)
To: Michal Piekos
Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maxime Ripard, linux-kernel, devicetree, linux-arm-kernel,
linux-sunxi
In-Reply-To: <xlvldmapdoql7nt3swube5vd6fdiosq7rt5afg246xertko5fa@4irmzupkar23>
Hi Michal,
On 4/20/26 13:27, Michal Piekos wrote:
> On Sun, Apr 19, 2026 at 10:55:39PM +0200, Andre Przywara wrote:
>> On Sun, 19 Apr 2026 14:46:06 +0200
>> Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
>>
>> Hi Michal,
>>
>>> Add support for Allwinner H616 high speed timer in sun5i hstimer driver
>>> and describe corresponding nodes in dts for H616 and T113-S3.
>>>
>>> H616 uses same model as existing driver except register shift compared
>>> to older variants.
>>>
>>> Added register layout abstraction in the driver, extended the binding
>>> with new compatibles and wired up dts nodes for H616 and T113-S3 which
>>> uses H616 as fallback compatible.
>>
>> Can you say *why* we need this? IIUC Linux only ever uses one clock
>> source, and selects the (non-optional) Generic Timer (aka arch timer)
>> for that? So can you say what this hstimer clock source adds? I guess
>> higher resolution, but what is your use case, so why would you need the
>> 200 MHz? And does this offset the higher access cost of an MMIO
>> access, compared to the arch timer's sysreg based access? Also, IIUC,
>> people would need to manually select this as the clocksource, why and
>> when would they do so? (Given they even know about it in the first
>> place).
>> Also the hstimer hasn't been used since the A20, so nobody seemed to
>> have missed it meanwhile?
>>
>> Cheers,
>> Andre
>>
> I took the table from https://linux-sunxi.org/Linux_mainlining_effort as
> a todo list and wanted to help with it. I do not have own use case for
> this timer. If it is not needed then I will spin v2 to include your
> comments and abandon it.
Ah, that's good to know, and thanks for picking things from that list! I
don't think there is a particular need to abandon your work, we could as
well upstream it. At least the DT changes should be added, so that other
DT users could make use of the timers - after all it's a Linux
implementation choice to utilise just one timer. But please go ahead and
post a complete v2, I don't think it hurts to have HSTIMER support in
the kernel.
And while you are at it: can you figure out what the need is for using
two timers? One is a clock source, the other is for clock events? And
why do we limit the counters and timers to 32 bit? Even the A13 manual
lists them as 56 bits, and a wraparound time of roughly 21 seconds (with
32 bit counters) does not sound very long to me.
Not sure what your primary motivation for fixing Allwinner support is,
but we could probably find more worthwhile targets. Do you have
Allwinner boards other than the OrangePi Zero 3? There are not many low
hanging fruits on the H616 left (MBUS and LDOs(?) maybe), but the A523
has quite some missing drivers still, some of them probably more on the
easy side.
If you are stuck with the OpiZero3, then you could just look and check
the existing devices, and verify their operation. For instance I think
USB-OTG is still broken - across most Allwinner SoCs actually, so it's a
sunxi driver issue.
Thanks,
Andre
>
> Michal
>
>>>
>>> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
>>> ---
>>> Michal Piekos (4):
>>> dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
>>> clocksource/drivers/sun5i: add H616 hstimer support
>>> arm64: dts: allwinner: h616: add hstimer node
>>> arm: dts: allwinner: t113s: add hstimer node
>>>
>>> .../timer/allwinner,sun5i-a13-hstimer.yaml | 8 +++-
>>> arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi | 12 +++++
>>> arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 ++++
>>> drivers/clocksource/timer-sun5i.c | 56 +++++++++++++++++++---
>>> 4 files changed, 78 insertions(+), 7 deletions(-)
>>> ---
>>> base-commit: faeab166167f5787719eb8683661fd41a3bb1514
>>> change-id: 20260413-h616-t113s-hstimer-62939948f91c
>>>
>>> Best regards,
>>
>>
^ permalink raw reply
* Re: [RESEND PATCH 0/3] arm_mpam: resctrl: Fixes for v7.1-rc1
From: Catalin Marinas @ 2026-04-20 14:15 UTC (permalink / raw)
To: James Morse; +Cc: linux-arm-kernel, will, Ben Horgan, Gavin Shan, Zeng Heng
In-Reply-To: <20260420140516.3892820-1-james.morse@arm.com>
Hi James,
On Mon, Apr 20, 2026 at 03:05:13PM +0100, James Morse wrote:
> This series is the collected fixes for MPAM series in arm64/for-next/core.
>
> These fix a unmount->remount problem with the CDP emulation,
> an uninitialised variable and a checker warning.
>
> If its easier, there is a branch here:
> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/glue/v7.0-rc3
I pulled the mpam/glue/v7.0-rc3+fixes into arm64 for-next/core.
Thanks!
--
Catalin
^ permalink raw reply
* Re: [PATCH RFC] arm64/irqflags: force inline of arch_local_irq_enable()
From: Mark Rutland @ 2026-04-20 14:14 UTC (permalink / raw)
To: Breno Leitao
Cc: Catalin Marinas, Will Deacon, leo.bras, leo.yan, linux-arm-kernel,
linux-kernel, palmer, paulmck, puranjay, usama.arif, kernel-team
In-Reply-To: <aeYmHr_lgPJbBoL_@gmail.com>
On Mon, Apr 20, 2026 at 06:15:24AM -0700, Breno Leitao wrote:
> On Mon, Apr 20, 2026 at 02:06:23PM +0100, Mark Rutland wrote:
> > On Mon, Apr 20, 2026 at 05:42:11AM -0700, Breno Leitao wrote:
> > > arch_local_irq_enable() is a small wrapper that dispatches between two
> > > unmask paths: __daif_local_irq_enable() on most systems, and
> > > __pmr_local_irq_enable() on builds that use GIC PMR-based masking
> > > (Pseudo-NMI). Both leaf primitives are already __always_inline; the
> > > wrapper itself is plain "static inline".
> > >
> > > In practice the compiler does not always inline the wrapper.
> >
> > I think this was my mistake, and we should have marked all the helpers
> > as __always_inline for noinstr safety, as x86 did in commit:
> >
> > 7a745be1cc90 ("x86/entry: __always_inline irqflags for noinstr")
> >
> > I think we should mark all of the following as __always_inline in one
> > go:
> >
> > * arch_local_irq_enable()
> > * arch_local_irq_disable()
> > * arch_local_save_flags()
> > * arch_irqs_disabled_flags()
> > * arch_irqs_disabled()
> > * arch_local_irq_save()
> > * arch_local_irq_restore()
> >
> > ... which then ensures noinstr safety, and has the side benefit of
> > giving nicer traces as you're suggesting here.
> >
> > Are you happy to try that?
>
> Absolutely, I'll work on testing it that and put together a patch
> addressing all of them.
>
> Should this be targeted for stable backports as well? If so, which
> commit should I reference in the Fixes tag?
I don't think we need to worry about backporting, and can do this as a
cleanup for now unless someone shouts that they're seeing brokenness in
a stable kernel.
There's no specific commit for a fixes tag; this has always been a bit
dodgy, but we've evidently been getting away with it in practice.
Mark.
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Krzysztof Kozlowski @ 2026-04-20 14:07 UTC (permalink / raw)
To: Daniel Golle
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <585fc832e4e5d3656bd25ecee6bafb636993104a.1776600269.git.daniel@makrotopia.org>
On Sun, Apr 19, 2026 at 01:05:01PM +0100, Daniel Golle wrote:
> + rng {
> + compatible = "mediatek,mt7981-rng";
I asked at v1. Reminded at v2. Nothing serious, but repeating myself is
pointless and kind of waste of time.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] ARM: mvebu: dt64 for v7.1 (#1)
From: Gregory CLEMENT @ 2026-04-20 14:05 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Arnd Bergmann, arm, soc, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel
In-Reply-To: <20260414-nifty-conscious-fox-973b65@quoll>
Hello Krzysztof,
> On Fri, Apr 10, 2026 at 03:25:39PM +0200, Gregory CLEMENT wrote:
>> Hi,
>>
>> Here is the first pull request for dt64 for mvebu for v7.1.
>>
>> Gregory
>>
>> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>>
>> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>>
>> are available in the Git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-dt64-7.1-1
>>
>> for you to fetch changes up to 00e6d608fe80b0f68c325cb46862f78e9a8ec768:
>>
>> arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node (2026-04-09 10:14:40 +0200)
>>
>> ----------------------------------------------------------------
>> mvebu dt64 for 7.1 (part 1)
>
> This was sent just 2 days before merge window open, thus I applied it as
> late branch.
Thanks for finally merging it.
Gregory
>
> Best regards,
> Krzysztof
>
--
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [RESEND PATCH 0/3] arm_mpam: resctrl: Fixes for v7.1-rc1
From: James Morse @ 2026-04-20 14:05 UTC (permalink / raw)
To: catalin.marinas; +Cc: linux-arm-kernel, will, Ben Horgan, Gavin Shan, Zeng Heng
Hi Catalin,
This series is the collected fixes for MPAM series in arm64/for-next/core.
These fix a unmount->remount problem with the CDP emulation,
an uninitialised variable and a checker warning.
If its easier, there is a branch here:
https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/glue/v7.0-rc3
Thanks,
James
Ben Horgan (2):
arm_mpam: resctrl: Fix the check for no monitor components found
arm_mpam: resctrl: Make resctrl_mon_ctx_waiters static
Zeng Heng (1):
arm_mpam: resctrl: Fix MBA CDP alloc_capable handling on unmount
drivers/resctrl/mpam_resctrl.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Sebastian Ene @ 2026-04-20 14:05 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe, jarkko,
jgg, sudeep.holla, maz, oupton, joey.gouly, suzuki.poulose,
yuzenghui, catalin.marinas, will
In-Reply-To: <aeYjiaPtAl7SMVkL@e129823.arm.com>
On Mon, Apr 20, 2026 at 02:00:57PM +0100, Yeoreum Yun wrote:
Hi,
>
> Hi Sebastian,
> > On Fri, Apr 17, 2026 at 06:57:59PM +0100, Yeoreum Yun wrote:
> >
> > Hello Yeoreum,
> >
> >
> > > When pKVM is enabled, the FF-A driver must be initialized after pKVM.
> > > Otherwise, pKVM cannot negotiate the FF-A version or
> > > obtain RX/TX buffer information, leading to failures in FF-A calls.
> >
> > At the moment this already happens after you move back ffa_init() to
> > device_initcall().
>
> How? the kvm_arm_init() is device_initcall() if both built as built-in.
>
> >
> > >
> > > During FF-A driver initialization, check whether pKVM has been initialized.
> > > If not, defer probing of the FF-A driver.
> > >
> >
> > I don't think you need to add this dependency. pKVM is
> > installed through KVM's module_init() which ends up calling hyp_ffa_init() to
> > do the proxy initialization. The ARM-FFA driver comes after it (since
> > pKVM is arch specific code). We don't have to call finalize_pkvm(..) to
> > be able to handle smc(FF-A) calls in the hyp-proxy.
> >
>
> As Marc said, the before finalised_pkvm(), smc wouldn't be trapped
> to pKVM. IOW, in case when both built as built-in,
They are, I tested before replying to this thread. The HCR_EL2 is
0x480080000 so HCR_EL2 TSC bit is set so SMC/FF-A and trapping is enabled.
In __pkvm_prot_finalize it sets the HCR_VM bit which enables stage-2 and
then write the HCR_EL2 from params->hcr_el2. However I wasn't sure that
this is seen as a 'hack' and not expected to work.
> if ffa_init() is called before finalised_pkvm(),
> it couldn't proxy the FFA_VERSION, FFA_RXTX_MAP and FFA_PARTITION_INFO_GET
> called by ffa_init().
>
> How can you gurantee hyp_ffa_init() which is called by kvm_arm_init()
> comes first even kvm_arm_init() and ffa_init() are on device_initcall?
>
While they are both on device_initcall, the only difference is that
kvm_arm_init is arch code which appears before the driver/ code in the
linker. That's why Marc said it is not a solid construct to rely on
this.
Thanks,
Sebastian
> [...]
>
> Thanks
>
>
> --
> Sincerely,
> Yeoreum Yun
^ permalink raw reply
* [RESEND PATCH 2/3] arm_mpam: resctrl: Fix the check for no monitor components found
From: James Morse @ 2026-04-20 14:05 UTC (permalink / raw)
To: catalin.marinas; +Cc: linux-arm-kernel, will, Ben Horgan, Gavin Shan, Zeng Heng
In-Reply-To: <20260420140516.3892820-1-james.morse@arm.com>
From: Ben Horgan <ben.horgan@arm.com>
Dan Carpenter reports that, in mpam_resctrl_alloc_domain(), any_mon_comp is
used in an 'if' condition when it may be uninitialized. Initialize it to
NULL so that the check behaves correctly when no monitor components are
found.
Reported-by: Dan Carpenter <error27@gmail.com>
Fixes: 264c285999fc ("arm_mpam: resctrl: Add monitor initialisation and domain boilerplate")
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: James Morse <james.morse@arm.com>
---
drivers/resctrl/mpam_resctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
index 4205fb2ee312..1b0b37da12af 100644
--- a/drivers/resctrl/mpam_resctrl.c
+++ b/drivers/resctrl/mpam_resctrl.c
@@ -1407,7 +1407,7 @@ mpam_resctrl_alloc_domain(unsigned int cpu, struct mpam_resctrl_res *res)
}
if (r->mon_capable) {
- struct mpam_component *any_mon_comp;
+ struct mpam_component *any_mon_comp = NULL;
struct mpam_resctrl_mon *mon;
enum resctrl_event_id eventid;
--
2.53.0
^ permalink raw reply related
* [RESEND PATCH 3/3] arm_mpam: resctrl: Make resctrl_mon_ctx_waiters static
From: James Morse @ 2026-04-20 14:05 UTC (permalink / raw)
To: catalin.marinas; +Cc: linux-arm-kernel, will, Ben Horgan, Gavin Shan, Zeng Heng
In-Reply-To: <20260420140516.3892820-1-james.morse@arm.com>
From: Ben Horgan <ben.horgan@arm.com>
resctrl_mon_ctx_waiters is not used outside of this file, so make it
static. This fixes the sparse warning:
drivers/resctrl/mpam_resctrl.c:25:1: warning: symbol 'resctrl_mon_ctx_waiters' was not declared. Should it be static?
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603281842.c2K96tJA-lkp@intel.com/
Fixes: 2a3c79c61539 ("arm_mpam: resctrl: Allow resctrl to allocate monitors")
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: James Morse <james.morse@arm.com>
---
drivers/resctrl/mpam_resctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
index 1b0b37da12af..226ff6f532fa 100644
--- a/drivers/resctrl/mpam_resctrl.c
+++ b/drivers/resctrl/mpam_resctrl.c
@@ -22,7 +22,7 @@
#include "mpam_internal.h"
-DECLARE_WAIT_QUEUE_HEAD(resctrl_mon_ctx_waiters);
+static DECLARE_WAIT_QUEUE_HEAD(resctrl_mon_ctx_waiters);
/*
* The classes we've picked to map to resctrl resources, wrapped
--
2.53.0
^ permalink raw reply related
* [RESEND PATCH 1/3] arm_mpam: resctrl: Fix MBA CDP alloc_capable handling on unmount
From: James Morse @ 2026-04-20 14:05 UTC (permalink / raw)
To: catalin.marinas; +Cc: linux-arm-kernel, will, Ben Horgan, Gavin Shan, Zeng Heng
In-Reply-To: <20260420140516.3892820-1-james.morse@arm.com>
From: Zeng Heng <zengheng4@huawei.com>
The code to set MBA's alloc_capable to true appears to be trying to
restore alloc_capable on unmount. This can never work because
resctrl_arch_set_cdp_enabled() is never invoked with RDT_RESOURCE_MBA
as the rid parameter. Consequently,
mpam_resctrl_controls[RDT_RESOURCE_MBA].cdp_enabled always remains false.
The alloc_capable setting in resctrl_arch_set_cdp_enabled() is to
re-enable MBA if the caller opts in to separate control values using
CDP for this resource. This doesn't happen today.
Add a comment to describe this.
However a bug remains where MBA allocation is permanently disabled after
the mount with CDP option. Remounting without CDP cannot restore the MBA
partition capability.
Add a check to re-enable MBA when CDP is disabled, which happens on
unmount.
Fixes: 6789fb99282c ("arm_mpam: resctrl: Add CDP emulation")
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
[ morse: Added comment for existing code, added hunk to fix this bug from
Ben H ]
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
---
drivers/resctrl/mpam_resctrl.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
index a9938006d0e6..4205fb2ee312 100644
--- a/drivers/resctrl/mpam_resctrl.c
+++ b/drivers/resctrl/mpam_resctrl.c
@@ -220,10 +220,18 @@ int resctrl_arch_set_cdp_enabled(enum resctrl_res_level rid, bool enable)
if (cdp_enabled && !mpam_resctrl_controls[RDT_RESOURCE_MBA].cdp_enabled)
mpam_resctrl_controls[RDT_RESOURCE_MBA].resctrl_res.alloc_capable = false;
+ /*
+ * If resctrl has attempted to enable CDP on MBA, re-enable MBA as two
+ * configurations will be provided so there is no aliasing problem.
+ */
if (mpam_resctrl_controls[RDT_RESOURCE_MBA].cdp_enabled &&
mpam_resctrl_controls[RDT_RESOURCE_MBA].class)
mpam_resctrl_controls[RDT_RESOURCE_MBA].resctrl_res.alloc_capable = true;
+ /* On unmount when CDP is disabled, re-enable MBA */
+ if (!cdp_enabled && mpam_resctrl_controls[RDT_RESOURCE_MBA].class)
+ mpam_resctrl_controls[RDT_RESOURCE_MBA].resctrl_res.alloc_capable = true;
+
if (enable) {
if (mpam_partid_max < 1)
return -EINVAL;
--
2.53.0
^ permalink raw reply related
* [PATCH] serial: fsl_lpuart: fix rx buffer and DMA map leaks in start_rx_dma
From: Shitalkumar Gandhi @ 2026-04-20 13:59 UTC (permalink / raw)
To: gregkh, jirislaby
Cc: bhuvanchandra.dv, Frank.Li, peng.fan, sherry.sun, linux-serial,
imx, linux-arm-kernel, linux-kernel, stable, Shitalkumar Gandhi
lpuart_start_rx_dma() allocates sport->rx_ring.buf with kzalloc() and
then maps a scatterlist via dma_map_sg(). On three subsequent error
paths the function returns directly without releasing those resources:
- when dma_map_sg() returns 0 (-EINVAL):
ring->buf is leaked.
- when dmaengine_slave_config() fails:
ring->buf and the DMA mapping are leaked.
- when dmaengine_prep_dma_cyclic() returns NULL:
ring->buf and the DMA mapping are leaked.
The sole cleanup path, lpuart_dma_rx_free(), is only reached when
lpuart_dma_rx_use is set, and the caller lpuart_rx_dma_startup() clears
that flag on failure of lpuart_start_rx_dma(). So these resources are
permanently leaked on every failure in this function. Repeated port
open/close or termios changes under error conditions will slowly consume
memory and leave stale streaming DMA mappings behind.
Fix it by introducing two error labels that unmap the scatterlist and
free the ring buffer as appropriate. While here, replace the misleading
-EFAULT (bad userspace pointer) returned when dmaengine_prep_dma_cyclic()
fails with the more accurate -ENOMEM, matching how other dmaengine users
in the tree treat this failure.
No functional change on the success path.
Fixes: 5887ad43ee02 ("tty: serial: fsl_lpuart: Use cyclic DMA for Rx")
Cc: stable@vger.kernel.org
Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com>
---
drivers/tty/serial/fsl_lpuart.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index f36d50fe056f..296a096be351 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -1376,7 +1376,8 @@ static inline int lpuart_start_rx_dma(struct lpuart_port *sport)
if (!nent) {
dev_err(sport->port.dev, "DMA Rx mapping error\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_free_buf;
}
dma_rx_sconfig.src_addr = lpuart_dma_datareg_addr(sport);
@@ -1388,7 +1389,7 @@ static inline int lpuart_start_rx_dma(struct lpuart_port *sport)
if (ret < 0) {
dev_err(sport->port.dev,
"DMA Rx slave config failed, err = %d\n", ret);
- return ret;
+ goto err_unmap_sg;
}
sport->dma_rx_desc = dmaengine_prep_dma_cyclic(chan,
@@ -1399,7 +1400,8 @@ static inline int lpuart_start_rx_dma(struct lpuart_port *sport)
DMA_PREP_INTERRUPT);
if (!sport->dma_rx_desc) {
dev_err(sport->port.dev, "Cannot prepare cyclic DMA\n");
- return -EFAULT;
+ ret = -ENOMEM;
+ goto err_unmap_sg;
}
sport->dma_rx_desc->callback = lpuart_dma_rx_complete;
@@ -1423,6 +1425,13 @@ static inline int lpuart_start_rx_dma(struct lpuart_port *sport)
}
return 0;
+
+err_unmap_sg:
+ dma_unmap_sg(chan->device->dev, &sport->rx_sgl, 1, DMA_FROM_DEVICE);
+err_free_buf:
+ kfree(ring->buf);
+ ring->buf = NULL;
+ return ret;
}
static void lpuart_dma_rx_free(struct uart_port *port)
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net v4 0/2] net: airoha: Fix airoha_qdma_cleanup_tx_queue() processing
From: Simon Horman @ 2026-04-20 13:56 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260417-airoha_qdma_cleanup_tx_queue-fix-net-v4-0-e04bcc2c9642@kernel.org>
On Fri, Apr 17, 2026 at 08:36:30AM +0200, Lorenzo Bianconi wrote:
> Add missing bits in airoha_qdma_cleanup_tx_queue routine.
> Fix airoha_qdma_cleanup_tx_queue processing errors intorduced in commit
> '3f47e67dff1f7 ("net: airoha: Add the capability to consume out-of-order
> DMA tx descriptors")'.
>
> ---
> Changes in v4:
> - Drop patch 2/3 to move entries to queue head in case of DMA mapping
> failure in airoha_dev_xmit().
> - Link to v3: https://lore.kernel.org/r/20260416-airoha_qdma_cleanup_tx_queue-fix-net-v3-0-2b69f5788580@kernel.org
>
> Changes in v3:
> - Move ndesc initialization fix in a dedicated patch.
> - Add patch 2/3 to move entries to queue head in case of DMA mapping
> failure in airoha_dev_xmit().
> - Cosmetics.
> - Link to v2: https://lore.kernel.org/r/20260414-airoha_qdma_cleanup_tx_queue-fix-net-v2-1-875de57cc022@kernel.org
>
> Changes in v2:
> - Move q->ndesc initialization at end of airoha_qdma_init_tx routine in
> order to avoid any possible NULL pointer dereference in
> airoha_qdma_cleanup_tx_queue()
> - Check if q->tx_list is empty in airoha_qdma_cleanup_tx_queue()
> - Link to v1: https://lore.kernel.org/r/20260410-airoha_qdma_cleanup_tx_queue-fix-net-v1-1-b7171c8f1e78@kernel.org
>
> ---
> Lorenzo Bianconi (2):
> net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx()
> net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
>
> drivers/net/ethernet/airoha/airoha_eth.c | 40 +++++++++++++++++++++++++++-----
> 1 file changed, 34 insertions(+), 6 deletions(-)
Thanks for the updates, this series looks good to me:
Reviewed-by: Simon Horman <horms@kernel.org>
As is the way of things, Sashiko has some feedback on this patchset.
Please consider looking over it for potential follow-up changes.
I do not think that needs to block progress of this patchset.
^ permalink raw reply
* [PATCH v4 4/4] arm64: dts: amlogic: t7: khadas-vim4: Enable Bluetooth
From: Ronald Claveau @ 2026-04-20 13:54 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
Ronald Claveau
In-Reply-To: <20260420-add-bluetooth-t7-vim4-v4-0-9505df0e7016@aliel.fr>
Enable UART C on the Khadas VIM4 board and attach the BCM43438
compatible Bluetooth controller to it. The node configures the RTS/CTS
hardware flow control, the associated pinmux, the power supplies (vddao_3v3
and vddao_1v8), the 32 kHz LPO clock shared with the wifi32k fixed
clock, and the GPIO lines used for host wakeup, device wakeup and
shutdown.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 3227ab27de107..8ea7ae609fbd5 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -251,3 +251,22 @@ &sd_emmc_c {
&uart_a {
status = "okay";
};
+
+&uart_c {
+ status = "okay";
+ pinctrl-0 = <&uart_c_pins>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
+ host-wakeup-gpios = <&gpio GPIOX_18 GPIO_ACTIVE_HIGH>;
+ device-wakeup-gpios = <&gpio GPIOX_19 GPIO_ACTIVE_HIGH>;
+ max-speed = <3000000>;
+ clocks = <&wifi32k>;
+ clock-names = "lpo";
+ vbat-supply = <&vddao_3v3>;
+ vddio-supply = <&vddao_1v8>;
+ };
+};
--
2.49.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