Hi,
On Tue, Sep 14, 2021 at 5:29 PM Stephen Boyd swboyd@chromium.org wrote:
Quoting Philip Chen (2021-09-14 16:28:44)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c index e340af381e05..8d3e7a147170 100644 --- a/drivers/gpu/drm/bridge/parade-ps8640.c +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -368,6 +396,12 @@ static int ps8640_probe(struct i2c_client *client)
ps_bridge->page[PAGE0_DP_CNTL] = client;
ps_bridge->regmap[PAGE0_DP_CNTL] = devm_regmap_init_i2c(client, ps8640_regmap_config);if (IS_ERR(ps_bridge->regmap[PAGE0_DP_CNTL])) {return dev_err_probe(dev, PTR_ERR(ps_bridge->regmap[PAGE0_DP_CNTL]),"Error initting page 0 regmap\n");This one also doesn't return -EPROBE_DEFER? The dev_err_probe() should really only be used on "get" style APIs that can defer.
Any reason why you say that dev_err_probe() should only be used on "get" style APIs that can defer? Even if an API can't return -EPROBE_DEFER, using dev_err_probe() still (IMO) makes the code cleaner and should be used for any error cases like this during probe. Why?
* It shows the error code in a standard way for you. * It returns the error code you passed it so you can make your error return "one line" instead of 2.
Is there some bad thing about dev_err_probe() that makes it problematic to use? If not then the above advantages should be a net win, right?
-Doug