WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

To: Yu Zhiguo <yuzg@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 21 Apr 2010 09:33:02 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Wed, 21 Apr 2010 09:34:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4BCF0352.50909@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4BC7C657.3010609@xxxxxxxxxxxxxx> <20100416145604.GC29398@xxxxxxxxxxxxxxxxxxx> <4BCA82FF.20901@xxxxxxxxxxxxxx> <4BCA8E9A.6090209@xxxxxxxx> <20100419133026.GA17501@xxxxxxxxxxxxxxxxxxx> <4BCD3C2B.3030706@xxxxxxxxxxxxxx> <20100420183301.GA32720@xxxxxxxxxxxxxxxxxxx> <4BCE7120.7020004@xxxxxxxxxxxxxx> <20100421130045.GA24393@xxxxxxxxxxxxxxxxxxx> <4BCF0352.50909@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.4
On 04/21/2010 06:53 AM, Yu Zhiguo wrote:
> Konrad Rzeszutek Wilk wrote:
>   
>>> method-3)
>>>       
>>>> Or maybe better take out the xen_register_gsi out of this double
>>>> #ifdef and move it to its own. Say:
>>>>
>>>>
>>>> #if !defined(CONFIG_XEN)
>>>> static int xen_register_gsi(..)
>>>>
>>>> #endif
>>>>         
>>> We must use #if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && 
>>> !defined(CONFIG_XEN_DOM0_PCI)).
>>> It is ugly, especially if there are more macros.
>>>       
>> Lets go with this one. Maybe after this is done there will be a way to
>> unmangle this spaghetti mess.
>>
>>
>>
>>     
> OK, please refer to this new version:
>
> ----------------
>
> routines 'xen_register_gsi' and 'xen_setup_msi_irqs' cannot be used
> unless macro 'CONFIG_XEN' is defined, otherwise build error occurs.
> So fix them in the header file.
>
> Signed-off-by: Yu Zhiguo <yuzg@xxxxxxxxxxxxxx>
> ---
>  arch/x86/include/asm/xen/pci.h |   55 +++++++++++++++++++++------------------
>  1 files changed, 30 insertions(+), 25 deletions(-)
>
> diff --git a/arch/x86/include/asm/xen/pci.h b/arch/x86/include/asm/xen/pci.h
> index 650645d..27e0667 100644
> --- a/arch/x86/include/asm/xen/pci.h
> +++ b/arch/x86/include/asm/xen/pci.h
> @@ -14,36 +14,12 @@ void xen_teardown_msi_dev(struct pci_dev *dev);
>  int xen_find_device_domain_owner(struct pci_dev *dev);
>  int xen_register_device_domain_owner(struct pci_dev *dev, uint16_t domain);
>  int xen_unregister_device_domain_owner(struct pci_dev *dev);
> -
> -#else
> -static inline int xen_register_gsi(u32 gsi, int triggering, int polarity)
> -{
> -     return -1;
> -}
> -static inline int xen_find_device_domain_owner(struct pci_dev *dev)
> -{
> -     return -1;
> -}
> -static inline int xen_register_device_domain_owner(struct pci_dev *dev,
> -                                                uint16_t domain)
> -{
> -     return -1;
> -}
> -static inline int xen_unregister_device_domain_owner(struct pci_dev *dev)
> -{
> -     return -1;
> -}
> -static inline void xen_teardown_msi_dev(struct pci_dev *dev) { }
>  #endif
>  
>  #if defined(CONFIG_PCI_MSI) && defined(CONFIG_XEN_DOM0_PCI)
>  int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
> -#else
> -static inline int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> -{
> -     return -1;
> -}
>  #endif
> +
>  #if defined(CONFIG_PCI_MSI)
>  
>  /* The drivers/pci/xen-pcifront.c sets this structure to
> @@ -97,4 +73,33 @@ static inline int xen_create_msi_irq(struct pci_dev *dev,
>       return -1;
>  }
>  #endif
> +
> +#if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && 
> !defined(CONFIG_XEN_DOM0_PCI))
>   

As I mentioned in the other mail, there's no need to test CONFIG_XEN.

> +static inline int xen_register_gsi(u32 gsi, int triggering, int polarity)
> +{
> +     return -1;
> +}
> +static inline int xen_find_device_domain_owner(struct pci_dev *dev)
> +{
> +     return -1;
> +}
> +static inline int xen_register_device_domain_owner(struct pci_dev *dev,
> +                                                uint16_t domain)
> +{
> +     return -1;
> +}
> +static inline int xen_unregister_device_domain_owner(struct pci_dev *dev)
> +{
> +     return -1;
> +}
> +static inline void xen_teardown_msi_dev(struct pci_dev *dev) { }
> +#endif
> +
> +#if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && \
> +     (!defined(CONFIG_PCI_MSI) || !defined(CONFIG_XEN_DOM0_PCI)))
>   

Likewise.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>