[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <63e83303-1bb8-44b4-b271-9052fbfd41e4@oss.nxp.com>
Date: Thu, 12 Sep 2024 15:16:37 +0300
From: Ciprian Marian Costea <ciprianmarian.costea@....nxp.com>
To: Conor Dooley <conor.dooley@...rochip.com>
Cc: Conor Dooley <conor@...nel.org>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Rob Herring <robh@...nel.org>, 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>,
Bogdan-Gabriel Roman <bogdan-gabriel.roman@....com>,
Ghennadi Procopciuc <ghennadi.procopciuc@....com>
Subject: Re: [PATCH 1/4] dt-bindings: rtc: add schema for NXP S32G2/S32G3 SoCs
On 9/12/2024 3:12 PM, Conor Dooley wrote:
> On Thu, Sep 12, 2024 at 03:00:20PM +0300, Ciprian Marian Costea wrote:
>> On 9/12/2024 2:13 PM, Conor Dooley wrote:
>>> On Thu, Sep 12, 2024 at 01:55:34PM +0300, Ciprian Marian Costea wrote:
>>>> On 9/11/2024 9:22 PM, Conor Dooley wrote:
>>>>> On Wed, Sep 11, 2024 at 10:00:25AM +0300, Ciprian Costea wrote:
>>>>>> From: Ciprian Marian Costea <ciprianmarian.costea@....nxp.com>
>>>>>>
>>>>>> This patch adds the dt-bindings for NXP S32G2/S32G3 SoCs RTC driver.
>>>>>
>>>>>> +properties:
>>>>>> + compatible:
>>>>>> + const: nxp,s32g-rtc
>>>>>
>>>>> Also, how come there are not specific compatibles for the two SoCs
>>>>> supported here?
>>>>
>>>> The RTC module is the same for S32G2 and S32G3 SoCs.
>>>> Therefore, I did not wanted to add two compatible strings ('nxp,s32g2-rtc'
>>>> and 'nxp,s32g3-rtc') when there is no actual difference which they could
>>>> target.
>>>
>>> Are these different fusings of the same silicon, or are they distinctly
>>> different SoCs that happen to share an IP block?
>>>
>>
>> S32G2 and S32G3 are different SoCs that share the RTC IP block.
>
> In that case, I'd expect there to be two compatibles, one for each SoC.
> One can then fall back to the other, so the driver only has to be aware
> of one compatible. Had they been different fusings of the same silicon,
> thus sharing the same integration etc, a generic compatible would have
> been fine.
I understand your point. I will update accordingly in V2 of this patchset.
Powered by blists - more mailing lists