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]

Message-ID: <afa9ed378b7fa62e81662363fdaf7543@codethink.co.uk>
Date:   Wed, 23 Jan 2019 16:14:49 +0000
From:   Ben Dooks <ben.dooks@...ethink.co.uk>
To:     Mark Brown <broonie@...nel.org>
Cc:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        linux-amlogic@...ts.infradead.org, thierry.reding@...il.com,
        boris.brezillon@...e-electrons.com, lgirdwood@...il.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] regulator: pwm: suppress EPROBE_DEFER error message



On 2019-01-23 16:04, Mark Brown wrote:
> 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.

Hmm, would it be useful to have a devfs file which holds the last probe 
code?