From: pavel@ucw.cz (Pavel Machek)
To: linux-arm-kernel@lists.infradead.org
Subject: [alsa-devel] regression v4.16 on Nokia N900: sound does not work
Date: Fri, 2 Mar 2018 17:53:21 +0100 [thread overview]
Message-ID: <20180302165321.GG28931@amd> (raw)
In-Reply-To: <0f090cc7-2b72-a038-26ee-d43077cb9663@ti.com>
On Fri 2018-03-02 08:22:52, Andrew F. Davis wrote:
> On 03/02/2018 05:10 AM, Pavel Machek wrote:
> > Hi!
> >
> >>> 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?
> >
> > Ok, so this code looks pretty crazy to me: I tried removing the
> > "of_find_spi_gpio" part, and audio started working.
> >
> > What is going on with the ()s around == s? You made me look up C
> > operator precedence.
> >
> > Hmm, and it is also wrong, right? It turns any error code into ENOENT,
> > as it tries to do the "special handling".
> >
> > *
> > * This means we don't need to look any further for
> > * alternate name conventions, and we should really
> > * preserve the return code for our user to be able to
> > * retry probing later.
> > */
> > if (IS_ERR(desc) && PTR_ERR(desc) == -EPROBE_DEFER)
> > return desc;
> >
> > if (!IS_ERR(desc) || (PTR_ERR(desc) != -ENOENT))
> > break;
> > }
> >
> > /* Special handling for SPI GPIOs if used */
> > if (IS_ERR(desc))
> > desc = of_find_spi_gpio(dev, con_id, &of_flags);
> >
> > /* Special handling for regulator GPIOs if used */
> > if (IS_ERR(desc) && PTR_ERR(desc) != -EPROBE_DEFER)
> > desc = of_find_regulator_gpio(dev, con_id, &of_flags);
> >
> > Something like this?
> >
> > diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> > index 84e5a9d..f0fab26 100644
> > --- a/drivers/gpio/gpiolib-of.c
> > +++ b/drivers/gpio/gpiolib-of.c
> > @@ -241,29 +241,17 @@ struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
> >
> > desc = of_get_named_gpiod_flags(dev->of_node, prop_name, idx,
> > &of_flags);
> > - /*
> > - * -EPROBE_DEFER in our case means that we found a
> > - * valid GPIO property, but no controller has been
> > - * registered so far.
> > - *
> > - * This means we don't need to look any further for
> > - * alternate name conventions, and we should really
> > - * preserve the return code for our user to be able to
> > - * retry probing later.
> > - */
> > - if (IS_ERR(desc) && PTR_ERR(desc) == -EPROBE_DEFER)
> > - return desc;
> >
> > - if (!IS_ERR(desc) || (PTR_ERR(desc) != -ENOENT))
> > + if (!IS_ERR(desc) || PTR_ERR(desc) != -ENOENT)
>
>
> I rather like the () so one doesn't always have to look up C operator
> precedence to verify..
Well, Ok, but then the ()s should be at the other ifs nearby, too. See?
>
> > break;
> > }
> >
> > /* Special handling for SPI GPIOs if used */
> > - if (IS_ERR(desc))
> > + if (IS_ERR(desc) && PTR_ERR(desc) == -ENOENT)
> > desc = of_find_spi_gpio(dev, con_id, &of_flags);
> >
> > /* Special handling for regulator GPIOs if used */
> > - if (IS_ERR(desc) && PTR_ERR(desc) != -EPROBE_DEFER)
> > + if (IS_ERR(desc) && PTR_ERR(desc) == -ENOENT)
> > desc = of_find_regulator_gpio(dev, con_id, &of_flags);
> >
> > if (IS_ERR(desc))
> >
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180302/cda89865/attachment.sig>
next prev parent reply other threads:[~2018-03-02 16:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-24 21:46 regression v4.16 on Nokia N900:/dev/input/event6 aka AV Jack support disappeared Pavel Machek
2018-02-26 9:47 ` Thorsten Leemhuis
2018-02-26 13:13 ` regression v4.16 on Nokia N900: sound does not work Pavel Machek
2018-02-26 14:02 ` [alsa-devel] " Daniel Baluta
2018-02-26 23:13 ` Pavel Machek
2018-02-26 23:30 ` Pavel Machek
2018-02-27 8:43 ` Linus Walleij
2018-03-02 9:10 ` Pavel Machek
2018-03-02 9:33 ` Linus Walleij
2018-03-02 10:31 ` Pavel Machek
2018-03-02 12:07 ` Linus Walleij
2018-03-02 12:14 ` Pavel Machek
2018-03-02 12:33 ` Linus Walleij
2018-03-02 11:10 ` Pavel Machek
2018-03-02 11:21 ` Pavel Machek
2018-03-02 14:22 ` Andrew F. Davis
2018-03-02 16:53 ` Pavel Machek [this message]
2018-03-02 17:08 ` Russell King - ARM Linux
2018-03-02 17:18 ` Andrew F. Davis
2018-02-26 15:43 ` regression v4.16 on Nokia N900:/dev/input/event6 aka AV Jack support disappeared Andrew F. Davis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180302165321.GG28931@amd \
--to=pavel@ucw.cz \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).