All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Andre Przywara <andre.przywara@linaro.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [PATCH 1/7] tools: ARM: vGICv3: avoid inserting optional DT properties
Date: Wed, 24 Jan 2018 16:39:24 +0000	[thread overview]
Message-ID: <975c58d7-61c0-321c-33b7-cabeeb56abf7@linaro.org> (raw)
In-Reply-To: <63067c49-e12a-16ca-27ae-b7dea7380361@linaro.org>

Hi Andre,

On 24/01/18 16:35, Andre Przywara wrote:
> On 24/01/18 16:08, Julien Grall wrote:
>> (+ Tools maintainers)
>>
>> Hi Andre,
>>
>> On 24/01/18 14:35, Andre Przywara wrote:
>>> When creating a GICv3 devicetree node, we currently insert the
>>> redistributor-stride and #redistributor-regions properties, with fixed
>>> values which are actually the architected ones. But those properties are
>>> optional and only needed to cover for broken platforms, where the values
>>> differ from the architected one. This will never be the case for the
>>
>> I understand that the stride is defined by GICv3. But I don't think this
>> is true for the number of regions. Looking at the spec, multiple regions
>> seems to be allowed (see GICR_TYPER.Last). Did I miss anything?
> 
> Well, the spec does indeed not say anything about it, but the DT binding
> description does:
> ==============
> Optional:
> ...
> - #redistributor-regions: The number of independent contiguous regions
>    occupied by the redistributors. Required if more than one such
>    region is present.
> ==============
> 
> So we don't need it in our case, and in fact we don't implement
> *anything* to actually give the toolstack a choice. So we should
> consequently remove these lines, as they are pointless right now. Should
> we ever need to implement support for multiple regions, bringing this
> back is really our least concern.

I am not against this patch. However, the commit message should not 
induce that platform with more than 1 re-distributor regions are broken.

So I don't see anything which would prevent us to provide a guest memory 
map with multiple re-distributor regions.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-01-24 16:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-24 14:35 [PATCH 0/7] ARM: vGICv3: clean up optional DT properties Andre Przywara
2018-01-24 14:35 ` [PATCH 1/7] tools: ARM: vGICv3: avoid inserting " Andre Przywara
2018-01-24 16:08   ` Julien Grall
2018-01-24 16:35     ` Andre Przywara
2018-01-24 16:39       ` Julien Grall [this message]
2018-01-24 14:35 ` [PATCH 2/7] ARM: vGICv3: drop GUEST_GICV3_RDIST_REGIONS symbol Andre Przywara
2018-01-24 16:13   ` Julien Grall
2018-01-24 16:58     ` Andre Przywara
2018-01-24 17:01       ` Julien Grall
2018-01-24 14:35 ` [PATCH 3/7] ARM: GICv3: emit optional DT property only when necessary Andre Przywara
2018-01-24 16:32   ` Julien Grall
2018-01-24 16:59     ` Andre Przywara
2018-01-24 14:35 ` [PATCH 4/7] ARM: GICv3: use hardware GICv3 redistributor regions for Dom0 Andre Przywara
2018-01-24 16:47   ` Julien Grall
2018-01-24 14:35 ` [PATCH 5/7] ARM: GICv3: simplify GICv3 redistributor stride handling Andre Przywara
2018-01-24 14:35 ` [PATCH 6/7] ARM: vGICv3: always use architected redist stride Andre Przywara
2018-01-24 17:24   ` Julien Grall
2018-01-24 14:35 ` [PATCH 7/7] ARM: vGICv3: remove rdist_stride from VGIC structure Andre Przywara
2018-01-24 17:24   ` Julien Grall

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=975c58d7-61c0-321c-33b7-cabeeb56abf7@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=andre.przywara@linaro.org \
    --cc=ian.jackson@eu.citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wei.liu2@citrix.com \
    --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.