* [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"
@ 2018-09-12 16:11 Jan Kundrát
2018-09-12 18:49 ` Baruch Siach
0 siblings, 1 reply; 24+ messages in thread
From: Jan Kundrát @ 2018-09-12 16:11 UTC (permalink / raw)
To: Thomas Petazzoni, Lorenzo Pieralisi
Cc: Jason Cooper, Lorenzo Pieralisi, Bjorn Helgaas, linux-pci,
linux-arm-kernel, linux-kernel
Hi,
since commit ee1604381a371b3ea6aec7d5e43b6e3f5e153854 ("PCI: mvebu: Only=20
remap I/O space if configured"), my board (Solidrun Clearfog Base) won't=20
finish booting with 4.18-rc3 won't boot:
> [ 1.741458] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM=
> [ 1.748182] CPU: 1 PID: 72 Comm: kworker/1:2 Tainted: G W =
4.19.0-rc3 #1
> [ 1.756120] Hardware name: Marvell Armada 380/385 (Device Tree)
> [ 1.762063] Workqueue: events deferred_probe_work_func
> [ 1.767222] PC is at ioremap_page_range+0x114/0x1a4
> [ 1.772117] LR is at mvebu_pcie_probe+0x134/0xa60
> [ 1.776832] pc : [<c06e643c>] lr : [<c03e9d5c>] psr: a0000013
> [ 1.783115] sp : ee30dd88 ip : 000f0000 fp : c0837b38
> [ 1.788352] r10: 00000243 r9 : e9200000 r8 : 00000103
> [ 1.793590] r7 : ef6f8000 r6 : fee10000 r5 : fee00000 r4 : ef6f8004
> [ 1.800133] r3 : ef6f8000 r2 : e8000243 r1 : fee0ffff r0 : c0004000
> [ 1.806678] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment=
none
> [ 1.813832] Control: 10c5387d Table: 0000404a DAC: 00000051
> [ 1.819592] Process kworker/1:2 (pid: 72, stack limit =3D 0x(ptrval))
> [ 1.825874] Stack: (0xee30dd88 to 0xee30e000)
> [ 1.830244] dd80: fee10000 e9200000 fee0ffff ffe00000 =
c0007fb8 ee33e224
> [ 1.838445] dda0: 00000000 ee33e010 00000000 ef575610 ee33e224 00000000 =
c0a30ac4 00000002
> [ 1.846646] ddc0: ef9f827c c03e9d5c c0ab6d30 ef9ed434 ee342898 ee342898 =
ee33e1d0 ee33e1dc
> [ 1.854848] dde0: ee342898 00000000 c0a03bc8 c07fcabc 00000001 ef575610 =
ef577000 c02a72b4
> [ 1.863050] de00: 00000000 ee342898 ef6744d0 ef6744d0 ee342898 ef577000 =
c07fcabc 5d6fd1e4
> [ 1.871252] de20: c0a30ac4 ef575610 00000000 c0a30ac4 00000000 00000000 =
c0a30ac4 00000002
> [ 1.879454] de40: ef9e40c0 c043dba4 c0ab3144 ef575610 c0ab3150 c043c4e4 =
ef575610 c0a30ac4
> [ 1.887656] de60: c043cb2c c0a03bc8 00000001 c0a5cf50 00000000 c043c958 =
ef575610 c0a30ac4
> [ 1.895858] de80: ef575610 00000000 ee30ded4 c043cb2c c0a03bc8 00000001 =
c0a5cf50 00000000
> [ 1.904059] dea0: ef9e40c0 c043af7c c0a5cf50 ef484d6c ef66d8b8 5d6fd1e4 =
ef575610 ef575610
> [ 1.912261] dec0: c0a03bc8 ef575644 c0a371c4 c043c7c0 00000003 ef575610 =
00000001 5d6fd1e4
> [ 1.920462] dee0: ef575610 ef575610 c0a373f0 c0a371c4 00000000 c043b160 =
ef575610 c0a371a8
> [ 1.928663] df00: c0a371a8 c043bdf8 c0a371e0 ee2f9880 ef9e40c0 ef9e5300 =
00000000 c01388b4
> [ 1.936864] df20: ef9e40c0 ef9e40c0 ee30c000 ee2f9880 ef9e40c0 ee2f9894 =
c0a02d00 ef9e40d8
> [ 1.945064] df40: ffffe000 00000008 ef9e40c0 c0138e4c ffffe000 c0a5ca32 =
c07d2f68 00000000
> [ 1.953265] df60: ffffe000 eee5e0c0 ee2fa4c0 00000000 ee30c000 ee2f9880 =
c0138ba4 ef4d5ea4
> [ 1.961466] df80: eee5e0dc c013e448 00000001 ee2fa4c0 c013e2fc 00000000 =
00000000 00000000
> [ 1.969668] dfa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 =
00000000 00000000
> [ 1.977869] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 =
00000000 00000000
> [ 1.986069] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 =
00000000 00000000
> [ 1.994277] [<c06e643c>] (ioremap_page_range) from [<c03e9d5c>] (mvebu_p=
cie_probe+0x134/0xa60)
> [ 2.002917] [<c03e9d5c>] (mvebu_pcie_probe) from [<c043dba4>] (platform_=
drv_probe+0x48/0x98)
> [ 2.011382] [<c043dba4>] (platform_drv_probe) from [<c043c4e4>] (really_=
probe+0x1d0/0x2bc)
> [ 2.019671] [<c043c4e4>] (really_probe) from [<c043c958>] (driver_probe_=
device+0x60/0x160)
> [ 2.027961] [<c043c958>] (driver_probe_device) from [<c043af7c>] (bus_fo=
r_each_drv+0x58/0xb8)
> [ 2.036511] [<c043af7c>] (bus_for_each_drv) from [<c043c7c0>] (__device_=
attach+0xd0/0x138)
> [ 2.044800] [<c043c7c0>] (__device_attach) from [<c043b160>] (bus_probe_=
device+0x84/0x8c)
> [ 2.053002] [<c043b160>] (bus_probe_device) from [<c043bdf8>] (deferred_=
probe_work_func+0x60/0x8c)
> [ 2.061991] [<c043bdf8>] (deferred_probe_work_func) from [<c01388b4>] (p=
rocess_one_work+0x218/0x508)
> [ 2.071152] [<c01388b4>] (process_one_work) from [<c0138e4c>] (worker_th=
read+0x2a8/0x5c0)
> [ 2.079355] [<c0138e4c>] (worker_thread) from [<c013e448>] (kthread+0x14=
c/0x154)
> [ 2.086774] [<c013e448>] (kthread) from [<c01010e8>] (ret_from_fork+0x14=
/0x2c)
> [ 2.094015] Exception stack(0xee30dfb0 to 0xee30dff8)
> [ 2.099079] dfa0: 00000000 00000000 =
00000000 00000000
> [ 2.107280] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 =
00000000 00000000
> [ 2.115481] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [ 2.122115] Code: e2844004 e5972000 e3520000 0affffee (e7f001f2)=20
> [ 2.128225] ---[ end trace 7a77412d00a47123 ]---
> [ 2.132853] Kernel panic - not syncing: Fatal exception
> [ 2.138094] CPU0: stopping
> [ 2.140811] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D W 4.=
19.0-rc3 #1
> [ 2.148489] Hardware name: Marvell Armada 380/385 (Device Tree)
> [ 2.154430] [<c01109fc>] (unwind_backtrace) from [<c010c894>] (show_stac=
k+0x10/0x14)
> [ 2.162198] [<c010c894>] (show_stack) from [<c06e29c4>] (dump_stack+0x88=
/0x9c)
> [ 2.169443] [<c06e29c4>] (dump_stack) from [<c010f71c>] (handle_IPI+0x38=
c/0x3ac)
> [ 2.176863] [<c010f71c>] (handle_IPI) from [<c03b4af4>] (gic_handle_irq+=
0x8c/0x90)
> [ 2.184457] [<c03b4af4>] (gic_handle_irq) from [<c0101a0c>] (__irq_svc+0=
x6c/0x90)
> [ 2.191960] Exception stack(0xc0a01f18 to 0xc0a01f60)
> [ 2.197024] 1f00: =
00000000 00001db4
> [ 2.205226] 1f20: ef9d1398 c0119260 ffffe000 c0a03bf0 c0a03c30 00000001 =
00000000 c0a03bc8
> [ 2.213426] 1f40: c0968980 00000000 00000000 c0a01f68 c0108e68 c0108e6c =
60000013 ffffffff
> [ 2.221631] [<c0101a0c>] (__irq_svc) from [<c0108e6c>] (arch_cpu_idle+0x=
38/0x3c)
> [ 2.229051] [<c0108e6c>] (arch_cpu_idle) from [<c014cf4c>] (do_idle+0x1e=
0/0x210)
> [ 2.236469] [<c014cf4c>] (do_idle) from [<c014d218>] (cpu_startup_entry+=
0x18/0x20)
> [ 2.244065] [<c014d218>] (cpu_startup_entry) from [<c0900f48>] (start_ke=
rnel+0x42c/0x454)
> [ 2.252268] [<c0900f48>] (start_kernel) from [<00000000>] ( (null))
> [ 2.258642] Rebooting in 10 seconds..
I cannot easily revert that commit now due to some followup changes. I'll=20
be happy to test patches which attempt to fix this.
The DTS file in use on this board is armada-388-clearfog-base.dts in case=20
it matters (we have some DT add-on patches on top of that, but nothing PCI-=20=
or MBUS-related).
With kind regards,
Jan
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-12 16:11 [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" Jan Kundrát @ 2018-09-12 18:49 ` Baruch Siach 2018-09-12 18:50 ` Thomas Petazzoni 2018-09-12 23:10 ` Russell King - ARM Linux 0 siblings, 2 replies; 24+ messages in thread From: Baruch Siach @ 2018-09-12 18:49 UTC (permalink / raw) To: Jan Kundrát Cc: Lorenzo Pieralisi, Jason Cooper, linux-pci, linux-kernel, Russell King, Thomas Petazzoni, Bjorn Helgaas, linux-arm-kernel SGkgSmFuLAoKSmFuIEt1bmRyw6F0IHdyaXRlczoKPiBzaW5jZSBjb21taXQgZWUxNjA0MzgxYTM3 MWIzZWE2YWVjN2Q1ZTQzYjZlM2Y1ZTE1Mzg1NCAoIlBDSTogbXZlYnU6IE9ubHkKPiByZW1hcCBJ L08gc3BhY2UgaWYgY29uZmlndXJlZCIpLCBteSBib2FyZCAoU29saWRydW4gQ2xlYXJmb2cgQmFz ZSkgd29uJ3QKPiBmaW5pc2ggYm9vdGluZyB3aXRoIDQuMTgtcmMzIHdvbid0IGJvb3Q6CgpZb3Ug bWVhbiAnNC4xOS1yYzMnLCByaWdodD8KCj4+IFsgICAgMS43NDE0NThdIEludGVybmFsIGVycm9y OiBPb3BzIC0gdW5kZWZpbmVkIGluc3RydWN0aW9uOiAwIFsjMV0gU01QIEFSTQo+PiBbICAgIDEu NzQ4MTgyXSBDUFU6IDEgUElEOiA3MiBDb21tOiBrd29ya2VyLzE6MiBUYWludGVkOiBHICAgICAg ICBXICAgICAgICAgNC4xOS4wLXJjMyAjMQoKVGhlICdXJyB0YWludCBtZWFucyB0aGF0IHRoZXJl IHdhcyBhIGtlcm5lbCB3YXJuaW5nIGJlZm9yZS4gV2hpY2gKd2FybmluZyB3YXMgdGhhdD8KCkkg cmVwcm9kdWNlZCB0aGUgc2FtZSBPb3BzIG9uIENsZWFyZm9nIEJhc2Ugd2l0aG91dCBhbnkgdGFp bnQ6CgpbICAgIDEuNDc2NDAxXSBJbnRlcm5hbCBlcnJvcjogT29wcyAtIHVuZGVmaW5lZCBpbnN0 cnVjdGlvbjogMCBbIzFdIFNNUCBBUk0KWyAgICAxLjQ4MzEyNF0gQ1BVOiAxIFBJRDogMTI0MSBD b21tOiBrd29ya2VyLzE6MiBOb3QgdGFpbnRlZCA0LjE5LjAtcmMzICMxNDUKWyAgICAxLjQ5MDAx M10gSGFyZHdhcmUgbmFtZTogTWFydmVsbCBBcm1hZGEgMzgwLzM4NSAoRGV2aWNlIFRyZWUpClsg ICAgMS40OTU5NTNdIFdvcmtxdWV1ZTogZXZlbnRzIGRlZmVycmVkX3Byb2JlX3dvcmtfZnVuYwpb ICAgIDEuNTAxMTA4XSBQQyBpcyBhdCBpb3JlbWFwX3BhZ2VfcmFuZ2UrMHgxMTQvMHgxYTQKWyAg ICAxLjUwNTk5OV0gTFIgaXMgYXQgbXZlYnVfcGNpZV9wcm9iZSsweDEzOC8weDdkOApbICAgIDEu NTEwNzExXSBwYyA6IFs8YzA4MzU1MmM+XSAgICBsciA6IFs8YzA0Mzk4MGM+XSAgICBwc3I6IGEw MDAwMDEzClsgICAgMS41MTY5OTBdIHNwIDogZWYyNTdkODAgIGlwIDogMDAwZjAwMDAgIGZwIDog YzBhNmQwYmMKWyAgICAxLjUyMjIyNV0gcjEwOiAwMDAwMDI0MyAgcjkgOiBlOTIwMDAwMCAgcjgg OiAwMDAwMDEwMwpbICAgIDEuNTI3NDYwXSByNyA6IGVlODdmMDAwICByNiA6IGZlZTEwMDAwICBy NSA6IGZlZTAwMDAwICByNCA6IGVlODdmMDA0ClsgICAgMS41MzQwMDFdIHIzIDogZWU4N2YwMDAg IHIyIDogZTgwMDAyNDMgIHIxIDogZmVlMGZmZmYgIHIwIDogYzAwMDQwMDAKWyAgICAxLjU0MDU0 M10gRmxhZ3M6IE56Q3YgIElSUXMgb24gIEZJUXMgb24gIE1vZGUgU1ZDXzMyICBJU0EgQVJNICBT ZWdtZW50IG5vbmUKWyAgICAxLjU0NzY5M10gQ29udHJvbDogMTBjNTM4N2QgIFRhYmxlOiAwMDAw NDA0YSAgREFDOiAwMDAwMDA1MQpbICAgIDEuNTUzNDUwXSBQcm9jZXNzIGt3b3JrZXIvMToyIChw aWQ6IDEyNDEsIHN0YWNrIGxpbWl0ID0gMHgocHRydmFsKSkKWyAgICAxLjU1OTkwM10gU3RhY2s6 ICgweGVmMjU3ZDgwIHRvIDB4ZWYyNTgwMDApClsgICAgMS41NjQyNjldIDdkODA6IGZlZTEwMDAw IGU5MjAwMDAwIGZlZTBmZmZmIGZmZTAwMDAwIGMwMDA3ZmI4IDAwMDAwMDAwIDAwMDAwMDAwIGVl NzQzMDEwClsgICAgMS41NzI0NjZdIDdkYTA6IGVmMjAwNDEwIGVlNzQzMjY0IDAwMDAwMDAwIDAw MDAwMDAwIGMwZTM5NDc0IDAwMDAwMDAxIDAwMDAwMDAwIGMwNDM5ODBjClsgICAgMS41ODA2NjJd IDdkYzA6IGVmMjU3ZTAwIGMwZTAzYzA4IGVmN2Y3NTc0IGMwYTI2MTIwIGVmN2Y3NTc0IGVlNzQz MjEwIGVlNzQzMjFjIGYyYThiMGQyClsgICAgMS41ODg4NThdIDdkZTA6IGMwZTAzYzA4IGMwZTAz YzA4IGMwZTM5NDc0IGVmMjAwNDEwIDAwMDAwMDAwIGMwNjNjZTg0IDAwMDAwMDAwIGMwMjk2YWQ0 ClsgICAgMS41OTcwNTRdIDdlMDA6IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAw IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIGYyYThiMGQyClsgICAgMS42MDUyNTBdIDdlMjA6 IDAwMDAwMDAwIGVmMjAwNDEwIDAwMDAwMDAwIGMwZTM5NDc0IDAwMDAwMDAwIDAwMDAwMDAwIGMw ZTM5NDc0IDAwMDAwMDAxClsgICAgMS42MTM0NDZdIDdlNDA6IGVmN2U1MmMwIGMwNDhjNGMwIGMw ZTk0NjFjIGVmMjAwNDEwIGMwZTk0NjI4IGMwNDhhOGZjIGVmMjAwNDEwIGMwZTM5NDc0ClsgICAg MS42MjE2NDJdIDdlNjA6IGMwNDhhZjQ0IGMwZTAzYzA4IDAwMDAwMDAxIGMwZTczYzMwIDAwMDAw MDAwIGMwNDhhZDcwIGVmMjAwNDEwIGMwZTM5NDc0ClsgICAgMS42Mjk4MzhdIDdlODA6IGVmMjAw NDEwIDAwMDAwMDAwIGVmMjU3ZWQ0IGMwNDhhZjQ0IGMwZTAzYzA4IDAwMDAwMDAxIGMwZTczYzMw IDAwMDAwMDAwClsgICAgMS42MzgwMzRdIDdlYTA6IGVmN2U1MmMwIGMwNDg5MzU0IGMwZTczYzMw IGVmMDg4ZDZjIGVmMzExNmI4IGYyYThiMGQyIGVmMjAwNDEwIGVmMjAwNDEwClsgICAgMS42NDYy MzBdIDdlYzA6IGMwZTAzYzA4IGVmMjAwNDQ0IGMwZTNmYWU4IGMwNDhhYmQ4IGMwZTAzYzA4IGVm MjAwNDEwIDAwMDAwMDAxIGYyYThiMGQyClsgICAgMS42NTQ0MjZdIDdlZTA6IGVmMjAwNDEwIGVm MjAwNDEwIGMwZTNmZDMwIGMwZTNmYWU4IDAwMDAwMDAwIGMwNDg5NTM4IGVmMjAwNDEwIGMwZTNm YWNjClsgICAgMS42NjI2MjJdIDdmMDA6IGMwZTNmYWNjIGMwNDhhMWQwIGMwZTNmYjA0IGVlNGI3 ZjAwIGVmN2U1MmMwIGVmN2U2NDAwIDAwMDAwMDAwIGMwMTM5OTc0ClsgICAgMS42NzA4MThdIDdm MjA6IGVmN2U1MmMwIGVmN2U1MmMwIGMwZTAyZDAwIGVlNGI3ZjAwIGVmN2U1MmMwIGVlNGI3ZjE0 IGMwZTAyZDAwIGVmN2U1MmQ4ClsgICAgMS42NzkwMTRdIDdmNDA6IGZmZmZlMDAwIDAwMDAwMDA4 IGVmN2U1MmMwIGMwMTM5ZjBjIDAwMDAwMDAwIGMwZTczNjk2IGMwOWVmYmUwIGVlOTUyZDQwClsg ICAgMS42ODcyMDldIDdmNjA6IDAwMDAwMDAwIGVlNzVmNjgwIGVmMjU2MDAwIGVlOTUyZDQwIDAw MDAwMDAwIGVlNGI3ZjAwIGMwMTM5YzY0IGVmMGQ5ZWE0ClsgICAgMS42OTU0MDVdIDdmODA6IGVl NzVmNjljIGMwMTNmNzVjIDAwMDAwMDRlIGVlOTUyZDQwIGMwMTNmNjJjIDAwMDAwMDAwIDAwMDAw MDAwIDAwMDAwMDAwClsgICAgMS43MDM2MDFdIDdmYTA6IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAw MDAwIGMwMTAxMGU4IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwClsgICAgMS43 MTE3OTZdIDdmYzA6IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAw IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwClsgICAgMS43MTk5OTJdIDdmZTA6IDAwMDAwMDAw IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDEzIDAwMDAwMDAwIDAwMDAwMDAwIDAw MDAwMDAwClsgICAgMS43MjgxOTVdIFs8YzA4MzU1MmM+XSAoaW9yZW1hcF9wYWdlX3JhbmdlKSBm cm9tIFs8YzA0Mzk4MGM+XSAobXZlYnVfcGNpZV9wcm9iZSsweDEzOC8weDdkOCkKWyAgICAxLjcz NjgzMF0gWzxjMDQzOTgwYz5dIChtdmVidV9wY2llX3Byb2JlKSBmcm9tIFs8YzA0OGM0YzA+XSAo cGxhdGZvcm1fZHJ2X3Byb2JlKzB4NDgvMHg5OCkKWyAgICAxLjc0NTI5MF0gWzxjMDQ4YzRjMD5d IChwbGF0Zm9ybV9kcnZfcHJvYmUpIGZyb20gWzxjMDQ4YThmYz5dIChyZWFsbHlfcHJvYmUrMHgx ZDAvMHgyYmMpClsgICAgMS43NTM1NzVdIFs8YzA0OGE4ZmM+XSAocmVhbGx5X3Byb2JlKSBmcm9t IFs8YzA0OGFkNzA+XSAoZHJpdmVyX3Byb2JlX2RldmljZSsweDYwLzB4MTYwKQpbICAgIDEuNzYx ODYwXSBbPGMwNDhhZDcwPl0gKGRyaXZlcl9wcm9iZV9kZXZpY2UpIGZyb20gWzxjMDQ4OTM1ND5d IChidXNfZm9yX2VhY2hfZHJ2KzB4NTgvMHhiOCkKWyAgICAxLjc3MDQwNF0gWzxjMDQ4OTM1ND5d IChidXNfZm9yX2VhY2hfZHJ2KSBmcm9tIFs8YzA0OGFiZDg+XSAoX19kZXZpY2VfYXR0YWNoKzB4 ZDAvMHgxMzgpClsgICAgMS43Nzg2ODhdIFs8YzA0OGFiZDg+XSAoX19kZXZpY2VfYXR0YWNoKSBm cm9tIFs8YzA0ODk1Mzg+XSAoYnVzX3Byb2JlX2RldmljZSsweDg0LzB4OGMpClsgICAgMS43ODY4 ODRdIFs8YzA0ODk1Mzg+XSAoYnVzX3Byb2JlX2RldmljZSkgZnJvbSBbPGMwNDhhMWQwPl0gKGRl ZmVycmVkX3Byb2JlX3dvcmtfZnVuYysweDYwLzB4OGMpClsgICAgMS43OTU4NjhdIFs8YzA0OGEx ZDA+XSAoZGVmZXJyZWRfcHJvYmVfd29ya19mdW5jKSBmcm9tIFs8YzAxMzk5NzQ+XSAocHJvY2Vz c19vbmVfd29yaysweDIxOC8weDUwOCkKWyAgICAxLjgwNTAyM10gWzxjMDEzOTk3ND5dIChwcm9j ZXNzX29uZV93b3JrKSBmcm9tIFs8YzAxMzlmMGM+XSAod29ya2VyX3RocmVhZCsweDJhOC8weDVj MCkKWyAgICAxLjgxMzIyMV0gWzxjMDEzOWYwYz5dICh3b3JrZXJfdGhyZWFkKSBmcm9tIFs8YzAx M2Y3NWM+XSAoa3RocmVhZCsweDEzMC8weDEzOCkKWyAgICAxLjgyMDYzNV0gWzxjMDEzZjc1Yz5d IChrdGhyZWFkKSBmcm9tIFs8YzAxMDEwZTg+XSAocmV0X2Zyb21fZm9yaysweDE0LzB4MmMpClsg ICAgMS44Mjc4NzJdIEV4Y2VwdGlvbiBzdGFjaygweGVmMjU3ZmIwIHRvIDB4ZWYyNTdmZjgpClsg ICAgMS44MzI5MzNdIDdmYTA6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAw MDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwClsgICAgMS44NDExMjldIDdmYzA6IDAw MDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAw MDAwIDAwMDAwMDAwClsgICAgMS44NDkzMjRdIDdmZTA6IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAw MDAwIDAwMDAwMDAwIDAwMDAwMDEzIDAwMDAwMDAwClsgICAgMS44NTU5NTRdIENvZGU6IGUyODQ0 MDA0IGU1OTcyMDAwIGUzNTIwMDAwIDBhZmZmZmVlIChlN2YwMDFmMikKWyAgICAxLjg2MjA1OV0g LS0tWyBlbmQgdHJhY2UgNDA2N2NkY2ZkODY1ODlhNSBdLS0tCgo+PiBbICAgIDEuNzU2MTIwXSBI YXJkd2FyZSBuYW1lOiBNYXJ2ZWxsIEFybWFkYSAzODAvMzg1IChEZXZpY2UgVHJlZSkKPj4gWyAg ICAxLjc2MjA2M10gV29ya3F1ZXVlOiBldmVudHMgZGVmZXJyZWRfcHJvYmVfd29ya19mdW5jCj4+ IFsgICAgMS43NjcyMjJdIFBDIGlzIGF0IGlvcmVtYXBfcGFnZV9yYW5nZSsweDExNC8weDFhNAo+ PiBbICAgIDEuNzcyMTE3XSBMUiBpcyBhdCBtdmVidV9wY2llX3Byb2JlKzB4MTM0LzB4YTYwCj4+ IFsgICAgMS43NzY4MzJdIHBjIDogWzxjMDZlNjQzYz5dICAgIGxyIDogWzxjMDNlOWQ1Yz5dICAg IHBzcjogYTAwMDAwMTMKPj4gWyAgICAxLjc4MzExNV0gc3AgOiBlZTMwZGQ4OCAgaXAgOiAwMDBm MDAwMCAgZnAgOiBjMDgzN2IzOAo+PiBbICAgIDEuNzg4MzUyXSByMTA6IDAwMDAwMjQzICByOSA6 IGU5MjAwMDAwICByOCA6IDAwMDAwMTAzCj4+IFsgICAgMS43OTM1OTBdIHI3IDogZWY2ZjgwMDAg IHI2IDogZmVlMTAwMDAgIHI1IDogZmVlMDAwMDAgIHI0IDogZWY2ZjgwMDQKPj4gWyAgICAxLjgw MDEzM10gcjMgOiBlZjZmODAwMCAgcjIgOiBlODAwMDI0MyAgcjEgOiBmZWUwZmZmZiAgcjAgOiBj MDAwNDAwMAo+PiBbICAgIDEuODA2Njc4XSBGbGFnczogTnpDdiAgSVJRcyBvbiAgRklRcyBvbiAg TW9kZSBTVkNfMzIgIElTQSBBUk0gIFNlZ21lbnQgbm9uZQo+PiBbICAgIDEuODEzODMyXSBDb250 cm9sOiAxMGM1Mzg3ZCAgVGFibGU6IDAwMDA0MDRhICBEQUM6IDAwMDAwMDUxCj4+IFsgICAgMS44 MTk1OTJdIFByb2Nlc3Mga3dvcmtlci8xOjIgKHBpZDogNzIsIHN0YWNrIGxpbWl0ID0gMHgocHRy dmFsKSkKPj4gWyAgICAxLjgyNTg3NF0gU3RhY2s6ICgweGVlMzBkZDg4IHRvIDB4ZWUzMGUwMDAp Cj4+IFsgICAgMS44MzAyNDRdIGRkODA6ICAgICAgICAgICAgICAgICAgIGZlZTEwMDAwIGU5MjAw MDAwIGZlZTBmZmZmIGZmZTAwMDAwIGMwMDA3ZmI4IGVlMzNlMjI0Cj4+IFsgICAgMS44Mzg0NDVd IGRkYTA6IDAwMDAwMDAwIGVlMzNlMDEwIDAwMDAwMDAwIGVmNTc1NjEwIGVlMzNlMjI0IDAwMDAw MDAwIGMwYTMwYWM0IDAwMDAwMDAyCj4+IFsgICAgMS44NDY2NDZdIGRkYzA6IGVmOWY4MjdjIGMw M2U5ZDVjIGMwYWI2ZDMwIGVmOWVkNDM0IGVlMzQyODk4IGVlMzQyODk4IGVlMzNlMWQwIGVlMzNl MWRjCj4+IFsgICAgMS44NTQ4NDhdIGRkZTA6IGVlMzQyODk4IDAwMDAwMDAwIGMwYTAzYmM4IGMw N2ZjYWJjIDAwMDAwMDAxIGVmNTc1NjEwIGVmNTc3MDAwIGMwMmE3MmI0Cj4+IFsgICAgMS44NjMw NTBdIGRlMDA6IDAwMDAwMDAwIGVlMzQyODk4IGVmNjc0NGQwIGVmNjc0NGQwIGVlMzQyODk4IGVm NTc3MDAwIGMwN2ZjYWJjIDVkNmZkMWU0Cj4+IFsgICAgMS44NzEyNTJdIGRlMjA6IGMwYTMwYWM0 IGVmNTc1NjEwIDAwMDAwMDAwIGMwYTMwYWM0IDAwMDAwMDAwIDAwMDAwMDAwIGMwYTMwYWM0IDAw MDAwMDAyCj4+IFsgICAgMS44Nzk0NTRdIGRlNDA6IGVmOWU0MGMwIGMwNDNkYmE0IGMwYWIzMTQ0 IGVmNTc1NjEwIGMwYWIzMTUwIGMwNDNjNGU0IGVmNTc1NjEwIGMwYTMwYWM0Cj4+IFsgICAgMS44 ODc2NTZdIGRlNjA6IGMwNDNjYjJjIGMwYTAzYmM4IDAwMDAwMDAxIGMwYTVjZjUwIDAwMDAwMDAw IGMwNDNjOTU4IGVmNTc1NjEwIGMwYTMwYWM0Cj4+IFsgICAgMS44OTU4NThdIGRlODA6IGVmNTc1 NjEwIDAwMDAwMDAwIGVlMzBkZWQ0IGMwNDNjYjJjIGMwYTAzYmM4IDAwMDAwMDAxIGMwYTVjZjUw IDAwMDAwMDAwCj4+IFsgICAgMS45MDQwNTldIGRlYTA6IGVmOWU0MGMwIGMwNDNhZjdjIGMwYTVj ZjUwIGVmNDg0ZDZjIGVmNjZkOGI4IDVkNmZkMWU0IGVmNTc1NjEwIGVmNTc1NjEwCj4+IFsgICAg MS45MTIyNjFdIGRlYzA6IGMwYTAzYmM4IGVmNTc1NjQ0IGMwYTM3MWM0IGMwNDNjN2MwIDAwMDAw MDAzIGVmNTc1NjEwIDAwMDAwMDAxIDVkNmZkMWU0Cj4+IFsgICAgMS45MjA0NjJdIGRlZTA6IGVm NTc1NjEwIGVmNTc1NjEwIGMwYTM3M2YwIGMwYTM3MWM0IDAwMDAwMDAwIGMwNDNiMTYwIGVmNTc1 NjEwIGMwYTM3MWE4Cj4+IFsgICAgMS45Mjg2NjNdIGRmMDA6IGMwYTM3MWE4IGMwNDNiZGY4IGMw YTM3MWUwIGVlMmY5ODgwIGVmOWU0MGMwIGVmOWU1MzAwIDAwMDAwMDAwIGMwMTM4OGI0Cj4+IFsg ICAgMS45MzY4NjRdIGRmMjA6IGVmOWU0MGMwIGVmOWU0MGMwIGVlMzBjMDAwIGVlMmY5ODgwIGVm OWU0MGMwIGVlMmY5ODk0IGMwYTAyZDAwIGVmOWU0MGQ4Cj4+IFsgICAgMS45NDUwNjRdIGRmNDA6 IGZmZmZlMDAwIDAwMDAwMDA4IGVmOWU0MGMwIGMwMTM4ZTRjIGZmZmZlMDAwIGMwYTVjYTMyIGMw N2QyZjY4IDAwMDAwMDAwCj4+IFsgICAgMS45NTMyNjVdIGRmNjA6IGZmZmZlMDAwIGVlZTVlMGMw IGVlMmZhNGMwIDAwMDAwMDAwIGVlMzBjMDAwIGVlMmY5ODgwIGMwMTM4YmE0IGVmNGQ1ZWE0Cj4+ IFsgICAgMS45NjE0NjZdIGRmODA6IGVlZTVlMGRjIGMwMTNlNDQ4IDAwMDAwMDAxIGVlMmZhNGMw IGMwMTNlMmZjIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwCj4+IFsgICAgMS45Njk2NjhdIGRm YTA6IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIGMwMTAxMGU4IDAwMDAwMDAwIDAwMDAwMDAw IDAwMDAwMDAwIDAwMDAwMDAwCj4+IFsgICAgMS45Nzc4NjldIGRmYzA6IDAwMDAwMDAwIDAwMDAw MDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAw Cj4+IFsgICAgMS45ODYwNjldIGRmZTA6IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAw MDAwIDAwMDAwMDEzIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwCj4+IFsgICAgMS45OTQyNzdd IFs8YzA2ZTY0M2M+XSAoaW9yZW1hcF9wYWdlX3JhbmdlKSBmcm9tIFs8YzAzZTlkNWM+XSAobXZl YnVfcGNpZV9wcm9iZSsweDEzNC8weGE2MCkKPj4gWyAgICAyLjAwMjkxN10gWzxjMDNlOWQ1Yz5d IChtdmVidV9wY2llX3Byb2JlKSBmcm9tIFs8YzA0M2RiYTQ+XSAocGxhdGZvcm1fZHJ2X3Byb2Jl KzB4NDgvMHg5OCkKPj4gWyAgICAyLjAxMTM4Ml0gWzxjMDQzZGJhND5dIChwbGF0Zm9ybV9kcnZf cHJvYmUpIGZyb20gWzxjMDQzYzRlND5dIChyZWFsbHlfcHJvYmUrMHgxZDAvMHgyYmMpCj4+IFsg ICAgMi4wMTk2NzFdIFs8YzA0M2M0ZTQ+XSAocmVhbGx5X3Byb2JlKSBmcm9tIFs8YzA0M2M5NTg+ XSAoZHJpdmVyX3Byb2JlX2RldmljZSsweDYwLzB4MTYwKQo+PiBbICAgIDIuMDI3OTYxXSBbPGMw NDNjOTU4Pl0gKGRyaXZlcl9wcm9iZV9kZXZpY2UpIGZyb20gWzxjMDQzYWY3Yz5dIChidXNfZm9y X2VhY2hfZHJ2KzB4NTgvMHhiOCkKPj4gWyAgICAyLjAzNjUxMV0gWzxjMDQzYWY3Yz5dIChidXNf Zm9yX2VhY2hfZHJ2KSBmcm9tIFs8YzA0M2M3YzA+XSAoX19kZXZpY2VfYXR0YWNoKzB4ZDAvMHgx MzgpCj4+IFsgICAgMi4wNDQ4MDBdIFs8YzA0M2M3YzA+XSAoX19kZXZpY2VfYXR0YWNoKSBmcm9t IFs8YzA0M2IxNjA+XSAoYnVzX3Byb2JlX2RldmljZSsweDg0LzB4OGMpCj4+IFsgICAgMi4wNTMw MDJdIFs8YzA0M2IxNjA+XSAoYnVzX3Byb2JlX2RldmljZSkgZnJvbSBbPGMwNDNiZGY4Pl0gKGRl ZmVycmVkX3Byb2JlX3dvcmtfZnVuYysweDYwLzB4OGMpCj4+IFsgICAgMi4wNjE5OTFdIFs8YzA0 M2JkZjg+XSAoZGVmZXJyZWRfcHJvYmVfd29ya19mdW5jKSBmcm9tIFs8YzAxMzg4YjQ+XSAocHJv Y2Vzc19vbmVfd29yaysweDIxOC8weDUwOCkKPj4gWyAgICAyLjA3MTE1Ml0gWzxjMDEzODhiND5d IChwcm9jZXNzX29uZV93b3JrKSBmcm9tIFs8YzAxMzhlNGM+XSAod29ya2VyX3RocmVhZCsweDJh OC8weDVjMCkKPj4gWyAgICAyLjA3OTM1NV0gWzxjMDEzOGU0Yz5dICh3b3JrZXJfdGhyZWFkKSBm cm9tIFs8YzAxM2U0NDg+XSAoa3RocmVhZCsweDE0Yy8weDE1NCkKPj4gWyAgICAyLjA4Njc3NF0g WzxjMDEzZTQ0OD5dIChrdGhyZWFkKSBmcm9tIFs8YzAxMDEwZTg+XSAocmV0X2Zyb21fZm9yaysw eDE0LzB4MmMpCj4+IFsgICAgMi4wOTQwMTVdIEV4Y2VwdGlvbiBzdGFjaygweGVlMzBkZmIwIHRv IDB4ZWUzMGRmZjgpCj4+IFsgICAgMi4wOTkwNzldIGRmYTA6ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwCj4+IFsg ICAgMi4xMDcyODBdIGRmYzA6IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAw MDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwCj4+IFsgICAgMi4xMTU0ODFdIGRmZTA6 IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDEzIDAwMDAwMDAwCj4+ IFsgICAgMi4xMjIxMTVdIENvZGU6IGUyODQ0MDA0IGU1OTcyMDAwIGUzNTIwMDAwIDBhZmZmZmVl IChlN2YwMDFmMikKPj4gWyAgICAyLjEyODIyNV0gLS0tWyBlbmQgdHJhY2UgN2E3NzQxMmQwMGE0 NzEyMyBdLS0tCj4+IFsgICAgMi4xMzI4NTNdIEtlcm5lbCBwYW5pYyAtIG5vdCBzeW5jaW5nOiBG YXRhbCBleGNlcHRpb24KPj4gWyAgICAyLjEzODA5NF0gQ1BVMDogc3RvcHBpbmcKPj4gWyAgICAy LjE0MDgxMV0gQ1BVOiAwIFBJRDogMCBDb21tOiBzd2FwcGVyLzAgVGFpbnRlZDogRyAgICAgIEQg VyAgICAgICAgIDQuMTkuMC1yYzMgIzEKPj4gWyAgICAyLjE0ODQ4OV0gSGFyZHdhcmUgbmFtZTog TWFydmVsbCBBcm1hZGEgMzgwLzM4NSAoRGV2aWNlIFRyZWUpCj4+IFsgICAgMi4xNTQ0MzBdIFs8 YzAxMTA5ZmM+XSAodW53aW5kX2JhY2t0cmFjZSkgZnJvbSBbPGMwMTBjODk0Pl0gKHNob3dfc3Rh Y2srMHgxMC8weDE0KQo+PiBbICAgIDIuMTYyMTk4XSBbPGMwMTBjODk0Pl0gKHNob3dfc3RhY2sp IGZyb20gWzxjMDZlMjljND5dIChkdW1wX3N0YWNrKzB4ODgvMHg5YykKPj4gWyAgICAyLjE2OTQ0 M10gWzxjMDZlMjljND5dIChkdW1wX3N0YWNrKSBmcm9tIFs8YzAxMGY3MWM+XSAoaGFuZGxlX0lQ SSsweDM4Yy8weDNhYykKPj4gWyAgICAyLjE3Njg2M10gWzxjMDEwZjcxYz5dIChoYW5kbGVfSVBJ KSBmcm9tIFs8YzAzYjRhZjQ+XSAoZ2ljX2hhbmRsZV9pcnErMHg4Yy8weDkwKQo+PiBbICAgIDIu MTg0NDU3XSBbPGMwM2I0YWY0Pl0gKGdpY19oYW5kbGVfaXJxKSBmcm9tIFs8YzAxMDFhMGM+XSAo X19pcnFfc3ZjKzB4NmMvMHg5MCkKPj4gWyAgICAyLjE5MTk2MF0gRXhjZXB0aW9uIHN0YWNrKDB4 YzBhMDFmMTggdG8gMHhjMGEwMWY2MCkKPj4gWyAgICAyLjE5NzAyNF0gMWYwMDogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDAwMDAgMDAw MDFkYjQKPj4gWyAgICAyLjIwNTIyNl0gMWYyMDogZWY5ZDEzOTggYzAxMTkyNjAgZmZmZmUwMDAg YzBhMDNiZjAgYzBhMDNjMzAgMDAwMDAwMDEgMDAwMDAwMDAgYzBhMDNiYzgKPj4gWyAgICAyLjIx MzQyNl0gMWY0MDogYzA5Njg5ODAgMDAwMDAwMDAgMDAwMDAwMDAgYzBhMDFmNjggYzAxMDhlNjgg YzAxMDhlNmMgNjAwMDAwMTMgZmZmZmZmZmYKPj4gWyAgICAyLjIyMTYzMV0gWzxjMDEwMWEwYz5d IChfX2lycV9zdmMpIGZyb20gWzxjMDEwOGU2Yz5dIChhcmNoX2NwdV9pZGxlKzB4MzgvMHgzYykK Pj4gWyAgICAyLjIyOTA1MV0gWzxjMDEwOGU2Yz5dIChhcmNoX2NwdV9pZGxlKSBmcm9tIFs8YzAx NGNmNGM+XSAoZG9faWRsZSsweDFlMC8weDIxMCkKPj4gWyAgICAyLjIzNjQ2OV0gWzxjMDE0Y2Y0 Yz5dIChkb19pZGxlKSBmcm9tIFs8YzAxNGQyMTg+XSAoY3B1X3N0YXJ0dXBfZW50cnkrMHgxOC8w eDIwKQo+PiBbICAgIDIuMjQ0MDY1XSBbPGMwMTRkMjE4Pl0gKGNwdV9zdGFydHVwX2VudHJ5KSBm cm9tIFs8YzA5MDBmNDg+XSAoc3RhcnRfa2VybmVsKzB4NDJjLzB4NDU0KQo+PiBbICAgIDIuMjUy MjY4XSBbPGMwOTAwZjQ4Pl0gKHN0YXJ0X2tlcm5lbCkgZnJvbSBbPDAwMDAwMDAwPl0gKCAgKG51 bGwpKQo+PiBbICAgIDIuMjU4NjQyXSBSZWJvb3RpbmcgaW4gMTAgc2Vjb25kcy4uCj4KPiBJIGNh bm5vdCBlYXNpbHkgcmV2ZXJ0IHRoYXQgY29tbWl0IG5vdyBkdWUgdG8gc29tZSBmb2xsb3d1cCBj aGFuZ2VzLiBJJ2xsCj4gYmUgaGFwcHkgdG8gdGVzdCBwYXRjaGVzIHdoaWNoIGF0dGVtcHQgdG8g Zml4IHRoaXMuCj4KPiBUaGUgRFRTIGZpbGUgaW4gdXNlIG9uIHRoaXMgYm9hcmQgaXMgYXJtYWRh LTM4OC1jbGVhcmZvZy1iYXNlLmR0cyBpbiBjYXNlCj4gaXQgbWF0dGVycyAod2UgaGF2ZSBzb21l IERUIGFkZC1vbiBwYXRjaGVzIG9uIHRvcCBvZiB0aGF0LCBidXQgbm90aGluZyBQQ0ktCj4gb3Ig TUJVUy1yZWxhdGVkKS4KCmJhcnVjaAoKLS0KICAgICBodHRwOi8vYmFydWNoLnNpYWNoLm5hbWUv YmxvZy8gICAgICAgICAgICAgICAgICB+LiAufiAgIFRrIE9wZW4gU3lzdGVtcwo9fS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLW9vTy0tVS0tT29vLS0tLS0t LS0tLS0tez0KICAgLSBiYXJ1Y2hAdGtvcy5jby5pbCAtIHRlbDogKzk3Mi41Mi4zNjguNDY1Niwg aHR0cDovL3d3dy50a29zLmNvLmlsIC0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1r ZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWls bWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-12 18:49 ` Baruch Siach @ 2018-09-12 18:50 ` Thomas Petazzoni 2018-09-12 19:00 ` Jan Kundrát 2018-09-12 23:10 ` Russell King - ARM Linux 1 sibling, 1 reply; 24+ messages in thread From: Thomas Petazzoni @ 2018-09-12 18:50 UTC (permalink / raw) To: Baruch Siach Cc: Lorenzo Pieralisi, Jason Cooper, linux-pci, linux-kernel, Russell King, Bjorn Helgaas, Jan Kundrát, linux-arm-kernel SmFuLCBCYXJ1Y2gsCgpPbiBXZWQsIDEyIFNlcCAyMDE4IDIxOjQ5OjQxICswMzAwLCBCYXJ1Y2gg U2lhY2ggd3JvdGU6Cgo+IEphbiBLdW5kcsOhdCB3cml0ZXM6Cj4gPiBzaW5jZSBjb21taXQgZWUx NjA0MzgxYTM3MWIzZWE2YWVjN2Q1ZTQzYjZlM2Y1ZTE1Mzg1NCAoIlBDSTogbXZlYnU6IE9ubHkK PiA+IHJlbWFwIEkvTyBzcGFjZSBpZiBjb25maWd1cmVkIiksIG15IGJvYXJkIChTb2xpZHJ1biBD bGVhcmZvZyBCYXNlKSB3b24ndAo+ID4gZmluaXNoIGJvb3Rpbmcgd2l0aCA0LjE4LXJjMyB3b24n dCBib290OiAgCj4gCj4gWW91IG1lYW4gJzQuMTktcmMzJywgcmlnaHQ/Cj4gCj4gPj4gWyAgICAx Ljc0MTQ1OF0gSW50ZXJuYWwgZXJyb3I6IE9vcHMgLSB1bmRlZmluZWQgaW5zdHJ1Y3Rpb246IDAg WyMxXSBTTVAgQVJNCj4gPj4gWyAgICAxLjc0ODE4Ml0gQ1BVOiAxIFBJRDogNzIgQ29tbToga3dv cmtlci8xOjIgVGFpbnRlZDogRyAgICAgICAgVyAgICAgICAgIDQuMTkuMC1yYzMgIzEgIAo+IAo+ IFRoZSAnVycgdGFpbnQgbWVhbnMgdGhhdCB0aGVyZSB3YXMgYSBrZXJuZWwgd2FybmluZyBiZWZv cmUuIFdoaWNoCj4gd2FybmluZyB3YXMgdGhhdD8KPiAKPiBJIHJlcHJvZHVjZWQgdGhlIHNhbWUg T29wcyBvbiBDbGVhcmZvZyBCYXNlIHdpdGhvdXQgYW55IHRhaW50OgoKVGhhbmtzIGZvciB0aGUg cmVwb3J0LCBJJ2xsIGhhdmUgYSBsb29rIHRvbW9ycm93IHdoZW4gSSBoYXZlIHRvCkNsZWFyRm9n IGhhcmR3YXJlLgoKVGhhbmtzLAoKVGhvbWFzCi0tIApUaG9tYXMgUGV0YXp6b25pLCBDVE8sIEJv b3RsaW4KRW1iZWRkZWQgTGludXggYW5kIEtlcm5lbCBlbmdpbmVlcmluZwpodHRwczovL2Jvb3Rs aW4uY29tCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwps aW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJh ZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51 eC1hcm0ta2VybmVsCg== ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-12 18:50 ` Thomas Petazzoni @ 2018-09-12 19:00 ` Jan Kundrát 0 siblings, 0 replies; 24+ messages in thread From: Jan Kundrát @ 2018-09-12 19:00 UTC (permalink / raw) To: Thomas Petazzoni, Baruch Siach Cc: Lorenzo Pieralisi, Jason Cooper, linux-pci, linux-kernel, Bjorn Helgaas, linux-arm-kernel, Russell King >> You mean '4.19-rc3', right? Right, sorry. >>>> [ 1.741458] Internal error: Oops - undefined instruction:=20 >>>> 0 [#1] SMP ARM >>>> [ 1.748182] CPU: 1 PID: 72 Comm: kworker/1:2 Tainted: G =20 >>>> W 4.19.0-rc3 #1 =20 >>=20 >> The 'W' taint means that there was a kernel warning before. Which >> warning was that? I have "spidev" listed in my DT, and the kernel complains about that;=20 that's a harmelss warning. (I sent a patch which adds my particular device=20= into the spidev driver some time ago.)=20 With kind regards, Jan ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-12 18:49 ` Baruch Siach 2018-09-12 18:50 ` Thomas Petazzoni @ 2018-09-12 23:10 ` Russell King - ARM Linux 2018-09-13 3:19 ` Baruch Siach 2018-09-13 7:45 ` Thomas Petazzoni 1 sibling, 2 replies; 24+ messages in thread From: Russell King - ARM Linux @ 2018-09-12 23:10 UTC (permalink / raw) To: Baruch Siach Cc: Lorenzo Pieralisi, Jason Cooper, linux-pci, linux-kernel, Thomas Petazzoni, Bjorn Helgaas, Jan Kundrát, linux-arm-kernel On Wed, Sep 12, 2018 at 09:49:41PM +0300, Baruch Siach wrote: > I reproduced the same Oops on Clearfog Base without any taint: > > [ 1.476401] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM ... > [ 1.855954] Code: e2844004 e5972000 e3520000 0affffee (e7f001f2) That is a BUG(). Please turn on verbose bug reporting to get more information about the cause. There are two possibilities: BUG_ON(addr >= end); and BUG_ON(!pte_none(*pte)); It's probably the latter - the region is probably already mapped, that being the PCI IO region. The original driver was setup to call pci_ioremap_io() as the very last thing - and as the driver is non-removable, we were guaranteed to never tear down this mapping (which is sensible, it's published to userspace.) However, the current code calls pci_ioremap_io() much earlier, in a path where probe failures can occur. This breaks pci_ioremap_io()'s requirements - it must not be called more than once. So: ee1604381a37 ("PCI: mvebu: Only remap I/O space if configured") is basically incorrect - pci_ioremap_io() needs to move back to a place where it is only called in a path which will never fail. However, looking at the generic host bits, I'm not sure such a place exists in the new effort to make stuff more generic. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-12 23:10 ` Russell King - ARM Linux @ 2018-09-13 3:19 ` Baruch Siach 2018-09-13 7:45 ` Thomas Petazzoni 1 sibling, 0 replies; 24+ messages in thread From: Baruch Siach @ 2018-09-13 3:19 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Lorenzo Pieralisi, Jason Cooper, linux-pci, linux-kernel, Thomas Petazzoni, Bjorn Helgaas, Jan Kundrát, linux-arm-kernel Hi Russell, Russell King - ARM Linux writes: > On Wed, Sep 12, 2018 at 09:49:41PM +0300, Baruch Siach wrote: >> I reproduced the same Oops on Clearfog Base without any taint: >> >> [ 1.476401] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM > ... >> [ 1.855954] Code: e2844004 e5972000 e3520000 0affffee (e7f001f2) > > That is a BUG(). Please turn on verbose bug reporting to get more > information about the cause. > > There are two possibilities: > > BUG_ON(addr >= end); > > and > > BUG_ON(!pte_none(*pte)); > > It's probably the latter - the region is probably already mapped, that > being the PCI IO region. That is the one. Enabling CONFIG_DEBUG_BUGVERBOSE shows: [ 1.481927] kernel BUG at lib/ioremap.c:72! [ 1.486118] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 1.491269] CPU: 0 PID: 1246 Comm: kworker/0:2 Not tainted 4.19.0-rc3 #146 ... baruch > The original driver was setup to call pci_ioremap_io() as the very > last thing - and as the driver is non-removable, we were guaranteed > to never tear down this mapping (which is sensible, it's published > to userspace.) > > However, the current code calls pci_ioremap_io() much earlier, in > a path where probe failures can occur. This breaks pci_ioremap_io()'s > requirements - it must not be called more than once. So: > > ee1604381a37 ("PCI: mvebu: Only remap I/O space if configured") > > is basically incorrect - pci_ioremap_io() needs to move back to a > place where it is only called in a path which will never fail. > However, looking at the generic host bits, I'm not sure such a place > exists in the new effort to make stuff more generic. -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-12 23:10 ` Russell King - ARM Linux 2018-09-13 3:19 ` Baruch Siach @ 2018-09-13 7:45 ` Thomas Petazzoni 2018-09-13 8:20 ` Jan Kundrát 1 sibling, 1 reply; 24+ messages in thread From: Thomas Petazzoni @ 2018-09-13 7:45 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Baruch Siach, Lorenzo Pieralisi, Jason Cooper, linux-pci, linux-kernel, Bjorn Helgaas, Jan Kundrát, linux-arm-kernel Russell, Baruch, Jan, On Thu, 13 Sep 2018 00:10:51 +0100, Russell King - ARM Linux wrote: > It's probably the latter - the region is probably already mapped, that > being the PCI IO region. > > The original driver was setup to call pci_ioremap_io() as the very > last thing - and as the driver is non-removable, we were guaranteed > to never tear down this mapping (which is sensible, it's published > to userspace.) > > However, the current code calls pci_ioremap_io() much earlier, in > a path where probe failures can occur. This breaks pci_ioremap_io()'s > requirements - it must not be called more than once. So: > > ee1604381a37 ("PCI: mvebu: Only remap I/O space if configured") > > is basically incorrect - pci_ioremap_io() needs to move back to a > place where it is only called in a path which will never fail. > However, looking at the generic host bits, I'm not sure such a place > exists in the new effort to make stuff more generic. What about something like the below. I tested it, including the error case by forcing an -EPROBE_DEFER. The new pci_unmap_io() is modeled after pci_unmap_iospace(). Actually, I would prefer to use pci_remap_iospace() and pci_unmap_iospace() but for now this API doesn't allow overloading the memory type used for the mapping. diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h index 2cfbc531f63b..cee0e2be5ac7 100644 --- a/arch/arm/include/asm/io.h +++ b/arch/arm/include/asm/io.h @@ -185,6 +185,7 @@ static inline void pci_ioremap_set_mem_type(int mem_type) {} #endif extern int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr); +extern void pci_unmap_io(unsigned int offset); /* * PCI configuration space mapping function. diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c index fc91205ff46c..f3a4df44bb27 100644 --- a/arch/arm/mm/ioremap.c +++ b/arch/arm/mm/ioremap.c @@ -482,6 +482,14 @@ int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr) } EXPORT_SYMBOL_GPL(pci_ioremap_io); +void pci_unmap_io(unsigned int offset) +{ + BUG_ON(offset + SZ_64K > IO_SPACE_LIMIT); + + unmap_kernel_range(PCI_IO_VIRT_BASE + offset, SZ_64K); +} +EXPORT_SYMBOL_GPL(pci_unmap_io); + void __iomem *pci_remap_cfgspace(resource_size_t res_cookie, size_t size) { return arch_ioremap_caller(res_cookie, size, MT_UNCACHED, diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c index 50eb0729385b..772cff19c2ce 100644 --- a/drivers/pci/controller/pci-mvebu.c +++ b/drivers/pci/controller/pci-mvebu.c @@ -1145,7 +1145,6 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) { struct device *dev = &pcie->pdev->dev; struct device_node *np = dev->of_node; - unsigned int i; int ret; INIT_LIST_HEAD(&pcie->resources); @@ -1179,15 +1178,34 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) resource_size(&pcie->io) - 1); pcie->realio.name = "PCI I/O"; - for (i = 0; i < resource_size(&pcie->realio); i += SZ_64K) - pci_ioremap_io(i, pcie->io.start + i); - pci_add_resource(&pcie->resources, &pcie->realio); } return devm_request_pci_bus_resources(dev, &pcie->resources); } +static void mvebu_pcie_map_io(struct mvebu_pcie *pcie) +{ + int i; + + if (resource_size(&pcie->io) == 0) + return; + + for (i = 0; i < resource_size(&pcie->realio); i += SZ_64K) + pci_ioremap_io(i, pcie->io.start + i); +} + +static void mvebu_pcie_unmap_io(struct mvebu_pcie *pcie) +{ + int i; + + if (resource_size(&pcie->io) == 0) + return; + + for (i = 0; i < resource_size(&pcie->realio); i += SZ_64K) + pci_unmap_io(i); +} + static int mvebu_pcie_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; @@ -1258,6 +1276,8 @@ static int mvebu_pcie_probe(struct platform_device *pdev) pcie->nports = i; + mvebu_pcie_map_io(pcie); + list_splice_init(&pcie->resources, &bridge->windows); bridge->dev.parent = dev; bridge->sysdata = pcie; @@ -1268,7 +1288,13 @@ static int mvebu_pcie_probe(struct platform_device *pdev) bridge->align_resource = mvebu_pcie_align_resource; bridge->msi = pcie->msi; - return pci_host_probe(bridge); + ret = pci_host_probe(bridge); + if (ret) { + mvebu_pcie_unmap_io(pcie); + return ret; + } + + return 0; } static const struct of_device_id mvebu_pcie_of_match_table[] = { -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-13 7:45 ` Thomas Petazzoni @ 2018-09-13 8:20 ` Jan Kundrát 2018-09-13 8:42 ` Thomas Petazzoni 0 siblings, 1 reply; 24+ messages in thread From: Jan Kundrát @ 2018-09-13 8:20 UTC (permalink / raw) To: Thomas Petazzoni Cc: Baruch Siach, Lorenzo Pieralisi, Jason Cooper, linux-pci, Russell King - ARM Linux, linux-kernel, Bjorn Helgaas, linux-arm-kernel T24gxI10dnJ0ZWsgMTMuIHrDocWZw60gMjAxOCA5OjQ1OjE1IENFU1QsIFRob21hcyBQZXRhenpv bmkgd3JvdGU6Cj4gV2hhdCBhYm91dCBzb21ldGhpbmcgbGlrZSB0aGUgYmVsb3cuIEkgdGVzdGVk IGl0LCBpbmNsdWRpbmcgdGhlIGVycm9yCj4gY2FzZSBieSBmb3JjaW5nIGFuIC1FUFJPQkVfREVG RVIuIFRoZSBuZXcgcGNpX3VubWFwX2lvKCkgaXMgbW9kZWxlZAo+IGFmdGVyIHBjaV91bm1hcF9p b3NwYWNlKCkuIEFjdHVhbGx5LCBJIHdvdWxkIHByZWZlciB0byB1c2UKPiBwY2lfcmVtYXBfaW9z cGFjZSgpIGFuZCBwY2lfdW5tYXBfaW9zcGFjZSgpIGJ1dCBmb3Igbm93IHRoaXMgQVBJCj4gZG9l c24ndCBhbGxvdyBvdmVybG9hZGluZyB0aGUgbWVtb3J5IHR5cGUgdXNlZCBmb3IgdGhlIG1hcHBp bmcuCgpUaGFua3MgZm9yIHByb3ZpZGluZyB0aGlzIGZpeCBzbyBxdWlja2x5LCBUaG9tYXMuIEkg Y2FuIGNvbmZpcm0gdGhhdCB0aGlzIApwYXRjaCAtLSB0ZXN0ZWQgb24gdG9wIG9mIDU0ZWRhOWRm MTdmMzIxNWI5ZWQxNjYyOWVlNzFlYTA3NDEzZWZkYWYgKCJNZXJnZSAKdGFnICdwY2ktdjQuMTkt Zml4ZXMtMScgb2YgCmdpdDovL2dpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dp dC9oZWxnYWFzL3BjaSIpLiBEaXNjbGFpbWVyOiBJIApoYXZlIHplcm8gZmFtaWxpYXJpdHkgd2l0 aCBMaW51eCcgUENJIGNvZGUuCgpUZXN0ZWQtYnk6IEphbiBLdW5kcsOhdCA8amFuLmt1bmRyYXRA Y2VzbmV0LmN6PgoKV2l0aCBraW5kIHJlZ2FyZHMsCkphbgoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QK bGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRl YWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo= ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-13 8:20 ` Jan Kundrát @ 2018-09-13 8:42 ` Thomas Petazzoni 2018-09-24 10:02 ` Jan Kundrát 2018-09-24 10:12 ` Russell King - ARM Linux 0 siblings, 2 replies; 24+ messages in thread From: Thomas Petazzoni @ 2018-09-13 8:42 UTC (permalink / raw) To: Jan Kundrát Cc: Baruch Siach, Lorenzo Pieralisi, Jason Cooper, linux-pci, Russell King - ARM Linux, linux-kernel, Bjorn Helgaas, linux-arm-kernel SGVsbG8sCgpPbiBUaHUsIDEzIFNlcCAyMDE4IDEwOjIwOjQ1ICswMjAwLCBKYW4gS3VuZHLDoXQg d3JvdGU6Cj4gT24gxI10dnJ0ZWsgMTMuIHrDocWZw60gMjAxOCA5OjQ1OjE1IENFU1QsIFRob21h cyBQZXRhenpvbmkgd3JvdGU6Cj4gPiBXaGF0IGFib3V0IHNvbWV0aGluZyBsaWtlIHRoZSBiZWxv dy4gSSB0ZXN0ZWQgaXQsIGluY2x1ZGluZyB0aGUgZXJyb3IKPiA+IGNhc2UgYnkgZm9yY2luZyBh biAtRVBST0JFX0RFRkVSLiBUaGUgbmV3IHBjaV91bm1hcF9pbygpIGlzIG1vZGVsZWQKPiA+IGFm dGVyIHBjaV91bm1hcF9pb3NwYWNlKCkuIEFjdHVhbGx5LCBJIHdvdWxkIHByZWZlciB0byB1c2UK PiA+IHBjaV9yZW1hcF9pb3NwYWNlKCkgYW5kIHBjaV91bm1hcF9pb3NwYWNlKCkgYnV0IGZvciBu b3cgdGhpcyBBUEkKPiA+IGRvZXNuJ3QgYWxsb3cgb3ZlcmxvYWRpbmcgdGhlIG1lbW9yeSB0eXBl IHVzZWQgZm9yIHRoZSBtYXBwaW5nLiAgCj4gCj4gVGhhbmtzIGZvciBwcm92aWRpbmcgdGhpcyBm aXggc28gcXVpY2tseSwgVGhvbWFzLiBJIGNhbiBjb25maXJtIHRoYXQgdGhpcyAKPiBwYXRjaCAt LSB0ZXN0ZWQgb24gdG9wIG9mIDU0ZWRhOWRmMTdmMzIxNWI5ZWQxNjYyOWVlNzFlYTA3NDEzZWZk YWYgKCJNZXJnZSAKPiB0YWcgJ3BjaS12NC4xOS1maXhlcy0xJyBvZiAKPiBnaXQ6Ly9naXQua2Vy bmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQvaGVsZ2Fhcy9wY2kiKS4gRGlzY2xhaW1l cjogSSAKPiBoYXZlIHplcm8gZmFtaWxpYXJpdHkgd2l0aCBMaW51eCcgUENJIGNvZGUuCj4gCj4g VGVzdGVkLWJ5OiBKYW4gS3VuZHLDoXQgPGphbi5rdW5kcmF0QGNlc25ldC5jej4KClRoYW5rcyBm b3IgdGhlIHRlc3RpbmcuIEknbGwgd2FpdCBmb3IgUnVzc2VsbCB0byBzYXkgaWYgaGUgaXMgaGFw cHkKKG9yIG5vdCkgd2l0aCB0aGUgYWRkaXRpb24gb2YgcGNpX3VubWFwX2lvKCkgaW4gdGhlIEFS TSBjb2RlLCBpZiB0aGF0J3MKdGhlIGNhc2UsIEknbGwgc2VuZCBhIHByb3BlciBwYXRjaCB0byBm aXggdGhlIGlzc3VlLgoKQmVzdCByZWdhcmRzLAoKVGhvbWFzCi0tIApUaG9tYXMgUGV0YXp6b25p LCBDVE8sIEJvb3RsaW4KRW1iZWRkZWQgTGludXggYW5kIEtlcm5lbCBlbmdpbmVlcmluZwpodHRw czovL2Jvb3RsaW4uY29tCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxp c3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0 aW5mby9saW51eC1hcm0ta2VybmVsCg== ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-13 8:42 ` Thomas Petazzoni @ 2018-09-24 10:02 ` Jan Kundrát 2018-09-24 10:10 ` Thomas Petazzoni 2018-09-24 10:12 ` Russell King - ARM Linux 1 sibling, 1 reply; 24+ messages in thread From: Jan Kundrát @ 2018-09-24 10:02 UTC (permalink / raw) To: Thomas Petazzoni, Russell King - ARM Linux Cc: Baruch Siach, Lorenzo Pieralisi, Jason Cooper, linux-pci, linux-kernel, Bjorn Helgaas, linux-arm-kernel >>> What about something like the below. I tested it, including the error >>> case by forcing an -EPROBE_DEFER. The new pci_unmap_io() is modeled >>> after pci_unmap_iospace(). Actually, I would prefer to use >>> pci_remap_iospace() and pci_unmap_iospace() but for now this API >>> doesn't allow overloading the memory type used for the mapping. >> >> Thanks for providing this fix so quickly, Thomas. I can confirm that this >> patch -- tested on top of >> 54eda9df17f3215b9ed16629ee71ea07413efdaf ("Merge >> tag 'pci-v4.19-fixes-1' of >> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci"). >> Disclaimer: I >> have zero familiarity with Linux' PCI code. >> >> Tested-by: Jan Kundrát <jan.kundrat@cesnet.cz> > > Thanks for the testing. I'll wait for Russell to say if he is happy > (or not) with the addition of pci_unmap_io() in the ARM code, if that's > the case, I'll send a proper patch to fix the issue. Hi Thomas, Russell, is there a proper patch for this? I've just verified that 4.19-rc5 won't boot for me either. Thomas' quick patch applies and makes the problem go away. With kind regards, Jan ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-24 10:02 ` Jan Kundrát @ 2018-09-24 10:10 ` Thomas Petazzoni 0 siblings, 0 replies; 24+ messages in thread From: Thomas Petazzoni @ 2018-09-24 10:10 UTC (permalink / raw) To: Jan Kundrát Cc: Russell King - ARM Linux, Baruch Siach, Lorenzo Pieralisi, Jason Cooper, linux-pci, linux-kernel, Bjorn Helgaas, linux-arm-kernel Hello, On Mon, 24 Sep 2018 12:02:33 +0200, Jan Kundrát wrote: > is there a proper patch for this? I've just verified that 4.19-rc5 won't > boot for me either. Thomas' quick patch applies and makes the problem go > away. I was waiting for a quick review from Russell on my proposal, but since it didn't happen so far, I will send a proper patch series, hopefully today. Thanks for your reminder! Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-13 8:42 ` Thomas Petazzoni 2018-09-24 10:02 ` Jan Kundrát @ 2018-09-24 10:12 ` Russell King - ARM Linux 2018-09-24 10:26 ` Thomas Petazzoni 1 sibling, 1 reply; 24+ messages in thread From: Russell King - ARM Linux @ 2018-09-24 10:12 UTC (permalink / raw) To: Thomas Petazzoni Cc: Jan Kundrát, Baruch Siach, Lorenzo Pieralisi, Jason Cooper, linux-pci, linux-kernel, Bjorn Helgaas, linux-arm-kernel On Thu, Sep 13, 2018 at 10:42:41AM +0200, Thomas Petazzoni wrote: > Hello, > > On Thu, 13 Sep 2018 10:20:45 +0200, Jan Kundrát wrote: > > On čtvrtek 13. září 2018 9:45:15 CEST, Thomas Petazzoni wrote: > > > What about something like the below. I tested it, including the error > > > case by forcing an -EPROBE_DEFER. The new pci_unmap_io() is modeled > > > after pci_unmap_iospace(). Actually, I would prefer to use > > > pci_remap_iospace() and pci_unmap_iospace() but for now this API > > > doesn't allow overloading the memory type used for the mapping. > > > > Thanks for providing this fix so quickly, Thomas. I can confirm that this > > patch -- tested on top of 54eda9df17f3215b9ed16629ee71ea07413efdaf ("Merge > > tag 'pci-v4.19-fixes-1' of > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci"). Disclaimer: I > > have zero familiarity with Linux' PCI code. > > > > Tested-by: Jan Kundrát <jan.kundrat@cesnet.cz> > > Thanks for the testing. I'll wait for Russell to say if he is happy > (or not) with the addition of pci_unmap_io() in the ARM code, if that's > the case, I'll send a proper patch to fix the issue. I'd prefer not to provide an unmapping API, because it gives the impression that it's okay to unmap the IO space mapping, and we'll end up with drivers that decide to call it in their cleanup path. IO space isn't expected to ever go away - eg, on a PC, it's always present. I've been toying with the idea of making pci_map_io() ignore subsequent attempts to overwrite the mapping with an identical mapping, and WARN() if there is an attempt to overwrite an existing mapping with other physical address, but I'm not entirely happy with that either (which is why I haven't responded sooner.) At the moment, I don't have a way forward that I'm happy with for this. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-24 10:12 ` Russell King - ARM Linux @ 2018-09-24 10:26 ` Thomas Petazzoni 2018-09-24 11:13 ` Russell King - ARM Linux 0 siblings, 1 reply; 24+ messages in thread From: Thomas Petazzoni @ 2018-09-24 10:26 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Jan Kundrát, Baruch Siach, Lorenzo Pieralisi, Jason Cooper, linux-pci, linux-kernel, Bjorn Helgaas, linux-arm-kernel Hello, On Mon, 24 Sep 2018 11:12:13 +0100, Russell King - ARM Linux wrote: > > Thanks for the testing. I'll wait for Russell to say if he is happy > > (or not) with the addition of pci_unmap_io() in the ARM code, if that's > > the case, I'll send a proper patch to fix the issue. > > I'd prefer not to provide an unmapping API, because it gives the > impression that it's okay to unmap the IO space mapping, and we'll > end up with drivers that decide to call it in their cleanup path. > IO space isn't expected to ever go away - eg, on a PC, it's always > present. But being able to unmap it would also be needed to be able to remove PCI host controller drivers, and therefore compile them as module, and make them more like any other drivers. I'm not sure why we need to guarantee that the I/O space is always mapped: - It isn't mapped before the PCI controller driver does the mapping. - There is no reason for it to be accessed when the PCI controller driver is not initialized: PCI devices can only be probed and initialized when the PCI controller driver is probed/initialized. Also, in general, pci_ioremap_io() is ARM specific, and is now only used by very few drivers: - Dove (Marvell platform) - IOP13xx - MV78xx0 (Marvell platform, should be moved to use pci-mvebu) - Orion5x (Marvell platform, should be moved to use pci-mvebu) - pci-mvebu - at91_cf All other drivers, including on ARM, use pci_remap_iospace(), which does provide the pci_unmap_iospace() counter part. The only reason I have not changed pci-mvebu to use pci_{remap,unmap}_iospace() is because it doesn't allow to change the memory attributes. But to me, the general direction is that the ARM-specific pci_remap_io() API is fading away, and its replacement already provides an unmapping capability. So why not add the same unmapping capability to pci_remap_io() ? > I've been toying with the idea of making pci_map_io() ignore > subsequent attempts to overwrite the mapping with an identical > mapping, and WARN() if there is an attempt to overwrite an existing > mapping with other physical address, but I'm not entirely happy > with that either (which is why I haven't responded sooner.) > > At the moment, I don't have a way forward that I'm happy with for > this. But we have a regression and we need to fix it. Do you suggest to not use the new pci_host_probe() API ? Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-24 10:26 ` Thomas Petazzoni @ 2018-09-24 11:13 ` Russell King - ARM Linux 2018-09-24 12:12 ` Thomas Petazzoni 0 siblings, 1 reply; 24+ messages in thread From: Russell King - ARM Linux @ 2018-09-24 11:13 UTC (permalink / raw) To: Thomas Petazzoni Cc: Jan Kundrát, Baruch Siach, Lorenzo Pieralisi, Jason Cooper, linux-pci, linux-kernel, Bjorn Helgaas, linux-arm-kernel On Mon, Sep 24, 2018 at 12:26:14PM +0200, Thomas Petazzoni wrote: > Hello, > > On Mon, 24 Sep 2018 11:12:13 +0100, Russell King - ARM Linux wrote: > > > > Thanks for the testing. I'll wait for Russell to say if he is happy > > > (or not) with the addition of pci_unmap_io() in the ARM code, if that's > > > the case, I'll send a proper patch to fix the issue. > > > > I'd prefer not to provide an unmapping API, because it gives the > > impression that it's okay to unmap the IO space mapping, and we'll > > end up with drivers that decide to call it in their cleanup path. > > IO space isn't expected to ever go away - eg, on a PC, it's always > > present. > > But being able to unmap it would also be needed to be able to remove > PCI host controller drivers, and therefore compile them as module, and > make them more like any other drivers. > > I'm not sure why we need to guarantee that the I/O space is always > mapped: > > - It isn't mapped before the PCI controller driver does the mapping. > > - There is no reason for it to be accessed when the PCI controller > driver is not initialized: PCI devices can only be probed and > initialized when the PCI controller driver is probed/initialized. There are historic reasons. PCI provides ISA IO space, and when you have a machine with ISA peripherals present, the PCI IO space must never be unmapped - if it is, ISA drivers will oops the kernel. There is no way for a vanishing PCI controller to cause ISA drivers to be unbound. If you have a host controller that does unmap PCI IO space and you have ISA peripherals with drivers present, unbinding the PCI host controller will remove the IO space mapping, and next time an ISA peripheral touches IO space, the kernel will oops. > All other drivers, including on ARM, use pci_remap_iospace(), which > does provide the pci_unmap_iospace() counter part. ... which has been created in PCI land just to deal with PCI without regard for the above issue. However, there's another issue I missed - if you _do_ have ISA peripherals, you likely want the IO space setup from very early on, and you won't be using the new fangled PCI host driver support anyway. That uses pci_map_io_early() rather than pci_ioremap_io() or pci_remap_io(). > But to me, the general direction is that the ARM-specific > pci_remap_io() API is fading away, and its replacement already provides > an unmapping capability. So why not add the same unmapping capability > to pci_remap_io() ? Yes, that would be a good longer term plan - we don't need three different ways to map PCI IO space, but it is development. > But we have a regression and we need to fix it. Do you suggest to not > use the new pci_host_probe() API ? Well, arguably, the patch that caused the regression is the buggy patch, _not_ the lack of unmapping API for pci_ioremap_io(). Trying to address a regression with further development means that _that_ development needs thought and review, which is a slower process. I do understand the desire to keep moving forward and never take a step backwards, but sometimes backwards steps are the best way to resolve a regression. But I also do appreciate that a simple revert in this case is not possible. I'll accept your patch on the condition that the ARM private pci_ioremap_io() will go away in the very near future (please _try_ to get agreement on that before this patch is merged.) -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-24 11:13 ` Russell King - ARM Linux @ 2018-09-24 12:12 ` Thomas Petazzoni 2018-09-24 12:46 ` Lorenzo Pieralisi 2018-09-25 8:18 ` Andrew Murray 0 siblings, 2 replies; 24+ messages in thread From: Thomas Petazzoni @ 2018-09-24 12:12 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Jan Kundrát, Baruch Siach, Lorenzo Pieralisi, Jason Cooper, linux-pci, linux-kernel, Bjorn Helgaas, linux-arm-kernel Hello, On Mon, 24 Sep 2018 12:13:41 +0100, Russell King - ARM Linux wrote: > > But being able to unmap it would also be needed to be able to remove > > PCI host controller drivers, and therefore compile them as module, and > > make them more like any other drivers. > > > > I'm not sure why we need to guarantee that the I/O space is always > > mapped: > > > > - It isn't mapped before the PCI controller driver does the mapping. > > > > - There is no reason for it to be accessed when the PCI controller > > driver is not initialized: PCI devices can only be probed and > > initialized when the PCI controller driver is probed/initialized. > > There are historic reasons. PCI provides ISA IO space, and when you > have a machine with ISA peripherals present, the PCI IO space must > never be unmapped - if it is, ISA drivers will oops the kernel. There > is no way for a vanishing PCI controller to cause ISA drivers to be > unbound. > > If you have a host controller that does unmap PCI IO space and you have > ISA peripherals with drivers present, unbinding the PCI host controller > will remove the IO space mapping, and next time an ISA peripheral > touches IO space, the kernel will oops. Thanks for sharing some additional technical context on this, very useful. I have another question though: shouldn't those ISA devices be child devices of the PCI controller, if they use some resources of the PCI controller ? Could you give an example of such an ISA device driver ? This is just to understand better the issue, because there seems to be a kind of hidden dependency between those ISA drivers and the setup of the PCI controller. > > All other drivers, including on ARM, use pci_remap_iospace(), which > > does provide the pci_unmap_iospace() counter part. > > ... which has been created in PCI land just to deal with PCI without > regard for the above issue. > > However, there's another issue I missed - if you _do_ have ISA > peripherals, you likely want the IO space setup from very early on, > and you won't be using the new fangled PCI host driver support anyway. > That uses pci_map_io_early() rather than pci_ioremap_io() or > pci_remap_io(). OK. There's today a single platform (Footbridge) that uses pci_map_io_early(), and it is indeed called through the ->map_io() hook, which is very early in the boot process. BTW, look at drivers/pcmcia/at91_cf.c. It has ->probe() and ->remove(), and does a pci_ioremap_io() in its ->probe(), and nothing in its ->remove(). I don't think this driver, compiled as a module, will work well after a insmod/rmmod/insmod cycle. > > But to me, the general direction is that the ARM-specific > > pci_remap_io() API is fading away, and its replacement already provides > > an unmapping capability. So why not add the same unmapping capability > > to pci_remap_io() ? > > Yes, that would be a good longer term plan - we don't need three > different ways to map PCI IO space, but it is development. Absolutely. Glad to hear that you agree on the longer term plan. > > But we have a regression and we need to fix it. Do you suggest to not > > use the new pci_host_probe() API ? > > Well, arguably, the patch that caused the regression is the buggy patch, > _not_ the lack of unmapping API for pci_ioremap_io(). Totally true. > Trying to address a regression with further development means that > _that_ development needs thought and review, which is a slower > process. > > I do understand the desire to keep moving forward and never take a > step backwards, but sometimes backwards steps are the best way to > resolve a regression. But I also do appreciate that a simple revert > in this case is not possible. Well, I can revert: 42342073e38b50113354944cd51dcfed28d857a1 PCI: mvebu: Convert to use pci_host_bridge directly ee1604381a371b3ea6aec7d5e43b6e3f5e153854 PCI: mvebu: Only remap I/O space if configured so it's not a big deal either. I can revert those, and then resubmit a more complete series later on that moves pci-mvebu to use pci_remap_iospace(). > I'll accept your patch on the condition that the ARM private > pci_ioremap_io() will go away in the very near future (please _try_ > to get agreement on that before this patch is merged.) Bjorn, Lorenzo, what do you prefer ? If we want to get rid of pci_ioremap_io(), then we need a way to tell pci_remap_iospace() the memory attributes that should be used for the mapping, because on Armada 38x, we need to map the I/O space mapped MT_UNCACHED instead of MT_DEVICE. I'm not sure how to achieve this yet. Should pgprot_device() be changed to return MT_UNCACHED on a platform-specific basis ? Any other idea ? Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-24 12:12 ` Thomas Petazzoni @ 2018-09-24 12:46 ` Lorenzo Pieralisi 2018-09-24 13:10 ` Thomas Petazzoni 2018-09-25 8:18 ` Andrew Murray 1 sibling, 1 reply; 24+ messages in thread From: Lorenzo Pieralisi @ 2018-09-24 12:46 UTC (permalink / raw) To: Thomas Petazzoni Cc: Russell King - ARM Linux, Jan Kundr??t, Baruch Siach, Jason Cooper, linux-pci, linux-kernel, Bjorn Helgaas, linux-arm-kernel On Mon, Sep 24, 2018 at 02:12:03PM +0200, Thomas Petazzoni wrote: [...] > > Trying to address a regression with further development means that > > _that_ development needs thought and review, which is a slower > > process. > > > > I do understand the desire to keep moving forward and never take a > > step backwards, but sometimes backwards steps are the best way to > > resolve a regression. But I also do appreciate that a simple revert > > in this case is not possible. > > Well, I can revert: > > 42342073e38b50113354944cd51dcfed28d857a1 PCI: mvebu: Convert to use > pci_host_bridge directly ee1604381a371b3ea6aec7d5e43b6e3f5e153854 PCI: > mvebu: Only remap I/O space if configured > > so it's not a big deal either. I can revert those, and then resubmit a > more complete series later on that moves pci-mvebu to use > pci_remap_iospace(). > > > I'll accept your patch on the condition that the ARM private > > pci_ioremap_io() will go away in the very near future (please _try_ > > to get agreement on that before this patch is merged.) > > Bjorn, Lorenzo, what do you prefer ? > > If we want to get rid of pci_ioremap_io(), then we need a way to tell > pci_remap_iospace() the memory attributes that should be used for the > mapping, because on Armada 38x, we need to map the I/O space mapped > MT_UNCACHED instead of MT_DEVICE. I'm not sure how to achieve this yet. > Should pgprot_device() be changed to return MT_UNCACHED on a > platform-specific basis ? Any other idea ? I think we should address Russell's concern, he has more insights into code that predates the PCI host developments. What I think you can do short term, given that AFAICS MVEBU is not removable, instead of using pci_host_probe() you move part of its code into the driver and make sure that you remap IO as last operation before probe completion (ie after scanning the host bridge) so that you do not need to unmap it on failure; write a commit log summarising/linking this thread please and when v4.20 lands we will give this a more thorough look as Russell requested. How does that sound ? Thanks, Lorenzo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-24 12:46 ` Lorenzo Pieralisi @ 2018-09-24 13:10 ` Thomas Petazzoni 2018-09-24 14:15 ` Lorenzo Pieralisi 0 siblings, 1 reply; 24+ messages in thread From: Thomas Petazzoni @ 2018-09-24 13:10 UTC (permalink / raw) To: Lorenzo Pieralisi Cc: Russell King - ARM Linux, Jan Kundr??t, Baruch Siach, Jason Cooper, linux-pci, linux-kernel, Bjorn Helgaas, linux-arm-kernel Hello, On Mon, 24 Sep 2018 13:46:29 +0100, Lorenzo Pieralisi wrote: > What I think you can do short term, given that AFAICS MVEBU is not > removable, instead of using pci_host_probe() you move part of its code > into the driver and make sure that you remap IO as last operation before > probe completion (ie after scanning the host bridge) so that you do not > need to unmap it on failure; write a commit log summarising/linking this > thread please and when v4.20 lands we will give this a more thorough > look as Russell requested. > > How does that sound ? The only thing that can fail in pci_host_probe() is: ret = pci_scan_root_bus_bridge(bridge); if (ret < 0) { dev_err(bridge->dev.parent, "Scanning root bridge failed"); return ret; } In the pci-mvebu driver prior to the conversion to pci_host_probe(), the code flow at the end of ->probe() was: mvebu_pcie_enable() pci_common_init_dev() pcibios_init_hw() and pcibios_init_hw() calls pci_scan_root_bus_bridge(), without doing much about the return value other than issuing a warning: ret = pci_scan_root_bus_bridge(bridge); } if (WARN(ret < 0, "PCI: unable to scan bus!")) { pci_free_host_bridge(bridge); break; } I.e, even before the conversion to pci_host_probe(), in case of failure in pci_scan_root_bus_bridge(), we would have the I/O mapping in place, but the PCI controller not registered. We could keep the same (not great) behavior by doing: diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c index 50eb0729385b..487492f0c5f7 100644 --- a/drivers/pci/controller/pci-mvebu.c +++ b/drivers/pci/controller/pci-mvebu.c @@ -1179,9 +1179,6 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) resource_size(&pcie->io) - 1); pcie->realio.name = "PCI I/O"; - for (i = 0; i < resource_size(&pcie->realio); i += SZ_64K) - pci_ioremap_io(i, pcie->io.start + i); - pci_add_resource(&pcie->resources, &pcie->realio); } @@ -1197,7 +1194,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev) struct device_node *child; int num, i, ret; - bridge = devm_pci_alloc_host_bridge(dev, sizeof(struct mvebu_pcie)); + bridge = pci_alloc_host_bridge(sizeof(struct mvebu_pcie)); if (!bridge) return -ENOMEM; @@ -1212,8 +1209,10 @@ static int mvebu_pcie_probe(struct platform_device *pdev) num = of_get_available_child_count(np); pcie->ports = devm_kcalloc(dev, num, sizeof(*pcie->ports), GFP_KERNEL); - if (!pcie->ports) - return -ENOMEM; + if (!pcie->ports) { + ret = -ENOMEM; + goto free_host_bridge; + } i = 0; for_each_available_child_of_node(np, child) { @@ -1222,7 +1221,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev) ret = mvebu_pcie_parse_port(pcie, port, child); if (ret < 0) { of_node_put(child); - return ret; + goto free_host_bridge; } else if (ret == 0) { continue; } @@ -1268,7 +1267,21 @@ static int mvebu_pcie_probe(struct platform_device *pdev) bridge->align_resource = mvebu_pcie_align_resource; bridge->msi = pcie->msi; - return pci_host_probe(bridge); + if (resource_size(&pcie->io) != 0) { + for (i = 0; i < resource_size(&pcie->realio); i += SZ_64K) + pci_ioremap_io(i, pcie->io.start + i); + } + + ret = pci_host_probe(bridge); + if (ret) + pci_free_host_bridge(bridge); + + /* Yes, when pci_host_probe() returns a failure, we don't care */ + return 0; + +free_host_bridge: + pci_free_host_bridge(bridge); + return ret; } static const struct of_device_id mvebu_pcie_of_match_table[] = { I.e, we simply ignore the failure of pci_host_probe(). To be honest, I really prefer the option of introducing pci_unmap_io(). Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-24 13:10 ` Thomas Petazzoni @ 2018-09-24 14:15 ` Lorenzo Pieralisi 2018-09-24 14:52 ` Thomas Petazzoni 0 siblings, 1 reply; 24+ messages in thread From: Lorenzo Pieralisi @ 2018-09-24 14:15 UTC (permalink / raw) To: Thomas Petazzoni Cc: Russell King - ARM Linux, Jan Kundr??t, Baruch Siach, Jason Cooper, linux-pci, linux-kernel, Bjorn Helgaas, linux-arm-kernel On Mon, Sep 24, 2018 at 03:10:40PM +0200, Thomas Petazzoni wrote: > Hello, > > On Mon, 24 Sep 2018 13:46:29 +0100, Lorenzo Pieralisi wrote: > > > What I think you can do short term, given that AFAICS MVEBU is not > > removable, instead of using pci_host_probe() you move part of its code > > into the driver and make sure that you remap IO as last operation before > > probe completion (ie after scanning the host bridge) so that you do not > > need to unmap it on failure; write a commit log summarising/linking this > > thread please and when v4.20 lands we will give this a more thorough > > look as Russell requested. > > > > How does that sound ? > > The only thing that can fail in pci_host_probe() is: > > ret = pci_scan_root_bus_bridge(bridge); > if (ret < 0) { > dev_err(bridge->dev.parent, "Scanning root bridge > failed"); return ret; > } > > In the pci-mvebu driver prior to the conversion to pci_host_probe(), > the code flow at the end of ->probe() was: > > mvebu_pcie_enable() > pci_common_init_dev() > pcibios_init_hw() > > and pcibios_init_hw() calls pci_scan_root_bus_bridge(), without doing > much about the return value other than issuing a warning: > > ret = pci_scan_root_bus_bridge(bridge); > } > > if (WARN(ret < 0, "PCI: unable to scan bus!")) { > pci_free_host_bridge(bridge); > break; > } > > I.e, even before the conversion to pci_host_probe(), in case of > failure in pci_scan_root_bus_bridge(), we would have the I/O mapping in > place, but the PCI controller not registered. > > We could keep the same (not great) behavior by doing: > > diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c > index 50eb0729385b..487492f0c5f7 100644 > --- a/drivers/pci/controller/pci-mvebu.c > +++ b/drivers/pci/controller/pci-mvebu.c > @@ -1179,9 +1179,6 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) > resource_size(&pcie->io) - 1); > pcie->realio.name = "PCI I/O"; > > - for (i = 0; i < resource_size(&pcie->realio); i += SZ_64K) > - pci_ioremap_io(i, pcie->io.start + i); > - > pci_add_resource(&pcie->resources, &pcie->realio); > } > > @@ -1197,7 +1194,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev) > struct device_node *child; > int num, i, ret; > > - bridge = devm_pci_alloc_host_bridge(dev, sizeof(struct mvebu_pcie)); > + bridge = pci_alloc_host_bridge(sizeof(struct mvebu_pcie)); > if (!bridge) > return -ENOMEM; > > @@ -1212,8 +1209,10 @@ static int mvebu_pcie_probe(struct platform_device *pdev) > num = of_get_available_child_count(np); > > pcie->ports = devm_kcalloc(dev, num, sizeof(*pcie->ports), GFP_KERNEL); > - if (!pcie->ports) > - return -ENOMEM; > + if (!pcie->ports) { > + ret = -ENOMEM; > + goto free_host_bridge; > + } > > i = 0; > for_each_available_child_of_node(np, child) { > @@ -1222,7 +1221,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev) > ret = mvebu_pcie_parse_port(pcie, port, child); > if (ret < 0) { > of_node_put(child); > - return ret; > + goto free_host_bridge; > } else if (ret == 0) { > continue; > } > @@ -1268,7 +1267,21 @@ static int mvebu_pcie_probe(struct platform_device *pdev) > bridge->align_resource = mvebu_pcie_align_resource; > bridge->msi = pcie->msi; > > - return pci_host_probe(bridge); > + if (resource_size(&pcie->io) != 0) { > + for (i = 0; i < resource_size(&pcie->realio); i += SZ_64K) > + pci_ioremap_io(i, pcie->io.start + i); > + } > + > + ret = pci_host_probe(bridge); > + if (ret) > + pci_free_host_bridge(bridge); > + > + /* Yes, when pci_host_probe() returns a failure, we don't care */ > + return 0; > + > +free_host_bridge: > + pci_free_host_bridge(bridge); > + return ret; > } > > static const struct of_device_id mvebu_pcie_of_match_table[] = { > > I.e, we simply ignore the failure of pci_host_probe(). > > To be honest, I really prefer the option of introducing pci_unmap_io(). I understand that, I wanted to make sure we come up with a fix asap and what I put forward would cover everything discussed in this thread, at least temporarily, giving us time to check ISA related issues while unmapping IO space. Lorenzo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-24 14:15 ` Lorenzo Pieralisi @ 2018-09-24 14:52 ` Thomas Petazzoni 2018-09-24 16:42 ` Lorenzo Pieralisi 2018-10-01 10:56 ` Jan Kundrát 0 siblings, 2 replies; 24+ messages in thread From: Thomas Petazzoni @ 2018-09-24 14:52 UTC (permalink / raw) To: Lorenzo Pieralisi Cc: Russell King - ARM Linux, Jan Kundr??t, Baruch Siach, Jason Cooper, linux-pci, linux-kernel, Bjorn Helgaas, linux-arm-kernel Hello, On Mon, 24 Sep 2018 15:15:12 +0100, Lorenzo Pieralisi wrote: > I understand that, I wanted to make sure we come up with a fix asap > and what I put forward would cover everything discussed in this thread, > at least temporarily, giving us time to check ISA related issues while > unmapping IO space. Something like this should implemented what you suggest I guess: diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c index 50eb0729385b..a41d79b8d46a 100644 --- a/drivers/pci/controller/pci-mvebu.c +++ b/drivers/pci/controller/pci-mvebu.c @@ -1145,7 +1145,6 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) { struct device *dev = &pcie->pdev->dev; struct device_node *np = dev->of_node; - unsigned int i; int ret; INIT_LIST_HEAD(&pcie->resources); @@ -1179,13 +1178,58 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) resource_size(&pcie->io) - 1); pcie->realio.name = "PCI I/O"; + pci_add_resource(&pcie->resources, &pcie->realio); + } + + return devm_request_pci_bus_resources(dev, &pcie->resources); +} + +/* + * This is a copy of pci_host_probe(), except that it does the I/O + * remap as the last step, once we are sure we won't fail. + * + * It should be removed once the I/O remap error handling issue has + * been sorted out. + */ +static int mvebu_pci_host_probe(struct pci_host_bridge *bridge) +{ + struct mvebu_pcie *pcie; + struct pci_bus *bus, *child; + int ret; + + ret = pci_scan_root_bus_bridge(bridge); + if (ret < 0) { + dev_err(bridge->dev.parent, "Scanning root bridge failed"); + return ret; + } + + pcie = pci_host_bridge_priv(bridge); + if (resource_size(&pcie->io) != 0) { + unsigned int i; + for (i = 0; i < resource_size(&pcie->realio); i += SZ_64K) pci_ioremap_io(i, pcie->io.start + i); + } - pci_add_resource(&pcie->resources, &pcie->realio); + bus = bridge->bus; + + /* + * We insert PCI resources into the iomem_resource and + * ioport_resource trees in either pci_bus_claim_resources() + * or pci_bus_assign_resources(). + */ + if (pci_has_flag(PCI_PROBE_ONLY)) { + pci_bus_claim_resources(bus); + } else { + pci_bus_size_bridges(bus); + pci_bus_assign_resources(bus); + + list_for_each_entry(child, &bus->children, node) + pcie_bus_configure_settings(child); } - return devm_request_pci_bus_resources(dev, &pcie->resources); + pci_bus_add_devices(bus); + return 0; } static int mvebu_pcie_probe(struct platform_device *pdev) @@ -1268,7 +1312,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev) bridge->align_resource = mvebu_pcie_align_resource; bridge->msi = pcie->msi; - return pci_host_probe(bridge); + return mvebu_pci_host_probe(bridge); } static const struct of_device_id mvebu_pcie_of_match_table[] = { If that's what you meant, I'll go ahead and test on actual hardware and submit as a proper patch. Thanks! Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-24 14:52 ` Thomas Petazzoni @ 2018-09-24 16:42 ` Lorenzo Pieralisi 2018-10-01 10:56 ` Jan Kundrát 1 sibling, 0 replies; 24+ messages in thread From: Lorenzo Pieralisi @ 2018-09-24 16:42 UTC (permalink / raw) To: Thomas Petazzoni Cc: Russell King - ARM Linux, Jan Kundrát, Baruch Siach, Jason Cooper, linux-pci, linux-kernel, Bjorn Helgaas, linux-arm-kernel On Mon, Sep 24, 2018 at 04:52:18PM +0200, Thomas Petazzoni wrote: > Hello, > > On Mon, 24 Sep 2018 15:15:12 +0100, Lorenzo Pieralisi wrote: > > > I understand that, I wanted to make sure we come up with a fix asap > > and what I put forward would cover everything discussed in this thread, > > at least temporarily, giving us time to check ISA related issues while > > unmapping IO space. > > Something like this should implemented what you suggest I guess: > > diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c > index 50eb0729385b..a41d79b8d46a 100644 > --- a/drivers/pci/controller/pci-mvebu.c > +++ b/drivers/pci/controller/pci-mvebu.c > @@ -1145,7 +1145,6 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) > { > struct device *dev = &pcie->pdev->dev; > struct device_node *np = dev->of_node; > - unsigned int i; > int ret; > > INIT_LIST_HEAD(&pcie->resources); > @@ -1179,13 +1178,58 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) > resource_size(&pcie->io) - 1); > pcie->realio.name = "PCI I/O"; > > + pci_add_resource(&pcie->resources, &pcie->realio); > + } > + > + return devm_request_pci_bus_resources(dev, &pcie->resources); > +} > + > +/* > + * This is a copy of pci_host_probe(), except that it does the I/O > + * remap as the last step, once we are sure we won't fail. > + * > + * It should be removed once the I/O remap error handling issue has > + * been sorted out. > + */ > +static int mvebu_pci_host_probe(struct pci_host_bridge *bridge) > +{ > + struct mvebu_pcie *pcie; > + struct pci_bus *bus, *child; > + int ret; > + > + ret = pci_scan_root_bus_bridge(bridge); > + if (ret < 0) { > + dev_err(bridge->dev.parent, "Scanning root bridge failed"); > + return ret; > + } > + > + pcie = pci_host_bridge_priv(bridge); > + if (resource_size(&pcie->io) != 0) { > + unsigned int i; > + > for (i = 0; i < resource_size(&pcie->realio); i += SZ_64K) > pci_ioremap_io(i, pcie->io.start + i); > + } > > - pci_add_resource(&pcie->resources, &pcie->realio); > + bus = bridge->bus; > + > + /* > + * We insert PCI resources into the iomem_resource and > + * ioport_resource trees in either pci_bus_claim_resources() > + * or pci_bus_assign_resources(). > + */ > + if (pci_has_flag(PCI_PROBE_ONLY)) { > + pci_bus_claim_resources(bus); > + } else { > + pci_bus_size_bridges(bus); > + pci_bus_assign_resources(bus); > + > + list_for_each_entry(child, &bus->children, node) > + pcie_bus_configure_settings(child); > } > > - return devm_request_pci_bus_resources(dev, &pcie->resources); > + pci_bus_add_devices(bus); > + return 0; > } > > static int mvebu_pcie_probe(struct platform_device *pdev) > @@ -1268,7 +1312,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev) > bridge->align_resource = mvebu_pcie_align_resource; > bridge->msi = pcie->msi; > > - return pci_host_probe(bridge); > + return mvebu_pci_host_probe(bridge); > } > > static const struct of_device_id mvebu_pcie_of_match_table[] = { > > If that's what you meant, I'll go ahead and test on actual hardware and > submit as a proper patch. Yes, that's what I meant, I hope that you will have some bandwidth to discuss a way forward for v4.21, when this fix is merged (I think that v4.20 is a tall order but we can try if you will have time to post the patches - I suspect your fix will go in -rc6 if Bjorn can pull it this week). Lorenzo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-24 14:52 ` Thomas Petazzoni 2018-09-24 16:42 ` Lorenzo Pieralisi @ 2018-10-01 10:56 ` Jan Kundrát 2018-10-01 12:51 ` Thomas Petazzoni 1 sibling, 1 reply; 24+ messages in thread From: Jan Kundrát @ 2018-10-01 10:56 UTC (permalink / raw) To: Thomas Petazzoni, Lorenzo Pieralisi, Russell King - ARM Linux Cc: Baruch Siach, Jason Cooper, linux-pci, linux-kernel, Bjorn Helgaas, linux-arm-kernel On pondělí 24. září 2018 16:52:18 CEST, Thomas Petazzoni wrote: > Hello, > > On Mon, 24 Sep 2018 15:15:12 +0100, Lorenzo Pieralisi wrote: > >> I understand that, I wanted to make sure we come up with a fix asap >> and what I put forward would cover everything discussed in this thread, >> at least temporarily, giving us time to check ISA related issues while >> unmapping IO space. > > Something like this should implemented what you suggest I guess: > > diff --git a/drivers/pci/controller/pci-mvebu.c > b/drivers/pci/controller/pci-mvebu.c > index 50eb0729385b..a41d79b8d46a 100644 > --- a/drivers/pci/controller/pci-mvebu.c > +++ b/drivers/pci/controller/pci-mvebu.c > @@ -1145,7 +1145,6 @@ static int > mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) > { > struct device *dev = &pcie->pdev->dev; > struct device_node *np = dev->of_node; > - unsigned int i; > int ret; > > INIT_LIST_HEAD(&pcie->resources); > @@ -1179,13 +1178,58 @@ static int > mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie) > resource_size(&pcie->io) - 1); > pcie->realio.name = "PCI I/O"; > > + pci_add_resource(&pcie->resources, &pcie->realio); > + } > + > + return devm_request_pci_bus_resources(dev, &pcie->resources); > +} > + > +/* > + * This is a copy of pci_host_probe(), except that it does the I/O > + * remap as the last step, once we are sure we won't fail. > + * > + * It should be removed once the I/O remap error handling issue has > + * been sorted out. > + */ > +static int mvebu_pci_host_probe(struct pci_host_bridge *bridge) > +{ > + struct mvebu_pcie *pcie; > + struct pci_bus *bus, *child; > + int ret; > + > + ret = pci_scan_root_bus_bridge(bridge); > + if (ret < 0) { > + dev_err(bridge->dev.parent, "Scanning root bridge failed"); > + return ret; > + } > + > + pcie = pci_host_bridge_priv(bridge); > + if (resource_size(&pcie->io) != 0) { > + unsigned int i; > + > for (i = 0; i < resource_size(&pcie->realio); i += SZ_64K) > pci_ioremap_io(i, pcie->io.start + i); > + } > > - pci_add_resource(&pcie->resources, &pcie->realio); > + bus = bridge->bus; > + > + /* > + * We insert PCI resources into the iomem_resource and > + * ioport_resource trees in either pci_bus_claim_resources() > + * or pci_bus_assign_resources(). > + */ > + if (pci_has_flag(PCI_PROBE_ONLY)) { > + pci_bus_claim_resources(bus); > + } else { > + pci_bus_size_bridges(bus); > + pci_bus_assign_resources(bus); > + > + list_for_each_entry(child, &bus->children, node) > + pcie_bus_configure_settings(child); > } > > - return devm_request_pci_bus_resources(dev, &pcie->resources); > + pci_bus_add_devices(bus); > + return 0; > } > > static int mvebu_pcie_probe(struct platform_device *pdev) > @@ -1268,7 +1312,7 @@ static int mvebu_pcie_probe(struct > platform_device *pdev) > bridge->align_resource = mvebu_pcie_align_resource; > bridge->msi = pcie->msi; > > - return pci_host_probe(bridge); > + return mvebu_pci_host_probe(bridge); > } > > static const struct of_device_id mvebu_pcie_of_match_table[] = { > > If that's what you meant, I'll go ahead and test on actual hardware and > submit as a proper patch. Thomas, Russell, Lorenzo, did you have time to convert this into a patch which can hit 4.19? I don't see anything related in 4.19-rc6, but perhaps I missed something. Is there something that I should test or otherwise help? With kind regards, Jan ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-10-01 10:56 ` Jan Kundrát @ 2018-10-01 12:51 ` Thomas Petazzoni 2018-10-01 21:01 ` Bjorn Helgaas 0 siblings, 1 reply; 24+ messages in thread From: Thomas Petazzoni @ 2018-10-01 12:51 UTC (permalink / raw) To: Jan Kundrát, linux-pci Cc: Lorenzo Pieralisi, Russell King - ARM Linux, Baruch Siach, Jason Cooper, linux-kernel, Bjorn Helgaas, linux-arm-kernel Hello, On Mon, 01 Oct 2018 12:56:37 +0200, Jan Kundrát wrote: > Thomas, Russell, Lorenzo, > did you have time to convert this into a patch which can hit 4.19? I don't > see anything related in 4.19-rc6, but perhaps I missed something. Is there > something that I should test or otherwise help? Sorry, I suddenly got busy (my second son arrived a few days earlier than expected). I just sent a proper patch with the proposal I made last week, after testing on ClearFog and Armada XP GP. Note that on ClearFog, I only tested that it fixes the panic at boot, since I didn't had any mini-PCIe devices at hand. On Armada XP GP, I verified that an E1000E NIC was still working as expected. Therefore, it would be useful if you could test on your ClearFog platform with PCI devices connected. Thanks a lot and sorry for the delay. Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-10-01 12:51 ` Thomas Petazzoni @ 2018-10-01 21:01 ` Bjorn Helgaas 0 siblings, 0 replies; 24+ messages in thread From: Bjorn Helgaas @ 2018-10-01 21:01 UTC (permalink / raw) To: Thomas Petazzoni Cc: Jan Kundrát, linux-pci, Baruch Siach, Lorenzo Pieralisi, Jason Cooper, linux-kernel, Russell King - ARM Linux, Bjorn Helgaas, linux-arm-kernel On Mon, Oct 01, 2018 at 02:51:48PM +0200, Thomas Petazzoni wrote: > Hello, > > On Mon, 01 Oct 2018 12:56:37 +0200, Jan Kundrát wrote: > > > Thomas, Russell, Lorenzo, > > did you have time to convert this into a patch which can hit 4.19? I don't > > see anything related in 4.19-rc6, but perhaps I missed something. Is there > > something that I should test or otherwise help? > > Sorry, I suddenly got busy (my second son arrived a few days earlier > than expected). Congratulations! > I just sent a proper patch with the proposal I made last week, after > testing on ClearFog and Armada XP GP. Note that on ClearFog, I only > tested that it fixes the panic at boot, since I didn't had any > mini-PCIe devices at hand. On Armada XP GP, I verified that an E1000E > NIC was still working as expected. Therefore, it would be useful if > you could test on your ClearFog platform with PCI devices connected. > > Thanks a lot and sorry for the delay. And thanks for the patch! No need to apologize for having a life :) Bjorn ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" 2018-09-24 12:12 ` Thomas Petazzoni 2018-09-24 12:46 ` Lorenzo Pieralisi @ 2018-09-25 8:18 ` Andrew Murray 1 sibling, 0 replies; 24+ messages in thread From: Andrew Murray @ 2018-09-25 8:18 UTC (permalink / raw) To: Thomas Petazzoni Cc: Russell King - ARM Linux, Baruch Siach, Lorenzo Pieralisi, Jason Cooper, linux-pci, linux-kernel, Bjorn Helgaas, Jan Kundrát, linux-arm-kernel Hi Thomas, On Mon, Sep 24, 2018 at 02:12:03PM +0200, Thomas Petazzoni wrote: > Hello, > > On Mon, 24 Sep 2018 12:13:41 +0100, Russell King - ARM Linux wrote: > > > > But being able to unmap it would also be needed to be able to remove > > > PCI host controller drivers, and therefore compile them as module, and > > > make them more like any other drivers. > > > > > > I'm not sure why we need to guarantee that the I/O space is always > > > mapped: > > > > > > - It isn't mapped before the PCI controller driver does the mapping. > > > > > > - There is no reason for it to be accessed when the PCI controller > > > driver is not initialized: PCI devices can only be probed and > > > initialized when the PCI controller driver is probed/initialized. > > > > There are historic reasons. PCI provides ISA IO space, and when you > > have a machine with ISA peripherals present, the PCI IO space must > > never be unmapped - if it is, ISA drivers will oops the kernel. There > > is no way for a vanishing PCI controller to cause ISA drivers to be > > unbound. > > > > If you have a host controller that does unmap PCI IO space and you have > > ISA peripherals with drivers present, unbinding the PCI host controller > > will remove the IO space mapping, and next time an ISA peripheral > > touches IO space, the kernel will oops. > > Thanks for sharing some additional technical context on this, very > useful. > > I have another question though: shouldn't those ISA devices be child > devices of the PCI controller, if they use some resources of the PCI > controller ? Could you give an example of such an ISA device driver ? Legacy VGA also falls into this category - for example drivers/video/console/vgacon.c will happily use outb/inb macros to hard coded addresses which are hoped to be present on some PCI/ISA bus. With regards to ISA drivers - take a look for anything that registers with isa_register_driver - for example: drivers/input/touchscreen/htcpen.c drivers/net/ethernet/3com/3c509.c drivers/watchdog/ebc-c384_wdt.c None of these drivers do any kind of mapping before attempting to access these addresses. Thanks, Andrew Murray > This is just to understand better the issue, because there seems to be > a kind of hidden dependency between those ISA drivers and the setup of > the PCI controller. > > > > All other drivers, including on ARM, use pci_remap_iospace(), which > > > does provide the pci_unmap_iospace() counter part. > > > > ... which has been created in PCI land just to deal with PCI without > > regard for the above issue. > > > > However, there's another issue I missed - if you _do_ have ISA > > peripherals, you likely want the IO space setup from very early on, > > and you won't be using the new fangled PCI host driver support anyway. > > That uses pci_map_io_early() rather than pci_ioremap_io() or > > pci_remap_io(). > > OK. There's today a single platform (Footbridge) that uses > pci_map_io_early(), and it is indeed called through the ->map_io() > hook, which is very early in the boot process. > > BTW, look at drivers/pcmcia/at91_cf.c. It has ->probe() and ->remove(), > and does a pci_ioremap_io() in its ->probe(), and nothing in its > ->remove(). I don't think this driver, compiled as a module, will work > well after a insmod/rmmod/insmod cycle. > > > > But to me, the general direction is that the ARM-specific > > > pci_remap_io() API is fading away, and its replacement already provides > > > an unmapping capability. So why not add the same unmapping capability > > > to pci_remap_io() ? > > > > Yes, that would be a good longer term plan - we don't need three > > different ways to map PCI IO space, but it is development. > > Absolutely. Glad to hear that you agree on the longer term plan. > > > > But we have a regression and we need to fix it. Do you suggest to not > > > use the new pci_host_probe() API ? > > > > Well, arguably, the patch that caused the regression is the buggy patch, > > _not_ the lack of unmapping API for pci_ioremap_io(). > > Totally true. > > > Trying to address a regression with further development means that > > _that_ development needs thought and review, which is a slower > > process. > > > > I do understand the desire to keep moving forward and never take a > > step backwards, but sometimes backwards steps are the best way to > > resolve a regression. But I also do appreciate that a simple revert > > in this case is not possible. > > Well, I can revert: > > 42342073e38b50113354944cd51dcfed28d857a1 PCI: mvebu: Convert to use > pci_host_bridge directly ee1604381a371b3ea6aec7d5e43b6e3f5e153854 PCI: > mvebu: Only remap I/O space if configured > > so it's not a big deal either. I can revert those, and then resubmit a > more complete series later on that moves pci-mvebu to use > pci_remap_iospace(). > > > I'll accept your patch on the condition that the ARM private > > pci_ioremap_io() will go away in the very near future (please _try_ > > to get agreement on that before this patch is merged.) > > Bjorn, Lorenzo, what do you prefer ? > > If we want to get rid of pci_ioremap_io(), then we need a way to tell > pci_remap_iospace() the memory attributes that should be used for the > mapping, because on Armada 38x, we need to map the I/O space mapped > MT_UNCACHED instead of MT_DEVICE. I'm not sure how to achieve this yet. > Should pgprot_device() be changed to return MT_UNCACHED on a > platform-specific basis ? Any other idea ? > > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2018-10-01 21:01 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-09-12 16:11 [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" Jan Kundrát 2018-09-12 18:49 ` Baruch Siach 2018-09-12 18:50 ` Thomas Petazzoni 2018-09-12 19:00 ` Jan Kundrát 2018-09-12 23:10 ` Russell King - ARM Linux 2018-09-13 3:19 ` Baruch Siach 2018-09-13 7:45 ` Thomas Petazzoni 2018-09-13 8:20 ` Jan Kundrát 2018-09-13 8:42 ` Thomas Petazzoni 2018-09-24 10:02 ` Jan Kundrát 2018-09-24 10:10 ` Thomas Petazzoni 2018-09-24 10:12 ` Russell King - ARM Linux 2018-09-24 10:26 ` Thomas Petazzoni 2018-09-24 11:13 ` Russell King - ARM Linux 2018-09-24 12:12 ` Thomas Petazzoni 2018-09-24 12:46 ` Lorenzo Pieralisi 2018-09-24 13:10 ` Thomas Petazzoni 2018-09-24 14:15 ` Lorenzo Pieralisi 2018-09-24 14:52 ` Thomas Petazzoni 2018-09-24 16:42 ` Lorenzo Pieralisi 2018-10-01 10:56 ` Jan Kundrát 2018-10-01 12:51 ` Thomas Petazzoni 2018-10-01 21:01 ` Bjorn Helgaas 2018-09-25 8:18 ` Andrew Murray
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).