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(-)

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

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.

-- 
viresh

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 :)

-- 
viresh