[PATCH 11/13] soc: qcom: Simplify with of_machine_get_match_data()

[Krzysztof Kozlowski]

On 08/11/2025 17:31, Dmitry Baryshkov wrote:
> On Fri, Nov 07, 2025 at 03:58:26PM +0100, Krzysztof Kozlowski wrote:
>> On 07/11/2025 15:23, Dmitry Baryshkov wrote:
>>> On Fri, Nov 07, 2025 at 08:08:28AM +0100, Krzysztof Kozlowski wrote:
>>>> On 07/11/2025 08:02, Krzysztof Kozlowski wrote:
>>>>> On 07/11/2025 04:19, Dmitry Baryshkov wrote:
>>>>>> On Thu, Nov 06, 2025 at 08:07:18PM +0100, Krzysztof Kozlowski wrote:
>>>>>>> Replace open-coded getting root OF node, matching against it and getting
>>>>>>> the match data with new of_machine_get_match_data() helper.
>>>>>>>
>>>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> Depends on the first OF patch.
>>>>>>> ---
>>>>>>>  drivers/soc/qcom/qcom_pd_mapper.c | 17 ++---------------
>>>>>>>  1 file changed, 2 insertions(+), 15 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/soc/qcom/qcom_pd_mapper.c b/drivers/soc/qcom/qcom_pd_mapper.c
>>>>>>> index 1bcbe69688d2..07198d44b559 100644
>>>>>>> --- a/drivers/soc/qcom/qcom_pd_mapper.c
>>>>>>> +++ b/drivers/soc/qcom/qcom_pd_mapper.c
>>>>>>> @@ -613,25 +613,12 @@ static void qcom_pdm_stop(struct qcom_pdm_data *data)
>>>>>>>  static struct qcom_pdm_data *qcom_pdm_start(void)
>>>>>>>  {
>>>>>>>  	const struct qcom_pdm_domain_data * const *domains;
>>>>>>> -	const struct of_device_id *match;
>>>>>>>  	struct qcom_pdm_data *data;
>>>>>>> -	struct device_node *root;
>>>>>>>  	int ret, i;
>>>>>>>  
>>>>>>> -	root = of_find_node_by_path("/");
>>>>>>> -	if (!root)
>>>>>>> -		return ERR_PTR(-ENODEV);
>>>>>>> -
>>>>>>> -	match = of_match_node(qcom_pdm_domains, root);
>>>>>>> -	of_node_put(root);
>>>>>>> -	if (!match) {
>>>>>>> -		pr_notice("PDM: no support for the platform, userspace daemon might be required.\n");
>>>>>>> -		return ERR_PTR(-ENODEV);
>>>>>>> -	}
>>>>>>> -
>>>>>>> -	domains = match->data;
>>>>>>> +	domains = of_machine_get_match_data(qcom_pdm_domains);
>>>>>>>  	if (!domains) {
>>>>>>> -		pr_debug("PDM: no domains\n");
>>>>>>> +		pr_notice("PDM: no support for the platform or no domains, userspace daemon might be required.\n");
>>>>>>>  		return ERR_PTR(-ENODEV);
>>>>>>>  	}
>>>>>>
>>>>>> Here you are mixing two cases:
>>>>>> - There is not match in the table (in which case the driver should print
>>>>>>   a notice)
>>>>>>
>>>>>> - There is a match in the table, but the data is NULL (the platform
>>>>>>   doesn't have PDM domains). In this case there should be no notice.
>>>>>
>>>>>
>>>>> Why? Existing code printed notice in both cases. Why refactoring which
>>>>> tries to keep code functionally equivalent should change it?
>>>>
>>>> Ah, you mean there was a debug before. Well, then I am a bit confused
>>>> because table has entries without data (so expected condition) but old
>>>> code returned ERRNO in such case - so unexpected condition.
>>>>
>>>> Wail failing the probe on expected condition?
>>>>
>>>> Unless it is not really expected and notice in second case is valid as well.
>>>
>>> If we know that there are no domains on the platform, then the notice
>>> definitely doesn't apply. Failing the probe is a separate topic. The
>>> rest of the code expects that _qcom_pdm_data is not NULL.
>>
>> I hoped that separate topic would be the reason, after commit msg
>> adjustments, to keep this change, but if you insist that this must stay
>> debug, then this patch should be just dropped because it is impossible
>> to achieve with current helpers.
> 
> Having the same pr_notice would be misleading: we point users to running
> userspace daemon, while we _know_ that the daemon is useless because
> there are no PDs. One of the ways to solve it would be to add extra
> wrapping, so that the data in the match table is never NULL.

The message does not matter. It still returns ENODEV which is failing
the probe. This leaves error messages in the dmesg already, if pdm is
ever probed for these devices, so my change of debug->notice here
really, really does not matter. Failing of probe is always a failure of
system, so it is not an expected behavior.

Anyway, I will just drop this change as I said.


Best regards,
Krzysztof