Re: [PATCH v5 01/16] staging: mt7621-pci: use generic kernel pci subsystem read and write
On Mon, Jul 30, 2018 at 05:05:15PM +1000, NeilBrown wrote: > On Mon, Jul 30 2018, Sergio Paracuellos wrote: > > > On Mon, Jul 30, 2018 at 03:20:47PM +1000, NeilBrown wrote: > >> On Fri, Jul 27 2018, Sergio Paracuellos wrote: > >> > >> > map_bus callback is called before every .read/.write operation. > >> > Implement it and change custom read write operations for the > >> > pci subsystem generics. Make the probe function to don't use > >> > legacy stuff and request bus resources directly. Get pci register > >> > base from device tree. > >> > > >> > Signed-off-by: Sergio Paracuellos > >> > >> Thanks for your persistence! > >> Something still isn't right ... weird hangs, though my serial connector > >> seems to be causing problems, which doesn't help. > >> > >> I tried one patch at a time, and this first patch doesn't work. > >> > >> It gets to pcibios_align_resource() and crashes because in: > >>if (start < PCIBIOS_MIN_MEM + hose->mem_resource->start) > >>start = PCIBIOS_MIN_MEM + hose->mem_resource->start; > >> > >> hose->mem_resource (which is pcie->mem_resource in mt7621_pci_probe()) > >> is NULL. > >> > >> The call stack is: > >> > >> [2.49] Call Trace: > >> [2.50] [<804a5948>] pcibios_align_resource+0xa0/0xb4 > >> [2.51] [<8002ceb4>] __find_resource+0x150/0x230 > >> [2.52] [<8002d17c>] allocate_resource+0x1e8/0x224 > >> [2.53] [<80365e94>] pci_bus_alloc_resource+0x168/0x1c8 > >> [2.54] [<80374450>] _pci_assign_resource+0xa8/0x180 > >> [2.55] [<803749a4>] pci_assign_resource+0xf4/0x25c > >> [2.56] [<80376820>] assign_requested_resources_sorted+0x90/0xe4 > >> [2.57] [<803771ec>] __assign_resources_sorted+0x110/0x4f8 > >> [2.58] [<80378618>] __pci_bus_assign_resources+0x74/0x240 > >> [2.59] [<803790c8>] pci_assign_unassigned_bus_resources+0x70/0xe8 > >> [2.61] [<804998f8>] mt7621_pci_probe+0x9e8/0xa44 > >> [2.62] [<803b1708>] platform_drv_probe+0x40/0x7c > >> [2.63] [<803afc88>] driver_probe_device+0x31c/0x474 > >> [2.64] [<803afe94>] __driver_attach+0xb4/0x138 > >> [2.65] [<803ad730>] bus_for_each_dev+0x6c/0xb0 > >> [2.65] [<803ae968>] bus_add_driver+0x204/0x24c > >> [2.66] [<803b07d8>] driver_register+0xd0/0x118 > >> [2.67] [<80001618>] do_one_initcall+0x84/0x19c > >> [2.68] [<80741ed0>] kernel_init_freeable+0x248/0x250 > >> [2.69] [<805f549c>] kernel_init+0x14/0x110 > >> > >> So presumably the resources aren't getting initialised properly? > > > > I think you cannot take this separately because it is mixing > > pci legacy code with the new one. > > That's a same. It is generally best if each patch is correct in itself. > It makes review and bisecting much harder if that isn't the case. Yes, you are right. That is the best but it gets a difficult diff to be easily reviewed. Maybe I can reorder a bit patches to get things easier to review. > > I've sprinkled printks around, and it is hanging in ahci_enable_ahci(): > > [9.61] [<803f61b8>] ahci_enable_ahci+0x40/0x144 > [9.62] [<803f6860>] ahci_save_initial_config+0x48/0x428 > [9.63] [<803f49a4>] ahci_init_one+0x4d4/0xb40 > [9.64] [<80371a70>] pci_device_probe+0x90/0x120 > [9.65] [<803afca8>] driver_probe_device+0x31c/0x474 > [9.66] [<803afeb4>] __driver_attach+0xb4/0x138 > [9.67] [<803ad750>] bus_for_each_dev+0x6c/0xb0 > [9.68] [<803ae988>] bus_add_driver+0x204/0x24c > [9.69] [<803b07f8>] driver_register+0xd0/0x118 > [9.70] [<80001618>] do_one_initcall+0x84/0x19c > [9.71] [<80741ed0>] kernel_init_freeable+0x248/0x250 > [9.72] [<805f50bc>] kernel_init+0x14/0x110 > > I have a printk() immediately after the readl() at the top of the > function, and sometimes parts of that are printed, and sometimes not. > So that 'readl' must be causing a problem. > The address it reads from is c4017004. > The value it reads (when it actually gets printed) is 409a1000. > (without patches, it reads from the same place and the returned value is > 8002 - so something's probably mapped wrongly). Yes the assigned BAR's in one and another trace are very different, and that is not good at all. I am going to try another approach closer to the actual legacy-code implementation and see what happends. I hope to send v6 with those changes tonight (GMT+2). > > The dmesg with patches applied is > > [0.00] Linux version 4.18.0-rc5+ (neilb@noble) (gcc version 7.2.0 > (GCC)) #250 SMP Mon Jul 30 16:49:51 AEST 2018 > [0.00] SoC Type: MediaTek MT7621 ver:1 eco:3 > [0.00] bootconsole [early0] enabled > [0.00] CPU0 revision is: 0001992f (MIPS 1004Kc) > [0.00] MIPS: machine is GB-PC1 > [0.00] Determined physical RAM map: > [0.00] memory: 1c00 @ (usable) > [0.00] memory: 0400 @ 2000 (usable) >
Re: [PATCH v5 01/16] staging: mt7621-pci: use generic kernel pci subsystem read and write
On Mon, Jul 30 2018, Sergio Paracuellos wrote:
> On Mon, Jul 30, 2018 at 03:20:47PM +1000, NeilBrown wrote:
>> On Fri, Jul 27 2018, Sergio Paracuellos wrote:
>>
>> > map_bus callback is called before every .read/.write operation.
>> > Implement it and change custom read write operations for the
>> > pci subsystem generics. Make the probe function to don't use
>> > legacy stuff and request bus resources directly. Get pci register
>> > base from device tree.
>> >
>> > Signed-off-by: Sergio Paracuellos
>>
>> Thanks for your persistence!
>> Something still isn't right ... weird hangs, though my serial connector
>> seems to be causing problems, which doesn't help.
>>
>> I tried one patch at a time, and this first patch doesn't work.
>>
>> It gets to pcibios_align_resource() and crashes because in:
>> if (start < PCIBIOS_MIN_MEM + hose->mem_resource->start)
>> start = PCIBIOS_MIN_MEM + hose->mem_resource->start;
>>
>> hose->mem_resource (which is pcie->mem_resource in mt7621_pci_probe())
>> is NULL.
>>
>> The call stack is:
>>
>> [2.49] Call Trace:
>> [2.50] [<804a5948>] pcibios_align_resource+0xa0/0xb4
>> [2.51] [<8002ceb4>] __find_resource+0x150/0x230
>> [2.52] [<8002d17c>] allocate_resource+0x1e8/0x224
>> [2.53] [<80365e94>] pci_bus_alloc_resource+0x168/0x1c8
>> [2.54] [<80374450>] _pci_assign_resource+0xa8/0x180
>> [2.55] [<803749a4>] pci_assign_resource+0xf4/0x25c
>> [2.56] [<80376820>] assign_requested_resources_sorted+0x90/0xe4
>> [2.57] [<803771ec>] __assign_resources_sorted+0x110/0x4f8
>> [2.58] [<80378618>] __pci_bus_assign_resources+0x74/0x240
>> [2.59] [<803790c8>] pci_assign_unassigned_bus_resources+0x70/0xe8
>> [2.61] [<804998f8>] mt7621_pci_probe+0x9e8/0xa44
>> [2.62] [<803b1708>] platform_drv_probe+0x40/0x7c
>> [2.63] [<803afc88>] driver_probe_device+0x31c/0x474
>> [2.64] [<803afe94>] __driver_attach+0xb4/0x138
>> [2.65] [<803ad730>] bus_for_each_dev+0x6c/0xb0
>> [2.65] [<803ae968>] bus_add_driver+0x204/0x24c
>> [2.66] [<803b07d8>] driver_register+0xd0/0x118
>> [2.67] [<80001618>] do_one_initcall+0x84/0x19c
>> [2.68] [<80741ed0>] kernel_init_freeable+0x248/0x250
>> [2.69] [<805f549c>] kernel_init+0x14/0x110
>>
>> So presumably the resources aren't getting initialised properly?
>
> I think you cannot take this separately because it is mixing
> pci legacy code with the new one.
That's a same. It is generally best if each patch is correct in itself.
It makes review and bisecting much harder if that isn't the case.
I've sprinkled printks around, and it is hanging in ahci_enable_ahci():
[9.61] [<803f61b8>] ahci_enable_ahci+0x40/0x144
[9.62] [<803f6860>] ahci_save_initial_config+0x48/0x428
[9.63] [<803f49a4>] ahci_init_one+0x4d4/0xb40
[9.64] [<80371a70>] pci_device_probe+0x90/0x120
[9.65] [<803afca8>] driver_probe_device+0x31c/0x474
[9.66] [<803afeb4>] __driver_attach+0xb4/0x138
[9.67] [<803ad750>] bus_for_each_dev+0x6c/0xb0
[9.68] [<803ae988>] bus_add_driver+0x204/0x24c
[9.69] [<803b07f8>] driver_register+0xd0/0x118
[9.70] [<80001618>] do_one_initcall+0x84/0x19c
[9.71] [<80741ed0>] kernel_init_freeable+0x248/0x250
[9.72] [<805f50bc>] kernel_init+0x14/0x110
I have a printk() immediately after the readl() at the top of the
function, and sometimes parts of that are printed, and sometimes not.
So that 'readl' must be causing a problem.
The address it reads from is c4017004.
The value it reads (when it actually gets printed) is 409a1000.
(without patches, it reads from the same place and the returned value is
8002 - so something's probably mapped wrongly).
The dmesg with patches applied is
[0.00] Linux version 4.18.0-rc5+ (neilb@noble) (gcc version 7.2.0
(GCC)) #250 SMP Mon Jul 30 16:49:51 AEST 2018
[0.00] SoC Type: MediaTek MT7621 ver:1 eco:3
[0.00] bootconsole [early0] enabled
[0.00] CPU0 revision is: 0001992f (MIPS 1004Kc)
[0.00] MIPS: machine is GB-PC1
[0.00] Determined physical RAM map:
[0.00] memory: 1c00 @ (usable)
[0.00] memory: 0400 @ 2000 (usable)
[0.00] Initrd not found or empty - disabling initrd
[0.00] VPE topology {2,2} total 4
[0.00] Primary instruction cache 32kB, VIPT, 4-way, linesize 32 bytes.
[0.00] Primary data cache 32kB, 4-way, PIPT, no aliases, linesize 32
bytes
[0.00] MIPS secondary cache 256kB, 8-way, linesize 32 bytes.
[0.00] Zone ranges:
[0.00] Normal [mem 0x-0x1fff]
[0.00] HighMem [mem 0x2000-0x23ff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00] node 0: [mem
Re: [PATCH v5 01/16] staging: mt7621-pci: use generic kernel pci subsystem read and write
On Mon, Jul 30, 2018 at 03:20:47PM +1000, NeilBrown wrote:
> On Fri, Jul 27 2018, Sergio Paracuellos wrote:
>
> > map_bus callback is called before every .read/.write operation.
> > Implement it and change custom read write operations for the
> > pci subsystem generics. Make the probe function to don't use
> > legacy stuff and request bus resources directly. Get pci register
> > base from device tree.
> >
> > Signed-off-by: Sergio Paracuellos
>
> Thanks for your persistence!
> Something still isn't right ... weird hangs, though my serial connector
> seems to be causing problems, which doesn't help.
>
> I tried one patch at a time, and this first patch doesn't work.
>
> It gets to pcibios_align_resource() and crashes because in:
> if (start < PCIBIOS_MIN_MEM + hose->mem_resource->start)
> start = PCIBIOS_MIN_MEM + hose->mem_resource->start;
>
> hose->mem_resource (which is pcie->mem_resource in mt7621_pci_probe())
> is NULL.
>
> The call stack is:
>
> [2.49] Call Trace:
> [2.50] [<804a5948>] pcibios_align_resource+0xa0/0xb4
> [2.51] [<8002ceb4>] __find_resource+0x150/0x230
> [2.52] [<8002d17c>] allocate_resource+0x1e8/0x224
> [2.53] [<80365e94>] pci_bus_alloc_resource+0x168/0x1c8
> [2.54] [<80374450>] _pci_assign_resource+0xa8/0x180
> [2.55] [<803749a4>] pci_assign_resource+0xf4/0x25c
> [2.56] [<80376820>] assign_requested_resources_sorted+0x90/0xe4
> [2.57] [<803771ec>] __assign_resources_sorted+0x110/0x4f8
> [2.58] [<80378618>] __pci_bus_assign_resources+0x74/0x240
> [2.59] [<803790c8>] pci_assign_unassigned_bus_resources+0x70/0xe8
> [2.61] [<804998f8>] mt7621_pci_probe+0x9e8/0xa44
> [2.62] [<803b1708>] platform_drv_probe+0x40/0x7c
> [2.63] [<803afc88>] driver_probe_device+0x31c/0x474
> [2.64] [<803afe94>] __driver_attach+0xb4/0x138
> [2.65] [<803ad730>] bus_for_each_dev+0x6c/0xb0
> [2.65] [<803ae968>] bus_add_driver+0x204/0x24c
> [2.66] [<803b07d8>] driver_register+0xd0/0x118
> [2.67] [<80001618>] do_one_initcall+0x84/0x19c
> [2.68] [<80741ed0>] kernel_init_freeable+0x248/0x250
> [2.69] [<805f549c>] kernel_init+0x14/0x110
>
> So presumably the resources aren't getting initialised properly?
>
> Thanks,
> NeilBrown
>
>
> > ---
> > drivers/staging/mt7621-pci/pci-mt7621.c | 143
> > ++--
> > 1 file changed, 134 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
> > b/drivers/staging/mt7621-pci/pci-mt7621.c
> > index 650e49b..b4f6de2 100644
> > --- a/drivers/staging/mt7621-pci/pci-mt7621.c
> > +++ b/drivers/staging/mt7621-pci/pci-mt7621.c
> > @@ -53,11 +53,16 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +#include
> > #include
> >
> > #include
> > #include
> >
> > +#include "../../pci/pci.h"
> > +
> > /*
> > * These functions and structures provide the BIOS scan and mapping of the
> > PCI
> > * devices.
> > @@ -178,6 +183,32 @@ static int pcie_link_status = 0;
> > #define PCI_ACCESS_WRITE_2 4
> > #define PCI_ACCESS_WRITE_4 5
> >
> > +/**
> > + * struct mt7621_pcie_port - PCIe port information
> > + * @base: IO mapped register base
> > + * @list: port list
> > + * @pcie: pointer to PCIe host info
> > + * @reset: pointer to port reset control
> > + */
> > +struct mt7621_pcie_port {
> > + void __iomem *base;
> > + struct list_head list;
> > + struct mt7621_pcie *pcie;
> > + struct reset_control *reset;
> > +};
> > +
> > +/**
> > + * struct mt7621_pcie - PCIe host information
> > + * @base: IO Mapped Register Base
> > + * @dev: Pointer to PCIe device
> > + * @ports: pointer to PCIe port information
> > + */
> > +struct mt7621_pcie {
> > + void __iomem *base;
> > + struct device *dev;
> > + struct list_head ports;
> > +};
> > +
> > static inline u32 mt7621_pci_get_cfgaddr(unsigned int bus, unsigned int
> > slot,
> > unsigned int func, unsigned int where)
> > {
> > @@ -297,15 +328,27 @@ pci_config_write(struct pci_bus *bus, unsigned int
> > devfn, int where, int size, u
> > }
> > }
> >
> > +static void __iomem *mt7621_pcie_map_bus(struct pci_bus *bus,
> > +unsigned int devfn, int where)
> > +{
> > + struct mt7621_pcie *pcie = bus->sysdata;
> > + u32 address = mt7621_pci_get_cfgaddr(bus->number, PCI_SLOT(devfn),
> > +PCI_FUNC(devfn), where);
> > +
> > + writel(address, pcie->base + RALINK_PCI_CONFIG_ADDR);
> > +
> > + return pcie->base + RALINK_PCI_CONFIG_DATA_VIRTUAL_REG + (where & 3);
> > +}
> > +
> > struct pci_ops mt7621_pci_ops = {
> > - .read = pci_config_read,
> > - .write = pci_config_write,
> > + .map_bus= mt7621_pcie_map_bus,
> > + .read = pci_generic_config_read,
> > +
Re: [PATCH v5 01/16] staging: mt7621-pci: use generic kernel pci subsystem read and write
On Mon, Jul 30, 2018 at 03:20:47PM +1000, NeilBrown wrote: > On Fri, Jul 27 2018, Sergio Paracuellos wrote: > > > map_bus callback is called before every .read/.write operation. > > Implement it and change custom read write operations for the > > pci subsystem generics. Make the probe function to don't use > > legacy stuff and request bus resources directly. Get pci register > > base from device tree. > > > > Signed-off-by: Sergio Paracuellos > > Thanks for your persistence! > Something still isn't right ... weird hangs, though my serial connector > seems to be causing problems, which doesn't help. > > I tried one patch at a time, and this first patch doesn't work. > > It gets to pcibios_align_resource() and crashes because in: > if (start < PCIBIOS_MIN_MEM + hose->mem_resource->start) > start = PCIBIOS_MIN_MEM + hose->mem_resource->start; > > hose->mem_resource (which is pcie->mem_resource in mt7621_pci_probe()) > is NULL. > > The call stack is: > > [2.49] Call Trace: > [2.50] [<804a5948>] pcibios_align_resource+0xa0/0xb4 > [2.51] [<8002ceb4>] __find_resource+0x150/0x230 > [2.52] [<8002d17c>] allocate_resource+0x1e8/0x224 > [2.53] [<80365e94>] pci_bus_alloc_resource+0x168/0x1c8 > [2.54] [<80374450>] _pci_assign_resource+0xa8/0x180 > [2.55] [<803749a4>] pci_assign_resource+0xf4/0x25c > [2.56] [<80376820>] assign_requested_resources_sorted+0x90/0xe4 > [2.57] [<803771ec>] __assign_resources_sorted+0x110/0x4f8 > [2.58] [<80378618>] __pci_bus_assign_resources+0x74/0x240 > [2.59] [<803790c8>] pci_assign_unassigned_bus_resources+0x70/0xe8 > [2.61] [<804998f8>] mt7621_pci_probe+0x9e8/0xa44 > [2.62] [<803b1708>] platform_drv_probe+0x40/0x7c > [2.63] [<803afc88>] driver_probe_device+0x31c/0x474 > [2.64] [<803afe94>] __driver_attach+0xb4/0x138 > [2.65] [<803ad730>] bus_for_each_dev+0x6c/0xb0 > [2.65] [<803ae968>] bus_add_driver+0x204/0x24c > [2.66] [<803b07d8>] driver_register+0xd0/0x118 > [2.67] [<80001618>] do_one_initcall+0x84/0x19c > [2.68] [<80741ed0>] kernel_init_freeable+0x248/0x250 > [2.69] [<805f549c>] kernel_init+0x14/0x110 > > So presumably the resources aren't getting initialised properly? I think you cannot take this separately because it is mixing pci legacy code with the new one. The 'hose' thing is PCI_LEGACY and we are commented this here so it is wrong. With all patches applied the one to be called should be the one included in pci_generic.c (arch/mips/pci/pci-generic.c +28) not the one included in pci-legacy.c (arch/mips/pci/pci-legacy.c +49) According to the last dmesg trace you included in the last series the resources were properly being assigned, so I think the problem is not there... I have only one concern about the ranges property in the device tree which is using non prefetchable memory and I don't know (because the pci controller for the mt7621 is not described in the datasheet) if that is correct. According the mt7620 and mt7623 it should but I don't know. Also DT it is only mapping 256 bytes (pci configuration space) for registers instead of mapping the whole 4 KB for all the pcie configuration space and I don't know why... So I suppose taking all the patches together the problem persists and it hangs when it tries to enable pci for the ahci... Can you please send me dmesg output with patches applied and without the patches applied in order to check some stuff I could be missing here? Because the code for the pci-legacy for the mips is doing pretty much the same... Well, in a more manual way just mapping manually those it needs. Maybe we can do that also first and try to figure out why the actual code does not work... Anyway we should check that bridges have properly set the 'master' bit before it hangs. This can be done just reading the PCI_COMMAND register with pci_read_config_word. The bit it should be set is the bit 2. Thanks for your effort and patience with this. > > Thanks, > NeilBrown Best regards, Sergio Paracuellos > > > > --- > > drivers/staging/mt7621-pci/pci-mt7621.c | 143 > > ++-- > > 1 file changed, 134 insertions(+), 9 deletions(-) > > > > diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c > > b/drivers/staging/mt7621-pci/pci-mt7621.c > > index 650e49b..b4f6de2 100644 > > --- a/drivers/staging/mt7621-pci/pci-mt7621.c > > +++ b/drivers/staging/mt7621-pci/pci-mt7621.c > > @@ -53,11 +53,16 @@ > > #include > > #include > > #include > > +#include > > +#include > > +#include > > #include > > > > #include > > #include > > > > +#include "../../pci/pci.h" > > + > > /* > > * These functions and structures provide the BIOS scan and mapping of the > > PCI > > * devices. > > @@ -178,6 +183,32 @@ static int pcie_link_status = 0; > > #define PCI_ACCESS_WRITE_2 4 > > #define PCI_ACCESS_WRITE_4 5
Re: [PATCH v5 01/16] staging: mt7621-pci: use generic kernel pci subsystem read and write
On Fri, Jul 27 2018, Sergio Paracuellos wrote:
> map_bus callback is called before every .read/.write operation.
> Implement it and change custom read write operations for the
> pci subsystem generics. Make the probe function to don't use
> legacy stuff and request bus resources directly. Get pci register
> base from device tree.
>
> Signed-off-by: Sergio Paracuellos
Thanks for your persistence!
Something still isn't right ... weird hangs, though my serial connector
seems to be causing problems, which doesn't help.
I tried one patch at a time, and this first patch doesn't work.
It gets to pcibios_align_resource() and crashes because in:
if (start < PCIBIOS_MIN_MEM + hose->mem_resource->start)
start = PCIBIOS_MIN_MEM + hose->mem_resource->start;
hose->mem_resource (which is pcie->mem_resource in mt7621_pci_probe())
is NULL.
The call stack is:
[2.49] Call Trace:
[2.50] [<804a5948>] pcibios_align_resource+0xa0/0xb4
[2.51] [<8002ceb4>] __find_resource+0x150/0x230
[2.52] [<8002d17c>] allocate_resource+0x1e8/0x224
[2.53] [<80365e94>] pci_bus_alloc_resource+0x168/0x1c8
[2.54] [<80374450>] _pci_assign_resource+0xa8/0x180
[2.55] [<803749a4>] pci_assign_resource+0xf4/0x25c
[2.56] [<80376820>] assign_requested_resources_sorted+0x90/0xe4
[2.57] [<803771ec>] __assign_resources_sorted+0x110/0x4f8
[2.58] [<80378618>] __pci_bus_assign_resources+0x74/0x240
[2.59] [<803790c8>] pci_assign_unassigned_bus_resources+0x70/0xe8
[2.61] [<804998f8>] mt7621_pci_probe+0x9e8/0xa44
[2.62] [<803b1708>] platform_drv_probe+0x40/0x7c
[2.63] [<803afc88>] driver_probe_device+0x31c/0x474
[2.64] [<803afe94>] __driver_attach+0xb4/0x138
[2.65] [<803ad730>] bus_for_each_dev+0x6c/0xb0
[2.65] [<803ae968>] bus_add_driver+0x204/0x24c
[2.66] [<803b07d8>] driver_register+0xd0/0x118
[2.67] [<80001618>] do_one_initcall+0x84/0x19c
[2.68] [<80741ed0>] kernel_init_freeable+0x248/0x250
[2.69] [<805f549c>] kernel_init+0x14/0x110
So presumably the resources aren't getting initialised properly?
Thanks,
NeilBrown
> ---
> drivers/staging/mt7621-pci/pci-mt7621.c | 143
> ++--
> 1 file changed, 134 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
> b/drivers/staging/mt7621-pci/pci-mt7621.c
> index 650e49b..b4f6de2 100644
> --- a/drivers/staging/mt7621-pci/pci-mt7621.c
> +++ b/drivers/staging/mt7621-pci/pci-mt7621.c
> @@ -53,11 +53,16 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> #include
>
> #include
> #include
>
> +#include "../../pci/pci.h"
> +
> /*
> * These functions and structures provide the BIOS scan and mapping of the
> PCI
> * devices.
> @@ -178,6 +183,32 @@ static int pcie_link_status = 0;
> #define PCI_ACCESS_WRITE_2 4
> #define PCI_ACCESS_WRITE_4 5
>
> +/**
> + * struct mt7621_pcie_port - PCIe port information
> + * @base: IO mapped register base
> + * @list: port list
> + * @pcie: pointer to PCIe host info
> + * @reset: pointer to port reset control
> + */
> +struct mt7621_pcie_port {
> + void __iomem *base;
> + struct list_head list;
> + struct mt7621_pcie *pcie;
> + struct reset_control *reset;
> +};
> +
> +/**
> + * struct mt7621_pcie - PCIe host information
> + * @base: IO Mapped Register Base
> + * @dev: Pointer to PCIe device
> + * @ports: pointer to PCIe port information
> + */
> +struct mt7621_pcie {
> + void __iomem *base;
> + struct device *dev;
> + struct list_head ports;
> +};
> +
> static inline u32 mt7621_pci_get_cfgaddr(unsigned int bus, unsigned int slot,
>unsigned int func, unsigned int where)
> {
> @@ -297,15 +328,27 @@ pci_config_write(struct pci_bus *bus, unsigned int
> devfn, int where, int size, u
> }
> }
>
> +static void __iomem *mt7621_pcie_map_bus(struct pci_bus *bus,
> + unsigned int devfn, int where)
> +{
> + struct mt7621_pcie *pcie = bus->sysdata;
> + u32 address = mt7621_pci_get_cfgaddr(bus->number, PCI_SLOT(devfn),
> + PCI_FUNC(devfn), where);
> +
> + writel(address, pcie->base + RALINK_PCI_CONFIG_ADDR);
> +
> + return pcie->base + RALINK_PCI_CONFIG_DATA_VIRTUAL_REG + (where & 3);
> +}
> +
> struct pci_ops mt7621_pci_ops = {
> - .read = pci_config_read,
> - .write = pci_config_write,
> + .map_bus= mt7621_pcie_map_bus,
> + .read = pci_generic_config_read,
> + .write = pci_generic_config_write,
> };
>
> static struct resource mt7621_res_pci_mem1;
> static struct resource mt7621_res_pci_io1;
> static struct pci_controller mt7621_controller = {
> - .pci_ops= _pci_ops,
> .mem_resource = _res_pci_mem1,
> .io_resource
