Hi Luis, On Sat, 4 Feb 2017 12:05:42 -0800 "Luis R. Rodriguez" <mcg...@kernel.org> wrote: > > though so it seems something with my configuration and boot. I > bisected next-20170203 between its latest commit and v4.10-rc6 and > ended up with this bad commit: > > 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62 > > $ git show 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62 > commit 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62 > Merge: 7c3b1edeee66 3f87493930a0 > Author: Stephen Rothwell <s...@canb.auug.org.au> > Date: Fri Feb 3 12:30:38 2017 +1100 > > Merge remote-tracking branch 'spi/for-next' > > I have checked Next/SHA1s and it shows: > > mcgrof@piggy ~/linux-next (git::original)$ grep spi Next/SHA1s > spi-nor dc12bcccadafb5441170e6b7c8a438c91d4f385b > spi 3f87493930a0f934549b04e100ecc2110e4f1efd > hwspinlock bd5717a4632cdecafe82d03de7dcb3b1876e2828 > > The commit 3f87493930a0f934549b04e100ecc2110e4f1efd then seems to be > what I need to test. I have cloned Mark's spi tree and just tried to > boot the for-next branch (on v4.10-rc1) on > 3f87493930a0f934549b04e100ecc2110e4f1efd, and it boots successfully. > This would lead me to believe this issue might be related to the merge > conflict resolution done by Stephen, but wanted to check and ask. > Perhaps there might be some specific tests I can run.
OK, it is possible that the merge is actually incorrect. I did *not* do any manual resolution of that merge and git only reported an automatic resolution in file drivers/spi/spi-bcm-qspi.c (which looks ok from a quick glance). It is always possible that there is some semantic conflict that git won't see and didn;t also involve a syntactic conflict or a build failure. e.g. the internal semantics of a function changes on one side of the merge but a new usage expecting the old semantics is introduced on the other side. -- Cheers, Stephen Rothwell
