QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2

[Enrico Tagliavini]

Yeah that's what I meant. My idea was to first bisect only the ath10k
directory, so restricting the bisect on the commits touching stuff
there. I guess if the issue is more broad it will come up somewhere
else as well, so this is a good starting point, I hope. Thank you for
pointing it out though, this will actually be the first time I do a
proper bisect.

Also do you want me to bisect Kalle's sources or Linus' master? By
what Michał said I guess Kalle's but I ask to be sure.

Also to be clear: I'm using Linus' sources at the moment, as provided
by Fedora rawhide.

For me it's the same, so let me know what you prefer and is more
useful to solve this issue.

On 29 July 2015 at 08:54, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>>> This wont work for bisecting. I have to setup something else. Is
>>> it ok if I restrict the bisect on the ath10k tree? That has enough
>>> commit already to begin with, plus I'm going to be on the road in less
>>> than two weeks.
>>
>> As long as you establish a working and a non-working commit id on
>> kvalo tree it should be fine I guess.
>
> And you can always limit the bisect to a certain directory, but the risk
> here is that if the regression is outside ath10k bisect won't find it.
> So you need to carefully consider is it safe to do or not. From the man
> page:
>
> "Cutting down bisection by giving more parameters to bisect start
>
>        You can further cut down the number of trials, if you know what
>        part of the tree is involved in the problem you are tracking
>        down, by specifying path parameters when issuing the bisect start
>        command:
>
>            $ git bisect start -- arch/i386 include/asm-i386"
>
> Also if you can even just narrow down the regression to a smaller set of
> patches, let's say few hundred, might make it easier to find the
> regression.
>
> --
> Kalle Valo