The ISR calls dev_pm_opp_find_bw_ceil(), which can return EINVAL, ERANGE or ENODEV, and if that one fails with ERANGE, then it tries again with floor dev_pm_opp_find_bw_floor(). In theory, following error paths are possible: 1. First dev_pm_opp_find_bw_ceil() failed with an error different than ERANGE, 2. Any error from second dev_pm_opp_find_bw_floor(). However in practice this would mean that there are no suitable OPPs at all, which is already being checked in the drivers probe() function. This is impossible condition. Relying however in interrupt handler bwmon_intr_thread() on preconditions checked in probe() are not easy to follow from code readability and very difficult to handle in static analysis, thus let's make the code just obvious to silence warning reported by Smatch: Reported by Smatch: icc-bwmon.c:693 bwmon_intr_thread() error: 'target_opp' dereferencing possible ERR_PTR() Reported-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx> Closes: https://lore.kernel.org/r/aJTNEQsRFjrFknG9@stanley.mountain/ Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> --- Changes in v2: 1. Rephrase commit msg (Konrad) 2. Drop Fixes and cc-stable as this is impossible to trigger --- drivers/soc/qcom/icc-bwmon.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/soc/qcom/icc-bwmon.c b/drivers/soc/qcom/icc-bwmon.c index 3dfa448bf8cf..597f9025e422 100644 --- a/drivers/soc/qcom/icc-bwmon.c +++ b/drivers/soc/qcom/icc-bwmon.c @@ -656,6 +656,9 @@ static irqreturn_t bwmon_intr_thread(int irq, void *dev_id) if (IS_ERR(target_opp) && PTR_ERR(target_opp) == -ERANGE) target_opp = dev_pm_opp_find_bw_floor(bwmon->dev, &bw_kbps, 0); + if (IS_ERR(target_opp)) + return IRQ_HANDLED; + bwmon->target_kbps = bw_kbps; bw_kbps--; -- 2.48.1
