linux-kernel - Re: [PATCH v2] mailbox: qcom-ipcc: Log the pending interrupt during resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <76a15747-b06e-e869-078f-ac4ad2e4a5ec@quicinc.com>
Date:   Thu, 12 May 2022 16:49:30 +0530
From:   Sibi Sankar <quic_sibis@...cinc.com>
To:     Manivannan Sadhasivam <mani@...nel.org>
CC:     <bjorn.andersson@...aro.org>, <jassisinghbrar@...il.com>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <agross@...nel.org>, Prasad Sodagudi <quic_psodagud@...cinc.com>
Subject: Re: [PATCH v2] mailbox: qcom-ipcc: Log the pending interrupt during
 resume



On 5/12/22 3:29 PM, Manivannan Sadhasivam wrote:
> On Thu, May 12, 2022 at 03:08:43PM +0530, Sibi Sankar wrote:
>> Hey Mani,
>>
>> Thanks for taking time to review the patch.
>>
>> On 5/12/22 1:13 PM, Manivannan Sadhasivam wrote:
>>> On Wed, May 11, 2022 at 12:13:24PM +0530, Sibi Sankar wrote:
>>>> From: Prasad Sodagudi <quic_psodagud@...cinc.com>
>>>>
>>>> Enable logging of the pending interrupt that triggered device wakeup. This
>>>> logging information helps to debug IRQs that cause periodic device wakeups
>>>> and prints the detailed information of pending IPCC interrupts instead of
>>>> the generic "Resume caused by IRQ 17, ipcc".
>>>>
>>>> Scenario: Device wakeup caused by Modem crash
>>>> Logs:
>>>> qcom-ipcc mailbox: virq: 182 triggered client-id: 2; signal-id: 2
>>>>
>>>>   From the IPCC bindings it can further understood that the client here is
>>>> IPCC_CLIENT_MPSS and the signal was IPCC_MPROC_SIGNAL_SMP2P.
>>>>
>>>> Signed-off-by: Prasad Sodagudi <quic_psodagud@...cinc.com>
>>>> Signed-off-by: Sibi Sankar <quic_sibis@...cinc.com>
>>>> ---
>>>>
>>>> V2:
>>>>    * Fix build error when ipcc is a module [Kernel Test Bot]
>>>>
>>>>    drivers/mailbox/qcom-ipcc.c | 27 +++++++++++++++++++++++++++
>>>>    1 file changed, 27 insertions(+)
>>>>
>>>> diff --git a/drivers/mailbox/qcom-ipcc.c b/drivers/mailbox/qcom-ipcc.c
>>>> index c5d963222014..21c071ec119c 100644
>>>> --- a/drivers/mailbox/qcom-ipcc.c
>>>> +++ b/drivers/mailbox/qcom-ipcc.c
>>>> @@ -254,6 +254,28 @@ static int qcom_ipcc_setup_mbox(struct qcom_ipcc *ipcc,
>>>>    	return devm_mbox_controller_register(dev, mbox);
>>>>    }
>>>> +#ifdef CONFIG_PM_SLEEP
>>>
>>> You don't need this guard anymore. Please see below.
>>
>> ack
>>
>>>
>>>> +static int qcom_ipcc_pm_resume(struct device *dev)
>>>> +{
>>>> +	struct qcom_ipcc *ipcc = dev_get_drvdata(dev);
>>>> +	u32 hwirq;
>>>> +	int virq;
>>>> +
>>>> +	hwirq = readl(ipcc->base + IPCC_REG_RECV_ID);
>>>> +	if (hwirq == IPCC_NO_PENDING_IRQ)
>>>> +		return 0;
>>>> +
>>>> +	virq = irq_find_mapping(ipcc->irq_domain, hwirq);
>>>> +
>>>> +	dev_info(dev, "virq: %d triggered client-id: %ld; signal-id: %ld\n", virq,
>>>> +		 FIELD_GET(IPCC_CLIENT_ID_MASK, hwirq), FIELD_GET(IPCC_SIGNAL_ID_MASK, hwirq));
>>>> +
>>>
>>> Does this really need to be dev_info? This looks like a dev_dbg() material to
>>> me.
>>
>> The whole point of the log is to catch sporadic issues like random
>> wakeups caused by remoteprocs through ipcc. We would just end up with
>> a single line identifying the client id during resume if ipcc had indeed
>> caused the wakeup else it wouldn't print anything.
>>
> 
> Right but that information is only required for debugging the periodic wakeups.
> And that's not going to be useful for an end user.

I would consider this an extension to "Resume caused by IRQ xx, xxxx"
print that we get to identify the wake up source. That's the reasoning
behind marking it as dev_info (being able to nail down random wakeups is
just an added advantage). That said I'll re-spin it with dbg if that's
the consensus.

> 
> Thanks,
> Mani
> 
>> -Sibi
>>>
>>>> +	return 0;
>>>> +}
>>>> +#else
>>>> +#define qcom_ipcc_pm_resume NULL
>>>> +#endif
>>>> +
>>>>    static int qcom_ipcc_probe(struct platform_device *pdev)
>>>>    {
>>>>    	struct qcom_ipcc *ipcc;
>>>> @@ -324,6 +346,10 @@ static const struct of_device_id qcom_ipcc_of_match[] = {
>>>>    };
>>>>    MODULE_DEVICE_TABLE(of, qcom_ipcc_of_match);
>>>> +static const struct dev_pm_ops qcom_ipcc_dev_pm_ops = {
>>>> +	SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(NULL, qcom_ipcc_pm_resume)
>>>> +};
>>>> +
>>>>    static struct platform_driver qcom_ipcc_driver = {
>>>>    	.probe = qcom_ipcc_probe,
>>>>    	.remove = qcom_ipcc_remove,
>>>> @@ -331,6 +357,7 @@ static struct platform_driver qcom_ipcc_driver = {
>>>>    		.name = "qcom-ipcc",
>>>>    		.of_match_table = qcom_ipcc_of_match,
>>>>    		.suppress_bind_attrs = true,
>>>> +		.pm = &qcom_ipcc_dev_pm_ops,
>>>
>>> You can use the new pm_sleep_ptr() macro to avoid the PM_SLEEP guard.
>>>
>>> 		.pm = pm_sleep_ptr(&qcom_ipcc_dev_pm_ops),
>>
>> ack
>>
>>>
>>> Thanks,
>>> Mani
>>>
>>>>    	},
>>>>    };
>>>> -- 
>>>> 2.7.4
>>>>
>>>
>