| Message ID | 20220401120325.820763-1-krzysztof.kozlowski@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | PM: opp: Fix NULL pointer exception on a v2 table combined with v1 opps | expand |
On 04-04-22, 08:28, Krzysztof Kozlowski wrote: > I understand this is not a proper use case, but it is easy to trigger > (UFS driver adds opps manually, DTS also adds one). Maybe you prefer to > handle it differently - exit with ERRNO? Because NULL pointer exception > in case of proper, but unexpected DTB is not a good way to handle it. Yeah, sure. I agree that we can return a proper error in that case. Will look forward to that patch :)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c index 740407252298..d21b7e7e3f9f 100644 --- a/drivers/opp/core.c +++ b/drivers/opp/core.c @@ -1760,7 +1760,9 @@ int _opp_add(struct device *dev, struct dev_pm_opp *new_opp, if (lazy_linking_pending(opp_table)) return 0; - _required_opps_available(new_opp, opp_table->required_opp_count); + /* No required_opps for v1 bindings OPP */ + if (new_opp->required_opps) + _required_opps_available(new_opp, opp_table->required_opp_count); return 0; }
dev_pm_opp_add() adds a v1 OPP. If the Devicetree contains an OPP v2 table with required-opps, but the driver uses dev_pm_opp_add(), the table might have required_opp_count!=0 but the opp->required_opps will be NULL. This leads to NULL pointer exception, e.g. with ufs-qcom.c driver and v2 OPP table in DTS: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ... Call trace: _required_opps_available+0x20/0x80 _opp_add_v1+0xa8/0x110 dev_pm_opp_add+0x54/0xcc ufshcd_async_scan+0x190/0x31c async_run_entry_fn+0x38/0x144 Fixes: cf65948d62c6 ("opp: Filter out OPPs based on availability of a required-OPP") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> --- drivers/opp/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)