* [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 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
* 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
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).