Re: [PATCH v3 1/2] drivers: rtc: add max313xx series rtc driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 13/03/23 15:20, Alexandre Belloni wrote:
> Hello,
> On 13/03/2023 02:15:26+0000, Chris Packham wrote:
>> Hi Ibrahim,
>> On 18/02/23 04:17, Tilki, Ibrahim wrote:
>>>> Hi Ibrahim,
>>>> On 9/11/22 01:22, Ibrahim Tilki wrote:
>>>>> Adding support for Analog Devices MAX313XX series RTCs.
>>>>> Signed-off-by: Ibrahim Tilki <Ibrahim.Tilki@xxxxxxxxxx>
>>>>> Signed-off-by: Zeynep Arslanbenzer <Zeynep.Arslanbenzer@xxxxxxxxxx>
>>>>> ---
>>>>>     drivers/rtc/Kconfig        |   11 +
>>>>>     drivers/rtc/Makefile       |    1 +
>>>>>     drivers/rtc/rtc-max313xx.c | 1070 ++++++++++++++++++++++++++++++++++++
>>>>>     3 files changed, 1082 insertions(+)
>>>>>     create mode 100644 drivers/rtc/rtc-max313xx.c
>>>> What is the current state of this work? I see there are some comments on
>>>> this v3 iteration from late last year and I couldn't find any newer
>>>> iteration on any mailing list. We've got some new hardware arriving soon
>>>> that will have the MAX31331 RTC and I'm keen to see this patch series
>>>> land. Is there anything I can do to help it along? I can't be very
>>>> specific about when I'll see the new hardware (who can these days), the
>>>> last update was "boards are due in March".
>>>> For the maintainers on the Cc list once the dust settles how would I get
>>>> this supported in a LTS kernel (we're currently using the 5.15 series)?
>>>> Or is totally out of the question because it's not just a new device id?
>>> Hi Chris,
>>> Patch v4 is on the way, I will be sending it in a few weeks.
>>> It is hard to tell when it is going to land but I expect to be more responsive
>>> to reviews after patch v4.
>> FYI I've now got some boards with a MAX31331. I've given v3 a quick test
>> and it works for me.
>> Are you also looking at a u-boot driver? If not I can port your driver
>> across reasonably easily.
> I'm curious why would you need an RTC driver for u-boot?

Short answer is because u-boot has RTC drivers and commands to set/read 

Slightly longer answer is that for our current products (most with a 
DS1340 or something close) our initial manufacturing process includes 
setting the RTC from u-boot. It's mostly a "because we've always done it 
that way" but it does have the advantage that any logs or files created 
on first boot get timestamped correctly. Yes we could set the clock from 
userland on first boot but there would be a few odd log entries from 
before the RTC was set.

[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux