All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexey Kardashevskiy" <aik@ozlabs.ru>
To: "BALATON Zoltan" <balaton@eik.bme.hu>,
	qemu-devel@nongnu.org, qemu-ppc@nongnu.org
Cc: "Nicholas Piggin" <npiggin@gmail.com>,
	"Daniel Henrique Barboza" <danielhb413@gmail.com>,
	"Harsh Prateek Bora" <harshpb@linux.ibm.com>
Subject: Re: [PATCH v2] ppc/vof: Make nextprop behave more like Open Firmware
Date: Fri, 04 Apr 2025 14:00:26 +1100	[thread overview]
Message-ID: <d8d883c3-afcd-44bd-aa71-6ca23d1dd9c3@app.fastmail.com> (raw)
In-Reply-To: <20250331142627.BAA2F4E6029@zero.eik.bme.hu>



On Tue, 1 Apr 2025, at 01:26, BALATON Zoltan wrote:
> The FDT does not normally store name properties but reconstructs it
> from path but each node in Open Firmware should at least have this
> property. This is correctly handled in getprop but nextprop should
> also return it even if not present as a property. This patch fixes
> that and also skips phandle which does not appear in Open Firmware
> and only added for internal use by VOF.
> 
> Explicit name properties are still allowed because they are needed
> e.g. on the root node that guests expect to have specific names as
> seen on real machines instead of being empty so sometimes the node
> name may need to be overriden.
> 
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
> I've tested this with pegasos2 but don't know how to test spapr.
> v2:
> Fixed a typo in commit message
> Simplified loop to get next property name
> 
> hw/ppc/vof.c | 51 ++++++++++++++++++++++++++++++++++-----------------
> 1 file changed, 34 insertions(+), 17 deletions(-)
> 
> diff --git a/hw/ppc/vof.c b/hw/ppc/vof.c
> index 09cb77de93..790d67c096 100644
> --- a/hw/ppc/vof.c
> +++ b/hw/ppc/vof.c
> @@ -353,34 +353,51 @@ static uint32_t vof_nextprop(const void *fdt, uint32_t phandle,
> {
>      int offset, nodeoff = fdt_node_offset_by_phandle(fdt, phandle);
>      char prev[OF_PROPNAME_LEN_MAX + 1];
> -    const char *tmp;
> +    const char *tmp = NULL;
> +    bool match = false;
>  
>      if (readstr(prevaddr, prev, sizeof(prev))) {
>          return PROM_ERROR;
>      }
> -
> -    fdt_for_each_property_offset(offset, fdt, nodeoff) {
> -        if (!fdt_getprop_by_offset(fdt, offset, &tmp, NULL)) {
> -            return 0;
> +    /*
> +     * "name" may or may not be present in fdt but we should still return it.

yeah we should, at least, to match "getprop". I also wonder if VOF does not add "name", then what would do so, do we really expect to see such properties anywhere? Because if not, then we do not need to skip it as we won't find it.

> +     * Do that first and then skip it if seen later. Also skip phandle which is

(a nit) appears to me that if handling of a missing "name" was done after the last property, the patch would look simpler, but not sure and do not insist.

> +     * an internal value we added in vof_build_dt but should not appear here.

I would not hide anything though, unless it breaks something. Thanks,

> +     */
> +    if (prev[0] == '\0') {
> +        tmp = "name";
> +    } else {
> +        if (strcmp(prev, "name") == 0) {
> +            prev[0] = '\0';
>          }
> -        if (prev[0] == '\0' || strcmp(prev, tmp) == 0) {
> -            if (prev[0] != '\0') {
> -                offset = fdt_next_property_offset(fdt, offset);
> -                if (offset < 0) {
> -                    return 0;
> -                }
> -            }
> +        fdt_for_each_property_offset(offset, fdt, nodeoff) {
>              if (!fdt_getprop_by_offset(fdt, offset, &tmp, NULL)) {
>                  return 0;
>              }
> -
> -            if (VOF_MEM_WRITE(nameaddr, tmp, strlen(tmp) + 1) != MEMTX_OK) {
> -                return PROM_ERROR;
> +            if (strcmp(tmp, "name") == 0 || strcmp(tmp, "phandle") == 0) {
> +                continue;
> +            }
> +            if (match) {
> +                break;
>              }
> -            return 1;
> +            if (strcmp(prev, tmp) == 0) {
> +                match = true;
> +                continue;
> +            }
> +            if (prev[0] == '\0') {
> +                break;
> +            }
> +        }
> +        if (offset < 0) {
> +            return 0;
>          }
>      }
> -
> +    if (tmp) {
> +        if (VOF_MEM_WRITE(nameaddr, tmp, strlen(tmp) + 1) != MEMTX_OK) {
> +            return PROM_ERROR;
> +        }
> +        return 1;
> +    }
>      return 0;
> }
>  
> -- 
> 2.41.3
> 
> 


  parent reply	other threads:[~2025-04-04  3:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-31 14:26 [PATCH v2] ppc/vof: Make nextprop behave more like Open Firmware BALATON Zoltan
2025-04-01  3:29 ` Nicholas Piggin
2025-04-01 12:23   ` BALATON Zoltan
2025-04-04  3:00 ` Alexey Kardashevskiy [this message]
2025-04-05  0:09   ` BALATON Zoltan
2025-04-08 10:58     ` Alexey Kardashevskiy

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=d8d883c3-afcd-44bd-aa71-6ca23d1dd9c3@app.fastmail.com \
    --to=aik@ozlabs.ru \
    --cc=balaton@eik.bme.hu \
    --cc=danielhb413@gmail.com \
    --cc=harshpb@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.