Sören Brinkmann soren.brinkmann@xilinx.com writes:

On Thu, 2015-01-29 at 05:27PM -0800, Sören Brinkmann wrote:

...

On Fri, 2015-01-30 at 12:51AM +0000, Kevin's boot bot wrote:

...

Full Build report: http://kernelci.org/build/arm-soc/kernel/v3.19-rc4-728-gbe9b5438817f/ Full Boot report: http://kernelci.org/boot/all/job/arm-soc/kernel/v3.19-rc4-728-gbe9b5438817f/

Tree/Branch: arm-soc Git describe: v3.19-rc4-728-gbe9b5438817f

Failed boot tests

                  zynq-zc702:     FAIL:    arm-multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
                                  kernel: ERROR: did not start booting.
                                  http://storage.kernelci.org/kernel-ci/arm-soc/v3.19-rc4-728-gbe9b5438817f/arm-multi_v7_defconfig+CONFIG_PROVE_LOCKING=y/lab-khilman/boot-zynq-zc702.html
                  zynq-zc702:     FAIL:    arm-multi_v7_defconfig
                                  kernel: ERROR: did not start booting.
                                  http://storage.kernelci.org/kernel-ci/arm-soc/v3.19-rc4-728-gbe9b5438817f/arm-multi_v7_defconfig/lab-khilman/boot-zynq-zc702.html

I looked into this. I don't know what exactly goes on, but my findings so far: Commit f52948ea12b61573224334ac0b637369ac56dc2f (ARM: zynq: DT: Add pinctrl information) is where boot breaks.

Reverting that commit fixes this. Merging pinctrl/devel (which has the pinctrl-zynq driver) fixes it too.

I would have expected that adding the pinctrl information without having a matching driver should not lead to any breakage. Apparently that is not the case, but at this point in time I don't know what's to blame for this.

Dumping the kernel's logbuffer shed some light on this: Turns out, when pinctrl information is in DT all drivers defer probing waiting for the pincontroller to become available. Since that one is missing in this branch this never happens, resulting in all drivers failing probe eventually.

Thanks for looking into it and reporting back.

I guess, our take away should be not to separate pinctrl driver and DT patches :)

It's probably OK that these patches take their separate paths to mainline. Ususally we notice stuff like this becuase of a boot breakage in arm-soc, but booting fine in linux-next.

One way to avoid the breakage in arm-soc is to be clear in the pull request that it has a dependency on some other tree/branch. We can then create some depends/* branches that are included in arm-soc/for-next so we avoid problems like this.

Anyways, thanks for doing the digging,

Kevin