From: Julien Grall <julien.grall@arm.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: edgar.iglesias@xilinx.com,
Stefano Stabellini <stefanos@xilinx.com>, nd <nd@arm.com>,
xen-devel@lists.xen.org
Subject: Re: [PATCH v3 4/6] xen/arm: zynqmp: eemi access control
Date: Tue, 16 Oct 2018 14:23:25 +0100 [thread overview]
Message-ID: <ea9e4900-c886-415c-585a-db620ac9194c@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1810160947370.4859@sstabellini-ThinkPad-X260>
Hi Stefano,
On 10/16/2018 03:39 AM, Stefano Stabellini wrote:
> On 15/10/2018 08:25, Julien Grall wrote:
>> Hi,
>>
>> On 10/10/2018 11:35 PM, Stefano Stabellini wrote:
>>> On Tue, 28 Aug 2018, Julien Grall wrote:
>>>> On 11/08/18 01:01, Stefano Stabellini wrote:
>>>>> #include <xen/iocap.h>
>>>>> #include <xen/sched.h>
>>>>> #include <xen/types.h>
>>>>> @@ -23,6 +91,721 @@
>>>>> #include <asm/regs.h>
>>>>> #include <asm/platforms/xilinx-zynqmp-eemi.h>
>>>>> +struct pm_access
>>>>> +{
>>>>> + paddr_t addr;
>>>>
>>>> It seems that the address will always page-aligned. So could we store a
>>>> frame
>>>> using mfn_t?
>>>
>>> Yes we could store just the frame. I started to make the change
>>> suggested, and all the required corresponding changes to the
>>> initializations below, for instance:
>>>
>>> [NODE_RPU] = { MM_RPU },
>>>
>>> needs to become:
>>>
>>> [NODE_RPU] = { _mfn(MM_RPU) },
>>>
>>> but when I tried to do that, I get a compilation error:
>>>
>>> xilinx-zynqmp-eemi.c:106:20: error: initializer element is not constant
>>> [NODE_RPU] = { _mfn(MM_RPU) },
>>>
>>> Unfortunately it is not possible to use mfn_t in static initializations,
>>> because it is a static inline. I could do:
>>>
>>
>> This is a bug in GCC older than 5.0.
>>
>>> [NODE_RPU] = { { MM_RPU } },
>>>
>>> which would work for DEBUG builds but wouldn't work for non-DEBUG
>>> builds.
>>>
>>> I'll keep paddr_t for the next version of the series.
>>
>> What is the issue with that on non-debug build? We are using this
>> construction in another place without any compiler issue.
>
> I modified the code as suggested again and tried with newer GCCs (both
> 6.3.1 and 7.3.1) but I still get the same error:
>
> xilinx-zynqmp-eemi.c:105:20: error: initializer element is not constant
> [NODE_RPU] = { _mfn(MM_RPU) },
I actually misremembered the problem. _mfn is using a static inline
helper which is not considered as a constant.
The correct solution would be (mfn_t){ MM_RPU } but GCC 5.0 (and older)
does not parse correctly the type cast. So we workaround by dropping the
cast for the initializer.
On your previous e-mail you said that { { MM_RPU } } would not work for
debug. One solution would be to introduce _mfn_initializer(...) that
would be implemented differently for debug and non-debug.
I think such helper would be useful in other context as well.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-10-16 13:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-11 0:01 [PATCH v3 0/6] zynqmp: Add forwarding of platform specific firmware calls Stefano Stabellini
2018-08-11 0:01 ` [PATCH v3 1/6] xen/arm: introduce platform_smc Stefano Stabellini
2018-08-23 15:37 ` Julien Grall
2018-08-23 23:40 ` Stefano Stabellini
2018-08-11 0:01 ` [PATCH v3 2/6] xen/arm: zynqmp: Forward plaform specific firmware calls Stefano Stabellini
2018-08-23 15:41 ` Julien Grall
2018-08-23 23:56 ` Stefano Stabellini
2018-08-24 9:01 ` Julien Grall
2018-10-10 21:50 ` Stefano Stabellini
2018-08-11 0:01 ` [PATCH v3 3/6] xen/arm: zynqmp: introduce zynqmp specific defines Stefano Stabellini
2018-08-11 0:01 ` [PATCH v3 4/6] xen/arm: zynqmp: eemi access control Stefano Stabellini
2018-08-28 16:05 ` Julien Grall
2018-10-10 22:35 ` Stefano Stabellini
2018-10-15 7:25 ` Julien Grall
2018-10-15 13:00 ` Julien Grall
2018-10-16 2:39 ` Stefano Stabellini
2018-10-16 13:23 ` Julien Grall [this message]
2018-10-17 13:58 ` Stefano Stabellini
2018-10-16 13:29 ` Julien Grall
2018-10-17 14:03 ` Stefano Stabellini
2018-10-17 14:26 ` Julien Grall
2018-08-11 0:01 ` [PATCH v3 5/6] xen/arm: zynqmp: implement zynqmp_eemi Stefano Stabellini
2018-08-28 16:29 ` Julien Grall
2018-10-10 22:49 ` Stefano Stabellini
2018-10-15 7:32 ` Julien Grall
2018-10-15 13:01 ` Julien Grall
2018-10-16 6:48 ` Stefano Stabellini
2018-10-16 13:44 ` Julien Grall
2018-08-11 0:01 ` [PATCH v3 6/6] xen/arm: zynqmp: Remove blacklist of ZynqMP's PM node Stefano Stabellini
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=ea9e4900-c886-415c-585a-db620ac9194c@arm.com \
--to=julien.grall@arm.com \
--cc=edgar.iglesias@xilinx.com \
--cc=nd@arm.com \
--cc=sstabellini@kernel.org \
--cc=stefanos@xilinx.com \
--cc=xen-devel@lists.xen.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 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).