Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Wed, 23 Jan 2019 16:14:49 +0000
From:   Ben Dooks <ben.dooks@codethink.co.uk>
To:     Mark Brown <broonie@kernel.org>
Cc:     Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
        linux-amlogic@lists.infradead.org, thierry.reding@gmail.com,
        boris.brezillon@free-electrons.com, lgirdwood@gmail.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] regulator: pwm: suppress EPROBE_DEFER error message
In-Reply-To: <20190123160405.GD7503@sirena.org.uk>
References: <20190121183723.25231-1-martin.blumenstingl@googlemail.com>
 <20190121183723.25231-2-martin.blumenstingl@googlemail.com>
 <20190123160405.GD7503@sirena.org.uk>
Message-ID: <afa9ed378b7fa62e81662363fdaf7543@codethink.co.uk>
User-Agent: Roundcube Webmail/1.1.5
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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?