linux-kernel - Re: [PATCH] iio: sx9310: Prefer async probe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200829181754.52d3cc3b@archlinux>
Date:   Sat, 29 Aug 2020 18:17:54 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Stephen Boyd <swboyd@...omium.org>,
        Alexandru Ardelean <alexandru.ardelean@...log.com>,
        Daniel Campello <campello@...omium.org>,
        Enrico Granata <egranata@...omium.org>,
        Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        linux-iio <linux-iio@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Dmitry Torokhov <dtor@...omium.org>
Subject: Re: [PATCH] iio: sx9310: Prefer async probe

On Sat, 29 Aug 2020 09:56:41 -0700
Doug Anderson <dianders@...omium.org> wrote:

> Hi,
> 
> On Sat, Aug 29, 2020 at 8:12 AM Jonathan Cameron <jic23@...nel.org> wrote:
> >
> > On Fri, 28 Aug 2020 17:01:18 -0700
> > Douglas Anderson <dianders@...omium.org> wrote:
> >  
> > > On one board I found that:
> > >   probe of 5-0028 returned 1 after 259547 usecs
> > >
> > > There's no reason to block probe of all other devices on our probe.
> > > Turn on async probe.
> > >
> > > Signed-off-by: Douglas Anderson <dianders@...omium.org>
> > > ---
> > > NOTE: I haven't done any analysis of the driver to see _why_ it's so
> > > slow, only that I have measured it to be slow.  Someone could
> > > certainly take the time to profile / optimize it, but in any case it
> > > still won't hurt to be async.  
> >
> > Hmm. It is vanishingly rare to use that flag  
> 
> My guess is that people just haven't been spending as much time
> optimizing boot performance recently.  I've been trying to do this and
> finding that there are quite a few drivers that could benefit from
> this flag.
> 
> In theory this flag should probably be on by default and it looks like
> that was Dmitry's original intention but the state of the world 5
> years ago was that it wasn't quite ready for this.  I think, in
> particular, drivers that are more core to the system (IOMMUs, clocks,
> regulators, etc) may not have been ready, but misc peripherals should
> be no problem.

That fits with my understanding.  Would be great to have it on
by default though I guess it could make for some really hard to debug
race conditions.


> 
> 
> > so I'm not particularly
> > keen on starting to deploy it when we don't know why a particular
> > driver is taking so long.  I agree it should be safe but I don't
> > like oddities I don't understand!
> >
> > There are some sleeps in there but they are all of the order of a few
> > msecs.
> >
> > Could it be there is a regulator that is coming up very slowly?
> >
> > Any other ideas?  
> 
> I can do a little bit of profiling next week, but even if we get this
> down from 250 ms to 10 ms I'd still like to see async probe turned on.
> There's no reason for it to be off and every little bit counts.
Agreed. However, I'd like a comment next to the place we turn it on
saying what delays we are trying to mitigate by enabling it in this
driver.

Jonathan

> 
> 
> > Jonathan
> >  
> > >
> > > This is a very safe flag to turn on since:
> > >
> > > 1. It's not like our probe order was defined by anything anyway.  When
> > > we probe is at the whim of when our i2c controller probes and that can
> > > be any time.
> > >
> > > 2. If some other driver needs us then they have to handle the fact
> > > that we might not have probed yet anyway.
> > >
> > > 3. There may be other drivers probing at the same time as us anyway
> > > because _they_ used async probe.
> > >
> > > While I won't say that it's impossible to tickle a bug by turning on
> > > async probe, I would assert that in almost all cases the bug was
> > > already there and needed to be fixed anyway.
> > >
> > > ALSO NOTE: measurement / testing was done on the downstream Chrome OS
> > > 5.4 tree.  I confirmed compiling on mainline.
> > >
> > >  drivers/iio/proximity/sx9310.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/iio/proximity/sx9310.c b/drivers/iio/proximity/sx9310.c
> > > index dc2e11b43431..444cafc53408 100644
> > > --- a/drivers/iio/proximity/sx9310.c
> > > +++ b/drivers/iio/proximity/sx9310.c
> > > @@ -1054,6 +1054,7 @@ static struct i2c_driver sx9310_driver = {
> > >               .acpi_match_table = ACPI_PTR(sx9310_acpi_match),
> > >               .of_match_table = of_match_ptr(sx9310_of_match),
> > >               .pm = &sx9310_pm_ops,
> > > +             .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> > >       },
> > >       .probe          = sx9310_probe,
> > >       .id_table       = sx9310_id,  
> >