From: Mark Brown <broonie@kernel.org>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: lgirdwood@gmail.com, linux-kernel@vger.kernel.org,
linux-amlogic@lists.infradead.org,
boris.brezillon@free-electrons.com, thierry.reding@gmail.com
Subject: Re: [PATCH 1/1] regulator: pwm: suppress EPROBE_DEFER error message
Date: Wed, 23 Jan 2019 16:04:05 +0000 [thread overview]
Message-ID: <20190123160405.GD7503@sirena.org.uk> (raw)
In-Reply-To: <20190121183723.25231-2-martin.blumenstingl@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]
On Mon, Jan 21, 2019 at 07:37:23PM +0100, Martin Blumenstingl wrote:
> Suppress the "Failed to get PWM" error output if the actual error code
> is EPROBE_DEFER. This makes the behavior of the pwm-regulator driver
> consistent with what most other drivers do (which is: print all errors
> except EPROBE_DEFER).
>
> An example where this cleans up the kernel log are the 32-bit Amlogic
> Meson boards:
> multi_v7_defconfig has CONFIG_REGULATOR_PWM=y and CONFIG_PWM_MESON=m.
This also cleans up the kernel log in the case where you've not got a
driver enabled that you need (or it's not loading for some reason) which
isn't super helpful when you're trying to figure out why the driver
won't probe. There's not even anything at debug level, that would
probably be fine.
The ideal thing here would be to work on setting up the dependency
information based on DT and using that to try to sort initialization
order so we try things in an order that minimizes the number of failed
tries.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-01-23 16:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-21 18:37 [PATCH 0/1] pwm-regulator: reduce noise on EPROBE_DEFER Martin Blumenstingl
2019-01-21 18:37 ` [PATCH 1/1] regulator: pwm: suppress EPROBE_DEFER error message Martin Blumenstingl
2019-01-23 15:27 ` Anand Moon
2019-01-23 16:04 ` Mark Brown [this message]
2019-01-23 16:14 ` Ben Dooks
2019-01-23 17:29 ` Mark Brown
2019-01-21 19:18 ` [PATCH 0/1] pwm-regulator: reduce noise on EPROBE_DEFER Mark Brown
2019-01-21 20:55 ` Martin Blumenstingl
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=20190123160405.GD7503@sirena.org.uk \
--to=broonie@kernel.org \
--cc=boris.brezillon@free-electrons.com \
--cc=lgirdwood@gmail.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=thierry.reding@gmail.com \
/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