From: William McVicker <willmcvicker@google.com>
To: Rob Herring <robh@kernel.org>
Cc: Zijun Hu <zijun_hu@icloud.com>,
Saravana Kannan <saravanak@google.com>,
Maxime Ripard <mripard@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Grant Likely <grant.likely@secretlab.ca>,
Marc Zyngier <maz@kernel.org>,
Andreas Herrmann <andreas.herrmann@calxeda.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Mike Rapoport <rppt@kernel.org>,
Oreoluwa Babatunde <quic_obabatun@quicinc.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Zijun Hu <quic_zijuhu@quicinc.com>,
stable@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH v4 09/14] of: reserved-memory: Fix using wrong number of cells to get property 'alignment'
Date: Mon, 24 Feb 2025 17:18:07 -0800 [thread overview]
Message-ID: <Z70aTw45KMqTUpBm@google.com> (raw)
In-Reply-To: <20250113232551.GB1983895-robh@kernel.org>
Hi Zijun and Rob,
On 01/13/2025, Rob Herring wrote:
> On Thu, Jan 09, 2025 at 09:27:00PM +0800, Zijun Hu wrote:
> > From: Zijun Hu <quic_zijuhu@quicinc.com>
> >
> > According to DT spec, size of property 'alignment' is based on parent
> > node’s #size-cells property.
> >
> > But __reserved_mem_alloc_size() wrongly uses @dt_root_addr_cells to get
> > the property obviously.
> >
> > Fix by using @dt_root_size_cells instead of @dt_root_addr_cells.
>
> I wonder if changing this might break someone. It's been this way for
> a long time. It might be better to change the spec or just read
> 'alignment' as whatever size it happens to be (len / 4). It's not really
> the kernel's job to validate the DT. We should first have some
> validation in place to *know* if there are any current .dts files that
> would break. That would probably be easier to implement in dtc than
> dtschema. Cases of #address-cells != #size-cells should be pretty rare,
> but that was the default for OpenFirmware.
>
> As the alignment is the base address alignment, it can be argued that
> "#address-cells" makes more sense to use than "#size-cells". So maybe
> the spec was a copy-n-paste error.
Yes, this breaks our Pixel downstream DT :( Also, the upstream Pixel 6 device
tree has cases where #address-cells != #size-cells.
I would prefer to not have this change, but if that's not possible, could we
not backport it to all the stable branches? That way we can just force new
devices to fix this instead of existing devices on older LTS kernels?
Thanks,
Will
>
> >
> > Fixes: 3f0c82066448 ("drivers: of: add initialization code for dynamic reserved memory")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
> > ---
> > drivers/of/of_reserved_mem.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> > index 45517b9e57b1add36bdf2109227ebbf7df631a66..d2753756d7c30adcbd52f57338e281c16d821488 100644
> > --- a/drivers/of/of_reserved_mem.c
> > +++ b/drivers/of/of_reserved_mem.c
> > @@ -409,12 +409,12 @@ static int __init __reserved_mem_alloc_size(unsigned long node, const char *unam
> >
> > prop = of_get_flat_dt_prop(node, "alignment", &len);
> > if (prop) {
> > - if (len != dt_root_addr_cells * sizeof(__be32)) {
> > + if (len != dt_root_size_cells * sizeof(__be32)) {
> > pr_err("invalid alignment property in '%s' node.\n",
> > uname);
> > return -EINVAL;
> > }
> > - align = dt_mem_next_cell(dt_root_addr_cells, &prop);
> > + align = dt_mem_next_cell(dt_root_size_cells, &prop);
> > }
> >
> > nomap = of_get_flat_dt_prop(node, "no-map", NULL) != NULL;
> >
> > --
> > 2.34.1
> >
next prev parent reply other threads:[~2025-02-25 1:18 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-09 13:26 [PATCH v4 00/14] of: fix bugs and improve codes Zijun Hu
2025-01-09 13:26 ` [PATCH v4 01/14] of: Correct child specifier used as input of the 2nd nexus node Zijun Hu
2025-01-10 17:38 ` Rob Herring (Arm)
2025-01-09 13:26 ` [PATCH v4 02/14] of: Do not expose of_alias_scan() and correct its comments Zijun Hu
2025-01-10 17:43 ` Rob Herring
2025-01-10 22:40 ` Zijun Hu
2025-01-09 13:26 ` [PATCH v4 03/14] of: Make of_property_present() applicable to all kinds of property Zijun Hu
2025-01-10 17:45 ` Rob Herring
2025-01-10 22:59 ` Zijun Hu
2025-01-09 13:26 ` [PATCH v4 04/14] of: property: Use of_property_present() for of_fwnode_property_present() Zijun Hu
2025-01-09 13:26 ` [PATCH v4 05/14] of: Fix available buffer size calculating error in API of_device_uevent_modalias() Zijun Hu
2025-01-10 17:48 ` Rob Herring
2025-01-10 23:33 ` Zijun Hu
2025-01-09 13:26 ` [PATCH v4 06/14] of: property: Avoiding using uninitialized variable @imaplen in parse_interrupt_map() Zijun Hu
2025-01-10 20:26 ` Rob Herring
2025-01-10 22:34 ` Zijun Hu
2025-01-11 9:01 ` Krzysztof Kozlowski
2025-01-11 12:52 ` Zijun Hu
2025-01-13 13:43 ` Rob Herring (Arm)
2025-01-09 13:26 ` [PATCH v4 07/14] of: property: Fix potential fwnode reference's argument count got out of range Zijun Hu
2025-01-10 20:35 ` Rob Herring
2025-01-11 0:40 ` Zijun Hu
2025-01-09 13:26 ` [PATCH v4 08/14] of: Remove a duplicated code block Zijun Hu
2025-01-13 14:39 ` Rob Herring (Arm)
2025-01-09 13:27 ` [PATCH v4 09/14] of: reserved-memory: Fix using wrong number of cells to get property 'alignment' Zijun Hu
2025-01-13 23:25 ` Rob Herring
2025-02-25 1:18 ` William McVicker [this message]
2025-02-25 2:46 ` Zijun Hu
2025-02-25 17:46 ` William McVicker
2025-02-26 19:45 ` Rob Herring
2025-02-26 20:31 ` Zijun Hu
2025-02-26 21:30 ` Rob Herring
2025-02-26 21:36 ` William McVicker
2025-02-26 23:25 ` Zijun Hu
2025-02-26 23:52 ` Zijun Hu
2025-02-27 11:55 ` Zijun Hu
2025-01-09 13:27 ` [PATCH v4 10/14] of: reserved-memory: Do not make kmemleak ignore freed address Zijun Hu
2025-01-13 23:27 ` Rob Herring (Arm)
2025-01-09 13:27 ` [PATCH v4 11/14] of: reserved-memory: Warn for missing static reserved memory regions Zijun Hu
2025-01-13 23:16 ` Rob Herring
2025-01-14 14:52 ` Zijun Hu
2025-01-09 13:27 ` [PATCH v4 12/14] of: reserved-memory: Move an assignment to effective place in __reserved_mem_alloc_size() Zijun Hu
2025-01-13 23:32 ` Rob Herring (Arm)
2025-01-09 13:27 ` [PATCH v4 13/14] of/fdt: Check fdt_get_mem_rsv() error in early_init_fdt_scan_reserved_mem() Zijun Hu
2025-01-13 23:32 ` Rob Herring (Arm)
2025-01-09 13:27 ` [PATCH v4 14/14] of: Improve __of_add_property_sysfs() readability Zijun Hu
2025-01-10 20:41 ` Rob Herring
2025-01-10 23:48 ` Zijun Hu
2025-01-11 9:17 ` Krzysztof Kozlowski
2025-01-11 12:44 ` Zijun Hu
2025-01-13 8:33 ` Krzysztof Kozlowski
2025-01-14 15:20 ` Zijun Hu
2025-01-14 15:30 ` Krzysztof Kozlowski
2025-01-13 15:00 ` Zijun Hu
2025-01-13 23:46 ` Rob Herring
2025-01-14 15:13 ` Zijun Hu
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=Z70aTw45KMqTUpBm@google.com \
--to=willmcvicker@google.com \
--cc=andreas.herrmann@calxeda.com \
--cc=catalin.marinas@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@secretlab.ca \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=maz@kernel.org \
--cc=mripard@kernel.org \
--cc=quic_obabatun@quicinc.com \
--cc=quic_zijuhu@quicinc.com \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=saravanak@google.com \
--cc=stable@vger.kernel.org \
--cc=zijun_hu@icloud.com \
/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).