- 16 Jan, 2022 3 commits
-
-
Riwen Lu authored
There's limiting the year to 2069. When setting the rtc year to 2070, reading it returns 1970. Evaluate century starting from 19 to count the correct year. $ sudo date -s 20700106 Mon 06 Jan 2070 12:00:00 AM CST $ sudo hwclock -w $ sudo hwclock -r 1970-01-06 12:00:49.604968+08:00 Fixes: 2a4daadd ("rtc: cmos: ignore bogus century byte") Signed-off-by:
Riwen Lu <luriwen@kylinos.cn> Acked-by:
Eric Wong <e@80x24.org> Reviewed-by:
Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220106084609.1223688-1-luriwen@kylinos.cn
-
Dan Carpenter authored
The devm_kzalloc() function returns NULL on error, it doesn't return error pointers. Fixes: 86559400 ("rtc: gamecube: Add a RTC driver for the GameCube, Wii and Wii U") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Emmanuel Gil Peyrot <linkmauve@linkmauve.fr> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220107073340.GF22086@kili
-
Dan Carpenter authored
The mc146818_get_time() function returns zero on success or negative a error code on failure. It needs to be type int. Fixes: d35786b3 ("rtc: mc146818-lib: change return values of mc146818_get_time()") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220111071922.GE11243@kili
-
- 05 Jan, 2022 7 commits
-
-
David Heidelberg authored
Extend registers up to 2, also document their names. Also fixes warnings generated by `make qcom/sdm845-oneplus-fajita.dtb`: arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dt.yaml: rtc@6000: reg: [[24576], [24832]] is too long From schema: Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dt.yaml: rtc@6000: 'reg-names' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml Signed-off-by:
David Heidelberg <david@ixit.cz> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211213192946.111320-1-david@ixit.cz
-
Laurence de Bruxelles authored
With the latest stable kernel versions the rtc on the PXA based Zaurus does not work, when booting I see the following kernel messages: pxa-rtc pxa-rtc: failed to find rtc clock source pxa-rtc pxa-rtc: Unable to init SA1100 RTC sub-device pxa-rtc: probe of pxa-rtc failed with error -2 hctosys: unable to open rtc device (rtc0) I think this is because commit f2997775 ("rtc: sa1100: fix possible race condition") moved the allocation of the rtc_device struct out of sa1100_rtc_init and into sa1100_rtc_probe. This means that pxa_rtc_probe also needs to do allocation for the rtc_device struct, otherwise sa1100_rtc_init will try to dereference a null pointer. This patch adds that allocation by copying how sa1100_rtc_probe in drivers/rtc/rtc-sa1100.c does it; after the IRQs are set up a managed rtc_device is allocated. I've tested this patch with `qemu-system-arm -machine akita` and with a real Zaurus SL-C1000 applied to 4.19, 5.4, and 5.10. Signed-off-by:
Laurence de Bruxelles <lfdebrux@gmail.com> Fixes: f2997775 ("rtc: sa1100: fix possible race condition") Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220101154149.12026-1-lfdebrux@gmail.com
-
Lad Prabhakar authored
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static allocation of IRQ resources in DT core code, this causes an issue when using hierarchical interrupt domains using "interrupts" property in the node as this bypasses the hierarchical setup and messes up the irq chaining. In preparation for removal of static setup of IRQ resource from DT core code use platform_get_irq(). Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211220011524.17206-1-prabhakar.mahadev-lad.rj@bp.renesas.com
-
Kees Cook authored
When building with automatic stack variable initialization, GCC 12 complains about variables defined outside of switch case statements. Move the variable into the case that uses it, which silences the warning: drivers/rtc/dev.c: In function 'rtc_dev_ioctl': drivers/rtc/dev.c:394:30: warning: statement will never be executed [-Wswitch-unreachable] 394 | long offset; | ^~~~~~ Fixes: 6a8af1b6 ("rtc: add parameter ioctl") Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211209043915.1378393-1-keescook@chromium.org
-
Hugo Villeneuve authored
Replace TFS2 with TSF2. Signed-off-by:
Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211207215626.2619819-1-hugo@hugovil.com
-
Vincent Shih authored
Add Sunplus RTC json-schema Signed-off-by:
Vincent Shih <vincent.sunplus@gmail.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/1638517579-10316-3-git-send-email-vincent.sunplus@gamil.com
-
Vincent Shih authored
Add driver for RTC in Sunplus SP7021 Signed-off-by:
Vincent Shih <vincent.sunplus@gmail.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/1638517579-10316-2-git-send-email-vincent.sunplus@gamil.com
-
- 04 Jan, 2022 2 commits
-
-
Camel Guo authored
The XSL bit only exists in RS5C372A/B. On other Ricoh RTC chips supported in rs5c372, this bit has different meaning. For example, on R2221x and R2223x, this bit of oscillation adjustment register determines the operation frequency of oscillation adjustment circuit and the oscillation is always 32768HZ. But rs5c372_get_trim gives 32000HZ to osc when DEV is 1. Signed-off-by:
Camel Guo <camelg@axis.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211206125832.6461-1-camel.guo@axis.com
-
Camel Guo authored
In order for linux userspace application to be able to adjust offset to keep rtc precision as high as possible, this commit adds support of offset correction by adjusting the time trimming register on rs5c372[a|b] and oscilluation adjustment register on r2025x, r222[1|3]x, rv5c38[6|7]a. Signed-off-by:
Camel Guo <camelg@axis.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211202152252.31264-1-camel.guo@axis.com
-
- 16 Dec, 2021 14 commits
-
-
Mateusz Jończyk authored
Some Intel chipsets disconnect the time and date RTC registers when the clock update is in progress: during this time reads may return bogus values and writes fail silently. This includes the RTC alarm registers. [1] cmos_set_alarm() did not take account for that, fix it. [1] 7th Generation Intel
® Processor Family I/O for U/Y Platforms [...] Datasheet, Volume 1 of 2 (Intel's Document Number: 334658-006) Page 208 https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/7th-and-8th-gen-core-family-mobile-u-y-processor-lines-i-o-datasheet-vol-1.pdf "If a RAM read from the ten time and date bytes is attempted during an update cycle, the value read do not necessarily represent the true contents of those locations. Any RAM writes under the same conditions are ignored." Signed-off-by:Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211210200131.153887-10-mat.jonczyk@o2.pl
-
Mateusz Jończyk authored
Some Intel chipsets disconnect the time and date RTC registers when the clock update is in progress: during this time reads may return bogus values and writes fail silently. This includes the RTC alarm registers. [1] cmos_read_alarm() did not take account for that, which caused alarm time reads to sometimes return bogus values. This can be shown with a test patch that I am attaching to this patch series. Fix this, by using mc146818_avoid_UIP(). [1] 7th Generation Intel
® Processor Family I/O for U/Y Platforms [...] Datasheet, Volume 1 of 2 (Intel's Document Number: 334658-006) Page 208 https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/7th-and-8th-gen-core-family-mobile-u-y-processor-lines-i-o-datasheet-vol-1.pdf "If a RAM read from the ten time and date bytes is attempted during an update cycle, the value read do not necessarily represent the true contents of those locations. Any RAM writes under the same conditions are ignored." Signed-off-by:Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211210200131.153887-9-mat.jonczyk@o2.pl
-
Mateusz Jończyk authored
Refactor mc146818_does_rtc_work() so that it uses mc146818_avoid_UIP(). It is enough to call mc146818_avoid_UIP() with no callback. Signed-off-by:
Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211210200131.153887-8-mat.jonczyk@o2.pl
-
Mateusz Jończyk authored
Refactor mc146818_get_time() so that it uses mc146818_avoid_UIP(). Signed-off-by:
Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211210200131.153887-7-mat.jonczyk@o2.pl
-
Mateusz Jończyk authored
Function mc146818_get_time() contains an elaborate mechanism of reading the RTC time while no RTC update is in progress. It turns out that reading the RTC alarm clock also requires avoiding the RTC update. Therefore, the mechanism in mc146818_get_time() should be reused - so extract it into a separate function. The logic in mc146818_avoid_UIP() is same as in mc146818_get_time() except that after every if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) { there is now "mdelay(1)". To avoid producing a very unreadable patch, mc146818_get_time() will be refactored to use mc146818_avoid_UIP() in the next patch. Signed-off-by:
Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211210200131.153887-6-mat.jonczyk@o2.pl
-
Mateusz Jończyk authored
To prevent an infinite loop in mc146818_get_time(), commit 211e5db1 ("rtc: mc146818: Detect and handle broken RTCs") added a check for RTC availability. Together with a later fix, it checked if bit 6 in register 0x0d is cleared. This, however, caused a false negative on a motherboard with an AMD SB710 southbridge; according to the specification [1], bit 6 of register 0x0d of this chipset is a scratchbit. This caused a regression in Linux 5.11 - the RTC was determined broken by the kernel and not used by rtc-cmos.c [3]. This problem was also reported in Fedora [4]. As a better alternative, check whether the UIP ("Update-in-progress") bit is set for longer then 10ms. If that is the case, then apparently the RTC is either absent (and all register reads return 0xff) or broken. Also limit the number of loop iterations in mc146818_get_time() to 10 to prevent an infinite loop there. The functions mc146818_get_time() and mc146818_does_rtc_work() will be refactored later in this patch series, in order to fix a separate problem with reading / setting the RTC alarm time. This is done so to avoid a confusion about what is being fixed when. In a previous approach to this problem, I implemented a check whether the RTC_HOURS register contains a value <= 24. This, however, sometimes did not work correctly on my Intel Kaby Lake laptop. According to Intel's documentation [2], "the time and date RAM locations (0-9) are disconnected from the external bus" during the update cycle so reading this register without checking the UIP bit is incorrect. [1] AMD SB700/710/750 Register Reference Guide, page 308, https://developer.amd.com/wordpress/media/2012/10/43009_sb7xx_rrg_pub_1.00.pdf [2] 7th Generation Intel
® Processor Family I/O for U/Y Platforms [...] Datasheet Volume 1 of 2, page 209 Intel's Document Number: 334658-006, https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/7th-and-8th-gen-core-family-mobile-u-y-processor-lines-i-o-datasheet-vol-1.pdf [3] Functions in arch/x86/kernel/rtc.c apparently were using it. [4] https://bugzilla.redhat.com/show_bug.cgi?id=1936688 Fixes: 211e5db1 ("rtc: mc146818: Detect and handle broken RTCs") Fixes: ebb22a05 ("rtc: mc146818: Dont test for bit 0-5 in Register D") Signed-off-by:Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211210200131.153887-5-mat.jonczyk@o2.pl
-
Mateusz Jończyk authored
There are 4 users of mc146818_get_time() and none of them was checking the return value from this function. Change this. Print the appropriate warnings in callers of mc146818_get_time() instead of in the function mc146818_get_time() itself, in order not to add strings to rtc-mc146818-lib.c, which is kind of a library. The callers of alpha_rtc_read_time() and cmos_read_time() may use the contents of (struct rtc_time *) even when the functions return a failure code. Therefore, set the contents of (struct rtc_time *) to 0x00, which looks more sensible then 0xff and aligns with the (possibly stale?) comment in cmos_read_time: /* * If pm_trace abused the RTC for storage, set the timespec to 0, * which tells the caller that this RTC value is unusable. */ For consistency, do this in mc146818_get_time(). Note: hpet_rtc_interrupt() may call mc146818_get_time() many times a second. It is very unlikely, though, that the RTC suddenly stops working and mc146818_get_time() would consistently fail. Only compile-tested on alpha. Signed-off-by:
Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: linux-alpha@vger.kernel.org Cc: x86@kernel.org Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211210200131.153887-4-mat.jonczyk@o2.pl
-
Mateusz Jończyk authored
No function is checking mc146818_get_time() return values yet, so correct them to make them more customary. Signed-off-by:
Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211210200131.153887-3-mat.jonczyk@o2.pl
-
Mateusz Jończyk authored
Reading from the CMOS involves writing to the index register and then reading from the data register. Therefore access to the CMOS has to be serialized with rtc_lock. This invocation of CMOS_READ was not serialized, which could cause trouble when other code is accessing CMOS at the same time. Use spin_lock_irq() like the rest of the function. Nothing in kernel modifies the RTC_DM_BINARY bit, so there could be a separate pair of spin_lock_irq() / spin_unlock_irq() before doing the math. Signed-off-by:
Mateusz Jończyk <mat.jonczyk@o2.pl> Reviewed-by:
Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: stable@vger.kernel.org Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211210200131.153887-2-mat.jonczyk@o2.pl
-
Emmanuel Gil Peyrot authored
This selects the rtc-gamecube driver, which provides a real-time clock on this platform. Signed-off-by:
Emmanuel Gil Peyrot <linkmauve@linkmauve.fr> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211215175501.6761-6-linkmauve@linkmauve.fr
-
Emmanuel Gil Peyrot authored
This selects the rtc-gamecube driver, which provides a real-time clock on this platform. Signed-off-by:
Emmanuel Gil Peyrot <linkmauve@linkmauve.fr> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211215175501.6761-5-linkmauve@linkmauve.fr
-
Emmanuel Gil Peyrot authored
This Hollywood register isn’t properly understood, but can allow or reject access to the SRAM, which we need to set for RTC usage if it isn’t previously set correctly beforehand. See https://wiibrew.org/wiki/Hardware/Hollywood_Registers#HW_SRNPROTSigned-off-by:
Emmanuel Gil Peyrot <linkmauve@linkmauve.fr> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211215175501.6761-4-linkmauve@linkmauve.fr
-
Emmanuel Gil Peyrot authored
I haven’t been able to test this patch as all of my consoles have a working RTC battery, but according to the documentation it should work like that. Signed-off-by:
Emmanuel Gil Peyrot <linkmauve@linkmauve.fr> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211215175501.6761-3-linkmauve@linkmauve.fr
-
Emmanuel Gil Peyrot authored
These three consoles share a device, the MX23L4005, which contains a clock and 64 bytes of SRAM storage, and is exposed on the EXI bus (similar to SPI) on channel 0, device 1. This driver allows it to be used as a Linux RTC device, where time can be read and set. The hardware also exposes two timers, one which shuts down the console and one which powers it on, but these aren’t supported currently. On the Wii U, the counter bias is stored in a XML file, /config/rtc.xml, encrypted in the SLC (eMMC storage), using a proprietary filesystem. In order to avoid having to implement all that, this driver assumes a bootloader will parse this XML file and write the bias into the SRAM, at the same location the other two consoles have it. Signed-off-by:
Emmanuel Gil Peyrot <linkmauve@linkmauve.fr> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211215175501.6761-2-linkmauve@linkmauve.fr
-
- 02 Dec, 2021 3 commits
-
-
Fabio Estevam authored
The Epson RX8804 RTC has the same programming model as RV8803. Add support for it in the driver. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Reviewed-by:
Otavio Salvador <otavio@ossystems.com.br> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211130125830.1166194-2-festevam@gmail.com
-
Fabio Estevam authored
The Epson RX8804 RTC has the same programming model as RV8803 and RX8900. Add an entry for it in the binding document. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Reviewed-by:
Otavio Salvador <otavio@ossystems.com.br> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211130125830.1166194-1-festevam@gmail.com
-
Nikita Shubin authored
As da9063 RTC is not a real I2C client, but relies on da9063 MFD driver, we need to explicitly mark da9063 RTC as a wakeup source to be able to access class/rtc/rtcN/wakealarm sysfs entry to set alarms, so we can wakeup from SHUTDOWN/RTC/DELIVERY mode. As da9063 driver refuses to load without irq, we simply add it as a wakeup source before registering rtc device. Signed-off-by:
Nikita Shubin <nikita.shubin@maquefel.me> Reviewed-by:
Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211129072650.22686-1-nikita.shubin@maquefel.me
-
- 30 Nov, 2021 3 commits
-
-
Alexandre Belloni authored
Stop using uie_unsupported and clear RTC_FEATURE_UPDATE_INTERRUPT instead. Also, let the core know that the alarm will truncate seconds as it only has a minute resolution. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by:
Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20211109234750.107115-1-alexandre.belloni@bootlin.com
-
Marc Ferland authored
The pcf85063 driver regsitration currently supports the "compatible" property type of matching (for DT). This patch adds "matching by name" support to the driver by defining an i2c_device_id table and setting the id_table parameter in the i2c_driver struct. This will, for example, make the driver easier to instantiate on systems where CONFIG_OF is not enabled (x86 in my case). Signed-off-by:
Marc Ferland <ferlandm@amotus.ca> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211116164733.17149-1-ferlandm@amotus.ca
-
Camel Guo authored
In order to make it possible to get battery voltage status, this commit adds RTC_VL_READ, RTC_VL_CLR ioctl commands to rtc-rs5c372. Signed-off-by:
Camel Guo <camelg@axis.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211111083625.10216-1-camel.guo@axis.com
-
- 14 Nov, 2021 8 commits
-
-
Linus Torvalds authored
-
Gustavo A. R. Silva authored
Add Kconfig support for -Wimplicit-fallthrough for both GCC and Clang. The compiler option is under configuration CC_IMPLICIT_FALLTHROUGH, which is enabled by default. Special thanks to Nathan Chancellor who fixed the Clang bug[1][2]. This bugfix only appears in Clang 14.0.0, so older versions still contain the bug and -Wimplicit-fallthrough won't be enabled for them, for now. This concludes a long journey and now we are finally getting rid of the unintentional fallthrough bug-class in the kernel, entirely. :) Link: https://github.com/llvm/llvm-project/commit/9ed4a94d6451046a51ef393cd62f00710820a7e8 [1] Link: https://bugs.llvm.org/show_bug.cgi?id=51094 [2] Link: https://github.com/KSPP/linux/issues/115 Link: https://github.com/ClangBuiltLinux/linux/issues/236Co-developed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Kees Cook <keescook@chromium.org> Co-developed-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Tested-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds authored
Pull xfs cleanups from Darrick Wong: "The most 'exciting' aspect of this branch is that the xfsprogs maintainer and I have worked through the last of the code discrepancies between kernel and userspace libxfs such that there are no code differences between the two except for #includes. IOWs, diff suffices to demonstrate that the userspace tools behave the same as the kernel, and kernel-only bits are clearly marked in the /kernel/ source code instead of just the userspace source. Summary: - Clean up open-coded swap() calls. - A little bit of #ifdef golf to complete the reunification of the kernel and userspace libxfs source code" * tag 'xfs-5.16-merge-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: sync xfs_btree_split macros with userspace libxfs xfs: #ifdef out perag code for userspace xfs: use swap() to make dabtree code cleaner
-
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linuxLinus Torvalds authored
Pull more parisc fixes from Helge Deller: "Fix a build error in stracktrace.c, fix resolving of addresses to function names in backtraces, fix single-stepping in assembly code and flush userspace pte's when using set_pte_at()" * tag 'for-5.16/parisc-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc/entry: fix trace test in syscall exit path parisc: Flush kernel data mapping in set_pte_at() when installing pte for user page parisc: Fix implicit declaration of function '__kernel_text_address' parisc: Fix backtrace to always include init funtion names
-
git://git.libc.org/linux-shLinus Torvalds authored
Pull arch/sh updates from Rich Felker. * tag 'sh-for-5.16' of git://git.libc.org/linux-sh: sh: pgtable-3level: Fix cast to pointer from integer of different size sh: fix READ/WRITE redefinition warnings sh: define __BIG_ENDIAN for math-emu sh: math-emu: drop unused functions sh: fix kconfig unmet dependency warning for FRAME_POINTER sh: Cleanup about SPARSE_IRQ sh: kdump: add some attribute to function maple: fix wrong return value of maple_bus_init(). sh: boot: avoid unneeded rebuilds under arch/sh/boot/compressed/ sh: boot: add intermediate vmlinux.bin* to targets instead of extra-y sh: boards: Fix the cacography in irq.c sh: check return code of request_irq sh: fix trivial misannotations
-
git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds authored
Pull ARM fixes from Russell King: - Fix early_iounmap - Drop cc-option fallbacks for architecture selection * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 9156/1: drop cc-option fallbacks for architecture selection ARM: 9155/1: fix early early_iounmap()
-
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linuxLinus Torvalds authored
Pull devicetree fixes from Rob Herring: - Two fixes due to DT node name changes on Arm, Ltd. boards - Treewide rename of Ingenic CGU headers - Update ST email addresses - Remove Netlogic DT bindings - Dropping few more cases of redundant 'maxItems' in schemas - Convert toshiba,tc358767 bridge binding to schema * tag 'devicetree-fixes-for-5.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: dt-bindings: watchdog: sunxi: fix error in schema bindings: media: venus: Drop redundant maxItems for power-domain-names dt-bindings: Remove Netlogic bindings clk: versatile: clk-icst: Ensure clock names are unique of: Support using 'mask' in making device bus id dt-bindings: treewide: Update @st.com email address to @foss.st.com dt-bindings: media: Update maintainers for st,stm32-hwspinlock.yaml dt-bindings: media: Update maintainers for st,stm32-cec.yaml dt-bindings: mfd: timers: Update maintainers for st,stm32-timers dt-bindings: timer: Update maintainers for st,stm32-timer dt-bindings: i2c: imx: hardware do not restrict clock-frequency to only 100 and 400 kHz dt-bindings: display: bridge: Convert toshiba,tc358767.txt to yaml dt-bindings: Rename Ingenic CGU headers to ingenic,*.h
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fix from Thomas Gleixner: "A single fix for POSIX CPU timers to address a problem where POSIX CPU timer delivery stops working for a new child task because copy_process() copies state information which is only valid for the parent task" * tag 'timers-urgent-2021-11-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: posix-cpu-timers: Clear task::posix_cputimers_work in copy_process()
-