Thread (102 messages) 102 messages, 22 authors, 2015-10-27

Re: [GIT PULL] On-demand device probing

From: Mark Brown <broonie@kernel.org>
Date: 2015-10-18 19:54:13
Also in: dri-devel, linux-clk, linux-fbdev, linux-gpio, linux-i2c, linux-pm, linux-pwm, linux-tegra, lkml

On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
quoted
On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
quoted
quoted
I can't see adding calls like this all over the tree just to solve a
bus-specific problem, you are adding of_* calls where they aren't
needed, or wanted, at all.
quoted
This isn't bus specific, I'm not sure what makes you say that?
You are making it bus-specific by putting these calls all over the tree
in different bus subsystems semi-randomly for all I can determine.
Do you mean firmware rather than bus here?  I think that's the confusion
I have...
quoted
One is that regardless of the actual performance of the system when
deferred probe goes off it splats errors all over the console which
makes it look like something is going wrong even if everything is fine
in the end.  If lots of deferred probing happens then the volume gets
big too.  People find this distracting, noisy and ugly - it obscures
actual issues and trains people to ignore errors.  I do think this is a
reasonable concern and that it's worth trying to mitigate against
deferral for this reason alone.  We don't want to just ignore the errors
and not print anything either since if the resource doesn't appear the
user needs to know what is preventing the driver from instantiating so
they can try to fix it.
This has come up many times, I have no objection to just turning that
message into a debug message that can be dynamically enabled for those
people wanting to debug their systems for boot time issues.
It's not just the driver core logging, it's also all the individual
drivers logging that they failed to get whatever resource since silently
failing is not a great user experience.  Many, hopefully most, of the
drivers don't actually have special handling for probe deferral since
half the beauty of probe deferral is that the subsystem supplying the
resource can just return -EPROBE_DEFER when it notices something is
missing but might appear and then the drivers will do the right thing so
long as they have error handling code that they really should have
anyway.

We'd need to have a special dev_err() that handled probe deferral
errors for drivers to use during probe or some other smarts in the
logging infrastructure.  Which isn't a totally horrible idea.

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help