[PATCH v5 2/4] rtc: s32g: add NXP S32G2/S32G3 SoC support

Ciprian Marian Costea ciprianmarian.costea at oss.nxp.com
Mon Dec 2 05:06:38 PST 2024


On 11/27/2024 5:32 PM, Alexandre Belloni wrote:
> On 27/11/2024 17:07:48+0200, Ciprian Marian Costea wrote:
>>>> +	if (priv->dt_irq_id < 0)
>>>> +		return priv->dt_irq_id;
>>>> +
>>>> +	ret = devm_request_irq(dev, priv->dt_irq_id,
>>>> +			       s32g_rtc_handler, 0, dev_name(dev), pdev);
>>>> +	if (ret) {
>>>> +		dev_err(dev, "Request interrupt %d failed, error: %d\n",
>>>> +			priv->dt_irq_id, ret);
>>>> +		goto disable_rtc;
>>>
>>>
>>> Already enable rtc at rtc_clk_src_setup(), you direct return fail after
>>> check clk_get_rate();
>>>
>>> if you want to disable_rtc, you use devm_add_action_or_reset() to add
>>> a disable action callback and return dev_err_probe() here directly.
>>>
>>> Frank
>>>
>>
>> Thanks for pointing this out. I will use 'devm_add_action_or_reset' in V6.
>>
> 
> Won't this disable the RTC on driver unload which we already discussed
> should not be done?
> 

This is true. Thanks for reminding me about this discussion/issue.
I will just fix the error paths for 'clk_get_rate' and 'platform_get_irq'.

>>>> +	/* Reset RTC to prevent overflow.
>>>> +	 * RTCCNT (RTC Counter) cannot be individually reset
>>>> +	 * since it is RO (read-only).
>>>> +	 */
>>>
>>> what's happen if overflow happen? I suppose it should go back to 0 and
>>> continue increase?
>>>
>>
>> Indeed if overflow happens the 'RTCCNT' counter goes back to 0 and continues
>> to increase. The reason for resetting it here in 'suspend' routine comes
>> after dropping the rollover support (as agreed on V4 of this patchset) to
>> prevent an overflow during the standby state.
>>
> 
> I don't think the overflow matters as the comparator should continue to work
> properly after it happens so you always have the complete range to wait
> for the alarm to happen.
> 
> 

I think I can drop the RTC reset from the suspend routine for this 
current patchset.


Best Regards,
Ciprian




More information about the linux-arm-kernel mailing list