From: Stephan Gerhold <stephan@gerhold.net>
To: Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>
Cc: Andy Gross <agross@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
devicetree@vger.kernel.org, devicetree-spec@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
Stephan Gerhold <stephan@gerhold.net>
Subject: [PATCH 3/5] of: reserved_mem: Use stable allocation order
Date: Mon, 15 May 2023 12:12:18 +0200 [thread overview]
Message-ID: <20230510-dt-resv-bottom-up-v1-3-3bf68873dbed@gerhold.net> (raw)
In-Reply-To: <20230510-dt-resv-bottom-up-v1-0-3bf68873dbed@gerhold.net>
sort() in Linux is based on heapsort which is not a stable sort
algorithm - equal elements are being reordered. For reserved memory in
the device tree this happens mainly for dynamic allocations: They do not
have an address to sort with, so they are reordered somewhat randomly
when adding/removing other unrelated reserved memory nodes.
Functionally this is not a big problem, but it's confusing during
development when all the addresses change after adding unrelated
reserved memory nodes.
Make the order stable by sorting dynamic allocations according to
the node order in the device tree. Static allocations are not affected
by this because they are still sorted by their (fixed) address.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
---
drivers/of/of_reserved_mem.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 6443140deacf..f6d14354a534 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -224,6 +224,11 @@ static int __init __rmem_cmp(const void *a, const void *b)
if (ra->size > rb->size)
return 1;
+ if (ra->fdt_node < rb->fdt_node)
+ return -1;
+ if (ra->fdt_node > rb->fdt_node)
+ return 1;
+
return 0;
}
--
2.40.1
next prev parent reply other threads:[~2023-05-15 10:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 10:12 [PATCH 0/5] of: reserved_mem: Provide more control about allocation behavior Stephan Gerhold
2023-05-15 10:12 ` [PATCH 1/5] dt-bindings: reserved-memory: Add alloc-{bottom-up,top-down} Stephan Gerhold
2023-06-08 14:02 ` Rob Herring
2023-06-09 9:16 ` Stephan Gerhold
2023-06-13 13:33 ` Rob Herring
2023-05-15 10:12 ` [PATCH 2/5] of: reserved_mem: Implement alloc-{bottom-up,top-down} Stephan Gerhold
2023-05-17 19:28 ` Konrad Dybcio
2023-05-15 10:12 ` Stephan Gerhold [this message]
2023-05-15 10:12 ` [PATCH RFC 4/5] arm64: dts: qcom: msm8916: Enable modem on two phones Stephan Gerhold
2023-05-15 10:12 ` [PATCH RFC 5/5] arm64: dts: qcom: msm8916: Reserve firmware memory dynamically Stephan Gerhold
2023-05-17 19:25 ` [PATCH 0/5] of: reserved_mem: Provide more control about allocation behavior Konrad Dybcio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230510-dt-resv-bottom-up-v1-3-3bf68873dbed@gerhold.net \
--to=stephan@gerhold.net \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree-spec@vger.kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).