On 7/19/19 10:36 AM, Lucas Stach wrote:
Both the supplies and reset GPIO might need a probe deferral for the resource to be available. Don't print a error message in that case, as it is a normal operating condition.
Signed-off-by: Lucas Stach l.stach@pengutronix.de
sound/soc/codecs/tlv320aic31xx.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c index 9b37e98da0db..26a4f6cd3288 100644 --- a/sound/soc/codecs/tlv320aic31xx.c +++ b/sound/soc/codecs/tlv320aic31xx.c @@ -1553,7 +1553,8 @@ static int aic31xx_i2c_probe(struct i2c_client *i2c, aic31xx->gpio_reset = devm_gpiod_get_optional(aic31xx->dev, "reset", GPIOD_OUT_LOW); if (IS_ERR(aic31xx->gpio_reset)) {
dev_err(aic31xx->dev, "not able to acquire gpio\n");
if (PTR_ERR(aic31xx->gpio_reset) != -EPROBE_DEFER)
return PTR_ERR(aic31xx->gpio_reset); }dev_err(aic31xx->dev, "not able to acquire gpio\n");
@@ -1564,7 +1565,9 @@ static int aic31xx_i2c_probe(struct i2c_client *i2c, ARRAY_SIZE(aic31xx->supplies), aic31xx->supplies); if (ret) {
dev_err(aic31xx->dev, "Failed to request supplies: %d\n", ret);
if (ret != -EPROBE_DEFER)
dev_err(aic31xx->dev,
"Failed to request supplies: %d\n", ret);
I can't be the only one who thinks this looks much less readable than just breaking the 80 char line by a little..
All these one-off handlers for probe defer are cluttering the code base, was there some issue with just yielding for a time in these _get() functions until the device finally probes?
Anyway that's unrelated to this, for this patch:
Acked-by: Andrew F. Davis afd@ti.com
return ret;
}