xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Sameer Goel <sgoel@codeaurora.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: Thu, 12 Oct 2017 13:45:42 +0100	[thread overview]
Message-ID: <6ba030d4-05f8-c11d-209b-af1c04b5692e@linaro.org> (raw)
In-Reply-To: <1505954230-18892-3-git-send-email-sgoel@codeaurora.org>

Hi,

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 */

Space missing before "fw".

>       struct dev_archdata archdata;
>   };
>   
> diff --git a/xen/include/xen/fwnode.h b/xen/include/xen/fwnode.h
> new file mode 100644
> index 0000000..0fed958
> --- /dev/null
> +++ b/xen/include/xen/fwnode.h
> @@ -0,0 +1,33 @@
> +/*
> + * fwnode.h - Firmware device node object handle type definition.
> + *
> + * Copyright (C) 2015, Intel Corporation
> + * Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Ported from Linux include/linux/fwnode.h
> + *  => commit ce793486e23e0162a732c605189c8028e0910e86
> + *
> + * No functional Xen modifications.
> + */
> +
> +#ifndef __XEN_FWNODE_H_
> +#define __XEN_FWNODE_H_
> +
> +enum fwnode_type {
> +	FWNODE_INVALID = 0,
> +	FWNODE_OF,
> +	FWNODE_ACPI,
> +	FWNODE_ACPI_STATIC,
> +	FWNODE_IRQCHIP
> +};
> +

Looking at Linux code, the fwnode_type already disappeared from Linux 
(see commit db3e50f3234b "device property: Get rid of struct 
fwnode_handle type field").

I understand the goal on using fwnode is to help porting drivers from 
Linux. So how much this has changed now?

Cheers,

> +struct fwnode_handle {
> +	enum fwnode_type type;
> +	struct fwnode_handle *secondary;
> +};
> +
> +#endif
> 

-- 
Julien Grall

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

  reply	other threads:[~2017-10-12 12:45 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 [this message]
2017-10-19 14:53     ` Goel, Sameer
2017-10-24 14:08       ` Julien Grall
2017-11-09  0:56         ` Goel, Sameer
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=6ba030d4-05f8-c11d-209b-af1c04b5692e@linaro.org \
    --to=julien.grall@linaro.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=mjaggi@caviumnetworks.com \
    --cc=nd@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=sgoel@codeaurora.org \
    --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).