* [PATCH v8 13/15] arm64: dts: qcom: sdm845-lg-common: Add camera flash
From: Paul Sajna @ 2026-04-02 6:41 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Heidelberg
Cc: Paul Sajna, linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Amir Dahan, Christopher Brown,
Konrad Dybcio
In-Reply-To: <20260401-judyln-dts-v8-0-cf13065e52ab@postmarketos.org>
Camera doesn't work yet (imx351), but we can use the flash as a flashlight.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
---
arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
index 71d070619ad7..9d82961d527e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
@@ -496,6 +496,19 @@ &pm8998_resin {
status = "okay";
};
+&pmi8998_flash {
+ status = "okay";
+
+ led-0 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <1>, <2>;
+ led-max-microamp = <100000>;
+ flash-max-microamp = <500000>;
+ flash-max-timeout-us = <500000>;
+ };
+};
+
&pmi8998_lpg {
status = "okay";
--
2.53.0
^ permalink raw reply related
* [PATCH v8 14/15] arm64: dts: qcom: sdm845-lg-common: Change ipa gsi-loader to 'self', add memory-region
From: Paul Sajna @ 2026-04-02 6:42 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Heidelberg
Cc: Paul Sajna, linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Amir Dahan, Christopher Brown,
Konrad Dybcio
In-Reply-To: <20260401-judyln-dts-v8-0-cf13065e52ab@postmarketos.org>
The modem firmware for this device doesn't preload the IPA firmware
and requires the OS handles that instead. Set qcom,gsi-loader = "self"
to reflect that.
Ensure the ipa uses the correct memory.
ipa 1e40000.ipa: channel 4 limited to 256 TREs
ipa 1e40000.ipa: IPA driver initialized
ipa 1e40000.ipa: received modem starting event
ipa 1e40000.ipa: received modem running event
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
---
arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
index 9d82961d527e..85dc4468b6c4 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
@@ -473,7 +473,9 @@ &gpu {
};
&ipa {
- qcom,gsi-loader = "modem";
+ qcom,gsi-loader = "self";
+ memory-region = <&ipa_fw_mem>;
+
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 0/5] Exynos850 APM-to-AP mailbox support
From: Krzysztof Kozlowski @ 2026-04-02 6:43 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Sam Protsenko,
Michael Turquette, Stephen Boyd, Rob Herring, Conor Dooley,
Tudor Ambarus, Jassi Brar, Krzysztof Kozlowski, Peter Griffin,
linux-samsung-soc, linux-arm-kernel, linux-clk, devicetree,
linux-kernel
In-Reply-To: <DHIB5E66SP7A.110YA5R1OOQHS@linaro.org>
On 02/04/2026 04:19, Alexey Klimov wrote:
> On Sat Mar 21, 2026 at 10:44 AM GMT, Krzysztof Kozlowski wrote:
>> On Fri, Mar 20, 2026 at 09:15:12PM +0000, Alexey Klimov wrote:
>>> Hi all,
>>>
>>> This patch series introduces support for the APM-to-AP mailbox on the
>>> Exynos850 SoC. This mailbox is required for communicating with the APM
>>> co-processor using ACPM.
>>>
>>> The Exynos850 mailbox operates similarly to the existing gs101
>>> implementation, but the register offsets and IRQ mask bits differ.
>>> This series abstracts these differences into platform-specific data
>>> structures matched via the device tree.
>>>
>>> Also, it requires APM-to-AP mailbox clock in CMU_APM block.
>>>
>>> In theory this can be split into two series with correct dependecies:
>>> device tree node requires clock changes to be merged. The suggestion
>>> is to let this go through Samsung SoC tree with corresponding acks
>>> if it is okay.
>>
>> I don't understand why this cannot be split into two seris
>> *practically*. What is exactly the dependency between mailbox and DTS,
>> that it had to be combined here?
>
> Do you suggest to send 3 single patches with proper dependencies
> description? DT bindings change first, then mailbox change that specifically
> depends on dt-bindings change and then dts update (which will depend on both)?
>
> I thought that mbox driver change depends implicitly on bindings update?
Please don't answer to a question with a question. Actually three
questions. If you cannot give argument why there is a dependency, feels
to me like you send something you do not understand.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v8 15/15] arm64: dts: qcom: sdm845-lg-{judyln, judyp}: Reference memory region in fb
From: Paul Sajna @ 2026-04-02 6:43 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Heidelberg
Cc: Paul Sajna, linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Amir Dahan, Christopher Brown
In-Reply-To: <20260401-judyln-dts-v8-0-cf13065e52ab@postmarketos.org>
To prevent duplicating the framebuffer address and size point out the
existing framebuffer memory region instead of specifying the address
manually.
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
---
arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 3 +--
arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts | 4 ++--
arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts | 4 ++--
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
index 85dc4468b6c4..86cf4eb44084 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
@@ -98,8 +98,7 @@ spss_mem: memory@99000000 {
no-map;
};
- /* Framebuffer region */
- memory@9d400000 {
+ framebuffer_mem: memory@9d400000 {
reg = <0x0 0x9d400000 0x0 0x2400000>;
no-map;
};
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
index adf41aa0146a..349faa123ff1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
@@ -14,9 +14,9 @@ / {
compatible = "lg,judyln", "qcom,sdm845";
chosen {
- framebuffer@9d400000 {
+ framebuffer {
compatible = "simple-framebuffer";
- reg = <0x0 0x9d400000 0x0 (1440 * 3120 * 4)>;
+ memory-region = <&framebuffer_mem>;
width = <1440>;
height = <3120>;
stride = <(1440 * 4)>;
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts b/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts
index d244ebdd17be..44e762f78e95 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts
@@ -14,9 +14,9 @@ / {
compatible = "lg,judyp", "qcom,sdm845";
chosen {
- framebuffer@9d400000 {
+ framebuffer {
compatible = "simple-framebuffer";
- reg = <0x0 0x9d400000 0x0 (1440 * 2880 * 4)>;
+ memory-region = <&framebuffer_mem>;
width = <1440>;
height = <2880>;
stride = <(1440 * 4)>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 5/6] dma-buf: heaps: Add Coherent heap to dmabuf heaps
From: Marek Szyprowski @ 2026-04-02 6:52 UTC (permalink / raw)
To: Maxime Ripard, Andrew Davis
Cc: Albert Esteve, Sumit Semwal, Benjamin Gaignard, Brian Starkey,
John Stultz, T.J. Mercier, Christian König, Robin Murphy,
Rob Herring, Saravana Kannan, linux-kernel, linux-media,
dri-devel, linaro-mm-sig, iommu, devicetree, echanude
In-Reply-To: <20260316-cherubic-eel-of-philosophy-10ef2b@houat>
On 16.03.2026 13:08, Maxime Ripard wrote:
> On Wed, Mar 11, 2026 at 08:18:28AM -0500, Andrew Davis wrote:
>> On 3/11/26 5:19 AM, Albert Esteve wrote:
>>> On Tue, Mar 10, 2026 at 4:34 PM Andrew Davis <afd@ti.com> wrote:
>>>> On 3/6/26 4:36 AM, Albert Esteve wrote:
>>>>> Expose DT coherent reserved-memory pools ("shared-dma-pool"
>>>>> without "reusable") as dma-buf heaps, creating one heap per
>>>>> region so userspace can allocate from the exact device-local
>>>>> pool intended for coherent DMA.
>>>>>
>>>>> This is a missing backend in the long-term effort to steer
>>>>> userspace buffer allocations (DRM, v4l2, dma-buf heaps)
>>>>> through heaps for clearer cgroup accounting. CMA and system
>>>>> heaps already exist; non-reusable coherent reserved memory
>>>>> did not.
>>>>>
>>>>> The heap binds the heap device to each memory region so
>>>>> coherent allocations use the correct dev->dma_mem, and
>>>>> it defers registration until module_init when normal
>>>>> allocators are available.
>>>>>
>>>>> Signed-off-by: Albert Esteve <aesteve@redhat.com>
>>>>> ---
>>>>> drivers/dma-buf/heaps/Kconfig | 9 +
>>>>> drivers/dma-buf/heaps/Makefile | 1 +
>>>>> drivers/dma-buf/heaps/coherent_heap.c | 414 ++++++++++++++++++++++++++++++++++
>>>>> 3 files changed, 424 insertions(+)
>>>>>
>>>>> (...)
>>>> You are doing this DMA allocation using a non-DMA pseudo-device (heap_dev).
>>>> This is why you need to do that dma_coerce_mask_and_coherent(64) nonsense, you
>>>> are doing a DMA alloc for the CPU itself. This might still work, but only if
>>>> dma_map_sgtable() can handle swiotlb/iommu for all attaching devices at map
>>>> time.
>>> The concern is valid. We're allocating via a synthetic device, which
>>> ties the allocation to that device's DMA domain. I looked deeper into
>>> this trying to address the concern.
>>>
>>> The approach works because dma_map_sgtable() handles both
>>> dma_map_direct and use_dma_iommu cases in __dma_map_sg_attrs(). For
>>> each physical address in the sg_table (extracted via sg_phys()), it
>>> creates device-specific DMA mappings:
>>> - For direct mapping: it checks if the address is directly accessible
>>> (dma_capable()), and if not, it falls back to swiotlb.
>>> - For IOMMU: it creates mappings that allow the device to access
>>> physical addresses.
>>>
>>> This means every attached device gets its own device-specific DMA
>>> mapping, properly handling cases where the physical addresses are
>>> inaccessible or have DMA constraints.
>>>
>> While this means it might still "work" it won't always be ideal. Take
>> the case where the consuming device(s) have a 32bit address restriction,
>> if the allocation was done using the real devices then the backing buffer
>> itself would be allocated in <32bit mem. Whereas here the allocation
>> could end up in >32bit mem, as the CPU/synthetic device supports that.
>> Then each mapping device would instead get a bounce buffer.
>>
>> (this example might not be great as we usually know the address of
>> carveout/reserved memory regions, but substitute in whatever restriction
>> makes more sense)
>>
>> These non-reusable carveouts tend to be made for some specific device, and
>> they are made specifically because that device has some memory restriction.
>> So we might run into the situation above more than one would expect.
>>
>> Not a blocker here, but just something worth thinking on.
> As I detailed in the previous version [1] the main idea behind that work
> is to allow to get rid of dma_alloc_attrs for framework and drivers to
> allocate from the heaps instead.
>
> Robin was saying he wasn't comfortable with exposing this heap to
> userspace, and we're saying here that maybe this might not always work
> anyway (or at least that we couldn't test it fully).
>
> Maybe the best thing is to defer this series until we are at a point
> where we can start enabling the "heap allocations" in frameworks then?
> Hopefully we will have hardware to test it with by then, and we might
> not even need to expose it to userspace at all but only to the kernel.
>
> What do you think?
IMHO a good idea. Maybe in-kernel heap for the coherent allocations will
be just enough.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v3 3/3] input: touchscreen: st1232: add system wakeup support
From: Geert Uytterhoeven @ 2026-04-02 6:56 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: phucduc.bui, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Wolfram Sang, Jeff LaBundy, Bastian Hecht,
Javier Carrasco, linux-input, devicetree, linux-renesas-soc,
linux-kernel
In-Reply-To: <ac37o-N5lqFMwDCC@google.com>
Hi Dmitry,
On Thu, 2 Apr 2026 at 07:17, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On Fri, Mar 06, 2026 at 06:19:12PM +0700, phucduc.bui@gmail.com wrote:
> > From: bui duc phuc <phucduc.bui@gmail.com>
> >
> > The ST1232 touchscreen controller can generate an interrupt when the
> > panel is touched, which may be used as a wakeup source for the system.
> >
> > Add support for system wakeup by initializing the device wakeup
> > capability in probe() based on the "wakeup-source" device property.
> > When wakeup is enabled, the driver enables IRQ wake during suspend
> > so that touch events can wake the system.
> >
> > If wakeup is not enabled, the driver retains the existing behavior of
> > disabling the IRQ and powering down the controller during suspend.
>
> I do not believe this patch is needed: i2c core already handles
> "wakeup-source" property and manages wakeup IRQ.
No, it is not needed, as mentioned in the cover letter of v4[1],
and as tested by me[2].
[1] https://lore.kernel.org/20260309000319.74880-1-phucduc.bui@gmail.com
[2] https://lore.kernel.org/CAMuHMdUqiaP=COTkKU_jK6Hdii+YJ5+zXnxFkOOnhLri5NakTw@mail.gmail.com
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: iio: dac: Add ADI AD5706R
From: Krzysztof Kozlowski @ 2026-04-02 7:00 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260401-dev_ad5706r-v4-1-a785184a8d53@analog.com>
On Wed, Apr 01, 2026 at 06:20:03PM +0800, Alexis Czezar Torreno wrote:
> + vref-supply:
> + description:
> + Optional external 2.5V voltage reference. If not provided, the
> + internal 2.5V reference is used.
> +
> + pwms:
> + maxItems: 1
> + description:
> + Optional PWM connected to the LDAC/TGP/DCK pin for hardware
> + triggered DAC updates, toggle, or dither clock generation.
> +
> + reset-gpios:
> + maxItems: 1
> + description:
> + GPIO connected to the active low RESET pin. If not provided,
> + software reset is used.
> +
> + out-en-gpios:
Isn't this just enable-gpios from gpio-consumer-common? Does the device
have more enable-like GPIOs?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v12 0/7] i2c: xiic: use generic device property accessors
From: Abdurrahman Hussain @ 2026-04-02 7:01 UTC (permalink / raw)
To: Andi Shyti, abdurrahman
Cc: Michal Simek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andy Shevchenko, linux-arm-kernel, linux-i2c, linux-kernel,
devicetree, Andrew Lunn, Jonathan Cameron
In-Reply-To: <ac2r9m9mSMZxgHwN@zenone.zhora.eu>
On Wed Apr 1, 2026 at 4:41 PM PDT, Andi Shyti wrote:
>> Abdurrahman Hussain (7):
>> i2c: xiic: switch to devres managed APIs
>> i2c: xiic: remove duplicate error message
>> i2c: xiic: switch to generic device property accessors
>> i2c: xiic: cosmetic cleanup
>> i2c: xiic: cosmetic: use resource format specifier in debug log
>> i2c: xiic: use numbered adapter registration
>> i2c: xiic: skip input clock setup on non-OF systems
>
> Good job Abdurrahman, thanks for following up in all the rounds
> of reviews. I finally merged your patch in i2c/i2c-host.
>
> Thanks,
> Andi
Thank you for merging the changes, Andi. I would also like to express my
appreciation to all reviewers for their valuable feedback and patience
throughout the review process.
Best regards,
Abdurrahman
^ permalink raw reply
* Re: [PATCH 3/3] pmdomain: qcom: rpmhpd: Add power domains for Hawi SoC
From: Taniya Das @ 2026-04-02 7:02 UTC (permalink / raw)
To: Fenglin Wu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Ulf Hansson, Konrad Dybcio
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel
In-Reply-To: <20260401-haw-rpmhpd-v1-3-c830c79ed8f9@oss.qualcomm.com>
On 4/1/2026 2:45 PM, Fenglin Wu wrote:
> Add the RPMh power domains required for the Hawi SoC. This includes
> new definitions for domains supplying specific hardware components:
> - DCX: supplies VDD_DISP
> - GBX: supplies VDD_GFX_BX
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> drivers/pmdomain/qcom/rpmhpd.c | 38 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/drivers/pmdomain/qcom/rpmhpd.c b/drivers/pmdomain/qcom/rpmhpd.c
> index 19849703be4a..f5ae2a63765d 100644
> --- a/drivers/pmdomain/qcom/rpmhpd.c
> +++ b/drivers/pmdomain/qcom/rpmhpd.c
> @@ -102,11 +102,21 @@ static struct rpmhpd cx_ao_w_mx_parent = {
> .res_name = "cx.lvl",
> };
>
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: media: qcom,sm8550-iris: Add X1P42100 compatible
From: Krzysztof Kozlowski @ 2026-04-02 7:05 UTC (permalink / raw)
To: Wangao Wang
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260401-enable_iris_on_purwa-v4-1-ca784552a3e9@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 06:24:38PM +0800, Wangao Wang wrote:
> Document the new compatible string "qcom,x1p42100-iris".
>
> The x1p42100 SoC integrates the same IRIS video hardware block as SM8550,
> but represents a distinct hardware instance.
Full stop, as I asked last time.
> and therefore uses its own
> compatible string.
Drop, redundant. X1P42100 is not the same soc as SM8550, thus you cannot
have the same compatible. This is explicitly written in bindings. Each
different device needs own compatible string.
Adding obvious explanation from documentation to commit msg is
redundant.
Explain why devices are not compatible.
>
> The x1p42100 variant includes an additional Bitstream Engine (BSE) clock
> that is not present on SM8550.
Presence of additional clock does not indicate that devices are
compatible. Look at other qcom bindings - many are compatible even
though they have different clocks.
So say that you need to do something with that clock differently.
> This clock is described explicitly in the
> binding.
Last sentence - again, redundant. Write concise but informative
messages.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 2/5] media: iris: Add hardware power on/off ops for X1P42100
From: Krzysztof Kozlowski @ 2026-04-02 7:08 UTC (permalink / raw)
To: Wangao Wang
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260401-enable_iris_on_purwa-v4-2-ca784552a3e9@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 06:24:39PM +0800, Wangao Wang wrote:
> On X1P42100 the Iris block has an extra BSE clock. Wire this clock into
> the power on/off sequence.
>
> The BSE clock is used to drive the Bin Stream Engine, which is a sub-block
> of the video codec hardware responsible for bitstream-level processing. It
> is required to be enabled separately from the core clock to ensure proper
> codec operation.
>
> Signed-off-by: Wangao Wang <wangao.wang@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_vpu3x.c | 46 ++++++++++++++++++++++
> drivers/media/platform/qcom/iris/iris_vpu_common.h | 1 +
> 2 files changed, 47 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu3x.c b/drivers/media/platform/qcom/iris/iris_vpu3x.c
> index fe4423b951b1e9e31d06dffc69d18071cc985731..e6a62b3ca78efeefa2eed267636789a6b405689f 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu3x.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu3x.c
> @@ -71,6 +71,44 @@ static void iris_vpu3_power_off_hardware(struct iris_core *core)
> iris_vpu_power_off_hw(core);
> }
>
> +static int iris_vpu3_purwa_power_on_hw(struct iris_core *core)
> +{
> + int ret;
> +
> + ret = iris_enable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
> + if (ret)
> + return ret;
> +
> + ret = iris_prepare_enable_clock(core, IRIS_HW_CLK);
> + if (ret)
> + goto err_disable_power;
> +
> + ret = iris_prepare_enable_clock(core, IRIS_BSE_HW_CLK);
> + if (ret)
> + goto err_disable_hw_clock;
> +
> + ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], true);
> + if (ret)
> + goto err_disable_bse_hw_clock;
> +
> + return 0;
> +
> +err_disable_bse_hw_clock:
> + iris_disable_unprepare_clock(core, IRIS_BSE_HW_CLK);
> +err_disable_hw_clock:
> + iris_disable_unprepare_clock(core, IRIS_HW_CLK);
> +err_disable_power:
> + iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
> +
> + return ret;
> +}
Why no IRIS_HW_AHB_CLK in power on sequence?
So if you rewrite the code that you have list of clocks for hw power on
(IRIS_HW_CLK + IRIS_HW_AHB_CLK for all variants, +IRIS_BSE_HW_CLK on
this variant) you could have just one function for all of them and
devices will be fully compatible.
No?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v1] ASoC: codecs: wcd937x: Add conditional regulator control for wcd937x
From: karthik.s @ 2026-04-02 7:08 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai
Cc: linux-arm-msm, linux-sound, devicetree, linux-kernel, karthik.s
Add has_always_on_supplies for managing regulators. Indicates that
the codec supply regulators are always enabled by the system and
must not be requested or enabled by the codec driver.
Signed-off-by: karthik.s <karthik.s@oss.qualcomm.com>
---
.../devicetree/bindings/sound/qcom,wcd937x.yaml | 6 ++++++
sound/soc/codecs/wcd937x.c | 13 +++++++++----
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
index f94203798f24..d89fff1f7171 100644
--- a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
@@ -28,6 +28,12 @@ properties:
vdd-px-supply:
description: A reference to the 1.8V I/O supply
+ qcom,always-on-supply:
+ type: boolean
+ description: Indicates that the codec supply regulators are always enabled
+ by the system and must not be requested or enabled by the codec
+ driver.
+
required:
- compatible
- vdd-px-supply
diff --git a/sound/soc/codecs/wcd937x.c b/sound/soc/codecs/wcd937x.c
index 10a2d598caa7..1514ceb7d790 100644
--- a/sound/soc/codecs/wcd937x.c
+++ b/sound/soc/codecs/wcd937x.c
@@ -100,6 +100,7 @@ struct wcd937x_priv {
int aux_pdm_wd_int;
bool comp1_enable;
bool comp2_enable;
+ bool has_always_on_supplies;
struct gpio_desc *us_euro_gpio;
struct gpio_desc *reset_gpio;
@@ -2907,10 +2908,14 @@ static int wcd937x_probe(struct platform_device *pdev)
cfg = &wcd937x->mbhc_cfg;
cfg->swap_gnd_mic = wcd937x_swap_gnd_mic;
- ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(wcd937x_supplies),
- wcd937x_supplies);
- if (ret)
- return dev_err_probe(dev, ret, "Failed to get and enable supplies\n");
+ wcd937x->has_always_on_supplies = of_property_read_bool(dev->of_node,
+ "qcom,always-on-supply");
+ if (!wcd937x->has_always_on_supplies) {
+ ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(wcd937x_supplies),
+ wcd937x_supplies);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to get and enable supplies\n");
+ }
ret = wcd_dt_parse_micbias_info(&wcd937x->common);
if (ret)
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 5/5] arm64: dts: qcom: purwa-iot-som: enable video
From: Krzysztof Kozlowski @ 2026-04-02 7:11 UTC (permalink / raw)
To: Dikshita Agarwal
Cc: Wangao Wang, Bryan O'Donoghue, Vikash Garodia, Abhinav Kumar,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-media,
linux-arm-msm, devicetree, linux-kernel, Dmitry Baryshkov,
Konrad Dybcio
In-Reply-To: <9f94af36-6460-c227-2735-628e45819a03@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 06:12:24PM +0530, Dikshita Agarwal wrote:
> On 4/1/2026 3:54 PM, Wangao Wang wrote:
> > Enable video nodes on the purwa-iot-som board.
> >
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > Signed-off-by: Wangao Wang <wangao.wang@oss.qualcomm.com>
> > ---
> > arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi b/arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi
> > index 394e65518ac5037e5c7c50583acefc0dbc8ebb47..ff8621f8750584636ad781467f9c35ace2354e4c 100644
> > --- a/arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi
> > @@ -389,6 +389,10 @@ &gpu_zap_shader {
> > firmware-name = "qcom/x1p42100/gen71500_zap.mbn";
> > };
> >
> > +&iris {
> > + status = "okay";
> > +};
> > +
> > &pcie3 {
> > pinctrl-0 = <&pcie3_default>;
> > pinctrl-names = "default";
> >
>
> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>
I wonder how many reviews from qcom are needed for such trivial one
liners which are 100% obvious. Let's go for more - please everyone,
let's provide here review:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Does it make any sense? Are we making the process just ridicilous?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1] ASoC: codecs: wcd937x: Add conditional regulator control for wcd937x
From: Krzysztof Kozlowski @ 2026-04-02 7:13 UTC (permalink / raw)
To: karthik.s, Srinivas Kandagatla, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-msm, linux-sound, devicetree, linux-kernel
In-Reply-To: <20260402070854.2804291-1-karthik.s@oss.qualcomm.com>
On 02/04/2026 09:08, karthik.s wrote:
> Add has_always_on_supplies for managing regulators. Indicates that
> the codec supply regulators are always enabled by the system and
> must not be requested or enabled by the codec driver.
>
> Signed-off-by: karthik.s <karthik.s@oss.qualcomm.com>
Please configure your Git.
> ---
> .../devicetree/bindings/sound/qcom,wcd937x.yaml | 6 ++++++
> sound/soc/codecs/wcd937x.c | 13 +++++++++----
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
> index f94203798f24..d89fff1f7171 100644
> --- a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
> +++ b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
> @@ -28,6 +28,12 @@ properties:
> vdd-px-supply:
> description: A reference to the 1.8V I/O supply
>
> + qcom,always-on-supply:
You described the desired Linux feature or behavior, not the actual
hardware. The bindings are about the latter, so instead you need to
rephrase the property and its description to match actual hardware
capabilities/features/configuration etc.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: perf: marvell: Document CN20K DDR PMU
From: Krzysztof Kozlowski @ 2026-04-02 7:16 UTC (permalink / raw)
To: Geetha sowjanya
Cc: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree,
mark.rutland, will, krzk+dt
In-Reply-To: <20260401081640.23740-2-gakula@marvell.com>
On Wed, Apr 01, 2026 at 01:46:39PM +0530, Geetha sowjanya wrote:
> Add a devicetree binding for the Marvell CN20K DDR performance
> monitor block, including the marvell,cn20k-ddr-pmu compatible
> string and the required MMIO reg region.
You just repeated the diff. No need, we can read the diff, but what we
cannot read is the hardware you are here describing.
>
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
> ---
> .../bindings/perf/marvell-cn20k-ddr.yaml | 39 +++++++++++++++++++
So you did not test v1. You did not test v2.
Did you finally test this one before sending?
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
>
> diff --git a/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
> new file mode 100644
> index 000000000000..fa757017d66e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
> @@ -0,0 +1,39 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/perf/marvell-cn20k-ddr.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Marvell CN20K DDR performance monitor
> +
> +description:
> + Performance Monitoring Unit (PMU) for the DDR controller
> + in Marvell CN20K SoCs.
> +
> +maintainers:
> + - Geetha sowjanya <gakula@marvell.com>
> +
> +properties:
> + compatible:
> + const: marvell,cn20k-ddr-pmu
There is no such thing as marvell,cn20k in upstream. What's that?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: perf: marvell: Document CN20K DDR PMU
From: Krzysztof Kozlowski @ 2026-04-02 7:17 UTC (permalink / raw)
To: Geetha sowjanya
Cc: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree,
mark.rutland, will, krzk+dt
In-Reply-To: <20260401081640.23740-2-gakula@marvell.com>
On Wed, Apr 01, 2026 at 01:46:39PM +0530, Geetha sowjanya wrote:
> Add a devicetree binding for the Marvell CN20K DDR performance
> monitor block, including the marvell,cn20k-ddr-pmu compatible
> string and the required MMIO reg region.
>
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
> ---
> .../bindings/perf/marvell-cn20k-ddr.yaml | 39 +++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
I forgot:
Filename must match compatible.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] ASoC: codecs: wcd937x: Add conditional regulator control for wcd937x
From: karthik.s @ 2026-04-02 7:22 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai
Cc: linux-sound, linux-arm-msm, devicetree, linux-kernel, karthik.s
Add has_always_on_supplies for managing regulators. Indicates that the
codec power supplies are provided by the board as always-on rails and
are not switchable by the codec or its associated regulators. This implies
that the codec supply regulators are always enabled by the system and
must not be requested or enabled by the codec driver.
Signed-off-by: karthik.s <karthik.s@oss.qualcomm.com>
---
.../devicetree/bindings/sound/qcom,wcd937x.yaml | 8 ++++++++
sound/soc/codecs/wcd937x.c | 13 +++++++++----
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
index f94203798f24..38b3452788e9 100644
--- a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
@@ -28,6 +28,14 @@ properties:
vdd-px-supply:
description: A reference to the 1.8V I/O supply
+ qcom,always-on-supply:
+ type: boolean
+ description: Indicates that the codec power supplies are provided by the board
+ as always-on rails and are not switchable by the codec or its
+ associated regulators. This implies that the codec supply regulators
+ are always enabled by the system and must not be requested or enabled
+ by the codec driver.
+
required:
- compatible
- vdd-px-supply
diff --git a/sound/soc/codecs/wcd937x.c b/sound/soc/codecs/wcd937x.c
index 10a2d598caa7..1514ceb7d790 100644
--- a/sound/soc/codecs/wcd937x.c
+++ b/sound/soc/codecs/wcd937x.c
@@ -100,6 +100,7 @@ struct wcd937x_priv {
int aux_pdm_wd_int;
bool comp1_enable;
bool comp2_enable;
+ bool has_always_on_supplies;
struct gpio_desc *us_euro_gpio;
struct gpio_desc *reset_gpio;
@@ -2907,10 +2908,14 @@ static int wcd937x_probe(struct platform_device *pdev)
cfg = &wcd937x->mbhc_cfg;
cfg->swap_gnd_mic = wcd937x_swap_gnd_mic;
- ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(wcd937x_supplies),
- wcd937x_supplies);
- if (ret)
- return dev_err_probe(dev, ret, "Failed to get and enable supplies\n");
+ wcd937x->has_always_on_supplies = of_property_read_bool(dev->of_node,
+ "qcom,always-on-supply");
+ if (!wcd937x->has_always_on_supplies) {
+ ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(wcd937x_supplies),
+ wcd937x_supplies);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to get and enable supplies\n");
+ }
ret = wcd_dt_parse_micbias_info(&wcd937x->common);
if (ret)
--
2.34.1
^ permalink raw reply related
* [PATCH v12 00/15] arm64/riscv: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-04-02 7:26 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, hbathini, eajames, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, takahiro.akashi, james.morse,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
The crash memory allocation, and the exclude of crashk_res, crashk_low_res
and crashk_cma memory are almost identical across different architectures,
This patch set handle them in crash core in a general way, which eliminate
a lot of duplication code.
And add support for crashkernel CMA reservation for arm64 and riscv.
Rebased on v7.0-rc1.
Basic second kernel boot test were performed on QEMU platforms for x86,
ARM64, and RISC-V architectures with the following parameters:
"cma=256M crashkernel=256M crashkernel=64M,cma"
Changes in v12:
- Remove the unused "nr_mem_ranges" for x86.
- Add "Fix crashk_low_res not exclude bug" test log.
- Provide a separate patch for each architecture for using
crash_prepare_headers(), which will make the review more convenient.
- Add Reviewed-by and Tested-by.
- Link to v11: https://lore.kernel.org/all/20260328074013.3589544-1-ruanjinjie@huawei.com/
Changes in v11:
- Avoid silently drop crash memory if the crash kernel is built without
CONFIG_CMA.
- Remove unnecessary "cmem->nr_ranges = 0" for arch_crash_populate_cmem()
as we use kvzalloc().
- Provide a separate patch for each architecture to fix the existing
buffer overflow issue.
- Add Acked-bys for arm64.
Changes in v10:
- Fix crashk_low_res not excluded bug in the existing
RISC-V code.
- Fix an existing memory leak issue in the existing PowerPC code.
- Fix the ordering issue of adding CMA ranges to
"linux,usable-memory-range".
- Fix an existing concurrency issue. A Concurrent memory hotplug may occur
between reading memblock and attempting to fill cmem during kexec_load()
for almost all existing architectures.
- Link to v9: https://lore.kernel.org/all/20260323072745.2481719-1-ruanjinjie@huawei.com/
Changes in v9:
- Collect Reviewed-by and Acked-by, and prepare for Sashiko AI review.
- Link to v8: https://lore.kernel.org/all/20260302035315.3892241-1-ruanjinjie@huawei.com/
Changes in v8:
- Fix the build issues reported by kernel test robot and Sourabh.
- Link to v7: https://lore.kernel.org/all/20260226130437.1867658-1-ruanjinjie@huawei.com/
Changes in v7:
- Correct the inclusion of CMA-reserved ranges for kdump kernel in of/kexec
for arm64 and riscv.
- Add Acked-by.
- Link to v6: https://lore.kernel.org/all/20260224085342.387996-1-ruanjinjie@huawei.com/
Changes in v6:
- Update the crash core exclude code as Mike suggested.
- Rebased on v7.0-rc1.
- Add acked-by.
- Link to v5: https://lore.kernel.org/all/20260212101001.343158-1-ruanjinjie@huawei.com/
Jinjie Ruan (14):
riscv: kexec_file: Fix crashk_low_res not exclude bug
powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()
x86/kexec: Fix potential buffer overflow in prepare_elf_headers()
arm64: kexec_file: Fix potential buffer overflow in
prepare_elf_headers()
riscv: kexec_file: Fix potential buffer overflow in
prepare_elf_headers()
LoongArch: kexec: Fix potential buffer overflow in
prepare_elf_headers()
crash: Add crash_prepare_headers() to exclude crash kernel memory
arm64: kexec_file: Use crash_prepare_headers() helper to simplify code
x86/kexec: Use crash_prepare_headers() helper to simplify code
riscv: kexec_file: Use crash_prepare_headers() helper to simplify code
LoongArch: kexec: Use crash_prepare_headers() helper to simplify code
crash: Use crash_exclude_core_ranges() on powerpc
arm64: kexec: Add support for crashkernel CMA reservation
riscv: kexec: Add support for crashkernel CMA reservation
Sourabh Jain (1):
powerpc/crash: sort crash memory ranges before preparing elfcorehdr
.../admin-guide/kernel-parameters.txt | 16 +--
arch/arm64/kernel/machine_kexec_file.c | 43 +++-----
arch/arm64/mm/init.c | 5 +-
arch/loongarch/kernel/machine_kexec_file.c | 43 +++-----
arch/powerpc/include/asm/kexec_ranges.h | 1 -
arch/powerpc/kexec/crash.c | 7 +-
arch/powerpc/kexec/ranges.c | 101 +-----------------
arch/riscv/kernel/machine_kexec_file.c | 42 +++-----
arch/riscv/mm/init.c | 5 +-
arch/x86/kernel/crash.c | 92 +++-------------
drivers/of/fdt.c | 9 +-
drivers/of/kexec.c | 9 ++
include/linux/crash_core.h | 9 ++
include/linux/crash_reserve.h | 4 +-
kernel/crash_core.c | 89 ++++++++++++++-
15 files changed, 193 insertions(+), 282 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v12 01/15] riscv: kexec_file: Fix crashk_low_res not exclude bug
From: Jinjie Ruan @ 2026-04-02 7:26 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, hbathini, eajames, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, takahiro.akashi, james.morse,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
In-Reply-To: <20260402072701.628293-1-ruanjinjie@huawei.com>
As done in commit 944a45abfabc ("arm64: kdump: Reimplement crashkernel=X")
and commit 4831be702b95 ("arm64/kexec: Fix missing extra range for
crashkres_low.") for arm64, while implementing crashkernel=X,[high,low],
riscv should have excluded the "crashk_low_res" reserved ranges from
the crash kernel memory to prevent them from being exported through
/proc/vmcore, and the exclusion would need an extra crash_mem range.
Just simply tested on qemu with crashkernel=4G with kexec in [1] mentioned
in [2]. And the second kernel can be started normally.
# dmesg | grep crash
[ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000 (128 MB)
[ 0.000000] crashkernel reserved: 0x000000017fe00000 - 0x000000027fe00000 (4096 MB)
Cc: Guo Ren <guoren@kernel.org>
Cc: Baoquan He <bhe@redhat.com>
[1]: https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
[2]: https://lore.kernel.org/all/20230726175000.2536220-1-chenjiahao16@huawei.com/
Fixes: 5882e5acf18d ("riscv: kdump: Implement crashkernel=X,[high,low]")
Reviewed-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/riscv/kernel/machine_kexec_file.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
index 54e2d9552e93..3f7766057cac 100644
--- a/arch/riscv/kernel/machine_kexec_file.c
+++ b/arch/riscv/kernel/machine_kexec_file.c
@@ -61,7 +61,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
unsigned int nr_ranges;
int ret;
- nr_ranges = 1; /* For exclusion of crashkernel region */
+ nr_ranges = 2; /* For exclusion of crashkernel region */
walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
@@ -76,8 +76,16 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
/* Exclude crashkernel region */
ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
- if (!ret)
- ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
+ if (ret)
+ goto out;
+
+ if (crashk_low_res.end) {
+ ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
+ if (ret)
+ goto out;
+ }
+
+ ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
out:
kfree(cmem);
--
2.34.1
^ permalink raw reply related
* [PATCH v12 02/15] powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()
From: Jinjie Ruan @ 2026-04-02 7:26 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, hbathini, eajames, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, takahiro.akashi, james.morse,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
In-Reply-To: <20260402072701.628293-1-ruanjinjie@huawei.com>
In get_crash_memory_ranges(), if crash_exclude_mem_range() failed
after realloc_mem_ranges() has successfully allocated the cmem
memory, it just returns an error but leaves cmem pointing to
the allocated memory, nor is it freed in the caller
update_crash_elfcorehdr(), which cause a memory leak, goto out
to free the cmem.
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Fixes: 849599b702ef ("powerpc/crash: add crash memory hotplug support")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/powerpc/kexec/crash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
index a325c1c02f96..1d12cef8e1e0 100644
--- a/arch/powerpc/kexec/crash.c
+++ b/arch/powerpc/kexec/crash.c
@@ -440,7 +440,7 @@ static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *
ret = get_crash_memory_ranges(&cmem);
if (ret) {
pr_err("Failed to get crash mem range\n");
- return;
+ goto out;
}
/*
--
2.34.1
^ permalink raw reply related
* [PATCH v12 03/15] x86/kexec: Fix potential buffer overflow in prepare_elf_headers()
From: Jinjie Ruan @ 2026-04-02 7:26 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, hbathini, eajames, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, takahiro.akashi, james.morse,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
In-Reply-To: <20260402072701.628293-1-ruanjinjie@huawei.com>
There is a race condition between the kexec_load() system call
(crash kernel loading path) and memory hotplug operations that can lead
to buffer overflow and potential kernel crash.
During prepare_elf_headers(), the following steps occur:
1. get_nr_ram_ranges_callback() queries current System RAM memory ranges
2. Allocates buffer based on queried count
3. prepare_elf64_ram_headers_callback() populates ranges from memblock
If memory hotplug occurs between step 1 and step 3, the number of ranges
can increase, causing out-of-bounds write when populating cmem->ranges[].
This happens because kexec_load() uses kexec_trylock (atomic_t) while
memory hotplug uses device_hotplug_lock (mutex), so they don't serialize
with each other.
Just add bounds checking in prepare_elf64_ram_headers_callback() to
prevent out-of-bounds (OOB) access,
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Fixes: 8d5f894a3108 ("x86: kexec_file: lift CRASH_MAX_RANGES limit on crash_mem buffer")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/x86/kernel/crash.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 335fd2ee9766..7fa6d45ebe3f 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -225,6 +225,9 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
{
struct crash_mem *cmem = arg;
+ if (cmem->nr_ranges >= cmem->max_nr_ranges)
+ return -ENOMEM;
+
cmem->ranges[cmem->nr_ranges].start = res->start;
cmem->ranges[cmem->nr_ranges].end = res->end;
cmem->nr_ranges++;
--
2.34.1
^ permalink raw reply related
* [PATCH v12 04/15] arm64: kexec_file: Fix potential buffer overflow in prepare_elf_headers()
From: Jinjie Ruan @ 2026-04-02 7:26 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, hbathini, eajames, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, takahiro.akashi, james.morse,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
In-Reply-To: <20260402072701.628293-1-ruanjinjie@huawei.com>
There is a race condition between the kexec_load() system call
(crash kernel loading path) and memory hotplug operations that can lead
to buffer overflow and potential kernel crash.
During prepare_elf_headers(), the following steps occur:
1. The first for_each_mem_range() queries current System RAM memory ranges
2. Allocates buffer based on queried count
3. The 2st for_each_mem_range() populates ranges from memblock
If memory hotplug occurs between step 1 and step 3, the number of ranges
can increase, causing out-of-bounds write when populating cmem->ranges[].
This happens because kexec_load() uses kexec_trylock (atomic_t) while
memory hotplug uses device_hotplug_lock (mutex), so they don't serialize
with each other.
Just add bounds checking to prevent out-of-bounds access.
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Fixes: 3751e728cef2 ("arm64: kexec_file: add crash dump support")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/arm64/kernel/machine_kexec_file.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index fba260ad87a9..df52ac4474c9 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -59,6 +59,11 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
cmem->max_nr_ranges = nr_ranges;
cmem->nr_ranges = 0;
for_each_mem_range(i, &start, &end) {
+ if (cmem->nr_ranges >= cmem->max_nr_ranges) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
cmem->ranges[cmem->nr_ranges].start = start;
cmem->ranges[cmem->nr_ranges].end = end - 1;
cmem->nr_ranges++;
--
2.34.1
^ permalink raw reply related
* [PATCH v12 05/15] riscv: kexec_file: Fix potential buffer overflow in prepare_elf_headers()
From: Jinjie Ruan @ 2026-04-02 7:26 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, hbathini, eajames, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, takahiro.akashi, james.morse,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
In-Reply-To: <20260402072701.628293-1-ruanjinjie@huawei.com>
There is a race condition between the kexec_load() system call
(crash kernel loading path) and memory hotplug operations that can lead
to buffer overflow and potential kernel crash.
During prepare_elf_headers(), the following steps occur:
1. get_nr_ram_ranges_callback() queries current System RAM memory ranges
2. Allocates buffer based on queried count
3. prepare_elf64_ram_headers_callback() populates ranges from memblock
If memory hotplug occurs between step 1 and step 3, the number of ranges
can increase, causing out-of-bounds write when populating cmem->ranges[].
This happens because kexec_load() uses kexec_trylock (atomic_t) while
memory hotplug uses device_hotplug_lock (mutex), so they don't serialize
with each other.
Just add bounds checking in prepare_elf64_ram_headers_callback() to prevent
out-of-bounds (OOB) access.
Fixes: 8acea455fafa ("RISC-V: Support for kexec_file on panic")
Reviewed-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/riscv/kernel/machine_kexec_file.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
index 3f7766057cac..773a1cba8ba0 100644
--- a/arch/riscv/kernel/machine_kexec_file.c
+++ b/arch/riscv/kernel/machine_kexec_file.c
@@ -48,6 +48,9 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
{
struct crash_mem *cmem = arg;
+ if (cmem->nr_ranges >= cmem->max_nr_ranges)
+ return -ENOMEM;
+
cmem->ranges[cmem->nr_ranges].start = res->start;
cmem->ranges[cmem->nr_ranges].end = res->end;
cmem->nr_ranges++;
--
2.34.1
^ permalink raw reply related
* [PATCH v12 06/15] LoongArch: kexec: Fix potential buffer overflow in prepare_elf_headers()
From: Jinjie Ruan @ 2026-04-02 7:26 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, hbathini, eajames, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, takahiro.akashi, james.morse,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
In-Reply-To: <20260402072701.628293-1-ruanjinjie@huawei.com>
There is a race condition between the kexec_load() system call
(crash kernel loading path) and memory hotplug operations that can lead
to buffer overflow and potential kernel crash.
During prepare_elf_headers(), the following steps occur:
1. The first for_each_mem_range() queries current System RAM memory ranges
2. Allocates buffer based on queried count
3. The 2st for_each_mem_range() populates ranges from memblock
If memory hotplug occurs between step 1 and step 3, the number of ranges
can increase, causing out-of-bounds write when populating cmem->ranges[].
This happens because kexec_load() uses kexec_trylock (atomic_t) while
memory hotplug uses device_hotplug_lock (mutex), so they don't serialize
with each other.
Just add bounds checking to prevent out-of-bounds access.
Cc: Youling Tang <tangyouling@kylinos.cn>
Cc: Huacai Chen <chenhuacai@loongson.cn>
Fixes: 1bcca8620a91 ("LoongArch: Add crash dump support for kexec_file")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/loongarch/kernel/machine_kexec_file.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/kernel/machine_kexec_file.c
index 5584b798ba46..167392c1da33 100644
--- a/arch/loongarch/kernel/machine_kexec_file.c
+++ b/arch/loongarch/kernel/machine_kexec_file.c
@@ -75,6 +75,11 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
cmem->max_nr_ranges = nr_ranges;
cmem->nr_ranges = 0;
for_each_mem_range(i, &start, &end) {
+ if (cmem->nr_ranges >= cmem->max_nr_ranges) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
cmem->ranges[cmem->nr_ranges].start = start;
cmem->ranges[cmem->nr_ranges].end = end - 1;
cmem->nr_ranges++;
--
2.34.1
^ permalink raw reply related
* [PATCH v12 07/15] powerpc/crash: sort crash memory ranges before preparing elfcorehdr
From: Jinjie Ruan @ 2026-04-02 7:26 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, hbathini, eajames, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, takahiro.akashi, james.morse,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
In-Reply-To: <20260402072701.628293-1-ruanjinjie@huawei.com>
From: Sourabh Jain <sourabhjain@linux.ibm.com>
During a memory hot-remove event, the elfcorehdr is rebuilt to exclude
the removed memory. While updating the crash memory ranges for this
operation, the crash memory ranges array can become unsorted. This
happens because remove_mem_range() may split a memory range into two
parts and append the higher-address part as a separate range at the end
of the array.
So far, no issues have been observed due to the unsorted crash memory
ranges. However, this could lead to problems once crash memory range
removal is handled by generic code, as introduced in the upcoming
patches in this series.
Currently, powerpc uses a platform-specific function,
remove_mem_range(), to exclude hot-removed memory from the crash memory
ranges. This function performs the same task as the generic
crash_exclude_mem_range() in crash_core.c. The generic helper also
ensures that the crash memory ranges remain sorted. So remove the
redundant powerpc-specific implementation and instead call
crash_exclude_mem_range_guarded() (which internally calls
crash_exclude_mem_range()) to exclude the hot-removed memory ranges.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan he <bhe@redhat.com>
Cc: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org
Acked-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/powerpc/include/asm/kexec_ranges.h | 4 +-
arch/powerpc/kexec/crash.c | 5 +-
arch/powerpc/kexec/ranges.c | 87 +------------------------
3 files changed, 7 insertions(+), 89 deletions(-)
diff --git a/arch/powerpc/include/asm/kexec_ranges.h b/arch/powerpc/include/asm/kexec_ranges.h
index 14055896cbcb..ad95e3792d10 100644
--- a/arch/powerpc/include/asm/kexec_ranges.h
+++ b/arch/powerpc/include/asm/kexec_ranges.h
@@ -7,7 +7,9 @@
void sort_memory_ranges(struct crash_mem *mrngs, bool merge);
struct crash_mem *realloc_mem_ranges(struct crash_mem **mem_ranges);
int add_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size);
-int remove_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size);
+int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
+ unsigned long long mstart,
+ unsigned long long mend);
int get_exclude_memory_ranges(struct crash_mem **mem_ranges);
int get_reserved_memory_ranges(struct crash_mem **mem_ranges);
int get_crash_memory_ranges(struct crash_mem **mem_ranges);
diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
index 1d12cef8e1e0..1426d2099bad 100644
--- a/arch/powerpc/kexec/crash.c
+++ b/arch/powerpc/kexec/crash.c
@@ -431,7 +431,7 @@ static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *
struct crash_mem *cmem = NULL;
struct kexec_segment *ksegment;
void *ptr, *mem, *elfbuf = NULL;
- unsigned long elfsz, memsz, base_addr, size;
+ unsigned long elfsz, memsz, base_addr, size, end;
ksegment = &image->segment[image->elfcorehdr_index];
mem = (void *) ksegment->mem;
@@ -450,7 +450,8 @@ static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *
if (image->hp_action == KEXEC_CRASH_HP_REMOVE_MEMORY) {
base_addr = PFN_PHYS(mn->start_pfn);
size = mn->nr_pages * PAGE_SIZE;
- ret = remove_mem_range(&cmem, base_addr, size);
+ end = base_addr + size - 1;
+ ret = crash_exclude_mem_range_guarded(&cmem, base_addr, end);
if (ret) {
pr_err("Failed to remove hot-unplugged memory from crash memory ranges\n");
goto out;
diff --git a/arch/powerpc/kexec/ranges.c b/arch/powerpc/kexec/ranges.c
index 867135560e5c..6c58bcc3e130 100644
--- a/arch/powerpc/kexec/ranges.c
+++ b/arch/powerpc/kexec/ranges.c
@@ -553,7 +553,7 @@ int get_usable_memory_ranges(struct crash_mem **mem_ranges)
#endif /* CONFIG_KEXEC_FILE */
#ifdef CONFIG_CRASH_DUMP
-static int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
+int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
unsigned long long mstart,
unsigned long long mend)
{
@@ -641,89 +641,4 @@ int get_crash_memory_ranges(struct crash_mem **mem_ranges)
pr_err("Failed to setup crash memory ranges\n");
return ret;
}
-
-/**
- * remove_mem_range - Removes the given memory range from the range list.
- * @mem_ranges: Range list to remove the memory range to.
- * @base: Base address of the range to remove.
- * @size: Size of the memory range to remove.
- *
- * (Re)allocates memory, if needed.
- *
- * Returns 0 on success, negative errno on error.
- */
-int remove_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size)
-{
- u64 end;
- int ret = 0;
- unsigned int i;
- u64 mstart, mend;
- struct crash_mem *mem_rngs = *mem_ranges;
-
- if (!size)
- return 0;
-
- /*
- * Memory range are stored as start and end address, use
- * the same format to do remove operation.
- */
- end = base + size - 1;
-
- for (i = 0; i < mem_rngs->nr_ranges; i++) {
- mstart = mem_rngs->ranges[i].start;
- mend = mem_rngs->ranges[i].end;
-
- /*
- * Memory range to remove is not part of this range entry
- * in the memory range list
- */
- if (!(base >= mstart && end <= mend))
- continue;
-
- /*
- * Memory range to remove is equivalent to this entry in the
- * memory range list. Remove the range entry from the list.
- */
- if (base == mstart && end == mend) {
- for (; i < mem_rngs->nr_ranges - 1; i++) {
- mem_rngs->ranges[i].start = mem_rngs->ranges[i+1].start;
- mem_rngs->ranges[i].end = mem_rngs->ranges[i+1].end;
- }
- mem_rngs->nr_ranges--;
- goto out;
- }
- /*
- * Start address of the memory range to remove and the
- * current memory range entry in the list is same. Just
- * move the start address of the current memory range
- * entry in the list to end + 1.
- */
- else if (base == mstart) {
- mem_rngs->ranges[i].start = end + 1;
- goto out;
- }
- /*
- * End address of the memory range to remove and the
- * current memory range entry in the list is same.
- * Just move the end address of the current memory
- * range entry in the list to base - 1.
- */
- else if (end == mend) {
- mem_rngs->ranges[i].end = base - 1;
- goto out;
- }
- /*
- * Memory range to remove is not at the edge of current
- * memory range entry. Split the current memory entry into
- * two half.
- */
- else {
- size = mem_rngs->ranges[i].end - end + 1;
- mem_rngs->ranges[i].end = base - 1;
- ret = add_mem_range(mem_ranges, end + 1, size);
- }
- }
-out:
- return ret;
-}
#endif /* CONFIG_CRASH_DUMP */
--
2.34.1
^ 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