linux-kernel - Re: [PATCH v2 2/4] rtc: s32g: add NXP S32G2/S32G3 SoC support

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: <638262ae-0324-40a4-ae34-6b7962958600@oss.nxp.com>
Date: Fri, 18 Oct 2024 11:45:00 +0300
From: Ciprian Marian Costea <ciprianmarian.costea@....nxp.com>
To: Rob Herring <robh@...nel.org>
Cc: Alexandre Belloni <alexandre.belloni@...tlin.com>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Catalin Marinas <catalin.marinas@....com>,
 Will Deacon <will@...nel.org>, linux-rtc@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, NXP S32 Linux Team <s32@....com>,
 Christophe Lizzi <clizzi@...hat.com>, Alberto Ruiz <aruizrui@...hat.com>,
 Enric Balletbo <eballetb@...hat.com>, Bogdan Hamciuc
 <bogdan.hamciuc@....com>, Ghennadi Procopciuc <Ghennadi.Procopciuc@....com>
Subject: Re: [PATCH v2 2/4] rtc: s32g: add NXP S32G2/S32G3 SoC support

On 10/16/2024 12:04 AM, Rob Herring wrote:

Hello Rob,

Thanks for your careful review!

> On Tue, Oct 15, 2024 at 01:51:31PM +0300, Ciprian Costea wrote:
>> From: Ciprian Marian Costea <ciprianmarian.costea@....nxp.com>
>>
>> Add a RTC driver for NXP S32G2/S32G3 SoCs.
>>
>> The RTC module is used to enable Suspend to RAM (STR) support
>> on NXP S32G2/S32G3 SoC based boards.
>> RTC tracks clock time during system suspend.
>>
>> RTC from S32G2/S32G3 is not battery-powered and it is not
>> kept alive during system reset.
>>
>> Co-developed-by: Bogdan Hamciuc <bogdan.hamciuc@....com>
>> Signed-off-by: Bogdan Hamciuc <bogdan.hamciuc@....com>
>> Co-developed-by: Ghennadi Procopciuc <Ghennadi.Procopciuc@....com>
>> Signed-off-by: Ghennadi Procopciuc <Ghennadi.Procopciuc@....com>
>> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@....nxp.com>
>> ---
>>   drivers/rtc/Kconfig    |  11 +
>>   drivers/rtc/Makefile   |   1 +
>>   drivers/rtc/rtc-s32g.c | 778 +++++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 790 insertions(+)
>>   create mode 100644 drivers/rtc/rtc-s32g.c
> 
> 
>> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
>> index 8ee79cb18322..a63d010a753c 100644
>> --- a/drivers/rtc/Makefile
>> +++ b/drivers/rtc/Makefile
>> @@ -158,6 +158,7 @@ obj-$(CONFIG_RTC_DRV_RX8025)	+= rtc-rx8025.o
>>   obj-$(CONFIG_RTC_DRV_RX8111)	+= rtc-rx8111.o
>>   obj-$(CONFIG_RTC_DRV_RX8581)	+= rtc-rx8581.o
>>   obj-$(CONFIG_RTC_DRV_RZN1)	+= rtc-rzn1.o
>> +obj-$(CONFIG_RTC_DRV_S32G)	+= rtc-s32g.o
>>   obj-$(CONFIG_RTC_DRV_S35390A)	+= rtc-s35390a.o
>>   obj-$(CONFIG_RTC_DRV_S3C)	+= rtc-s3c.o
>>   obj-$(CONFIG_RTC_DRV_S5M)	+= rtc-s5m.o
>> diff --git a/drivers/rtc/rtc-s32g.c b/drivers/rtc/rtc-s32g.c
>> new file mode 100644
>> index 000000000000..d6502d8bf616
>> --- /dev/null
>> +++ b/drivers/rtc/rtc-s32g.c
> 
> 
>> +static const struct of_device_id rtc_dt_ids[] = {
>> +	{ .compatible = "nxp,s32g2-rtc", .data = &rtc_s32g2_data},
>> +	{ .compatible = "nxp,s32g3-rtc", .data = &rtc_s32g2_data},
> 
> Considering the data is the same and g3 has a fallback to g2 in the
> binding, you can drop this line.

Correct, I will update in V2.

> 
> And really you don't need rtc_s32g2_data because there is only 1
> possible value. But maybe you know some differences which are coming
> soon? Then it's probably okay. Up to the RTC maintainer though.
> 

I understand your point. I've considered adding 'rtc_s32g2_data' because 
for both S32G2 and S32G3 SoCs, one entry in the clock source mux is 
reserved.
Since this is IMHO a SoC limiation, and future SoCs which may use this 
driver may not have this limitation I've considered adding this 
limitation as a quirk.

> Rob



Best Regards,
Ciprian