diff mbox series

PM: opp: Fix NULL pointer exception on a v2 table combined with v1 opps

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

Commit Message

Krzysztof Kozlowski April 1, 2022, 12:03 p.m. UTC
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(-)

Comments

Viresh Kumar April 4, 2022, 6:26 a.m. UTC | #1
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.
Krzysztof Kozlowski April 4, 2022, 6:28 a.m. UTC | #2
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
Viresh Kumar April 4, 2022, 6:31 a.m. UTC | #3
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 mbox series

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;
 }