Message ID | 20220401120325.820763-1-krzysztof.kozlowski@linaro.org (mailing list archive) |
---|---|
State | New, archived |
Delegated to: | viresh kumar |
Headers | show |
Series | PM: opp: Fix NULL pointer exception on a v2 table combined with v1 opps | expand |
On 01-04-22, 14:03, Krzysztof Kozlowski wrote: > 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 use-case isn't supported currently, as either all OPPs should have required-opp or none. This kind of scenario may end up breaking at other places later on, as I have designed this stuff with the above assumption.
On 04/04/2022 08:26, Viresh Kumar wrote: > On 01-04-22, 14:03, Krzysztof Kozlowski wrote: >> 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 use-case isn't supported currently, as either all OPPs should > have required-opp or none. This kind of scenario may end up breaking > at other places later on, as I have designed this stuff with the > above assumption. 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. Best regards, Krzysztof
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(-)