From: "Goel, Sameer" <sgoel@codeaurora.org>
To: Julien Grall <julien.grall@linaro.org>,
xen-devel@lists.xenproject.org, julien.grall@arm.com,
mjaggi@caviumnetworks.com
Cc: sstabellini@kernel.org, wei.liu2@citrix.com,
george.dunlap@eu.citrix.com, Andrew.Cooper3@citrix.com,
jbeulich@suse.com, Ian.Jackson@citrix.com, nd@arm.com,
robin.murphy@arm.com, shankerd@codeaurora.org
Subject: Re: [RFC v2 2/7] arm64: Add definitions for fwnode_handle
Date: Wed, 8 Nov 2017 17:56:00 -0700 [thread overview]
Message-ID: <538f31d3-5200-09f1-5469-f032c7bfb0f9@codeaurora.org> (raw)
In-Reply-To: <a0a8f33d-273c-a22b-42fc-171ecf125c4a@linaro.org>
On 10/24/2017 8:08 AM, Julien Grall wrote:
> Hi Sameer,
>
> On 19/10/17 15:53, Goel, Sameer wrote:
>> On 10/12/2017 6:45 AM, Julien Grall wrote:
>>> On 21/09/17 01:37, Sameer Goel wrote:
>>>> This will be used as a device property to match the DMA capable devices
>>>> with the associated SMMU. The header file is a port from linux. The code
>>>> was changed to remove the types that were not needed for Xen.
>>>
>>> I think you probably want a bit more context in the commit message about implement fwnode.h in common code.
>>>
>>> Within this series, fwnode seems to only be used by Arm. So what would be the advantage to get that in xen/? Is it going to be used by x86 or taken advantage in common code?
>>>
>>>>
>>>> Linux ChangeId:ce793486e23e: driver core / ACPI: Represent ACPI
>>>> companions using fwnode_handle
>>>>
>>>> Signed-off-by: Sameer Goel <sgoel@codeaurora.org>
>>>> ---
>>>> xen/include/asm-arm/device.h | 2 ++
>>>> xen/include/xen/fwnode.h | 33 +++++++++++++++++++++++++++++++++
>>>> 2 files changed, 35 insertions(+)
>>>> create mode 100644 xen/include/xen/fwnode.h
>>>>
>>>> diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
>>>> index 6734ae8..78c38fe 100644
>>>> --- a/xen/include/asm-arm/device.h
>>>> +++ b/xen/include/asm-arm/device.h
>>>> @@ -2,6 +2,7 @@
>>>> #define __ASM_ARM_DEVICE_H
>>>> #include <xen/init.h>
>>>> +#include <xen/fwnode.h>
>>>> enum device_type
>>>> {
>>>> @@ -19,6 +20,7 @@ struct device
>>>> #ifdef CONFIG_HAS_DEVICE_TREE
>>>> struct dt_device_node *of_node; /* Used by drivers imported from Linux */
>>>
>>> I was expecting a todo in the code after the discussion about leave of_node here.
>>>
>>>> #endif
>>>> + struct fwnode_handle *fwnode; /*fw device node identifier */
>> The fwnode handle was provide a match cookie for the SMMUs and not much else. Even with this around we will need the
>> dt info in the device node. I agree that this rolls up into fw spec and I can look at the code cleanup for the next patch.
>
> A clean-up patch would be great but not necessary. What I expect is a TODO mentioning the possible clean-up.
>
I looked through the Linux code a bit more. The reason for pulling in the fwnode was to port the iort code as is. So, really I do not need this at all. All I need is a dummy struct for fwnode.
I will remove this header file and add a new definition in the linux compat header. What is a good location for this header?
> Cheers,
>
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-11-09 0:56 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-21 0:37 [RFC v2 0/7] SMMUv3 driver and the supporting framework Sameer Goel
2017-09-21 0:37 ` [RFC v2 1/7] passthrough/arm: Modify SMMU driver to use generic device definition Sameer Goel
2017-09-21 0:37 ` [RFC v2 2/7] arm64: Add definitions for fwnode_handle Sameer Goel
2017-10-12 12:45 ` Julien Grall
2017-10-19 14:53 ` Goel, Sameer
2017-10-24 14:08 ` Julien Grall
2017-11-09 0:56 ` Goel, Sameer [this message]
2017-09-21 0:37 ` [RFC v2 3/7] xen/passthrough/arm: Introduce iommu_fwspec Sameer Goel
2017-10-12 13:05 ` Julien Grall
2017-10-12 13:36 ` Julien Grall
2017-10-19 14:58 ` Goel, Sameer
2017-09-21 0:37 ` [RFC v2 4/7] ACPI: arm: Support for IORT Sameer Goel
2017-09-21 0:37 ` [RFC v2 5/7] acpi:arm64: Add support for parsing IORT table Sameer Goel
2017-10-10 12:36 ` Manish Jaggi
2017-10-19 15:00 ` Goel, Sameer
2017-10-20 6:25 ` Manish Jaggi
2017-10-12 14:06 ` Julien Grall
2017-10-19 15:21 ` Goel, Sameer
2017-10-24 14:26 ` Julien Grall
2017-10-12 14:23 ` Julien Grall
2017-11-08 14:41 ` Manish Jaggi
2017-11-15 1:27 ` Goel, Sameer
2017-11-15 8:58 ` Julien Grall
2017-09-21 0:37 ` [RFC v2 6/7] Add verbatim copy of arm-smmu-v3.c from Linux Sameer Goel
2017-09-21 0:37 ` [RFC v2 7/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver Sameer Goel
2017-09-26 0:03 ` Goel, Sameer
2017-10-12 16:36 ` Julien Grall
2017-11-19 7:45 ` Goel, Sameer
2017-11-20 14:25 ` Julien Grall
2017-11-20 15:19 ` Robin Murphy
2017-11-20 15:24 ` Julien Grall
2017-11-22 2:17 ` Goel, Sameer
2017-11-27 12:28 ` Julien Grall
2017-09-21 5:43 ` [RFC v2 0/7] SMMUv3 driver and the supporting framework Manish Jaggi
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=538f31d3-5200-09f1-5469-f032c7bfb0f9@codeaurora.org \
--to=sgoel@codeaurora.org \
--cc=Andrew.Cooper3@citrix.com \
--cc=Ian.Jackson@citrix.com \
--cc=george.dunlap@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=julien.grall@arm.com \
--cc=julien.grall@linaro.org \
--cc=mjaggi@caviumnetworks.com \
--cc=nd@arm.com \
--cc=robin.murphy@arm.com \
--cc=shankerd@codeaurora.org \
--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 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).