Re: [PATCH v3 2/2] PCI: imx6: limit DBI register length

[Leonard Crestez]

On Wed, 2018-11-28 at 18:36 +0100, Stefan Agner wrote:
> On 28.11.2018 13:19, Stefan Agner wrote:
> > On 21.11.2018 14:47, Leonard Crestez wrote:
> > > My tests show that this series breaks pci cards on 6qdl and I
> > > think it should be reverted until a fix is found. Are you OK with
> > > this?
> > > 
> > > Fixing might require an entirely different approach.
> > 
> > I tried to reproduce this issue on Apalis iMX6 (i.MX 6Q) with a ath9k
> > PCIe WiFi card, the issue you are seeing did not happen. My lspci looks
> > as follows:

I think in order to get "irq: nobody cared" you need to do a soft
reboot after scanning with the card on a functional kernel.

A better way to check for issues is to print when the dbi_length check
fails. I get stack traces like this:

imx6q-pcie 1ffc000.pcie: host bridge /soc/pcie@1ffc000 ranges:
imx6q-pcie 1ffc000.pcie: Parsing ranges property...
imx6q-pcie 1ffc000.pcie:    IO 0x01f80000..0x01f8ffff -> 0x00000000
imx6q-pcie 1ffc000.pcie:   MEM 0x01000000..0x01efffff -> 0x01000000
refuse rd_own_conf where=828
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc1-00012-g864d906b2f62 #3
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[<c01133cc>] (unwind_backtrace) from [<c010da90>] (show_stack+0x10/0x14)
[<c010da90>] (show_stack) from [<c0b30610>] (dump_stack+0x8c/0xac)
[<c0b30610>] (dump_stack) from [<c04f1ff4>] (dw_pcie_rd_own_conf+0x6c/0x78)
[<c04f1ff4>] (dw_pcie_rd_own_conf) from [<c04f2db4>] (dw_pcie_setup_rc+0x54/0x394)
[<c04f2db4>] (dw_pcie_setup_rc) from [<c04f46bc>] (imx6_pcie_host_init+0x80/0x138)
[<c04f46bc>] (imx6_pcie_host_init) from [<c04f2ad8>] (dw_pcie_host_init+0x258/0x4e0)
[<c04f2ad8>] (dw_pcie_host_init) from [<c04f4380>] (imx6_pcie_probe+0x2b8/0x574)
[<c04f4380>] (imx6_pcie_probe) from [<c05d4834>] (platform_drv_probe+0x48/0x98)
[<c05d4834>] (platform_drv_probe) from [<c05d2630>] (really_probe+0x2a8/0x40c)
[<c05d2630>] (really_probe) from [<c05d293c>] (driver_probe_device+0x6c/0x1c0)
[<c05d293c>] (driver_probe_device) from [<c05d2ba0>] (__driver_attach+0x110/0x138)
[<c05d2ba0>] (__driver_attach) from [<c05d04e4>] (bus_for_each_dev+0x70/0xb4)
[<c05d04e4>] (bus_for_each_dev) from [<c05d17f0>] (bus_add_driver+0x1a4/0x264)
[<c05d17f0>] (bus_add_driver) from [<c05d38b4>] (driver_register+0x74/0x108)
[<c05d38b4>] (driver_register) from [<c0102f8c>] (do_one_initcall+0x80/0x26c)
[<c0102f8c>] (do_one_initcall) from [<c11010cc>] (kernel_init_freeable+0x268/0x33c)
[<c11010cc>] (kernel_init_freeable) from [<c0b492e0>] (kernel_init+0x8/0x114)
[<c0b492e0>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)

If rd/wr_own_conf is incorrectly ignored then behavior is somewhat impredictible.

--
Regards,
Leonard