* Re: [PATCH v3 1/2] dt-bindings: spi: nuvoton,ma35d1-qspi: Add Nuvoton MA35D1 QSPI
From: Chi-Wen Weng @ 2026-06-15 1:18 UTC (permalink / raw)
To: Conor Dooley
Cc: broonie, robh, krzk+dt, conor+dt, linux-arm-kernel, linux-spi,
devicetree, linux-kernel, cwweng
In-Reply-To: <20260612-diagram-florist-01a0e8f923d8@spud>
Hi Conor,
Thanks for the clarification.
I will make the driver read num-cs in v4 and fall back to the hardware
default of 2 when the property is not present. I will also keep the
binding default in sync with that behavior.
Best regards,
Chi-Wen
Conor Dooley 於 2026/6/12 下午 11:48 寫道:
> On Fri, Jun 12, 2026 at 08:33:01AM +0800, Chi-Wen Weng wrote:
>> Hi Conor,
>>
>> Thanks for the review.
>>
>> I will add a default value for num-cs in v4:
>>
>> num-cs:
>> maximum: 2
>> default: 2
>>
>> The controller has two native chip selects and the driver currently uses
>> that hardware default.
> The driver should handle the property and fall back to the default.
> It's not complex to support, so surely there's no reason not to?
>
> Cheers,
> Conor.
>
>> Best regards,
>> Chi-Wen
>>
>> Conor Dooley 於 2026/6/12 上午 01:34 寫道:
>>> On Thu, Jun 11, 2026 at 05:12:45PM +0800, Chi-Wen Weng wrote:
>>>> From: Chi-Wen Weng <cwweng@nuvoton.com>
>>>>
>>>> Add a devicetree binding for the Quad SPI controller found in
>>>> Nuvoton MA35D1 SoCs.
>>>>
>>>> The controller supports SPI memory devices such as SPI NOR and SPI NAND
>>>> flashes. It has one register range, one clock input and one reset line,
>>>> and supports up to two chip selects.
>>>>
>>>> Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
>>>> ---
>>>> .../bindings/spi/nuvoton,ma35d1-qspi.yaml | 62 +++++++++++++++++++
>>>> 1 file changed, 62 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml b/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
>>>> new file mode 100644
>>>> index 000000000000..d3b36e612eb0
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
>>>> @@ -0,0 +1,62 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/spi/nuvoton,ma35d1-qspi.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Nuvoton MA35D1 Quad SPI Controller
>>>> +
>>>> +maintainers:
>>>> + - Chi-Wen Weng <cwweng@nuvoton.com>
>>>> +
>>>> +allOf:
>>>> + - $ref: /schemas/spi/spi-controller.yaml#
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + const: nuvoton,ma35d1-qspi
>>>> +
>>>> + reg:
>>>> + maxItems: 1
>>>> +
>>>> + interrupts:
>>>> + maxItems: 1
>>>> +
>>>> + clocks:
>>>> + maxItems: 1
>>>> +
>>>> + resets:
>>>> + maxItems: 1
>>>> +
>>>> + num-cs:
>>>> + maximum: 2
>>> Missing a default of 2, unless you make the property required.
>>> FWIW, your driver doesn't appear to read this value.
>>>
>>> pw-bot: changes-requested
>>>
>>> Cheers,
>>> Conor.
>>>
>>>> +
>>>> +required:
>>>> + - compatible
>>>> + - reg
>>>> + - clocks
>>>> + - resets
>>>> +
>>>> +unevaluatedProperties: false
>>>> +
>>>> +examples:
>>>> + - |
>>>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
>>>> + #include <dt-bindings/reset/nuvoton,ma35d1-reset.h>
>>>> +
>>>> + soc {
>>>> + #address-cells = <2>;
>>>> + #size-cells = <2>;
>>>> +
>>>> + spi@40680000 {
>>>> + compatible = "nuvoton,ma35d1-qspi";
>>>> + reg = <0 0x40680000 0 0x100>;
>>>> + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
>>>> + clocks = <&clk QSPI0_GATE>;
>>>> + resets = <&sys MA35D1_RESET_QSPI0>;
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + };
>>>> + };
>>>> +
>>>> --
>>>> 2.25.1
>>>>
^ permalink raw reply
* Re: [PATCH bpf-next] arm64: mm: Remove misleading pte_none() comment from ptep_try_set()
From: patchwork-bot+netdevbpf @ 2026-06-14 23:30 UTC (permalink / raw)
To: Tejun Heo
Cc: catalin.marinas, will, ast, andrii, daniel, martin.lau, memxor,
akpm, david, rppt, arighi, emil, linux-arm-kernel, bpf, linux-mm,
linux-kernel
In-Reply-To: <20260614210209.2371030-1-tj@kernel.org>
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:
On Sun, 14 Jun 2026 11:02:09 -1000 you wrote:
> This comment was thoughtlessly copied from the x86 version and doesn't
> apply to arm64. Remove it.
>
> Reported-by: Will Deacon <will@kernel.org>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> ---
> arch/arm64/include/asm/pgtable.h | 4 ----
> 1 file changed, 4 deletions(-)
Here is the summary with links:
- [bpf-next] arm64: mm: Remove misleading pte_none() comment from ptep_try_set()
https://git.kernel.org/bpf/bpf-next/c/16deef8de06e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] ARM: disable broken eBPF JIT on the Risc PC
From: Ethan Nelson-Moore @ 2026-06-14 22:41 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Linus Walleij, linux-arm-kernel, linux-kernel, stable,
Arnd Bergmann, Kees Cook, Nathan Chancellor, Thomas Weissschuh,
Peter Zijlstra, Shubham Bansal, David S. Miller
In-Reply-To: <ai8nrc0ZUfPaqC_7@shell.armlinux.org.uk>
Hi, Russell,
On Sun, Jun 14, 2026 at 3:14 PM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
> > https://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=9477/1
>
> Should be s/arm\./arm/
Got it. Would it make sense to make the domain with the dot 301
redirect to the same URL at the one without the dot? Right now, Google
is indexing both, and this would remedy that.
> Also, you can use:
>
> Link: https://lore.kernel.org/all/CAD++jL=0qYGoygUwGEXQL7C_ROnC7kfpRv8RA+H5tNWwYu+pQA@mail.gmail.com/
>
> in the attributions in the commit message to indicate where more
> patch context can be found.
Thanks. I knew that but didn't think of it at the time I submitted.
> Lastly, too late for v7.1 as a fix, I already sent the pull request
> for that, sorry.
That's okay. It's not a particularly high priority :p
Ethan
^ permalink raw reply
* Re: [PATCH v7 2/8] dt-bindings: i2c: amlogic: Add compatible for T7 SOC
From: Andi Shyti @ 2026-06-14 22:24 UTC (permalink / raw)
To: linux-kernel-dev
Cc: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Beniamino Galvani, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Liam Girdwood, Mark Brown, linux-amlogic, devicetree,
linux-kernel, linux-i2c, linux-arm-kernel, linux-pm
In-Reply-To: <20260603-add-mcu-fan-khadas-vim4-v7-2-594ba8a965d8@aliel.fr>
Hi Ronald,
On Wed, Jun 03, 2026 at 08:05:24PM +0200, Ronald Claveau via B4 Relay wrote:
> From: Ronald Claveau <linux-kernel-dev@aliel.fr>
>
> Add the T7 SOC compatible which fallback to AXG compatible.
>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH] ARM: disable broken eBPF JIT on the Risc PC
From: Russell King (Oracle) @ 2026-06-14 22:14 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: Linus Walleij, linux-arm-kernel, linux-kernel, stable,
Arnd Bergmann, Kees Cook, Nathan Chancellor, Thomas Weissschuh,
Peter Zijlstra, Shubham Bansal, David S. Miller
In-Reply-To: <CADkSEUjsS8bOXDhgZ2EW40xifDZ-pk5y=YqyWT-+vQNd8JikUw@mail.gmail.com>
On Sat, Jun 13, 2026 at 06:50:40PM -0700, Ethan Nelson-Moore wrote:
> On Mon, May 25, 2026 at 1:18 AM Linus Walleij <linusw@kernel.org> wrote:
> > Looks correct to me.
> > Reviewed-by: Linus Walleij <linusw@kernel.org>
> >
> > Please put this into Russell's patch tracker!
>
> Done!
>
> https://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=9477/1
Should be s/arm\./arm/
Also, you can use:
Link: https://lore.kernel.org/all/CAD++jL=0qYGoygUwGEXQL7C_ROnC7kfpRv8RA+H5tNWwYu+pQA@mail.gmail.com/
in the attributions in the commit message to indicate where more
patch context can be found.
Lastly, too late for v7.1 as a fix, I already sent the pull request
for that, sorry.
--
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] i2c: davinci: Unregister cpufreq notifier on probe failure
From: Andi Shyti @ 2026-06-14 22:10 UTC (permalink / raw)
To: Haoxiang Li
Cc: brgl, khilman, chaithrika, linux-arm-kernel, linux-i2c,
linux-kernel, stable
In-Reply-To: <20260610030513.2651018-1-haoxiang_li2024@163.com>
Hi Haoxing,
On Wed, Jun 10, 2026 at 11:05:13AM +0800, Haoxiang Li wrote:
> davinci_i2c_probe() registers a cpufreq transition notifier before adding
> the I2C adapter. If i2c_add_numbered_adapter() fails, the probe error path
> releases the device resources without unregistering the notifier.
>
> Add a dedicated error path to unregister the cpufreq notifier after
> i2c_add_numbered_adapter() fails.
>
> Fixes: 82c0de11b734 ("i2c: davinci: Add cpufreq support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
merged to i2c/i2c-host.
Thanks,
Andi
^ permalink raw reply
* [PATCH v2 0/3] drm/msm: Add support for Shikra GPU (A704)
From: Akhil P Oommen @ 2026-06-14 21:32 UTC (permalink / raw)
To: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD)
Cc: Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu, Akhil P Oommen,
Aditya Sherawat, Krzysztof Kozlowski, Konrad Dybcio
Adreno A704 GPU found in Shikra is an IP reuse of A702 GPU with very
minimal changes. The only KMD facing difference is the chipid and the
zap firmware which is specified via devicetree.
Mesa side support is already merged:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41762
The dependencies for the devicetree patches are still on the mailing
lists. So I will send that separately.
-Akhil.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
Changes in v2:
- Add a new patch to document the GPU SMMU bindings
- Capture trailers
- Link to v1: https://lore.kernel.org/r/20260609-shikra-gpu-v1-0-9d0e09cab115@oss.qualcomm.com
---
Aditya Sherawat (2):
dt-bindings: display/msm/gpu: Add support for A704 GPU
drm/msm/adreno: Add support for A704 GPU
Bibek Kumar Patro (1):
dt-bindings: arm-smmu: Document GPU SMMU for Shikra SoC
Documentation/devicetree/bindings/display/msm/gpu.yaml | 1 +
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 2 ++
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 2 +-
3 files changed, 4 insertions(+), 1 deletion(-)
---
base-commit: 61087e3a8490908a65da4e2d33fb5de6eb888982
change-id: 20260609-shikra-gpu-5432bdeaf0f7
Best regards,
--
Akhil P Oommen <akhilpo@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] ARM: disable broken eBPF JIT on the Risc PC
From: Ethan Nelson-Moore @ 2026-06-14 21:44 UTC (permalink / raw)
To: David Laight
Cc: linux-arm-kernel, linux-kernel, stable, Russell King,
Russell King (Oracle), Arnd Bergmann, Linus Walleij, Kees Cook,
Nathan Chancellor, Thomas Weissschuh, Peter Zijlstra,
Shubham Bansal, David S. Miller
In-Reply-To: <20260614125857.398a0e13@pumpkin>
Hi, David,
On Sun, Jun 14, 2026 at 4:58 AM David Laight
<david.laight.linux@gmail.com> wrote:
> Isn't it more the case that the ldrh/strh instructions were added for armv4.
> Whether the bus supports 16bit accesses is entirely different.
No, it is in fact the bus. While the Risc PC initially shipped with
ARMv3 CPUs, which the kernel no longer supports, it was later upgraded
to an ARMv4 StrongARM CPU. However, its bus was designed for ARMv3
CPUs and has no way to represent a half-word access to memory. This
means that ldrh/strh will execute (because the CPU supports them) but
do not function as intended.
Ethan
^ permalink raw reply
* Re: [PATCH] i2c: stm32f7: truncate clock period instead of rounding it
From: Andi Shyti @ 2026-06-14 21:34 UTC (permalink / raw)
To: Guillermo Rodríguez
Cc: Pierre-Yves MORDRET, Alain Volmat, Maxime Coquelin,
Alexandre Torgue, M'boumba Cedric Madianga, Wolfram Sang,
Pierre-Yves MORDRET, linux-i2c, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260611104857.242153-1-guille.rodriguez@gmail.com>
Pierre-Yves,
any thought on this?
Andi
On Thu, Jun 11, 2026 at 12:48:56PM +0200, Guillermo Rodríguez wrote:
> stm32f7_i2c_compute_timing() derives the I2C clock source period
> (i2cclk) with DIV_ROUND_CLOSEST, which may round it up. When the
> period is overestimated, all timings computed from it (SCLDEL,
> SDADEL, SCLL, SCLH) come out shorter on the wire than calculated,
> and the resulting bus rate can exceed the requested speed, violating
> the I2C specification minimums for tLOW and tHIGH.
>
> For example, with a 104.45 MHz clock source (e.g. PCLK1, the
> reset-default I2C clock source on STM32MP1), i2cclk is rounded from
> 9.574 ns up to 10 ns. Requesting a 400 kHz fast mode bus with
> 72/27 ns rise/fall times and no analog/digital filters then produces
> an actual bus rate of 415.6 kHz with tLOW = 1254 ns, violating both
> the 400 kHz maximum rate and the 1300 ns tLOW minimum of the
> specification.
>
> Truncate the period instead, so that it can only be underestimated.
> The error then falls on the safe side: the programmed timings come
> out slightly longer than computed and the bus runs marginally below
> the target rate (375.3 kHz in the example above) while meeting the
> specification.
>
> i2cbus is left rounded-to-closest: it is only used as the target of
> the clk_error comparison and is never multiplied into the programmed
> timings, so nearest rounding remains accurate there.
>
> Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guillermo Rodríguez <guille.rodriguez@gmail.com>
> ---
> drivers/i2c/busses/i2c-stm32f7.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
> index 53d9df70ebe4..6439620d6bed 100644
> --- a/drivers/i2c/busses/i2c-stm32f7.c
> +++ b/drivers/i2c/busses/i2c-stm32f7.c
> @@ -464,8 +464,13 @@ static int stm32f7_i2c_compute_timing(struct stm32f7_i2c_dev *i2c_dev,
> {
> struct stm32f7_i2c_spec *specs;
> u32 p_prev = STM32F7_PRESC_MAX;
> - u32 i2cclk = DIV_ROUND_CLOSEST(NSEC_PER_SEC,
> - setup->clock_src);
> + /*
> + * Truncate instead of rounding to closest: if the clock period is
> + * overestimated, the computed SCL timings will come out shorter on
> + * the wire, which can push the bus above the target rate and below
> + * the spec's tLOW/tHIGH minimums.
> + */
> + u32 i2cclk = NSEC_PER_SEC / setup->clock_src;
> u32 i2cbus = DIV_ROUND_CLOSEST(NSEC_PER_SEC,
> setup->speed_freq);
> u32 clk_error_prev = i2cbus;
> --
> 2.25.1
>
^ permalink raw reply
* [PATCH v2 3/3] dt-bindings: arm-smmu: Document GPU SMMU for Shikra SoC
From: Akhil P Oommen @ 2026-06-14 21:32 UTC (permalink / raw)
To: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD)
Cc: Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu, Akhil P Oommen
In-Reply-To: <20260615-shikra-gpu-v2-0-2f2d1347c3fb@oss.qualcomm.com>
From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
Add specific compatible strings to document the GPU SMMU present
in the Shikra SoC.
Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index a701dec2fa0a..ad15fda5c25e 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -108,6 +108,7 @@ properties:
- qcom,sc7280-smmu-500
- qcom,sc8180x-smmu-500
- qcom,sc8280xp-smmu-500
+ - qcom,shikra-smmu-500
- qcom,sm6115-smmu-500
- qcom,sm6125-smmu-500
- qcom,sm8150-smmu-500
@@ -543,6 +544,7 @@ allOf:
- enum:
- qcom,milos-smmu-500
- qcom,sar2130p-smmu-500
+ - qcom,shikra-smmu-500
- qcom,sm8550-smmu-500
- qcom,sm8650-smmu-500
- qcom,x1e80100-smmu-500
--
2.51.0
^ permalink raw reply related
* [PATCH v2 2/3] drm/msm/adreno: Add support for A704 GPU
From: Akhil P Oommen @ 2026-06-14 21:32 UTC (permalink / raw)
To: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD)
Cc: Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu, Akhil P Oommen,
Aditya Sherawat, Konrad Dybcio
In-Reply-To: <20260615-shikra-gpu-v2-0-2f2d1347c3fb@oss.qualcomm.com>
From: Aditya Sherawat <asherawa@qti.qualcomm.com>
Adreno A704 GPU found in Shikra is an IP reuse of A702 GPU with very
minimal changes. The only KMD facing difference is the chipid and the
zap firmware which is specified via devicetree.
Just add the new chipid to enable support for A704 GPU in Shikra.
Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
index 3e6f409d13a2..2de3ab010135 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
@@ -1454,7 +1454,7 @@ DECLARE_ADRENO_REGLIST_PIPE_LIST(a7xx_dyn_pwrup_reglist);
static const struct adreno_info a7xx_gpus[] = {
{
- .chip_ids = ADRENO_CHIP_IDS(0x07000200),
+ .chip_ids = ADRENO_CHIP_IDS(0x07000200, 0x07000400),
.family = ADRENO_6XX_GEN1, /* NOT a mistake! */
.fw = {
[ADRENO_FW_SQE] = "a702_sqe.fw",
--
2.51.0
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: display/msm/gpu: Add support for A704 GPU
From: Akhil P Oommen @ 2026-06-14 21:32 UTC (permalink / raw)
To: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD)
Cc: Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu, Akhil P Oommen,
Aditya Sherawat, Krzysztof Kozlowski
In-Reply-To: <20260615-shikra-gpu-v2-0-2f2d1347c3fb@oss.qualcomm.com>
From: Aditya Sherawat <asherawa@qti.qualcomm.com>
Adreno A704 GPU found Shikra SoC is an IP reuse of A702 GPU with very
minimal changes.
Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml
index dbbd8b814189..8e648bfb3b23 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
@@ -353,6 +353,7 @@ allOf:
- qcom,adreno-610.0
- qcom,adreno-619.1
- qcom,adreno-07000200
+ - qcom,adreno-07000400
then:
properties:
clocks:
--
2.51.0
^ permalink raw reply related
* [PATCH bpf-next] arm64: mm: Remove misleading pte_none() comment from ptep_try_set()
From: Tejun Heo @ 2026-06-14 21:02 UTC (permalink / raw)
To: catalin.marinas, will
Cc: ast, andrii, daniel, martin.lau, memxor, akpm, david, rppt,
arighi, emil, linux-arm-kernel, bpf, linux-mm, linux-kernel
This comment was thoughtlessly copied from the x86 version and doesn't
apply to arm64. Remove it.
Reported-by: Will Deacon <will@kernel.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
---
arch/arm64/include/asm/pgtable.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 3ce0f2a6cab6..b0213799ebc4 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -1830,10 +1830,6 @@ static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
return __ptep_get_and_clear(mm, addr, ptep);
}
-/*
- * Note: strictly-zero compare is narrower than pte_none(), but the gap is
- * harmless: a fresh kernel PTE has no software bits set.
- */
static inline bool ptep_try_set(pte_t *ptep, pte_t new_pte)
{
pteval_t old = 0;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2] Input: apple_z2 - bound the device-reported finger count
From: Dmitry Torokhov @ 2026-06-14 20:56 UTC (permalink / raw)
To: hexlabsecurity
Cc: Sasha Finkelstein, linux-kernel, Janne Grunau, linux-arm-kernel,
linux-input, Sven Peter, asahi, Neal Gompa
In-Reply-To: <20260613-b4-disp-4ebcbd68-v2-1-0161acfbd688@proton.me>
Hi Bryam,
On Sat, Jun 13, 2026 at 08:22:51PM -0500, Bryam Vargas via B4 Relay wrote:
> From: Bryam Vargas <hexlabsecurity@proton.me>
>
> apple_z2_parse_touches() takes the finger count from the touch
> controller's report and loops over that many fixed-size finger records
> without ever checking the count against the length of the report:
>
> nfingers = msg[APPLE_Z2_NUM_FINGERS_OFFSET];
> fingers = (struct apple_z2_finger *)(msg + APPLE_Z2_FINGERS_OFFSET);
> for (i = 0; i < nfingers; i++)
> /* read fingers[i] ... */
>
> msg points into the fixed 4000-byte z2->rx_buf and nfingers is a single
> device-supplied byte, so it can be as large as 255. A malicious,
> malfunctioning or counterfeit controller (or an interposer on the SPI
> bus) can report a large finger count in a short packet, making the loop
> read up to 255 * sizeof(struct apple_z2_finger) bytes starting 24 bytes
> into msg -- far past the 4000-byte buffer. This is a controller-driven
> heap out-of-bounds read, and the finger fields that are read (position,
> pressure, touch and tool dimensions) are forwarded to userspace as input
> events, leaking adjacent kernel memory.
>
> Bound the device-reported count to the number of finger records the
> report actually carries.
As Sashiko mentioned, if we do not trust hardware to send valid data we
should also validate that packet size supplied by the device is
reasonable.
Also I wonder why would we want to report some of fingers in case when
device sends bogus number of contacts? I'd drop such packet (maybe
logging ratelimited or "once" message).
You can ignore Sahiko's comment about __free(kfree) not handling error
pointers.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: (subset) [PATCH v7 0/5] Add microchip sama7d65 SoC I3C support
From: Alexandre Belloni @ 2026-06-14 20:39 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, nicolas.ferre, claudiu.beznea,
linux, mturquette, sboyd, bmasney, aubin.constans, Ryan.Wanner,
romain.sioen, tytso, cristian.birsan, adrian.hunter, npitre,
linux-i3c, devicetree, linux-kernel, linux-arm-kernel, linux-clk,
Manikandan Muralidharan
In-Reply-To: <20260525092405.1514213-1-manikandan.m@microchip.com>
On Mon, 25 May 2026 14:54:00 +0530, Manikandan Muralidharan wrote:
> Add support for microchip sama7d65 SoC I3C master only IP which is
> based on mipi-i3c-hci from synopsys implementing version 1.0
> specification. The platform specific changes are integrated in the
> mipi-i3c-hci driver using existing quirks.
>
> I3C in master mode supports up to 12.5MHz, SDR mode data transfer in
> mixed bus mode (I2C and I3C target devices on same i3c bus).
>
> [...]
Applied, thanks!
[1/5] dt-bindings: i3c: mipi-i3c-hci: add Microchip SAMA7D65 compatible
https://git.kernel.org/i3c/c/9092105b87af
[3/5] i3c: mipi-i3c-hci: add microchip sama7d65 SoC compatible with the required quirk
https://git.kernel.org/i3c/c/efaa912ab0f1
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 1/8] mm: Add ptep_try_set() for lockless empty-slot installs
From: Tejun Heo @ 2026-06-14 20:29 UTC (permalink / raw)
To: Will Deacon
Cc: David Vernet, Andrea Righi, Changwoo Min, Alexei Starovoitov,
Andrii Nakryiko, Daniel Borkmann, Martin KaFai Lau,
Kumar Kartikeya Dwivedi, Peter Zijlstra, Catalin Marinas,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Andrew Morton, David Hildenbrand, Mike Rapoport, Emil Tsalapatis,
sched-ext, bpf, x86, linux-arm-kernel, linux-mm, linux-kernel
In-Reply-To: <ai50IpfcvBiTZ7Ss@willie-the-truck>
Hello,
On Sun, Jun 14, 2026 at 10:28:02AM +0100, Will Deacon wrote:
> > +/*
> > + * Note: strictly-zero compare is narrower than pte_none(), but the gap is
> > + * harmless: a fresh kernel PTE has no software bits set.
> > + */
>
> This comment really confused me :/
>
> What is a "fresh" kernel PTE and why do you specifically call out "software
> bits" if the CAS requires all 64 bits to be 0? Why is that narrower than
> pte_none() given that pte_none() for arm64 is:
>
> #define pte_none(pte) (!pte_val(pte))
Yeah, that's complete non-sense for arm. The comment is about x86's
pte_none() excluding DIRTY and ACCESSED due to an erratum when testing none
and how that doesn't matter here. This shouldn't have been copied to arm.
I'll send a patch to remove that.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Add bluetooth support to manta
From: Lukas Timmermann @ 2026-06-14 20:16 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alim Akhtar
Cc: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
Alexandre Marquet, Lukas Timmermann
Enable the bcm4330-bt device for manta boards on serial0.
Also adds the necessary pin definitions and interrupt handling for
wakeup.
Co-developed-by: Alexandre Marquet <tb@a-marquet.fr>
Signed-off-by: Alexandre Marquet <tb@a-marquet.fr>
Co-developed-by: Lukas Timmermann <linux@timmermann.space>
Signed-off-by: Lukas Timmermann <linux@timmermann.space>
---
Changes in v2:
- Sorted DCO chain (@krzk)
- Link to v1: https://patch.msgid.link/20260408-manta-bluetooth-v1-1-b7658e78359a@timmermann.space
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Alim Akhtar <alim.akhtar@samsung.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/boot/dts/samsung/exynos5250-manta.dts | 41 +++++++++++++++++++++++++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/samsung/exynos5250-manta.dts b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
index 24a27b342227..76d3657eb22f 100644
--- a/arch/arm/boot/dts/samsung/exynos5250-manta.dts
+++ b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
@@ -461,6 +461,13 @@ acc_int: acc-int-pins {
samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
};
+ bt_host_wakeup: bt-host-wakeup-pins {
+ samsung,pins = "gpx2-6";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
+ };
+
max77686_irq: max77686-irq-pins {
samsung,pins = "gpx0-2";
samsung,pin-function = <EXYNOS_PIN_FUNC_F>;
@@ -488,6 +495,20 @@ bh1721fvc_reset: bh1721fvc-reset-pins {
samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
};
+ bt_reg_on: bt-reg-on-pins {
+ samsung,pins = "gph0-0";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-con-pdn = <EXYNOS_PIN_PDN_PREV>;
+ samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ bt_wake: bt-wake-pins {
+ samsung,pins = "gph1-3";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-con-pdn = <EXYNOS_PIN_PDN_PREV>;
+ samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>;
+ };
+
msense_reset: msense-reset-pins {
samsung,pins = "gpg2-0";
samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
@@ -536,7 +557,25 @@ &sd1_cmd {
/* Bluetooth */
&serial_0 {
- status = "disabled";
+ pinctrl-0 = <&uart0_data &uart0_fctl>;
+ pinctrl-names = "default";
+
+ bluetooth {
+ compatible = "brcm,bcm4330-bt";
+
+ pinctrl-0 = <&bt_reg_on &bt_wake &bt_host_wakeup>;
+ pinctrl-names = "default";
+
+ shutdown-gpios = <&gph0 0 GPIO_ACTIVE_HIGH>;
+ device-wakeup-gpios = <&gph1 3 GPIO_ACTIVE_HIGH>;
+
+ interrupt-parent = <&gpx2>;
+ interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "host-wakeup";
+
+ clocks = <&max77686 MAX77686_CLK_PMIC>;
+ clock-names = "lpo";
+ };
};
/* GPS */
---
base-commit: e5f7e05a699f41275d6380c497293446034bc8af
change-id: 20260404-manta-bluetooth-836133028bb6
Best regards,
--
Lukas Timmermann <linux@timmermann.space>
^ permalink raw reply related
* Re: [PATCH RFC 3/4] printk: nbcon: move printk_delay to console emiting code
From: Andrew Murray @ 2026-06-14 19:17 UTC (permalink / raw)
To: Petr Mladek
Cc: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Andrew Morton,
Sebastian Andrzej Siewior, Clark Williams, Randy Dunlap,
Linus Torvalds, linux-doc, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, linux-rt-devel
In-Reply-To: <aibe12WcrLxVWTez@pathway.suse.cz>
On Mon, 8 Jun 2026 at 16:25, Petr Mladek <pmladek@suse.com> wrote:
>
> On Mon 2026-06-01 00:17:39, Andrew Murray wrote:
> > The printk_delay and boot_delay features are helpful for debugging
> > as kernel output can be slowed down during boot allowing messages to
> > be seen before scrolling off the screen, or to correlate timing between
> > some physical event and console output.
> >
> > However, since the introduction of nbcon and the legacy printer thread
> > for PREEMPT_RT kernels, printk records are now emited to the console
> > asynchronously to the caller of printk. Thus, any printk delay added by
> > boot_delay/printk_delay continues to slow down the calling process but
> > may not have any impact to the rate in which records are emited to the
> > console.
> >
> > Let's address this by moving the printk delay from the calling code
> > to the console emiting code instead. Whilst this ensures that delays
> > are still observed (especially for slower consoles), it doesn't improve
> > the use-case of using boot_delay/printk_delay to correlate timings
> > between physical events and console output.
> >
> > --- a/include/linux/printk.h
> > +++ b/include/linux/printk.h
>
> The declaration is needed just inside kernel/printk/ directory.
> It should better be done via kernel/printk/internal.h
>
> > @@ -209,6 +209,7 @@ extern bool nbcon_device_try_acquire(struct console *con);
> > extern void nbcon_device_release(struct console *con);
> > void nbcon_atomic_flush_unsafe(void);
> > bool pr_flush(int timeout_ms, bool reset_on_progress);
> > +void printk_delay(bool use_atomic);
> > #else
> > static inline __printf(1, 0)
> > int vprintk(const char *s, va_list args)
> > @@ -326,6 +327,9 @@ static inline bool pr_flush(int timeout_ms, bool reset_on_progress)
> > {
> > return true;
> > }
> > +static inline void printk_delay(bool use_atomic)
> > +{
> > +}
> >
> > #endif
> >
> > diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
> > index d7044a7a214bdd4537a5e20d876d99bc3ffe8b3a..a507a2fed5bf4366e24330f763b842a698ecf6f7 100644
> > --- a/kernel/printk/nbcon.c
> > +++ b/kernel/printk/nbcon.c
> > @@ -1267,11 +1267,16 @@ static int nbcon_kthread_func(void *__console)
> >
> > con_flags = console_srcu_read_flags(con);
> >
> > + wctxt.len = 0;
> > +
> > if (console_is_usable(con, con_flags, false))
> > backlog = nbcon_emit_one(&wctxt, false);
> >
> > console_srcu_read_unlock(cookie);
> >
> > + if (backlog && wctxt.len > 0)
>
> Heh, this is tricky. It might probably work but it is not guarantted
> by design.
>
> The "backlog" name is a bit misleading. The value is basically
> wctxt.ctxt.backlog. The real meaning is that printk_get_next_message()
> was able to read a message. It means that there _was_ a backlog.
> But it is not clear whether there are still pending messages or not.
>
> Also it is not clear that whether the message was pushed to the
> console or not. It might have been supressed in which case
> (wctxt.len == 0). But it might also be emitted only partially
> when a higher priority context took over the console context
> ownership.
>
> I would prefer to explicitely set some flag when
> nbcon_emit_next_record() really called con->write*().
> See below.
>
> > + printk_delay(false);
> > +
> > cond_resched();
> >
> > } while (backlog);
> > @@ -1525,6 +1530,8 @@ bool nbcon_legacy_emit_next_record(struct console *con, bool *handover,
> > }
> >
> > progress = nbcon_emit_one(&wctxt, use_atomic);
> > + if (progress && wctxt.len > 0)
>
> Same here.
>
> > + printk_delay(use_atomic);
> >
> > if (use_atomic) {
> > start_critical_timings();
> > @@ -1584,6 +1591,8 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> > if (!nbcon_context_try_acquire(ctxt, false))
> > return -EPERM;
> >
> > + wctxt.len = 0;
> > +
> > /*
> > * nbcon_emit_next_record() returns false when
> > * the console was handed over or taken over.
> > @@ -1595,7 +1604,9 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> > nbcon_context_release(ctxt);
> > }
> >
> > - if (!ctxt->backlog) {
> > + if (ctxt->backlog && wctxt.len > 0) {
> > + printk_delay(true);
> > + } else {
>
> This changes the semantic. The original code call this when
> no message was read. The new code would call this path also
> when the output was suppressed. It would probably work.
> But still.
>
> > /* Are there reserved but not yet finalized records? */
> > if (nbcon_seq_read(con) < stop_seq)
> > err = -ENOENT;
>
>
> As mentioned above, I would add a flag which would be set when
> con->write*() was called.
>
> It modifies the type of unsafe_takeover in struct nbcon_write_context.
> But it actually makes it more compatible with struct nbcon_state.
>
> My proposal (on top of this patch):
>
> diff --git a/include/linux/console.h b/include/linux/console.h
> index 5520e4477ad7..5a86942e55ef 100644
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -290,6 +290,7 @@ struct nbcon_context {
> * @outbuf: Pointer to the text buffer for output
> * @len: Length to write
> * @unsafe_takeover: If a hostile takeover in an unsafe state has occurred
> + * @emitted: The write context tried to emit the message. Might be incomplete.
> * @cpu: CPU on which the message was generated
> * @pid: PID of the task that generated the message
> * @comm: Name of the task that generated the message
> @@ -298,7 +299,8 @@ struct nbcon_write_context {
> struct nbcon_context __private ctxt;
> char *outbuf;
> unsigned int len;
> - bool unsafe_takeover;
> + unsigned char unsafe_takeover : 1;
> + unsigned char emitted : 1
> #ifdef CONFIG_PRINTK_EXECUTION_CTX
> int cpu;
> pid_t pid;
> diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
> index a507a2fed5bf..060534becefc 100644
> --- a/kernel/printk/nbcon.c
> +++ b/kernel/printk/nbcon.c
> @@ -1069,6 +1069,9 @@ static bool nbcon_emit_next_record(struct nbcon_write_context *wctxt, bool use_a
> else
> con->write_thread(con, wctxt);
>
> + /* Tried to emit something. Might be incomplete. */
> + wctxt.emitted = 1;
> +
> if (!wctxt->outbuf) {
> /*
> * Ownership was lost and reacquired by the driver. Handle it
> @@ -1267,14 +1270,14 @@ static int nbcon_kthread_func(void *__console)
>
> con_flags = console_srcu_read_flags(con);
>
> - wctxt.len = 0;
> + wctxt.emitted = 0;
>
> if (console_is_usable(con, con_flags, false))
> backlog = nbcon_emit_one(&wctxt, false);
>
> console_srcu_read_unlock(cookie);
>
> - if (backlog && wctxt.len > 0)
> + if (wctxt.emitted)
I think this (and the others) should be:
if (backlog && wctxt.emitted)
Otherwise you may delay in instances where con->write_* was called but
ownership is lost, for example if write_thread calls
nbcon_enter_unsafe which returns false and doesn't write anything. I
assume that when ownership is lost, the record will be reattempted in
the future, thus it would presumably make sense to delay upon
successful emit, rather than each/any partial attempt? Is that
understanding correct?
Thanks,
Andrew Murray
>
> printk_delay(false);
>
> cond_resched();
> @@ -1530,7 +1533,7 @@ bool nbcon_legacy_emit_next_record(struct console *con, bool *handover,
> }
>
> progress = nbcon_emit_one(&wctxt, use_atomic);
> - if (progress && wctxt.len > 0)
> + if (wctxt.emitted)
> printk_delay(use_atomic);
>
> if (use_atomic) {
> @@ -1591,7 +1594,7 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> if (!nbcon_context_try_acquire(ctxt, false))
> return -EPERM;
>
> - wctxt.len = 0;
> + wctxt.emitted = 0;
>
> /*
> * nbcon_emit_next_record() returns false when
> @@ -1604,9 +1607,10 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> nbcon_context_release(ctxt);
> }
>
> - if (ctxt->backlog && wctxt.len > 0) {
> + if (wctxt.emitted)
> printk_delay(true);
> - } else {
> +
> + if (!ctxt->backlog) {
> /* Are there reserved but not yet finalized records? */
> if (nbcon_seq_read(con) < stop_seq)
> err = -ENOENT;
^ permalink raw reply
* [PATCH] arm64: errata: Handle Apple WFI State Loss
From: Yureka Lilian @ 2026-06-14 18:42 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Yureka Lilian, linux-arm-kernel, linux-kernel, sven, j, k,
towinchenmi
Apple Silicon CPUs can lose register state in WFI, leading to crashes
in the idle loop early in the boot process.
This applies to any previous Apple Silicon CPUs too, but is worked
around by configuring the WFI mode in SYS_IMP_APL_CYC_OVRD sysreg
during m1n1's chickens setup.
This workaround no longer exists since M4.
Add a workaround capability for replacing wfi and wfit with nop, and
an erratum to enable it on the affected CPUs if the workaround using the
sysreg is not already applied. Leave the decision whether the sysreg
workaround can be used up to the earlier parts of the boot chain which
already configure the Apple Silicon chicken bits.
This alternative has to be applied in early boot, since otherwise some
cores might enter the idle loop before apply_alternatives_all() is run.
Reviewed-by: Sasha Finkelstein <k@chaosmail.tech>
Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
---
Tested on M4 and M4 Pro (which now sometimes nondeterministically
crash later during boot).
Successfully booted on M3 Max with the SYS_IMP_APL_CYC_OVRD
workaround disabled in the bootloader, as well as A18 Pro (which,
like M4 / M4 Pro, doesn't have SYS_IMP_APL_CYC_OVRD).
There is probably a better place for the SYS_IMP_APL_CYC_OVRD
defines, which I currently put in the middle of cpu_errata.c, but I
wouldn't know where.
---
arch/arm64/Kconfig | 12 ++++++++++++
arch/arm64/include/asm/barrier.h | 19 ++++++++++++++++---
arch/arm64/kernel/cpu_errata.c | 19 +++++++++++++++++++
arch/arm64/tools/cpucaps | 1 +
4 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b3afe0688919..8c8ff069856f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -453,6 +453,18 @@ config AMPERE_ERRATUM_AC04_CPU_23
If unsure, say Y.
+config APPLE_ERRATUM_WFI_STATE
+ bool "Apple Silicon: WFI loses state"
+ default y
+ help
+ This option adds an alternative code sequence to work around some
+ Apple Silicon CPUs losing register state during wfi and wfit
+ instructions.
+
+ As a workaround, the wfi and wfit instructions are replaced with nop
+ operations via the alternative framework if an affected CPU is
+ detected.
+
config ARM64_WORKAROUND_CLEAN_CACHE
bool
diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
index 9495c4441a46..f72eddc7c434 100644
--- a/arch/arm64/include/asm/barrier.h
+++ b/arch/arm64/include/asm/barrier.h
@@ -20,9 +20,22 @@
#define wfe() asm volatile("wfe" : : : "memory")
#define wfet(val) asm volatile("msr s0_3_c1_c0_0, %0" \
: : "r" (val) : "memory")
-#define wfi() asm volatile("wfi" : : : "memory")
-#define wfit(val) asm volatile("msr s0_3_c1_c0_1, %0" \
- : : "r" (val) : "memory")
+#define wfi() \
+ do { \
+ asm volatile( \
+ ALTERNATIVE("wfi", \
+ "nop", \
+ ARM64_WORKAROUND_WFI_STATE) \
+ : : : "memory"); \
+ } while (0)
+#define wfit(val) \
+ do { \
+ asm volatile( \
+ ALTERNATIVE("msr s0_3_c1_c0_1, %0", \
+ "nop", \
+ ARM64_WORKAROUND_WFI_STATE) \
+ : : "r" (val) : "memory"); \
+ } while (0)
#define isb() asm volatile("isb" : : : "memory")
#define dmb(opt) asm volatile("dmb " #opt : : : "memory")
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 1995e1198648..04c8c312b27d 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -309,6 +309,17 @@ static void cpu_enable_impdef_pmuv3_traps(const struct arm64_cpu_capabilities *_
sysreg_clear_set_s(SYS_HACR_EL2, 0, BIT(56));
}
+#ifdef CONFIG_APPLE_ERRATUM_WFI_STATE
+static bool has_apple_erratum_wfi_state(const struct arm64_cpu_capabilities *entry, int scope)
+{
+#define SYS_IMP_APL_CYC_OVRD sys_reg(3, 5, 15, 5, 0)
+#define CYC_OVRD_WFI_MODE_MASK GENMASK(26, 24)
+ if (read_cpuid_implementor() != ARM_CPU_IMP_APPLE)
+ return false;
+ return FIELD_GET(CYC_OVRD_WFI_MODE_MASK, read_sysreg_s(SYS_IMP_APL_CYC_OVRD)) != 2;
+}
+#endif
+
#ifdef CONFIG_ARM64_WORKAROUND_REPEAT_TLBI
static const struct arm64_cpu_capabilities arm64_repeat_tlbi_list[] = {
#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1009
@@ -1009,6 +1020,14 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
.matches = has_impdef_pmuv3,
.cpu_enable = cpu_enable_impdef_pmuv3_traps,
},
+#ifdef CONFIG_APPLE_ERRATUM_WFI_STATE
+ {
+ .desc = "Apple WFI loses state",
+ .capability = ARM64_WORKAROUND_WFI_STATE,
+ .type = ARM64_CPUCAP_SCOPE_BOOT_CPU | ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU,
+ .matches = has_apple_erratum_wfi_state,
+ },
+#endif
{
}
};
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index 9b85a84f6fd4..bbf8c15d79b0 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -128,3 +128,4 @@ WORKAROUND_REPEAT_TLBI
WORKAROUND_SPECULATIVE_AT
WORKAROUND_SPECULATIVE_SSBS
WORKAROUND_SPECULATIVE_UNPRIV_LOAD
+WORKAROUND_WFI_STATE
---
base-commit: c425609d6ac4012c8bbf01ec2e10e801b1923a7b
change-id: 20260614-wfi-erratum-7a9f305f601f
Best regards,
--
Yureka Lilian <yureka@cyberchaos.dev>
^ permalink raw reply related
* [PATCH 06/22] media: platform: stm32-csi: Add missing media_entity_cleanup()
From: Biren Pandya @ 2026-06-14 16:55 UTC (permalink / raw)
To: linux-media, mchehab
Cc: Biren Pandya, Alain Volmat, Maxime Coquelin, Alexandre Torgue,
Hans Verkuil, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260614165630.3896-1-birenpandya@gmail.com>
Fixes: dcb0f4c16be5 ("media: stm32: csi: addition of the STM32 CSI driver")
Signed-off-by: Biren Pandya <birenpandya@gmail.com>
---
drivers/media/platform/st/stm32/stm32-csi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/st/stm32/stm32-csi.c b/drivers/media/platform/st/stm32/stm32-csi.c
index fd2b6dfbd44c..0847fd347d56 100644
--- a/drivers/media/platform/st/stm32/stm32-csi.c
+++ b/drivers/media/platform/st/stm32/stm32-csi.c
@@ -1060,6 +1060,7 @@ static int stm32_csi_probe(struct platform_device *pdev)
err_cleanup:
v4l2_async_nf_cleanup(&csidev->notifier);
+ media_entity_cleanup(&csidev->sd.entity);
return ret;
}
@@ -1068,6 +1069,7 @@ static void stm32_csi_remove(struct platform_device *pdev)
struct stm32_csi_dev *csidev = platform_get_drvdata(pdev);
v4l2_async_unregister_subdev(&csidev->sd);
+ media_entity_cleanup(&csidev->sd.entity);
pm_runtime_disable(&pdev->dev);
}
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v2 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Jonathan Cameron @ 2026-06-14 17:22 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay
Cc: rva333, David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260609-mt6323-adc-v2-2-aa93a22309f9@protonmail.com>
On Tue, 09 Jun 2026 16:31:59 +0300
Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:
> From: Roman Vivchar <rva333@protonmail.com>
>
> The mt6323 AUXADC is a 15-bit ADC used for system monitoring. This driver
> provides support for reading various channels including battery and
> charger voltages, battery and chip temperature, current sensing and
> accessory detection.
>
> Add a driver for the AUXADC found in the MediaTek mt6323 PMIC.
>
> Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
Make sure to take a look at:
https://sashiko.dev/#/patchset/20260609-mt6323-adc-v2-0-aa93a22309f9%40protonmail.com
A few minor other comments inline.
> diff --git a/drivers/iio/adc/mt6323-auxadc.c b/drivers/iio/adc/mt6323-auxadc.c
> new file mode 100644
> index 000000000000..f2cef989d3ce
> --- /dev/null
> +++ b/drivers/iio/adc/mt6323-auxadc.c
> +
> +#define MTK_PMIC_IIO_CHAN(_name, _chan, _addr) \
> +{ \
> + .type = IIO_VOLTAGE, \
> + .indexed = 1, \
> + .channel = _chan, \
> + .address = _addr, \
> + .datasheet_name = __stringify(_name), \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_SCALE), \
> +}
> +
> +static const struct iio_chan_spec mt6323_auxadc_channels[] = {
> + MTK_PMIC_IIO_CHAN(baton2, MT6323_AUXADC_BATON2, MT6323_AUXADC_ADC6),
> + MTK_PMIC_IIO_CHAN(ch6, MT6323_AUXADC_CH6, MT6323_AUXADC_ADC11),
> + MTK_PMIC_IIO_CHAN(bat_temp, MT6323_AUXADC_BAT_TEMP, MT6323_AUXADC_ADC5),
Reasonable query from Sashiko on why temperature channels are presented as voltages.
If for some reason that is the right choice, then maybe a comment here.
> + MTK_PMIC_IIO_CHAN(chip_temp, MT6323_AUXADC_CHIP_TEMP, MT6323_AUXADC_ADC4),
> + MTK_PMIC_IIO_CHAN(vcdt, MT6323_AUXADC_VCDT, MT6323_AUXADC_ADC2),
> + MTK_PMIC_IIO_CHAN(baton1, MT6323_AUXADC_BATON1, MT6323_AUXADC_ADC3),
> + MTK_PMIC_IIO_CHAN(isense, MT6323_AUXADC_ISENSE, MT6323_AUXADC_ADC1),
> + MTK_PMIC_IIO_CHAN(batsns, MT6323_AUXADC_BATSNS, MT6323_AUXADC_ADC0),
> + MTK_PMIC_IIO_CHAN(accdet, MT6323_AUXADC_ACCDET, MT6323_AUXADC_ADC7),
> +};
> +
> +/*
> + * The MediaTek MT6323 (as well as a lot of other PMICs) has the following hierarchy:
> + * PMIC AUXADC <- PMIC MFD <- SoC PWRAP (wrapper for PWRAP FSM)
> + *
> + * Therefore, PWRAP regmap should be obtained using dev->parent->parent.
> + */
> +struct mt6323_auxadc {
> + struct regmap *regmap;
> + struct mutex lock;
Locks should always have a comment on what data they are protecting.
I think this one is about protecting the state of a device during a channel read
by serializing those reads.
> +};
>
> +
> +static int mt6323_auxadc_request(struct mt6323_auxadc *auxadc,
> + unsigned long channel)
> +{
> + struct regmap *map = auxadc->regmap;
> + int ret;
> +
> + ret = regmap_set_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
> + if (ret)
> + return ret;
> +
> + return regmap_set_bits(map, MT6323_AUXADC_CON22, BIT(channel));
I'm not sure whether the sashiko question on this is valid or not. Make sure to take
a look.
https://sashiko.dev/#/patchset/20260609-mt6323-adc-v2-0-aa93a22309f9%40protonmail.com
You may have carefully selected the numbering so the channel numbering matches
the bits in this register. If so, it is probably worth a comment in the header
to provide a cross reference. No idea if Sashiko will notice that, but at least
humans should!
> +}
> +
> +
> +static int mt6323_auxadc_read_raw(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int *val, int *val2, long mask)
> +{
> + struct mt6323_auxadc *auxadc = iio_priv(indio_dev);
> + int ret, mult;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE:
> + if (chan->channel == MT6323_AUXADC_ISENSE ||
> + chan->channel == MT6323_AUXADC_BATSNS)
> + mult = 4;
> + else
> + mult = 1;
> +
> + /* 1800mV full range with 15-bit resolution. */
> + *val = mult * 1800;
> + *val2 = 15;
> +
> + return IIO_VAL_FRACTIONAL_LOG2;
> + case IIO_CHAN_INFO_RAW:
What Andy suggested here is the preferred path in IIO at least.
Mainly because it reduced indent without hurting readability.
Just be careful to define the scope with { }
> + scoped_guard(mutex, &auxadc->lock) {
> + ret = mt6323_auxadc_prepare_channel(auxadc);
> + if (ret)
> + return ret;
> +
> + ret = mt6323_auxadc_request(auxadc, chan->channel);
> + if (ret)
> + return ret;
> +
> + /* Hardware limitation: the AUXADC needs a delay to become ready. */
> + fsleep(300);
> +
> + ret = mt6323_auxadc_read(auxadc, chan, val);
> +
> + if (mt6323_auxadc_release(auxadc, chan->channel))
> + dev_err(&indio_dev->dev,
> + "failed to release channel %d\n", chan->channel);
> +
> + if (ret)
> + return ret;
> + }
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> +}
^ permalink raw reply
* Re: [PATCH v2 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Jonathan Cameron @ 2026-06-14 17:11 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Roman Vivchar, David Lechner, Nuno Sá, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <aihqeLKHC3PP436t@black.igk.intel.com>
On Tue, 9 Jun 2026 21:33:12 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Tue, Jun 09, 2026 at 07:15:42PM +0000, Roman Vivchar wrote:
> > On Tuesday, June 9th, 2026 at 9:30 PM, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > > On Tue, Jun 09, 2026 at 04:31:59PM +0300, Roman Vivchar via B4 Relay wrote:
>
> ...
>
> > > > + case IIO_CHAN_INFO_RAW:
> > > > + scoped_guard(mutex, &auxadc->lock) {
> > >
> > > I'm wondering why we haven't moved to guard()() here
> >
> > The compiler would complain about 'cannot jump from switch statement'
> > due to default case.
See the brackets Andy suggested. That error is what you get without specifically
defining the scope.
>
> I am not sure I follow. See the examples in the existing drivers. They are
> warning clean in that sense.
>
^ permalink raw reply
* [PATCH 14/22] media: platform: cfe: Add missing media_entity_cleanup()
From: Biren Pandya @ 2026-06-14 16:55 UTC (permalink / raw)
To: linux-media, mchehab
Cc: Biren Pandya, Tomi Valkeinen, Raspberry Pi Kernel Maintenance,
Florian Fainelli, Broadcom internal kernel review list,
Sakari Ailus, Naushir Patuck, linux-rpi-kernel, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260614165630.3896-1-birenpandya@gmail.com>
Fixes: 6edb685abb2a ("media: raspberrypi: Add support for RP1-CFE")
Signed-off-by: Biren Pandya <birenpandya@gmail.com>
---
drivers/media/platform/raspberrypi/rp1-cfe/cfe.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c b/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c
index 8375ed3e97b9..17c523d32db7 100644
--- a/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c
+++ b/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c
@@ -2039,6 +2039,7 @@ static int cfe_register_node(struct cfe_device *cfe, int id)
if (ret) {
cfe_err(cfe, "Unable to register video device %s\n",
vdev->name);
+ media_entity_cleanup(&vdev->entity);
return ret;
}
@@ -2064,6 +2065,7 @@ static void cfe_unregister_nodes(struct cfe_device *cfe)
if (check_state(cfe, NODE_REGISTERED, i)) {
clear_state(cfe, NODE_REGISTERED, i);
video_unregister_device(&node->video_dev);
+ media_entity_cleanup(&node->video_dev.entity);
}
}
}
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH 07/22] media: platform: sun4i_csi: Add missing media_entity_cleanup()
From: Biren Pandya @ 2026-06-14 16:55 UTC (permalink / raw)
To: linux-media, mchehab
Cc: Biren Pandya, Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Sakari Ailus, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <20260614165630.3896-1-birenpandya@gmail.com>
Fixes: 577bbf23b758 ("media: sunxi: Add A10 CSI driver")
Signed-off-by: Biren Pandya <birenpandya@gmail.com>
---
drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c b/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c
index e53a07b770b7..f50d97ca795f 100644
--- a/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c
+++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c
@@ -242,11 +242,11 @@ static int sun4i_csi_probe(struct platform_device *pdev)
vdev->entity.ops = &sun4i_csi_video_entity_ops;
ret = media_entity_pads_init(&vdev->entity, 1, &csi->vdev_pad);
if (ret < 0)
- return ret;
+ goto err_clean_subdev_entity;
ret = sun4i_csi_dma_register(csi, irq);
if (ret)
- goto err_clean_pad;
+ goto err_clean_vdev_entity;
ret = sun4i_csi_notifier_init(csi);
if (ret)
@@ -266,6 +266,10 @@ static int sun4i_csi_probe(struct platform_device *pdev)
media_device_unregister(&csi->mdev);
sun4i_csi_dma_unregister(csi);
+err_clean_vdev_entity:
+ media_entity_cleanup(&vdev->entity);
+err_clean_subdev_entity:
+ media_entity_cleanup(&subdev->entity);
err_clean_pad:
media_device_cleanup(&csi->mdev);
@@ -282,6 +286,8 @@ static void sun4i_csi_remove(struct platform_device *pdev)
vb2_video_unregister_device(&csi->vdev);
media_device_unregister(&csi->mdev);
sun4i_csi_dma_unregister(csi);
+ media_entity_cleanup(&csi->subdev.entity);
+ media_entity_cleanup(&csi->vdev.entity);
media_device_cleanup(&csi->mdev);
}
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH 7/7] KVM: arm64: Set IL in fake ESR for pKVM memory sharing exit
From: Fuad Tabba @ 2026-06-14 16:33 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, linux-arm-kernel, kvmarm,
linux-kernel
Cc: Catalin Marinas, Will Deacon, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Vincent Donnefort, Sascha Bischoff,
tabba
In-Reply-To: <20260614163336.3490925-1-tabba@google.com>
__pkvm_memshare_page_req() constructs a fake DABT ESR_EL2 to exit to
the host without setting IL. The ESR has ISV=0, so IL must be 1 per the
architecture. The host does not read IL on this path, but the
constructed syndrome should still be architecturally valid.
Set ESR_ELx_IL.
Fixes: 03313efed5e2 ("KVM: arm64: Implement the MEM_SHARE hypercall for protected VMs")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/hyp/nvhe/pkvm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index eb1c10120f9f..c982a3a04c37 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -1054,7 +1054,8 @@ static u64 __pkvm_memshare_page_req(struct kvm_vcpu *vcpu, u64 ipa)
/* Fake up a data abort (level 3 translation fault on write) */
vcpu->arch.fault.esr_el2 = (ESR_ELx_EC_DABT_LOW << ESR_ELx_EC_SHIFT) |
- ESR_ELx_WNR | ESR_ELx_FSC_FAULT |
+ ESR_ELx_IL | ESR_ELx_WNR |
+ ESR_ELx_FSC_FAULT |
FIELD_PREP(ESR_ELx_FSC_LEVEL, 3);
/* Shuffle the IPA around into the HPFAR */
--
2.54.0.1136.gdb2ca164c4-goog
^ 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