Re: [PATCH v3 11/17] xen/arm: PCI host bridge discovery within XEN on ARM

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.09.2021 20:18, Rahul Singh wrote:
> XEN during boot will read the PCI device tree node “reg” property
> and will map the PCI config space to the XEN memory.
> 
> As of now only "pci-host-ecam-generic" compatible board is supported.
> 
> "linux,pci-domain" device tree property assigns a fixed PCI domain
> number to a host bridge, otherwise an unstable (across boots) unique
> number will be assigned by Linux. XEN access the PCI devices based on
> Segment:Bus:Device:Function. A Segment number in the XEN is same as a
> domain number in Linux. Segment number and domain number has to be in
> sync to access the correct PCI devices.
> 
> XEN will read the “linux,pci-domain” property from the device tree node
> and configure the host bridge segment number accordingly. If this
> property is not available XEN will allocate the unique segment number
> to the host bridge.
> 
> Signed-off-by: Rahul Singh <rahul.singh@xxxxxxx>
> ---
> Change in v3:
> - Modify commit msg based on received comments.
> - Remove added struct match_table{} struct in struct device{}
> - Replace uint32_t sbdf to pci_sbdf_t sbdf to avoid typecast
> - Remove bus_start,bus_end and void *sysdata from struct pci_host_bridge{}
> - Move "#include <asm/pci.h>" in "xen/pci.h" after pci_sbdf_t sbdf declaration

This part, if not split into a separate patch in the first place, wants
mentioning in at least half a sentence of the description. Then ...

> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -15,7 +15,6 @@
>  #include <xen/pfn.h>
>  #include <asm/device.h>
>  #include <asm/numa.h>
> -#include <asm/pci.h>
>  
>  /*
>   * The PCI interface treats multi-function devices as independent
> @@ -62,6 +61,8 @@ typedef union {
>      };
>  } pci_sbdf_t;
>  
> +#include <asm/pci.h>
> +
>  struct pci_dev_info {
>      /*
>       * VF's 'is_extfn' field is used to indicate whether its PF is an 
> extended
> 

.. this part
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
(also if you decide to move this to a separate patch)

Jan