On Fri, Mar 2, 2018 at 11:31 AM, Pavel Machek pavel@ucw.cz wrote:
On Fri 2018-03-02 10:33:24, Linus Walleij wrote:
On Fri, Mar 2, 2018 at 10:10 AM, Pavel Machek pavel@ucw.cz wrote:
Linux-Regression-ID: lr#4b650f
On Tue 2018-02-27 09:43:32, Linus Walleij wrote:
On Tue, Feb 27, 2018 at 12:13 AM, Pavel Machek pavel@ucw.cz wrote:
I did git bisect, and the winner seems to be:
pavel@duo:/data/l/linux-n900$ git bisect bad c85823390215e52d68d3826df92a447ed31e5c80 is the first bad commit commit c85823390215e52d68d3826df92a447ed31e5c80 Author: Linus Walleij linus.walleij@linaro.org Date: Wed Dec 27 16:37:44 2017 +0100
gpio: of: Support SPI nonstandard GPIO propertiesI have fixes queued for this, tried to send a pull request yesterday but it turns out the fixes need fixing... OK I'm onto it anyways.
Do you have any updates? Is there way to fix dts so that this does not trigger on N900?
If this is taking longer to fix, should c85823390215 be reverted in the meantime? It does not seem particulary important/urgent...
No patience between the v4.16 release candidates eh ;)
commit 6662ae6af82df10259a70c7569b4c12ea7f3ba93 ("gpiolib: Keep returning EPROBE_DEFER when we should")
and
commit ce27fb2c56db6ccfe8099343bb4afdab15e77e7b ("gpio: Handle deferred probing in of_find_gpio() properly")
that are both in Torvalds' tree since yesterday should be fixing this, I think? Did you try just using the upstream HEAD?
After I spent hours bisecting, I was kind of assuming you'd cc me on merge request or something like that... so that I could test it before going mainline.
Sorry, I'm not very good with planning and coordination. I just try my best to keep this working.
I guess ideally we should use Bugzilla to track regressions like this, but it also comes with a bit of overhead so I don't know if it helps more than trying to keep things in the head.
Which of those should fix it?
The first one I guess, the second is mostly about supporting -EPROBE_DEFER for different use cases.
I tested today's mainline, and... sound fails, different way:
pavel@n900:~$ cat /proc/asound/cards 0 [RX51 ]: RX-51 - RX-51 RX-51 pavel@n900:~$ cd g/tui/ofone/ pavel@n900:~/g/tui/ofone$ cd pavel@n900:~$ festival --tts ahoj ^D uname -a
(Festival is hung).
Sorry but I need some background here, I have no idea what festival is, other than it seems to be some kind of userspace test program?
Ok, so this code looks pretty crazy to me: I tried removing the "of_find_spi_gpio" part, and audio started working.
Hmm. Looks like audio is working w/o any changes, too. Not sure why festival hung on me before.
Does it mean that mainline is working find for you or do we need to look deeper into the problem in the OF lookup?
Yours, Linus Walleij