From: Thierry Reding <thierry.reding@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/6] fdtdec: Implement fdtdec_get_max_phandle()
Date: Mon, 11 Mar 2019 10:27:21 +0100 [thread overview]
Message-ID: <20190311092721.GA11545@ulmo> (raw)
In-Reply-To: <CAPnjgZ2YAgGYJQRr6Jv2QX87g45nCkv6i-n2AZ6zAN9Thsz7aQ@mail.gmail.com>
On Sun, Mar 10, 2019 at 03:51:31PM -0600, Simon Glass wrote:
> Hi Thierry,
>
> On Fri, 8 Mar 2019 at 13:11, Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > From: Thierry Reding <treding@nvidia.com>
> >
> > This function allows looking up the highest phandle value stored in a
> > device tree, which is useful to determine the next best phandle value
> > for new nodes.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > include/fdtdec.h | 12 ++++++++++++
> > lib/fdtdec.c | 28 ++++++++++++++++++++++++++++
> > 2 files changed, 40 insertions(+)
>
> Can we use fdt_get_max_phandle() instead? If not, could you please add
> a bit more detail to the commit message as we might consider changing
> the upstream function.
fdt_get_max_phandle() has a slightly awkward signature. It returns the
phandle via the return value, which means that it can distinguish
between error conditions and also uses 0 and -1 to signal no phandle
found and error conditions, respectively. Using the function requires
weird looking code like this:
uint32_t phandle;
phandle = fdt_get_max_phandle(fdt);
if (phandle == 0 || phandle == (uint32_t)-1)
/* process error */;
So the goal here was to add an alternative that would provide a more
standard interface where a regular error could be returned via the
return value and the phandle would be stored in an output parameter on
success.
I specifically didn't want to update the upstream function because it
was introduced about 2.5 years ago and will probably be used by some
number of users. I'm not sure if there's a stable API policy for libfdt,
but I would expect a lot of users to be annoyed if we just changed the
signature of fdt_get_max_phandle().
That said, perhaps another alternative would be to implement this as a
different function. If you look at the subsequent patches, the goal is
to generate a new phandle for newly added nodes, so perhaps something
like this could work:
int fdtdec_generate_phandle(const void *fdt, uint32_t *phandle);
That would be slightly more in line with the higher level of fdtdec
compared to libfdt.
Or perhaps you'd prefer fdt_generate_phandle() in libfdt?
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190311/412b11fe/attachment.sig>
next prev parent reply other threads:[~2019-03-11 9:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-08 20:11 [U-Boot] [PATCH 1/6] fdtdec: Add cpu_to_fdt_{addr,size}() macros Thierry Reding
2019-03-08 20:11 ` [U-Boot] [PATCH 2/6] fdtdec: Implement fdtdec_get_max_phandle() Thierry Reding
2019-03-10 21:51 ` Simon Glass
2019-03-11 9:27 ` Thierry Reding [this message]
2019-03-19 1:24 ` Simon Glass
2019-03-08 20:11 ` [U-Boot] [PATCH 3/6] fdtdec: Implement fdtdec_set_phandle() Thierry Reding
2019-03-10 21:51 ` Simon Glass
2019-03-11 10:04 ` Thierry Reding
2019-03-19 1:24 ` Simon Glass
2019-03-08 20:11 ` [U-Boot] [PATCH 4/6] fdtdec: Implement fdtdec_add_reserved_memory() Thierry Reding
2019-03-10 21:51 ` Simon Glass
2019-03-11 10:06 ` Thierry Reding
2019-03-19 1:24 ` Simon Glass
2019-03-08 20:11 ` [U-Boot] [PATCH 5/6] fdtdec: Implement carveout support functions Thierry Reding
2019-03-10 21:51 ` Simon Glass
2019-03-08 20:11 ` [U-Boot] [PATCH 6/6] p2371-2180: Add support for framebuffer carveouts Thierry Reding
2019-03-19 1:24 ` Simon Glass
2019-03-10 21:51 ` [U-Boot] [PATCH 1/6] fdtdec: Add cpu_to_fdt_{addr, size}() macros Simon Glass
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=20190311092721.GA11545@ulmo \
--to=thierry.reding@gmail.com \
--cc=u-boot@lists.denx.de \
/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