 Okay, so I guess it's time I'm a bit sick, so I hope you will understand me correctly So first slide. Who am I? So I'm Alexandre Belloni. I'm an embedded Linux engineer at bootlin We are doing embedded link stuff mostly development consulting a bit of training and We have a strong open source focus, right? So I'm a I'm a Contributor and one of the main I'm the maintainer for the Linux kernel RTC subsystem So that's why this talk is there and now I'm also co-maintaining Support for the microchip arm. So see so previously they were at mail now there are microchip and I'm also maintaining the microchip MIPS so sees now so The RTC subsystem it was introduced in 2.6.17 So it's actually pretty recent I would say because all the history is it is in git Right, so there is if you want to see the whole development story of it. It's it's in it So it's a pretty convenient. I took over the maintenance in 4.1. So it was in April 2015 and And just for some information just Historic information so basically the mailing list was on Google group groups until Google decided it was sending a lot of spam Actually, it still receives like I don't know 300 job offers per day or so. So, yeah, it was sending a lot So now it's on Voyager on Kernel.org It has been created just after that The archives are now also on Lore which is pretty nice because it's a public inbox. So if you want to To get all the archives from the beginning so you will get them I'm using patchwork This is something I did basically patchwork was kind of left as is it had like 3600 patches to review. I did most of the work and now At about 20 something like that. So that's nice And the git repository is on kernel.org if you are looking for the latest code, so it's there Some statistics just to show you it's it's still lively right, so those are mailing list statistics inside I took the Since I took the project right so This is a number of mails. I'm kind of reading And he commits statistics. So those are the statistics in the beginning of The RTC subsystems you will see some spikes So there is a spike since 3.10 and another one is 3.11 those were the conversions to the Dev and manage Registration for the RTCs. So we had one patch per driver, which is a kind of a lot Yeah, so The recent changes Yeah, so why do we have so many commits and so many mails It's because basically every vendor just decided that their own IP will be better than the other one So we have many many drivers and so since 4.0, I have all those drivers that are brand new and some other ones that just took That are compatible with new IPs. So yeah You will say okay an RTC is quite simple, right? It just gives it that is a date and the time But basically every vendor just said that it does that better than the other ones so Recent changes So the RTC is not one RTC is not exactly just giving the time, right? you sort of want that time to be precise enough and what you will get is that You have a crystal that is either external or in package of the RTC and it's usually running as 32 kilohertz and Because of my manufacturing process or Even because of the temperature or simply aging of the quartz inside the crystal You will find variants in the exact frequency So you want to be able to be to change or to tune that frequency so some RTCs will Provide you with some registers to control Correction pulses so basically what they do is that they will add or subtract pulses from time to time in a second and so that second will be a slightly Longer or slightly smaller, right? So we have a CFS interface for that now It's named it's an offset file that is in the RTC folder and the unit of that file is in part per billion and A positive value will add a pulse, right? so positive values adds pulses which means that it makes a day longer, right and Negative values will make the day smaller As a name that we chose I kind of The name is coming from the NXP data sheets NXP is making many RTCs and even their IPs are used inside other RTCs So I took the name from them. You will find some other vendors calling that digital trimming something I didn't know at the beginning and Now you also have the other part of it so that will be analog trimming so That's another way to try to Tune a crystal it will be to change the load capacitance So basically you have a capacitor that is on the X1 X2 Pins of the RTC and some RTCs are able to actually change it So you usually have like I don't know like Three or four values that you can put there some RTCs are quite more complex than that And because it changed quite drastically the actual The actual speed of the crystal It is a device tree property because it actually depends on what kind of crystal you are putting there So the device tree property is quartz load femto farad, so it's in femto farad Why because we have RTCs that are using picofarads, but it's a floating point in picofarads So we had to go to femto farad also some other change It's a the non volatile memory So that's what you will have some RTCs actually many RTCs will have a small amount of RAM sometimes. It's only one bit Which is not much sometimes we will get to Almost one meg so it's not bad and Because the RTC is always on it's it's always powered right even if your system is Is shut down you will always get some voltage on your RTC else you will basically just lose the time So what is the use of that RTC? So basically because it's always on the RAM is non volatile And that memory is now exposed using the NVM Framework so NVM for non volatile memory Which is something really nice because you You can now access it through the other space, but also From kernel space. So if you store something that you need In the kernel you can still retrieve data from there. It was not possible before so I added a new function to register Memory in the NVM framework, so you just pass An RTC device and an NVM config and then the RTC subsystem will take care of registering the NVM Device at the correct place It was not the case at the beginning but now multiple calls are also allowed for that. So sometimes you will have Multiple RAM banks or you may have a problem and RAM on the same RTC. So they can both be exposed through the same well through NVM You also have something so you have the end and very ham old API We had to do that because some drivers already had support for that particular Well to read and write to that particular ham Unfortunately, it was only done from user space and they basically just added a ccps file and using that so Because this is part of the ABI user space ABI it was not removed But if you use it now You will get a deprecation warning so I'm I still didn't decide when I will want to actually remove it. I Will try to do that just after an LTS, but yeah, I don't know so I also change the RTC registration So basically before you had DevM RTC device register and it was actually difficult to use because it was Allocating the RTC device structure and registering it at the same time. So if you need it to do something with the Strict RTC device Then you would already have the RTC registered at the time you allocated it. So now I split that registration into two parts The first one is Allocating it so that the one that is DevM manage, right? So DevM RTC allocate device and then the other one will just register the RTC device itself in the in the framework So that really allows you to handle the strict RTC device. We will see why just later why it's important but it also allows to remove a lot of Rest conditions in the in the drivers because For example, if you are adding well if you are requesting an interrupt and that Interrupt handler will probably need the RTC device, right? So if you actually register the interrupt before calling DevM RTC device register Then you may just the reference null. So that's that could happen. It actually happened on a on a few platforms So those stress conditions are not solved. So that's that's good Also note that there is no None DevM manage registration anymore. So I just removed All of it If it's necessary, I will just add it back But I don't think it's necessary for a driver to be able to manage the life cycle of an RTC device So one change that was done just after that was the CCFS attribute registration And that's where it's important to be able to allocate and register the device Separately So before you had the CCFS attributes that were created just after registration and that's actually opens up a risk condition where the RTC the CCFS RTC folder will appear and Then later you will have all the Elements of all the other attributes appearing inside And so if your user space is monitoring for that particular RTC folder It may not it may decide that the attributes are not there because they are not there at the beginning so Greg Cartman already Voted a blockbuster a while ago about that. So it's a pretty well-known risk condition So we don't have it now because basically what we do is allocating the RTC device and then just use RTC add group and RTC add groups And that will add RTC CCFS attributes to your RTC and so all the attributes will appear just as at the same time so one of the important change Also is the RTC range. So There are two new members inside. So it's a range min and range max Range max is a time you 64 and Range mean is a time 60 40 so This is this allows a driver to actually declare the time and date as a date in time range that is supported by the RTC Hardware which is pretty nice because now the core will be able to just check that the That whatever is coming from user space Will fit inside that range There is something that is really important is that no discontinuity is allowed in that range Which means that the time in the range has to be Continuous It's quite important because for example, you will find some RTC that will just say okay. I'm I can basically support everything up to 9999 But it's actually not the case because for example on the centuries they will not properly under the leap years, right and Once you have that kind of discontinuity so basically you never know if you have you are just before or if you are after or if You are after and you already You already corrected that discontinuity or not so it's really important that the time has to be Just continuously in that range so Something else it's the RTC offset. So In retrospect, I think I should have called that another way But it's not exposed as is to user space so I can still rename it. So I will probably do that at some point. So We probably we just have an issue for the RTC end of time. So when the when the RTC will not be able to To continue let's say after 2106 for example We need you we want to be able to just add or subtract an offset Before calling the driver callback. So that's something the core is doing and it's only able to do that Obviously, if it knows if the available range of the RTC, right? So the drivers that are supporting that right now are the ones that are setting ranch min and ranch max And I just know that we don't we don't really have the issue in 2038 Which because we are never using a time t in the RTC subsystem. So it's always unsigned. So Basically There are almost no RTCs that will fail in 2038 At the end of the UNIX epoch on 32 this right because it's actually 31 bits So the most common failing date will be 2100 and then it's followed by 2106 just because that's when these 32 bit unsigned will overflow So why it was important to do that? It's mainly because it's mandatory for Android devices to be able to be to set the RTC to something before 2000 I didn't know that I I I don't know. I don't know. I mean I've asked I never had the answer and Basically people were not really happy, but yeah, basically they want to be able to to set to the 1970 right so if your device is not set it has to be set to 1970 right but why so we have a Device three property to Change then the offset. It's called start here is basically the beginning year that you want So time zero for that RTC will start at that year. So for example in that case if you have an RTC that does 2000 to 2100 then you do start here is 1970 and then the whole range will be shifted So it will do 1970 to 2069, right So There are also some other improvements. So we have a new pin K format Which is nice. So it's PTR capital R So that one you just you just pass an RTC TM. So that's a broken out Date and time And it will just print all the members of the structure, which is really nice instead of doing person D person D person D and all the Structure difference. So that's that's really useful. We also have trace points at Interesting Functions so when you set the time when you read the time when you have an alarm and that kind of things That allows you to actually debug your driver without even adding debug inside Which is really nice We also have the Time T overflow. So that one will be the signed 32 bit that is now Properly handled in RTC H2C so that's basically what is reading the RTC When you Linux is booting and setting the system time with that The fact is that it didn't care that the user space was sort of it only and it could set a time that was later than 2038 which will just basically break system D It's not really system this full but Yeah, it will break and system D will just start looping because the kernel will say a your timer has expired And your timer has expired and your timer is expired And it will just so so that speaks now and we had a few Before that we had a few drivers On links and on links that on their own Pretty poorly so yeah now it's not doing that anymore. I Also did some a new tool. So that's RTC range That one will test the continuous range of an RTC. So it's not really testing all the dates, obviously, but There is a set of cutoff dates that are usually problematic for RTCs and it will test those right so and it will say Okay, that RTC looks like It will fail at that time Another impromptu that we have is time stamping I have more on that later Basically time stamping is a quite interesting feature of an RTC. It's just that your RTC will be able to Remember the time when it's it has seen an event the event can be whatever Usually what you get is that you will get a few GPIOs on your RTC and you will just connect something there Just to detect for example tampering all that kind of stuff That's what you get for example Some well just to know if someone someone Open the case of whatever product you you are doing all that kind of stuff So and you will it will even remember at what time it happened, right? So you can also say, okay, I Want the first occurrence of the event or the last one and that kind of thing so so we have support for time stamping now And we also have support for trickle charging, which is Well, which was not Straightforward at first so trickle charging is basically when you have a battery and it's a chargeable battery and you are just Sending a really small current there to keep the battery topped up and Yeah, you can you have to configure it Depending on your battery Physical attributes, right? You don't want to overcharge it and you probably don't want to undercharge it else. You will not remember the date and time at some point I did also some cleanup There were many many RTC valid TM calls that were unnecessary. So basically drivers were Looking at the validity of the date and time that the RTC was Returning and it was also looking at the validity of date and time that was coming from user space But basically just the RTT core is already doing that. So it's not necessary to do that in a driver So I went and I removed all those unnecessary calls So people copy pasting code from other drivers will not make the same mistake again I also remove many members of the strict class ops. So the strict RTC class ops It's basically the set of callbacks from your driver. So that's where you will define your read time set time Read alarm and set alarms callbacks for example and Many of those were not necessary anymore. So I removed the open and release because basically what Well, nobody was using open And what was done in a release didn't make sense. So I just removed the three or four users of the release callback And then we have set MMSS and set MSS 64 I removed those simply by replacing them by set time Which was quite straightforward and then we have read callback that was basically not used anymore. So It also has been removed Some people also try to quantified the RTT class ops inside the driver So it's pretty important because those are callbacks. So if an attacker ever had control over that structure it could have been Using that as a jump point to whatever payload of the attack. So That's good It was not always possible to do so and I will talk about that just a bit later The RTC control API also has been removed Basically, it had only one user. It was ASOC and ASOC was not using that since Ages, so I just removed it was already replaced by HR timer in 2006 so Well, I didn't have I didn't even have to write a replacement for it There is also the RTC IRQ registers that was not used. It's basically it was the in kernel IRQ user or consumer of the alarms for an RTC and nobody's actually using that Mainly because now we are also using timers inside the RTC core Before setting the alarm so we always know when an alarm just happened and I also Recently renamed the core files So now in the in drivers RTCs You will get all the artist drivers starting with RTC And all the core files will not start with RTC Right So future changes that's What needs to happen soon because there are many people waiting for those features So the first one is voltage detection. We kind of have already something to detect voltage drop Unfortunately, it was an IU control That's quite simple. It's not even documented. It basically returns one integer So it's RTC VLR read But the fact that RTCs quite often have different types of Monetary monitored voltage So usually what you will get is the main one will be as the auxiliary Supply that's the one that will be monitored because it's your battery and you want to know when you have to change it, but they may also monitors the main supply and so that you will know when it is switching from the main supply to the auxiliary supply or battery supply and Quite often you will also have multiple states for that. So which means okay the battery is okay The battery is low Please change it or the battery is low and I'm starting to remove functionalities and What kind of functionalities you will? lose is for example the Temperature composition of your crystal right some RTCs will have that enabled by default and which is nice because then you Don't have to care about the offset You remember of the digital trimming of your crystal because the RTC will do it for you depending on the temperature it measures But if the battery is too low, then you will start losing that functionality and so While you will not lose the time it will get less precise And the last stage is basically That I is lost the voltage is too low and I can't work anymore. So My idea is to actually have a new eye of control to to manage that and I'm still Not decided on the exact Structures that I will have to pass because I want to be able to to be flexible enough to support all the RTCs that are only multiple voltages because I Found an RTC that had three different voltages it can monitor. So I need to also be able to support them So there are also some changes to time stamping so time stamping a lot already describes that The fact is that right now it's exposed through a ccFS file Which is quite okay because that's the satisfy can block and read which then you just say, okay You have a user space program that will try to read that timestamp So time stamp zero time stamp one or time stamp two five And it will block until the event happened, which is nice But I'm thinking maybe we need a new eye control because We also need to be able to configure what kind of time stamp you want whether you want to keep only the first event or if you want Also the last event for some of the RTCs You can you you have three different time stamp and you have two different input pins. So that gives you Four different configuration for only three times some so you actually have to be able to configure what kind of Time stamp you want to keep whether you want the first event or the last event of that pin or the other pin It is also currently open coded in each driver that supports that feature. So there is There is room for factorization in the core because there is no point in letting the drivers all Just define their own functions to do that So I'm still not quite sure. Well, we already have a solution to I'm still not quite sure what I will do is that but It's not that urgent the voltage detection is way more urgent than that because people are waiting for for me to do something And there is also another change that is quite urgent right now. It's the backup switch mode basically, it's possible for some RTCs to Select the backup switch policy. So basically that means that when do you want to switch to your auxiliary power source, right? so The common policies will be disabled. Okay, I don't have any other power source So I don't want to ever switch and why would you do that? It's actually important to be able to disable it because the backup switch detection Is actually consuming a bit of power. So if your main source is already a battery, you probably don't want To what you want to disable it to save a bit of power Then you also have the direct policy, which means okay as soon as my main power supply Drop below drops below my auxiliary supply. I want to switch to my auxiliary Supply You also have standby that is kind of well, it's only used by one RTC, but it's there and the last one is level so basically When my main power supply dropped below a certain level I will want to to switch to my auxiliary auxiliary supply, which is a bit different from direct so This will be implemented through a device tree property. We already discussed that with Rob. So that's probably fine the main issue I add is that I need I need to find meaningful values for all those policies and I need to kind of find The common policies that are available so that Well, it's not too specific to one particular device and will be able to be reused across all the devices that we support right so There is also one point that is there is that It is necessary to actually avoid our coding that kind of policy into into the driver because The RTC is always on again So it's it may have been already configured by someone else, right? And if you actually outcode that into the driver you may break break someone else platform because they already specifically configured their RTC for to work that way and then you are doing something else and You break some Some platforms So I know that I have two patches to review and that's exactly what they do so Yes, that's why Well, it's not it's not there yet, but it's quite urgent to to work on that There is also some alarm handling things I need to take care of or someone needs to take care So there is the alarm support detection Right now you have many drivers that will just modify these troops RTC ops when alarms are not present and This prevents Constitutions, right? So inside your drivers, you probably want to constify you remember that That structure because it's using callbacks and Some drivers are actually modifying it so you can't constify it there. So this is Quite some work to do because probably the way forward is just to to have some flags in the RTC device strict saying okay that RTC supports alarms or doesn't support alarms and it may support alarms well, the drivers may support alarms, but the RTC integration may not support alarm. For example, if the alarm pin is not connected to any interrupt Then you will not be able to handle the alarms We also have something else with alarms is that some RTCs only have a minute Granularity on the alarm. So which means that it has to be well, there is no seconds register for the alarm Currently it's open-coded in each driver that will just run down or run up the The alarm which is not nice because They are not be all behaving the same way and we probably want to have a common way of handling that and well, it's also Good to factorize as that kind of code and the same for wake-up support There are actually many parameters to take into account When decided whether an RTC is able to wake up the platform One of them is for example, if you have an interrupt You probably you are probably already able to to wake up But then you will have to ensure that this interrupt you can actually request it But you may also have some platforms without With the alarm pin not connected to the CPU But for example to a PMIC and in that case the RTC is still able to wake up the system All right just that it just means that your CPU will never be aware of it right, but the PMIC will will see the signal so Everything there is already working, but all the drivers are currently currently open coding that kind of things And it's probably worth having it just at one place I know that for the actually for the I2C RTC is already undone by the I2C subsystem So it's it's mainly an issue for the SPI RTCs And then the last one it's alarm routing, so I only saw one patch trying to do that and We couldn't agree to the correct Device tree properties yet So basically what we have is that some RTCs have multiple interrupt pins So those are interrupts outputs, right and they can configure which interrupt goes to which pin It's not that useful if your interrupt is just basically going to your CPU because well It will it doesn't matter if you have multiple interrupts or only one You probably will have only one interrupt handler anyway, so But it's useful if you have A way an interrupt for the CPU and then an interrupt for the PMIC for example Something else I need to work on or someone needs to work on is that many RTCs are storing the time and date in BCD format, so the BCD encoding And basically there is a good potential for code factorization there, especially One day driver is using Greg map to access to access the RTC registers Then it's quite easy to actually say okay I want just one function to read the time and date from that BCD RTC because they are all using the same layout for the date and time and it's probably Well, it's something I have in the back of my mind. I never actually really worked on it And I also need to do something about drivers that are not RTCs Of timers that are not RTCs because we now have some platform timers that are able to wake up the platform And they don't actually under the system time for multiple different reason Sometimes because the counter is too small Or it will be counting the downward or maybe you are not even able to read that counter, right? So The driver currently open-coded the dummy read time and set time to make the RTC core happy So it will be able to set the alarm and then you will be able to set your timer and say okay I need that timer to fire at that time But yeah, well, and it will just wake up the platform. So There is also potential for factorization there There are only two drivers right now doing that so it's not that urgent, but at some point time I Will probably need to to have something for that So I will Finish with that. So I Need to revisit two different are you controlled there is epoch read and epoch set To change the RTC offset. So I'm right now. It's already changing the RTC of that But there is only one platform doing that. I think it's alpha So But that will allow Changing the RTC offset at runtime instead of relying on a device reproperty Which will be much better because then you you your users user space will be able to do that Properly and say okay. I need to read the RTC time Change the RTC epoch and then Set the RTC time again. So yeah, that's something that needs to be done I Definitely need to write documentation on how to write a drug an RTC driver and avoid the common pitfalls Because I kind of repeat myself every time I see a new driver, which is not good and it most of the issue I see is because people never realize that the the Must not initialize the RTC in the prop function Right, you you must only initialize the RTC when you are sure that it is in a power-on condition meaning that it lost power just before and it's now ready to be initialized because If you initialize it every time you may lose some data or whatever, right? well people never realize that the RTC is always on basically and And the last point is basically splitting up the DS 13-07 Franken driver, I call it It will come after the BCD stings because it's basically people saying okay all the BCD RTCs are using the same layout and so they just add whatever new RTC inside that driver which is I Mean it's it's okay, but it's that driver is starting to be too big to be maintainable and I really want to split it up just so that it's Easier to review and less easy to break all the other RTCs When changing one only one specific RTC and I think that was it So any question, yes So somewhere at the beginning you have device tree property which allows you to change the Beginning of the RTC. Yes the epoch here. Do you think that's encoding? Policy into the device tree instead of describing hardware Yeah, well it's I mean your yeah the start here you're not supposed to encode policy into device tree, I believe yeah, it's not actually Yeah, there's a reasoning behind that is that it's not actually Really policy it just means that all your device Well, it's kind of related to your hardware, but yeah, I mean I understand what you say But it's not really configuration. It's something that you need to know. Okay that RTC Starts at that time Just so that you can actually read the time properly if if you never encode that then you never know what kind of time you have in your RTC, so it's not really policy it's It's also Hardware dependent It's hard what dependent in the sense that if you have an RTC that is going only from 2000 and to 2100 or so and you want the you're hence to be from 1970 then well you have to use that and say okay my device is starting at 1970 but then it's a policy well it has been reviewed and accepted But I kind of agree that it's not the best solution to that basically the reason for device tree to only Describe hardware so you can boot another OS and it uses the same device tree. Yes Well, if you put another way, it should use the same time for the RTC. Yes, otherwise, it's going to have a different interpretation of the RTC. It's it's like it's like GPO hogging it's this thing actually has that function so you can't use it any other way Where else are you gonna put it in in bios yeah There's kind of no place to encode that and that's that's where you see that you have the issue on x86 with the local time versus UTC time right and Because nobody is actually saying okay the RTC is in UTC or in local times and you are kind of screwed so so looking into that the RTCs usually handle like Leap days and all that stuff Does that work with that property start here? So if I said like an arbitrary start here there How will that handle like leap years and Yeah, yeah, okay. Yeah leap years are Properly undone by that You don't really care what we do is basically we know what the what is the second the offset in seconds from epoch For the start here versus the start of the RTC And we just do the conversion to time Which means that we at that point we don't care about leap years anymore Because we know okay the we have an amount of seconds From whatever is the start of the time for that RTC we well that idea is actually coming from one RTC that Was thinking there was 31 day in November So Yeah, basically that RTC is kind of useless But yes, that's what we did there. It just we said okay Even if it is a time is stored in BCD Which we will just consider the amount of second since a particular epoch and just say okay, that's that's how it's working So it requires to do Some conversion so it's less efficient, but what is working one the other question Thank you