Hi Julien,
> On 9 Sep 2021, at 12:32 pm, Julien Grall <[email protected]> wrote:
>
> Hi Rahul,
>
> On 19/08/2021 13:02, Rahul Singh wrote:
>> Add support for PCI ecam operations to access the PCI
>> configuration space.
>> Signed-off-by: Rahul Singh <[email protected]>
>> ---
>> xen/arch/arm/pci/Makefile | 1 +
>> xen/arch/arm/pci/ecam.c | 63 +++++++++++++++++++++++++++++
>> xen/arch/arm/pci/pci-access.c | 53 ++++++++++++++++++++++++
>> xen/arch/arm/pci/pci-host-common.c | 13 +++++-
>> xen/arch/arm/pci/pci-host-generic.c | 8 +++-
>> xen/include/asm-arm/pci.h | 32 +++++++++++++++
>> 6 files changed, 167 insertions(+), 3 deletions(-)
>> create mode 100644 xen/arch/arm/pci/ecam.c
>> diff --git a/xen/arch/arm/pci/Makefile b/xen/arch/arm/pci/Makefile
>> index f3d97f859e..6f32fbbe67 100644
>> --- a/xen/arch/arm/pci/Makefile
>> +++ b/xen/arch/arm/pci/Makefile
>> @@ -2,3 +2,4 @@ obj-y += pci.o
>> obj-y += pci-access.o
>> obj-y += pci-host-generic.o
>> obj-y += pci-host-common.o
>> +obj-y += ecam.o
>> diff --git a/xen/arch/arm/pci/ecam.c b/xen/arch/arm/pci/ecam.c
>> new file mode 100644
>> index 0000000000..91c691b41f
>> --- /dev/null
>> +++ b/xen/arch/arm/pci/ecam.c
>> @@ -0,0 +1,63 @@
>> +/*
>> + * Copyright (C) 2021 Arm Ltd.
>> + *
>> + * Based on Linux drivers/pci/ecam.c
>> + * Copyright 2016 Broadcom
>> + *
>> + * 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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <xen/pci.h>
>> +#include <xen/sched.h>
>> +
>> +/*
>> + * Function to implement the pci_ops ->map_bus method.
>> + */
>> +void __iomem *pci_ecam_map_bus(struct pci_host_bridge *bridge,
>> + uint32_t sbdf, uint32_t where)
>> +{
>> + const struct pci_config_window *cfg = bridge->sysdata;
>> + unsigned int devfn_shift = cfg->ops->bus_shift - 8;
>> + void __iomem *base;
>> +
>> + pci_sbdf_t sbdf_t = (pci_sbdf_t) sbdf ;
>
> AFAICT, pci_sbdf is an union between a 32-bit and a structure. So please
> don't use the cast and use the 32-bit field to assign the value.
>
> Also, there is an extra space before ';'.
Ok. As per your below comment I will remove the sbdf_t completely.
>
>
>> + unsigned int busn = sbdf_t.bus;
>> +
>> + if ( busn < cfg->busn_start || busn > cfg->busn_end )
>> + return NULL;
>> +
>> + busn -= cfg->busn_start;
>> + base = cfg->win + (busn << cfg->ops->bus_shift);
>> +
>> + return base + (PCI_DEVFN(sbdf_t.dev, sbdf_t.fn) << devfn_shift) + where;
>
> How about using PCI_DEVFN2(sbdf)? This would allow you to drop the use of
> sbdf_t completely (sbdf_t.bus could be replaced with PCI_BUS(sdbf)).
Make sense. I will modify as per your request.
>
>> +}
>> +
>> +/* ECAM ops */
>> +const struct pci_ecam_ops pci_generic_ecam_ops = {
>> + .bus_shift = 20,
>> + .pci_ops = {
>> + .map_bus = pci_ecam_map_bus,
>> + .read = pci_generic_config_read,
>> + .write = pci_generic_config_write,
>> + }
>> +};
>> +
>> +/*
>> + * Local variables:
>> + * mode: C
>> + * c-file-style: "BSD"
>> + * c-basic-offset: 4
>> + * tab-width: 4
>> + * indent-tabs-mode: nil
>> + * End:
>> + */
>> diff --git a/xen/arch/arm/pci/pci-access.c b/xen/arch/arm/pci/pci-access.c
>> index b938047c03..f39f6a3a38 100644
>> --- a/xen/arch/arm/pci/pci-access.c
>> +++ b/xen/arch/arm/pci/pci-access.c
>> @@ -15,6 +15,59 @@
>> */
>> #include <xen/pci.h>
>> +#include <asm/io.h>
>> +
>> +int pci_generic_config_read(struct pci_host_bridge *bridge, uint32_t sbdf,
>> + uint32_t reg, uint32_t len, uint32_t *value)
>> +{
>> + void __iomem *addr = bridge->ops->map_bus(bridge, sbdf, reg);
>
> Please add a newline here.
Ack.
>
>> + if (!addr) {
>
> You seem to use a mix of Xen and Linux coding style. If the file contains
> mostly Xen code, then we should use the former.
Ok. I will fix the coding style in next version.
Regards,
Rahul
