All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: "Orzel, Michal" <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org, Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH] xen/arm: Create GIC node using the node name from host dt
Date: Thu, 20 Feb 2025 10:21:44 +0100	[thread overview]
Message-ID: <6dda7f58-ca4f-4cd9-b2fb-e1adf711951b@gmail.com> (raw)
In-Reply-To: <18e030b4-8268-497e-b42c-f0d920fcb9c7@amd.com>

[-- Attachment #1: Type: text/plain, Size: 2965 bytes --]


On 2/20/25 9:00 AM, Orzel, Michal wrote:
>
> On 20/02/2025 03:26, Stefano Stabellini wrote:
>>
>> On Wed, 19 Feb 2025, Michal Orzel wrote:
>>> At the moment the GIC node we create for hwdom has a name
>>> "interrupt-controller". Change it so that we use the same name as the
>>> GIC node from host device tree. This is done for at least 2 purposes:
>>> 1) The convention in DT spec is that a node name with "reg" property
>>> is formed "node-name@unit-address".
>>> 2) With DT overlay feature, many overlays refer to the GIC node using
>>> the symbol under __symbols__ that we copy to hwdom 1:1. With the name
>>> changed, the symbol is no longer valid and requires error prone manual
>>> change by the user.
>>>
>>> The unit-address part of the node name always refers to the first
>>> address in the "reg" property which in case of GIC, always refers to
>>> GICD and hwdom uses host memory layout.
>>>
>>> Signed-off-by: Michal Orzel<michal.orzel@amd.com>
>> Reviewed-by: Stefano Stabellini<sstabellini@kernel.org>
>>
>> While this fix changes behavior for everyone, so it is risky at RC5, it
>> also fixes bugs with DT overlays, but that is an experimental feature. I
>> am in two minds whether it should go in right now or not. Maybe I would
>> wait until 4.20 is out and commit when the tree reopens.
> Technically this is not a bug, hence no Fixes tag. I'm fine with this patch not
> landing in 4.20. That said, I don't agree with what you wrote about a change in
> behavior. There is no functional change at all. Only the node name change. It
> could impact only those OSes that parse by the exact name which would be super
> irrational and wrong. The only way one should parse intc is by searching for
> "interrupt-controller" property as written in DT spec.

I would prefer to have this changes when the tree reopens.

~ Oleksii

>>
>>> ---
>>>   xen/arch/arm/domain_build.c | 7 ++++++-
>>>   1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>> index 7b47abade196..e760198d8609 100644
>>> --- a/xen/arch/arm/domain_build.c
>>> +++ b/xen/arch/arm/domain_build.c
>>> @@ -1615,6 +1615,7 @@ static int __init make_gic_node(const struct domain *d, void *fdt,
>>>       int res = 0;
>>>       const void *addrcells, *sizecells;
>>>       u32 addrcells_len, sizecells_len;
>>> +    const char *name;
>>>
>>>       /*
>>>        * Xen currently supports only a single GIC. Discard any secondary
>>> @@ -1628,7 +1629,11 @@ static int __init make_gic_node(const struct domain *d, void *fdt,
>>>
>>>       dt_dprintk("Create gic node\n");
>>>
>>> -    res = fdt_begin_node(fdt, "interrupt-controller");
>>> +    /* Use the same name as the GIC node in host device tree */
>>> +    name = strrchr(gic->full_name, '/');
>>> +    name = name ? name + 1 : gic->full_name;
>>> +
>>> +    res = fdt_begin_node(fdt, name);
>>>       if ( res )
>>>           return res;
>>>
>>> --
>>> 2.25.1
>>>

[-- Attachment #2: Type: text/html, Size: 3977 bytes --]

      reply	other threads:[~2025-02-20  9:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-19 17:29 [PATCH] xen/arm: Create GIC node using the node name from host dt Michal Orzel
2025-02-20  2:26 ` Stefano Stabellini
2025-02-20  8:00   ` Orzel, Michal
2025-02-20  9:21     ` Oleksii Kurochko [this message]

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=6dda7f58-ca4f-4cd9-b2fb-e1adf711951b@gmail.com \
    --to=oleksii.kurochko@gmail.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=bertrand.marquis@arm.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.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.