On Tue, Dec 16, 2014 at 11:27:03AM +0100, Mike Looijmans wrote: > On 12/09/2014 07:48 PM, Mark Brown wrote: > >On Tue, Dec 09, 2014 at 07:12:30PM +0100, Mike Looijmans wrote:
> >>Can we instead at least reduce it to WARN or INFO level then? > >You appear to have deleted my reply here... one problem with your > >suggestion is that it means we have to special case all error handling > >on probe for deferral which isn't wonderful. > special casing deferral may not be "wonderful", but it is what currently > happens in many places, and it's just "the best we can do for now". A > similar patch for MMC got approval: > https://lkml.org/lkml/2014/10/27/477 That's just one call site, were all the other places that might see a probe deferral updated too? That also looks like a case of the core passing through other errors rather than a case of primary error reporting - I guess there's a reasonable case for the core not logging at all here since the drivers ought to be doing it. > >>I have to explain over and over again that there's no problem when that > >>message comes along ten times in a row. And it causes people to overlook the > >>messages that really are errors. > >Can we do something with the log message that triggers on probe > >deferral? There tends to be a learning curve with probe deferral but > >the fact that it's generally extremely noisy tends to be useful - I > >usually point people at that (not just in the context at regulators) and > >tell them not to worry unless debugging. > Using "dev_err" is not really "tell them not to worry unless debugging", I > think that is what "dev_dbg" was meant to do. Well, then the core probe deferral stuff ought to be less chatty then... > The only real solution I could come up with here is to replace "return > -EPROBE_DEFER" with something that stores the current stack, registers the > resource it requires and jumps back to where the driver probe originated. > Once the resource is available, the stored stack is resumed and then the > probe code path can continue as if nothing bad happened. This would also > deliver excellent diagnostic data in case the resource remains absent. I've > built something like this in Python which has a "yield" statement one can > use for this purpose. It's a bit tougher to do in C I guess. So until then, > we're stuck with sprinkling "if (ret == -EPROBE_DEFER)" code snippets all > over the place. There was a proposal the other day for a restrack framework (name might change in future) which drivers would call in their probe and get a callback when everything appears.
signature.asc
Description: Digital signature
