linux-kernel - Re: [PATCH 1/1] regulator: pwm: suppress EPROBE

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]

Date:   Wed, 23 Jan 2019 16:04:05 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc:     lgirdwood@...il.com, linux-kernel@...r.kernel.org,
        linux-amlogic@...ts.infradead.org,
        boris.brezillon@...e-electrons.com, thierry.reding@...il.com
Subject: Re: [PATCH 1/1] regulator: pwm: suppress EPROBE_DEFER error message

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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)