* [rtc-linux] [PATCH 2/3] tools: timer: add test to check y2038/2106 bug
From: Benjamin Gaignard @ 2017-06-16 14:03 UTC (permalink / raw)
To: john.stultz, tglx, sboyd, shuah, linux-kernel, linux-kselftest,
patrice.chotard, a.zummo, alexandre.belloni, linux-arm-kernel,
rtc-linux
Cc: linaro-kernel, Benjamin Gaignard
In-Reply-To: <1497621833-9942-1-git-send-email-benjamin.gaignard@linaro.org>
The goal of this test is to check if a RTC device correctly support
dates after years 2038 or 2106.
It set a date (1-1-2200) on RTC and read it back to be sure that the
driver is working well.
The same thing is done on alarm.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
---
tools/testing/selftests/timers/Makefile | 4 +-
tools/testing/selftests/timers/rtctest-2038.c | 135 ++++++++++++++++++++++++++
2 files changed, 138 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/timers/rtctest-2038.c
diff --git a/tools/testing/selftests/timers/Makefile b/tools/testing/selftests/timers/Makefile
index 54481f1..7791f79 100644
--- a/tools/testing/selftests/timers/Makefile
+++ b/tools/testing/selftests/timers/Makefile
@@ -9,7 +9,8 @@ TEST_GEN_PROGS = posix_timers nanosleep nsleep-lat set-timer-lat mqueue-lat \
TEST_GEN_PROGS_EXTENDED = alarmtimer-suspend valid-adjtimex adjtick change_skew \
skew_consistency clocksource-switch leap-a-day \
- leapcrash set-tai set-2038 set-tz rtctest_setdate
+ leapcrash set-tai set-2038 set-tz rtctest_setdate \
+ rtctest-2038
include ../lib.mk
@@ -29,4 +30,5 @@ run_destructive_tests: run_tests
./set-tz
./set-tai
./set-2038
+ ./rtctest-2038
diff --git a/tools/testing/selftests/timers/rtctest-2038.c b/tools/testing/selftests/timers/rtctest-2038.c
new file mode 100644
index 0000000..213b7ee
--- /dev/null
+++ b/tools/testing/selftests/timers/rtctest-2038.c
@@ -0,0 +1,135 @@
+/* Real Time Clock Driver Test
+ * by: Benjamin Gaignard (benjamin.gaignard@linaro.org)
+ *
+ * To build
+ * gcc rtctest-2038.c -o rtctest-2038
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <stdio.h>
+#include <linux/rtc.h>
+#include <sys/ioctl.h>
+#include <sys/time.h>
+#include <sys/types.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <errno.h>
+
+static const char default_rtc[] = "/dev/rtc0";
+
+int main(int argc, char **argv)
+{
+ int fd, retval;
+ struct rtc_time new, current;
+ const char *rtc = default_rtc;
+
+ switch (argc) {
+ case 2:
+ rtc = argv[1];
+ /* FALLTHROUGH */
+ case 1:
+ break;
+ default:
+ fprintf(stderr, "usage: rtctest-2038 [rtcdev]\n");
+ return 1;
+ }
+
+ fprintf(stderr, "\nTest if RTC is robust for date after y2038/2106\n\n");
+
+ fd = open(rtc, O_RDONLY);
+ if (fd == -1) {
+ perror(rtc);
+ exit(errno);
+ }
+
+ new.tm_year = 300; /* 2200 - 1900 */
+ new.tm_mon = 0;
+ new.tm_mday = 1;
+ new.tm_hour = 0;
+ new.tm_min = 0;
+ new.tm_sec = 0;
+
+ fprintf(stderr, "Test will set RTC date/time to %d-%d-%d, %02d:%02d:%02d.\n",
+ new.tm_mday, new.tm_mon + 1, new.tm_year + 1900,
+ new.tm_hour, new.tm_min, new.tm_sec);
+
+ /* Write the new date in RTC */
+ retval = ioctl(fd, RTC_SET_TIME, &new);
+ if (retval == -1) {
+ perror("RTC_SET_TIME ioctl");
+ close(fd);
+ exit(errno);
+ }
+
+ /* Read back */
+ retval = ioctl(fd, RTC_RD_TIME, ¤t);
+ if (retval == -1) {
+ perror("RTC_RD_TIME ioctl");
+ exit(errno);
+ }
+
+ fprintf(stderr, "RTC date/time is %d-%d-%d, %02d:%02d:%02d.\n",
+ current.tm_mday, current.tm_mon + 1, current.tm_year + 1900,
+ current.tm_hour, current.tm_min, current.tm_sec);
+
+ if (new.tm_year != current.tm_year ||
+ new.tm_mon != current.tm_mon ||
+ new.tm_mday != current.tm_mday ||
+ new.tm_hour != current.tm_hour ||
+ new.tm_min != current.tm_min ||
+ new.tm_sec != current.tm_sec) {
+ fprintf(stderr, "\n\nSet Time test failed\n");
+ close(fd);
+ return 1;
+ }
+
+ new.tm_sec += 5;
+
+ fprintf(stderr, "\nTest will set RTC alarm to %d-%d-%d, %02d:%02d:%02d.\n",
+ new.tm_mday, new.tm_mon + 1, new.tm_year + 1900,
+ new.tm_hour, new.tm_min, new.tm_sec);
+
+ /* Write the new alarm in RTC */
+ retval = ioctl(fd, RTC_ALM_SET, &new);
+ if (retval == -1) {
+ perror("RTC_ALM_SET ioctl");
+ close(fd);
+ exit(errno);
+ }
+
+ /* Read back */
+ retval = ioctl(fd, RTC_ALM_READ, ¤t);
+ if (retval == -1) {
+ perror("RTC_ALM_READ ioctl");
+ exit(errno);
+ }
+
+ fprintf(stderr, "RTC alarm is %d-%d-%d, %02d:%02d:%02d.\n",
+ current.tm_mday, current.tm_mon + 1, current.tm_year + 1900,
+ current.tm_hour, current.tm_min, current.tm_sec);
+
+ if (new.tm_year != current.tm_year ||
+ new.tm_mon != current.tm_mon ||
+ new.tm_mday != current.tm_mday ||
+ new.tm_hour != current.tm_hour ||
+ new.tm_min != current.tm_min ||
+ new.tm_sec != current.tm_sec) {
+ fprintf(stderr, "\n\nSet alarm test failed\n");
+ close(fd);
+ return 1;
+ }
+
+ fprintf(stderr, "\nTest complete\n");
+ close(fd);
+ return 0;
+}
--
1.9.1
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply related
* [PATCH 1/3] tools: timer: add rtctest_setdate
From: Benjamin Gaignard @ 2017-06-16 14:03 UTC (permalink / raw)
To: john.stultz, tglx, sboyd, shuah, linux-kernel, linux-kselftest,
patrice.chotard, a.zummo, alexandre.belloni, linux-arm-kernel,
rtc-linux
Cc: linaro-kernel, Benjamin Gaignard
In-Reply-To: <1497621833-9942-1-git-send-email-benjamin.gaignard@linaro.org>
This tool allow to set directly the time and date to a RTC device.
Unlike other tools isn't doens't use "strut timeval" or "time_t"
so it is safe for 32bits platforms when testing for y2038/2106 bug.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
---
tools/testing/selftests/timers/Makefile | 2 +-
tools/testing/selftests/timers/rtctest_setdate.c | 86 ++++++++++++++++++++++++
2 files changed, 87 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/timers/rtctest_setdate.c
diff --git a/tools/testing/selftests/timers/Makefile b/tools/testing/selftests/timers/Makefile
index 5fa1d7e9..54481f1 100644
--- a/tools/testing/selftests/timers/Makefile
+++ b/tools/testing/selftests/timers/Makefile
@@ -9,7 +9,7 @@ TEST_GEN_PROGS = posix_timers nanosleep nsleep-lat set-timer-lat mqueue-lat \
TEST_GEN_PROGS_EXTENDED = alarmtimer-suspend valid-adjtimex adjtick change_skew \
skew_consistency clocksource-switch leap-a-day \
- leapcrash set-tai set-2038 set-tz
+ leapcrash set-tai set-2038 set-tz rtctest_setdate
include ../lib.mk
diff --git a/tools/testing/selftests/timers/rtctest_setdate.c b/tools/testing/selftests/timers/rtctest_setdate.c
new file mode 100644
index 0000000..2cb7848
--- /dev/null
+++ b/tools/testing/selftests/timers/rtctest_setdate.c
@@ -0,0 +1,86 @@
+/* Real Time Clock Driver Test
+ * by: Benjamin Gaignard (benjamin.gaignard@linaro.org)
+ *
+ * To build
+ * gcc rtctest_setdate.c -o rtctest_setdate
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <stdio.h>
+#include <linux/rtc.h>
+#include <sys/ioctl.h>
+#include <sys/time.h>
+#include <sys/types.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <errno.h>
+
+static const char default_time[] = "00:00:00";
+
+int main(int argc, char **argv)
+{
+ int fd, retval;
+ struct rtc_time new, current;
+ const char *rtc, *date;
+ const char *time = default_time;
+
+ switch (argc) {
+ case 4:
+ time = argv[3];
+ /* FALLTHROUGH */
+ case 3:
+ date = argv[2];
+ rtc = argv[1];
+ break;
+ default:
+ fprintf(stderr, "usage: rtctest_setdate <rtcdev> <DD-MM-YYYY> [HH:MM:SS]\n");
+ return 1;
+ }
+
+ fd = open(rtc, O_RDONLY);
+ if (fd == -1) {
+ perror(rtc);
+ exit(errno);
+ }
+
+ sscanf(date, "%d-%d-%d", &new.tm_mday, &new.tm_mon, &new.tm_year);
+ new.tm_mon -= 1;
+ new.tm_year -= 1900;
+ sscanf(time, "%d:%d:%d", &new.tm_hour, &new.tm_min, &new.tm_sec);
+
+ fprintf(stderr, "Test will set RTC date/time to %d-%d-%d, %02d:%02d:%02d.\n",
+ new.tm_mday, new.tm_mon + 1, new.tm_year + 1900,
+ new.tm_hour, new.tm_min, new.tm_sec);
+
+ /* Write the new date in RTC */
+ retval = ioctl(fd, RTC_SET_TIME, &new);
+ if (retval == -1) {
+ perror("RTC_SET_TIME ioctl");
+ close(fd);
+ exit(errno);
+ }
+
+ /* Read back */
+ retval = ioctl(fd, RTC_RD_TIME, ¤t);
+ if (retval == -1) {
+ perror("RTC_RD_TIME ioctl");
+ exit(errno);
+ }
+
+ fprintf(stderr, "\n\nCurrent RTC date/time is %d-%d-%d, %02d:%02d:%02d.\n",
+ current.tm_mday, current.tm_mon + 1, current.tm_year + 1900,
+ current.tm_hour, current.tm_min, current.tm_sec);
+
+ close(fd);
+ return 0;
+}
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3] rtc: make st-lpc robust against y2038/2106 bug
From: Benjamin Gaignard @ 2017-06-16 14:03 UTC (permalink / raw)
To: john.stultz, tglx, sboyd, shuah, linux-kernel, linux-kselftest,
patrice.chotard, a.zummo, alexandre.belloni, linux-arm-kernel,
rtc-linux
Cc: linaro-kernel, Benjamin Gaignard
On 32bits platforms "struct timeval" or "time_t" are using u32 to code the
date, this cause tools like "date" or "hwclock" failed even before setting
the RTC device if the date is superior to year 2038 (or 2106).
To avoid this problem I add two RTC tests files which directly use RTC ioctl
to set and read RTC time and alarm values.
rtctest_setdate allow to set any date/time given in the command line.
rtctest-2038 perform a basic test by writing 1-1-2200 in RTC time and alarm
and checking that the read back values are correct.
Finally that had allowed me to test and fix rtc-st-lpc driver.
Benjamin Gaignard (3):
tools: timer: add rtctest_setdate
tools: timer: add test to check y2038/2106 bug
rtc: st-lpc: make it robust against y2038/2106 bug
drivers/rtc/rtc-st-lpc.c | 19 ++--
tools/testing/selftests/timers/Makefile | 4 +-
tools/testing/selftests/timers/rtctest-2038.c | 135 +++++++++++++++++++++++
tools/testing/selftests/timers/rtctest_setdate.c | 86 +++++++++++++++
4 files changed, 232 insertions(+), 12 deletions(-)
create mode 100644 tools/testing/selftests/timers/rtctest-2038.c
create mode 100644 tools/testing/selftests/timers/rtctest_setdate.c
--
1.9.1
^ permalink raw reply
* [rtc-linux] [PATCH 2/2] rtc: brcmstb-waketimer: Add Broadcom STB wake-timer
From: Florian Fainelli @ 2017-06-15 19:59 UTC (permalink / raw)
To: linux-kernel
Cc: Brian Norris, Markus Mayer, Florian Fainelli, Alessandro Zummo,
Alexandre Belloni, Rob Herring, Mark Rutland, Gregory Fong,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
open list:REAL TIME CLOCK (RTC) SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE
In-Reply-To: <20170615195904.12653-1-f.fainelli@gmail.com>
From: Brian Norris <computersforpeace@gmail.com>
This adds support for the Broadcom STB wake-timer which is a timer in
the chip's 27Mhz clock domain that offers the ability to wake the system
(wake-up source) from suspend states (S2, S3, S5). It is supported using
the rtc framework allowing us to configure alarms for system wake-up.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/rtc/Kconfig | 11 ++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-brcmstb-waketimer.c | 345 ++++++++++++++++++++++++++++++++=
++++
3 files changed, 357 insertions(+)
create mode 100644 drivers/rtc/rtc-brcmstb-waketimer.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 8d3b95728326..8e1aa67fe533 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -197,6 +197,17 @@ config RTC_DRV_AC100
This driver can also be built as a module. If so, the module
will be called rtc-ac100.
=20
+config RTC_DRV_BRCMSTB
+ tristate "Broadcom STB wake-timer"
+ depends on ARCH_BRCMSTB || BMIPS_GENERIC || COMPILE_TEST
+ default ARCH_BRCMSTB || BMIPS_GENERIC
+ help
+ If you say yes here you get support for the wake-timer found on
+ Broadcom STB SoCs (BCM7xxx).
+
+ This driver can also be built as a module. If so, the module will
+ be called rtc-brcmstb-waketimer.
+
config RTC_DRV_AS3722
tristate "ams AS3722 RTC driver"
depends on MFD_AS3722
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 13857d2fce09..df89cac1f9ae 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_RTC_DRV_AT91RM9200)+=3D rtc-at91rm9200.o
obj-$(CONFIG_RTC_DRV_AT91SAM9) +=3D rtc-at91sam9.o
obj-$(CONFIG_RTC_DRV_AU1XXX) +=3D rtc-au1xxx.o
obj-$(CONFIG_RTC_DRV_BFIN) +=3D rtc-bfin.o
+obj-$(CONFIG_RTC_DRV_BRCMSTB) +=3D rtc-brcmstb-waketimer.o
obj-$(CONFIG_RTC_DRV_BQ32K) +=3D rtc-bq32k.o
obj-$(CONFIG_RTC_DRV_BQ4802) +=3D rtc-bq4802.o
obj-$(CONFIG_RTC_DRV_CMOS) +=3D rtc-cmos.o
diff --git a/drivers/rtc/rtc-brcmstb-waketimer.c b/drivers/rtc/rtc-brcmstb-=
waketimer.c
new file mode 100644
index 000000000000..c7f166e39f5e
--- /dev/null
+++ b/drivers/rtc/rtc-brcmstb-waketimer.c
@@ -0,0 +1,345 @@
+/*
+ * Copyright =C2=A9 2014-2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irqreturn.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm.h>
+#include <linux/pm_wakeup.h>
+#include <linux/reboot.h>
+#include <linux/rtc.h>
+#include <linux/stat.h>
+#include <linux/suspend.h>
+
+struct brcmstb_waketmr {
+ struct rtc_device *rtc;
+ struct device *dev;
+ void __iomem *base;
+ int irq;
+ struct notifier_block reboot_notifier;
+ struct clk *clk;
+ u32 rate;
+};
+
+#define BRCMSTB_WKTMR_EVENT 0x00
+#define BRCMSTB_WKTMR_COUNTER 0x04
+#define BRCMSTB_WKTMR_ALARM 0x08
+#define BRCMSTB_WKTMR_PRESCALER 0x0C
+#define BRCMSTB_WKTMR_PRESCALER_VAL 0x10
+
+#define BRCMSTB_WKTMR_DEFAULT_FREQ 27000000
+
+static inline void brcmstb_waketmr_clear_alarm(struct brcmstb_waketmr *tim=
er)
+{
+ writel_relaxed(1, timer->base + BRCMSTB_WKTMR_EVENT);
+ (void)readl_relaxed(timer->base + BRCMSTB_WKTMR_EVENT);
+}
+
+static void brcmstb_waketmr_set_alarm(struct brcmstb_waketmr *timer,
+ unsigned int secs)
+{
+ brcmstb_waketmr_clear_alarm(timer);
+
+ writel_relaxed(secs + 1, timer->base + BRCMSTB_WKTMR_ALARM);
+}
+
+static irqreturn_t brcmstb_waketmr_irq(int irq, void *data)
+{
+ struct brcmstb_waketmr *timer =3D data;
+
+ pm_wakeup_event(timer->dev, 0);
+
+ return IRQ_HANDLED;
+}
+
+struct wktmr_time {
+ u32 sec;
+ u32 pre;
+};
+
+static void wktmr_read(struct brcmstb_waketmr *timer,
+ struct wktmr_time *t)
+{
+ u32 tmp;
+
+ do {
+ t->sec =3D readl_relaxed(timer->base + BRCMSTB_WKTMR_COUNTER);
+ tmp =3D readl_relaxed(timer->base + BRCMSTB_WKTMR_PRESCALER_VAL);
+ } while (tmp >=3D timer->rate);
+
+ t->pre =3D timer->rate - tmp;
+}
+
+static int brcmstb_waketmr_prepare_suspend(struct brcmstb_waketmr *timer)
+{
+ struct device *dev =3D timer->dev;
+ int ret =3D 0;
+
+ if (device_may_wakeup(dev)) {
+ dev_dbg(dev, "enable wake IRQ\n");
+ ret =3D enable_irq_wake(timer->irq);
+ if (ret) {
+ dev_err(dev, "failed to enable wake-up interrupt\n");
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
+/* If enabled as a wakeup-source, arm the timer when powering off */
+static int brcmstb_waketmr_reboot(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct brcmstb_waketmr *timer;
+
+ timer =3D container_of(nb, struct brcmstb_waketmr, reboot_notifier);
+
+ /* Set timer for cold boot */
+ if (action =3D=3D SYS_POWER_OFF)
+ brcmstb_waketmr_prepare_suspend(timer);
+
+ return NOTIFY_DONE;
+}
+
+static int brcmstb_waketmr_gettime(struct device *dev,
+ struct rtc_time *tm)
+{
+ struct brcmstb_waketmr *timer =3D dev_get_drvdata(dev);
+ struct wktmr_time now;
+
+ wktmr_read(timer, &now);
+
+ rtc_time_to_tm(now.sec, tm);
+
+ return 0;
+}
+
+static int brcmstb_waketmr_settime(struct device *dev,
+ struct rtc_time *tm)
+{
+ struct brcmstb_waketmr *timer =3D dev_get_drvdata(dev);
+ unsigned long sec;
+ int ret;
+
+ ret =3D rtc_valid_tm(tm);
+ if (ret)
+ return ret;
+
+ rtc_tm_to_time(tm, &sec);
+
+ dev_dbg(dev, "%s: sec=3D%ld\n", __func__, sec);
+ writel_relaxed(sec, timer->base + BRCMSTB_WKTMR_COUNTER);
+
+ return 0;
+}
+
+static int brcmstb_waketmr_getalarm(struct device *dev,
+ struct rtc_wkalrm *alarm)
+{
+ struct brcmstb_waketmr *timer =3D dev_get_drvdata(dev);
+ unsigned long sec;
+ u32 reg;
+
+ sec =3D readl_relaxed(timer->base + BRCMSTB_WKTMR_ALARM);
+ if (sec =3D=3D 0) {
+ /* Alarm is disabled */
+ alarm->enabled =3D 0;
+ alarm->time.tm_mon =3D -1;
+ alarm->time.tm_mday =3D -1;
+ alarm->time.tm_year =3D -1;
+ alarm->time.tm_hour =3D -1;
+ alarm->time.tm_min =3D -1;
+ alarm->time.tm_sec =3D -1;
+ dev_dbg(dev, "%s: alarm is disabled\n", __func__);
+ } else {
+ /* Alarm is enabled */
+ alarm->enabled =3D 1;
+ rtc_time_to_tm(sec, &alarm->time);
+ dev_dbg(dev, "%s: alarm is enabled\n", __func__);
+ }
+
+ reg =3D readl_relaxed(timer->base + BRCMSTB_WKTMR_EVENT);
+ alarm->pending =3D !!(reg & 1);
+ dev_dbg(dev, "%s: alarm pending=3D%d\n", __func__, alarm->pending);
+
+ return 0;
+}
+
+static int brcmstb_waketmr_setalarm(struct device *dev,
+ struct rtc_wkalrm *alarm)
+{
+ struct brcmstb_waketmr *timer =3D dev_get_drvdata(dev);
+ unsigned long sec;
+
+ if (alarm->enabled)
+ rtc_tm_to_time(&alarm->time, &sec);
+ else
+ sec =3D 0;
+
+ dev_dbg(dev, "%s: timeout=3D%ld\n", __func__, sec);
+ brcmstb_waketmr_set_alarm(timer, sec);
+
+ return 0;
+}
+
+/*
+ * Does not do much but keep the RTC class happy. We always support
+ * alarms.
+ */
+static int brcmstb_waketmr_alarm_enable(struct device *dev,
+ unsigned int enabled)
+{
+ dev_dbg(dev, "%s: enabled=3D%d\n", __func__, enabled);
+ return 0;
+}
+
+static const struct rtc_class_ops brcmstb_waketmr_ops =3D {
+ .read_time =3D brcmstb_waketmr_gettime,
+ .set_time =3D brcmstb_waketmr_settime,
+ .read_alarm =3D brcmstb_waketmr_getalarm,
+ .set_alarm =3D brcmstb_waketmr_setalarm,
+ .alarm_irq_enable =3D brcmstb_waketmr_alarm_enable,
+};
+
+static int brcmstb_waketmr_probe(struct platform_device *pdev)
+{
+ struct device *dev =3D &pdev->dev;
+ struct brcmstb_waketmr *timer;
+ struct resource *res;
+ int ret;
+
+ timer =3D devm_kzalloc(dev, sizeof(*timer), GFP_KERNEL);
+ if (!timer)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, timer);
+ timer->dev =3D dev;
+
+ res =3D platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ timer->base =3D devm_ioremap_resource(dev, res);
+ if (IS_ERR(timer->base))
+ return PTR_ERR(timer->base);
+
+ /*
+ * Set wakeup capability before requesting wakeup interrupt, so we can
+ * process boot-time "wakeups" (e.g., from S5 soft-off)
+ */
+ device_set_wakeup_capable(dev, true);
+ device_wakeup_enable(dev);
+
+ timer->irq =3D platform_get_irq(pdev, 0);
+ if (timer->irq < 0)
+ return -ENODEV;
+
+ timer->clk =3D devm_clk_get(dev, NULL);
+ if (!IS_ERR(timer->clk)) {
+ ret =3D clk_prepare_enable(timer->clk);
+ if (ret)
+ return ret;
+ timer->rate =3D clk_get_rate(timer->clk);
+ if (!timer->rate)
+ timer->rate =3D BRCMSTB_WKTMR_DEFAULT_FREQ;
+ } else {
+ timer->rate =3D BRCMSTB_WKTMR_DEFAULT_FREQ;
+ timer->clk =3D NULL;
+ }
+
+ ret =3D devm_request_irq(dev, timer->irq, brcmstb_waketmr_irq, 0,
+ "brcmstb-waketimer", timer);
+ if (ret < 0)
+ return ret;
+
+ timer->reboot_notifier.notifier_call =3D brcmstb_waketmr_reboot;
+ register_reboot_notifier(&timer->reboot_notifier);
+
+ timer->rtc =3D rtc_device_register("brcmstb-waketmr", dev,
+ &brcmstb_waketmr_ops, THIS_MODULE);
+ if (IS_ERR(timer->rtc)) {
+ dev_err(dev, "unable to register device\n");
+ unregister_reboot_notifier(&timer->reboot_notifier);
+ return PTR_ERR(timer->rtc);
+ }
+
+ dev_info(dev, "registered, with irq %d\n", timer->irq);
+
+ return ret;
+}
+
+static int brcmstb_waketmr_remove(struct platform_device *pdev)
+{
+ struct brcmstb_waketmr *timer =3D dev_get_drvdata(&pdev->dev);
+
+ unregister_reboot_notifier(&timer->reboot_notifier);
+ rtc_device_unregister(timer->rtc);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int brcmstb_waketmr_suspend(struct device *dev)
+{
+ struct brcmstb_waketmr *timer =3D dev_get_drvdata(dev);
+
+ return brcmstb_waketmr_prepare_suspend(timer);
+}
+
+static int brcmstb_waketmr_resume(struct device *dev)
+{
+ struct brcmstb_waketmr *timer =3D dev_get_drvdata(dev);
+ int ret;
+
+ if (!device_may_wakeup(dev))
+ return 0;
+
+ ret =3D disable_irq_wake(timer->irq);
+
+ brcmstb_waketmr_clear_alarm(timer);
+
+ return ret;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static SIMPLE_DEV_PM_OPS(brcmstb_waketmr_pm_ops,
+ brcmstb_waketmr_suspend, brcmstb_waketmr_resume);
+
+static const struct of_device_id brcmstb_waketmr_of_match[] =3D {
+ { .compatible =3D "brcm,brcmstb-waketimer" },
+ { /* sentinel */ },
+};
+
+static struct platform_driver brcmstb_waketmr_driver =3D {
+ .probe =3D brcmstb_waketmr_probe,
+ .remove =3D brcmstb_waketmr_remove,
+ .driver =3D {
+ .name =3D "brcmstb-waketimer",
+ .pm =3D &brcmstb_waketmr_pm_ops,
+ .of_match_table =3D of_match_ptr(brcmstb_waketmr_of_match),
+ }
+};
+module_platform_driver(brcmstb_waketmr_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Brian Norris");
+MODULE_AUTHOR("Markus Mayer");
+MODULE_DESCRIPTION("Wake-up timer driver for STB chips");
--=20
2.9.3
--=20
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---=20
You received this message because you are subscribed to the Google Groups "=
rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: Document the Broadcom STB wake-up timer node
From: Florian Fainelli @ 2017-06-15 19:59 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Alessandro Zummo, Alexandre Belloni,
Rob Herring, Mark Rutland, Brian Norris, Gregory Fong,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
open list:REAL TIME CLOCK (RTC) SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE
In-Reply-To: <20170615195904.12653-1-f.fainelli@gmail.com>
Document the binding for the Broadcom STB SoCs wake-up timer node
allowing the system to generate alarms and exit low power states.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
.../bindings/rtc/brcm,brcmstb-waketimer.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.txt
diff --git a/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.txt b/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.txt
new file mode 100644
index 000000000000..1d990bcc0baf
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.txt
@@ -0,0 +1,22 @@
+Broadcom STB wake-up Timer
+
+The Broadcom STB wake-up timer provides a 27Mhz resolution timer, with the
+ability to wake up the system from low-power suspend/standby modes.
+
+Required properties:
+- compatible : should contain "brcm,brcmstb-waketimer"
+- reg : the register start and length for the WKTMR block
+- interrupts : The TIMER interrupt
+- interrupt-parent: The phandle to the Always-On (AON) Power Management (PM) L2
+ interrupt controller node
+- clocks : The phandle to the UPG fixed clock (27Mhz domain)
+
+Example:
+
+waketimer@f0411580 {
+ compatible = "brcm,brcmstb-waketimer";
+ reg = <0xf0411580 0x14>;
+ interrupts = <0x3>;
+ interrupt-parent = <&aon_pm_l2_intc>;
+ clocks = <&upg_fixed>;
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 0/2] Broadcom STB wake-timer support
From: Florian Fainelli @ 2017-06-15 19:59 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Alessandro Zummo, Alexandre Belloni,
Rob Herring, Mark Rutland, Brian Norris, Gregory Fong,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
open list:REAL TIME CLOCK (RTC) SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE
Hi Alexandre,
This patch series adds support for the Broadcom STB wake-timer. This is a 27Mhz
timer which allows the system to exit S2/S3/S5 sleep states when configured.
The wake-timer has has a long history within our internal/downstream tree, and
Brian authored it in the first place, then Markus added the rtc bits, and then I
cleaned it up for upstream.
Thanks!
Brian Norris (1):
rtc: brcmstb-waketimer: Add Broadcom STB wake-timer
Florian Fainelli (1):
dt-bindings: Document the Broadcom STB wake-up timer node
.../bindings/rtc/brcm,brcmstb-waketimer.txt | 22 ++
drivers/rtc/Kconfig | 11 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-brcmstb-waketimer.c | 345 +++++++++++++++++++++
4 files changed, 379 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.txt
create mode 100644 drivers/rtc/rtc-brcmstb-waketimer.c
--
2.9.3
^ permalink raw reply
* [rtc-linux] Re: [PATCH 1/3 v2] rtc: gemini: Add optional clock handling
From: Linus Walleij @ 2017-06-11 22:12 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni
Cc: rtc-linux@googlegroups.com, Linus Walleij
In-Reply-To: <20170530075332.3740-1-linus.walleij@linaro.org>
On Tue, May 30, 2017 at 9:53 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> This makes the Gemini optionally take two clock references to
> the PCLK and EXTCLK. As we are adding a clock framework to the
> Gemini platform we need to make sure that we get the right
> references.
>
> Acked-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Use devm_clk_get() so we do not leave dangling clocks
> behind.
> - Add Hans' ACK.
Alessandro, Alexandre:
Is this v2 series fine, or do I need to fix something?
Just restless, sorry ...
Yours,
Linus Walleij
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v1 24/25] kdb: Switch to use %pt
From: Daniel Thompson @ 2017-06-09 13:42 UTC (permalink / raw)
To: Andy Shevchenko, Rasmus Villemoes, Greg Kroah-Hartman,
Andrew Morton, linux-kernel, Alessandro Zummo, Alexandre Belloni,
linux-rtc
Cc: Jason Wessel, Ingo Molnar
In-Reply-To: <20170608134811.60786-25-andriy.shevchenko@linux.intel.com>
On 08/06/17 14:48, Andy Shevchenko wrote:
> Use %pt instead of open coded variant to print content of
> struct rtc_time in human readable format.
>
> Cc: Jason Wessel <jason.wessel@windriver.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
> ---
> kernel/debug/kdb/kdb_main.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
> index c8146d53ca67..2a6f12be79d8 100644
> --- a/kernel/debug/kdb/kdb_main.c
> +++ b/kernel/debug/kdb/kdb_main.c
> @@ -2556,12 +2556,7 @@ static int kdb_summary(int argc, const char **argv)
>
> now = __current_kernel_time();
> kdb_gmtime(&now, &tm);
> - kdb_printf("date %04d-%02d-%02d %02d:%02d:%02d "
> - "tz_minuteswest %d\n",
> - 1900+tm.tm_year, tm.tm_mon+1, tm.tm_mday,
> - tm.tm_hour, tm.tm_min, tm.tm_sec,
> - sys_tz.tz_minuteswest);
> -
> + kdb_printf("date %pt tz_minuteswest %d\n", &tm, sys_tz.tz_minuteswest);
> kdb_sysinfo(&val);
> kdb_printf("uptime ");
> if (val.uptime > (24*60*60)) {
>
^ permalink raw reply
* Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv]
From: Joe Perches @ 2017-06-09 5:08 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Andy Shevchenko, Rasmus Villemoes, Greg Kroah-Hartman,
Andrew Morton, linux-kernel@vger.kernel.org, Alessandro Zummo,
Alexandre Belloni, linux-rtc
In-Reply-To: <CAHp75VcCEO6yfd51n=g8tpWGBfwZrMuJO9aDGBY6ZXb5sQPd5g@mail.gmail.com>
On Thu, 2017-06-08 at 18:02 +0300, Andy Shevchenko wrote:
> On Thu, Jun 8, 2017 at 5:52 PM, Joe Perches <joe@perches.com> wrote:
> > On Thu, 2017-06-08 at 16:47 +0300, Andy Shevchenko wrote:
> > > Recently I have noticed too many users of struct rtc_time that printing
> > > its content field by field.
> > >
> > > In this series I introduce %pt[dt][rv] specifier to make life a bit
> > > easier.
[]
> > > Most of the users currently are RTC drivers, thus the patch series is
> > > assumed to go via RTC tree.
> >
> > What I wonder about this series is how much
> > larger it makes a typical kernel and how
> > often multiple rtc clocks are built for a
> > single kernel?
>
> We may hide it under CONFIG_RTC_??? if we want to reduce kernel for
> non RTC cases.
Depends whether it is for rtc_time only
> > What is the size impact on an embedded kernel
> > that uses a single rtc driver?
>
> I would
You would what?
^ permalink raw reply
* Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt
From: Joe Perches @ 2017-06-08 23:09 UTC (permalink / raw)
To: Andy Shevchenko, Arnd Bergmann
Cc: Andy Shevchenko, Rasmus Villemoes, Greg Kroah-Hartman,
Andrew Morton, Linux Kernel Mailing List, Alessandro Zummo,
Alexandre Belloni, linux-rtc, Bartlomiej Zolnierkiewicz,
Dmitry Torokhov, Geert Uytterhoeven, Guan Xuetao, Ingo Molnar,
Jason Wessel, Jonathan Corbet, Jonathan Hunter,
Krzysztof Kozlowski, Rafael J. Wysocki, Thierry Reding
In-Reply-To: <CAHp75VfeyGH9wHmvcmJN9M8GNfG0iXTNO_wacsr+9SZ2CUJxYA@mail.gmail.com>
On Thu, 2017-06-08 at 21:02 +0300, Andy Shevchenko wrote:
> On Thu, Jun 8, 2017 at 6:33 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thu, Jun 8, 2017 at 4:55 PM, Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Thu, Jun 8, 2017 at 5:49 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Thu, Jun 8, 2017 at 3:47 PM, Andy Shevchenko
> > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > I really like the idea, and the implementation seems fine for this use case, but
> > > > before we reserve %pt for rtc_time, could we discuss whether we want
> > > > that for printing struct tm, struct timespec64, time64_t or ktime_t instead?
> > >
> > > How many users?
> >
> > It's hard to predict, I would assume we get more users once there is an
> > easy way to print the time.
>
> So, at least for now we can guess using existing users, right?
>
> I don't check yet how to calculate those cases of time64_t,
> timespec64, ktime_t and alike if they are about pretty ptintong time
> and date.
> I'm speculating that there are (almost) none.
>
> > > For struct tm it's somelike 4 (which want to print its content).
> >
> > Good point. I notice that they all convert from time64_t or time_t into
> > struct tm immediately before printing it, so we can scratch that one
> > as long as there is a way to pretty-print a time64_t. We also don't
> > need to print a time_t as we want to kill that one off anyway.
> >
> > If we only care about printing time64_t and rtc_time, we can easily
> > use %pT for one and %pt for the other, but there may still be good
> > reasons to print a timespec64 or ktime_t.
>
> No need, we may still use 3rd/4th letter in the format for that.
>
> %pt(t/d) time/date + whatever modifications, like raw, validate, timespec, etc.
>
> 's' for timespec64, for example.
My preference would be for %pt[type]<output style>
where <type> is mandatory and could be:
r for struct rtc_time
6 for time64_t
k for ktime_t
T for struct timespec64
etc
and <output style> has an unspecified default of
YYYY-MM-DD:hh:mm:ss
Perhaps use the "date" formats without the leading
% uses for <output style> for additional styles.
^ permalink raw reply
* Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt
From: Arnd Bergmann @ 2017-06-08 21:45 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rasmus Villemoes, Alexandre Belloni, Andy Shevchenko,
Rasmus Villemoes, Greg Kroah-Hartman, Andrew Morton,
Linux Kernel Mailing List, Alessandro Zummo, linux-rtc,
Bartlomiej Zolnierkiewicz, Dmitry Torokhov, Geert Uytterhoeven,
Guan Xuetao, Ingo Molnar, Jason Wessel, Jonathan Corbet,
Jonathan Hunter, Krzysztof Kozlowski, Rafael J. Wysocki
In-Reply-To: <CAHp75VdVV6i8SD6=z5Bt=UCsDB7mYTnxpZqP5=pWiob1CVPSaA@mail.gmail.com>
On Thu, Jun 8, 2017 at 11:25 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Thu, Jun 8, 2017 at 11:42 PM, Rasmus Villemoes
> <linux@rasmusvillemoes.dk> wrote:
>> On Thu, Jun 08 2017, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>>> On Thu, Jun 8, 2017 at 9:41 PM, Alexandre Belloni
>>> <alexandre.belloni@free-electrons.com> wrote:
>>>> On 08/06/2017 at 20:57:05 +0300, Andy Shevchenko wrote:
>>>>> On Thu, Jun 8, 2017 at 6:05 PM, Alexandre Belloni
>>>>> <alexandre.belloni@free-electrons.com> wrote:
>
>>> Yeah, but the problem is to pass the reference. All dances around will
>>> uglify the code.
>>> (Obviously we can't pass timespec64/time64_t or anything longer than
>>> 32 bits as is in %p extension)
>
>> I like that this gets rid of some mm/dd/yy and other more or less random
>> format and ends up standardizing yyyy-mm-dd HH:MM:SS. However, I do
>> think %pt should take either ktime_t or timespec64 (obviously by
>> reference),
>
> I will try to look in this direction.
sounds good.
>> Please don't give people the option of eliding either the time or the
>> date; I've spent too much time dealing with syslog files that don't
>> include the year in the timestamps.
>
> I understand that, but see above.
When we pretty-print a ktime_t, we probably want to leave out the high
fields as well, as this often refers to a time interval, e.g. a few seconds.
Even for absolute values, the start of ktime_t is usually not the 1970
epoch but system boot, so we may not necessarily want the higher
fields. I hoped to find some inspiration in the 'date' man page, which
contains a lot of formatting options, but it's hard to translate that into
a useful format string within the constraints of %p flags in printk.
Arnd
^ permalink raw reply
* Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt
From: Andy Shevchenko @ 2017-06-08 21:25 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Alexandre Belloni, Arnd Bergmann, Andy Shevchenko,
Rasmus Villemoes, Greg Kroah-Hartman, Andrew Morton,
Linux Kernel Mailing List, Alessandro Zummo, linux-rtc,
Bartlomiej Zolnierkiewicz, Dmitry Torokhov, Geert Uytterhoeven,
Guan Xuetao, Ingo Molnar, Jason Wessel, Jonathan Corbet,
Jonathan Hunter, Krzysztof Kozlowski, Rafael J. Wysocki
In-Reply-To: <87wp8mky7z.fsf@rasmusvillemoes.dk>
On Thu, Jun 8, 2017 at 11:42 PM, Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
> On Thu, Jun 08 2017, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>> On Thu, Jun 8, 2017 at 9:41 PM, Alexandre Belloni
>> <alexandre.belloni@free-electrons.com> wrote:
>>> On 08/06/2017 at 20:57:05 +0300, Andy Shevchenko wrote:
>>>> On Thu, Jun 8, 2017 at 6:05 PM, Alexandre Belloni
>>>> <alexandre.belloni@free-electrons.com> wrote:
>> Yeah, but the problem is to pass the reference. All dances around will
>> uglify the code.
>> (Obviously we can't pass timespec64/time64_t or anything longer than
>> 32 bits as is in %p extension)
> I like that this gets rid of some mm/dd/yy and other more or less random
> format and ends up standardizing yyyy-mm-dd HH:MM:SS. However, I do
> think %pt should take either ktime_t or timespec64 (obviously by
> reference),
I will try to look in this direction.
> with fx these options
>
> [ir] ISO (yyyy-mm-dd HH:MM:SS) or raw (seconds since epoch)
> [n] append nanoseconds (.%09ld).
We still need to be able to print time *and/or* year groups
separately. There are users which provide that via procfs or sysfs
(ABI).
> Please don't give people the option of eliding either the time or the
> date; I've spent too much time dealing with syslog files that don't
> include the year in the timestamps.
I understand that, but see above.
> Getting a timespec64* or ktime_t* from <something else> is not that
> bad. There's the compound literal option
Will look at it later, thanks for it.
>
> #define rtc_tm2timespec64p(tm) \
> (&(struct timespec64){ .tv_sec = rtc_tm_to_time64(tm), .tv_nsec = 0 })
>
> printk("%pt", rtc_tm2timespec64p(tm))
>
> or the two-extra-lines per call-site
>
> struct timespec64 ts;
> rtc_tm2time64(tm, &ts)
> printk("%pt", &ts)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 01/25] lib/vsprintf: Remove useless NULL checks
From: Rasmus Villemoes @ 2017-06-08 20:59 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rasmus Villemoes, Greg Kroah-Hartman, Andrew Morton, linux-kernel,
Alessandro Zummo, Alexandre Belloni, linux-rtc
In-Reply-To: <20170608134811.60786-2-andriy.shevchenko@linux.intel.com>
On Thu, Jun 08 2017, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> The pointer can't be NULL since it's first what has been done in the
> pointer().
>
> Remove useless checks.
>
> Note when we print clock name or rate it is safe in case !CONFIG_HAVE_CLK.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> lib/vsprintf.c | 11 -----------
> 1 file changed, 11 deletions(-)
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 9f16406288c0..031c2cc5c1c0 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -811,10 +811,6 @@ char *hex_string(char *buf, char *end, u8 *addr, struct printf_spec spec,
> /* nothing to print */
> return buf;
>
> - if (ZERO_OR_NULL_PTR(addr))
> - /* NULL pointer */
> - return string(buf, end, NULL, spec);
> -
> switch (fmt[1]) {
> case 'C':
> separator = ':';
> @@ -1253,10 +1249,6 @@ char *escaped_string(char *buf, char *end, u8 *addr, struct printf_spec spec,
> if (spec.field_width == 0)
> return buf; /* nothing to print */
>
> - if (ZERO_OR_NULL_PTR(addr))
> - return string(buf, end, NULL, spec); /* NULL pointer */
> -
> -
Well, ZERO_OR_NULL_PTR checks for a little more than !addr, but I
suppose that if anyone passes the result from kmalloc(0) to %ph, they'd
better also pass 0 as the size, so the .field_width tests should be
sufficient.
> do {
> switch (fmt[count++]) {
> case 'a':
> @@ -1391,9 +1383,6 @@ static noinline_for_stack
> char *clock(char *buf, char *end, struct clk *clk, struct printf_spec spec,
> const char *fmt)
> {
> - if (!IS_ENABLED(CONFIG_HAVE_CLK) || !clk)
> - return string(buf, end, NULL, spec);
> -
Well, it may be safe, but removing the IS_ENABLED(CONFIG_HAVE_CLK) check
means that clock() becomes a much bigger function when
!IS_ENABLED(CONFIG_HAVE_CLK). You're right that the !clk check is
pointless.
^ permalink raw reply
* Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt
From: Rasmus Villemoes @ 2017-06-08 20:42 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Alexandre Belloni, Arnd Bergmann, Andy Shevchenko,
Rasmus Villemoes, Greg Kroah-Hartman, Andrew Morton,
Linux Kernel Mailing List, Alessandro Zummo, linux-rtc,
Bartlomiej Zolnierkiewicz, Dmitry Torokhov, Geert Uytterhoeven,
Guan Xuetao, Ingo Molnar, Jason Wessel, Jonathan Corbet,
Jonathan Hunter, Krzysztof Kozlowski, Rafael J. Wysocki
In-Reply-To: <CAHp75VcJZS+x8KdBs0nQj_sq9yx23gx3NBP_AqGi0xU+AqEDwQ@mail.gmail.com>
On Thu, Jun 08 2017, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Thu, Jun 8, 2017 at 9:41 PM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
>> On 08/06/2017 at 20:57:05 +0300, Andy Shevchenko wrote:
>>> On Thu, Jun 8, 2017 at 6:05 PM, Alexandre Belloni
>>> <alexandre.belloni@free-electrons.com> wrote:
>
>>> > I understand this may not fit your debugging needs but what about pretty
>>> > printing time64_t and using rtc_tm_to_time64?
>>>
>>> There are two downsides as I can see:
>>> 1) conversion to and from just for that;
>>
>> Those are almost all debug messages, I would be fine with that.
>
> Yeah, but the problem is to pass the reference. All dances around will
> uglify the code.
> (Obviously we can't pass timespec64/time64_t or anything longer than
> 32 bits as is in %p extension)
>
I like that this gets rid of some mm/dd/yy and other more or less random
format and ends up standardizing yyyy-mm-dd HH:MM:SS. However, I do
think %pt should take either ktime_t or timespec64 (obviously by
reference), with fx these options
[ir] ISO (yyyy-mm-dd HH:MM:SS) or raw (seconds since epoch)
[n] append nanoseconds (.%09ld).
Please don't give people the option of eliding either the time or the
date; I've spent too much time dealing with syslog files that don't
include the year in the timestamps.
Getting a timespec64* or ktime_t* from <something else> is not that
bad. There's the compound literal option
#define rtc_tm2timespec64p(tm) \
(&(struct timespec64){ .tv_sec = rtc_tm_to_time64(tm), .tv_nsec = 0 })
printk("%pt", rtc_tm2timespec64p(tm))
or the two-extra-lines per call-site
struct timespec64 ts;
rtc_tm2time64(tm, &ts)
printk("%pt", &ts)
Rasmus
^ permalink raw reply
* Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt
From: Andy Shevchenko @ 2017-06-08 18:49 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Arnd Bergmann, Andy Shevchenko, Rasmus Villemoes,
Greg Kroah-Hartman, Andrew Morton, Linux Kernel Mailing List,
Alessandro Zummo, linux-rtc, Bartlomiej Zolnierkiewicz,
Dmitry Torokhov, Geert Uytterhoeven, Guan Xuetao, Ingo Molnar,
Jason Wessel, Jonathan Corbet, Jonathan Hunter,
Krzysztof Kozlowski, Rafael J. Wysocki, Thierry Reding
In-Reply-To: <20170608184154.y7tqsv7ghpbcbf77@piout.net>
On Thu, Jun 8, 2017 at 9:41 PM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> On 08/06/2017 at 20:57:05 +0300, Andy Shevchenko wrote:
>> On Thu, Jun 8, 2017 at 6:05 PM, Alexandre Belloni
>> <alexandre.belloni@free-electrons.com> wrote:
>> > I understand this may not fit your debugging needs but what about pretty
>> > printing time64_t and using rtc_tm_to_time64?
>>
>> There are two downsides as I can see:
>> 1) conversion to and from just for that;
>
> Those are almost all debug messages, I would be fine with that.
Yeah, but the problem is to pass the reference. All dances around will
uglify the code.
(Obviously we can't pass timespec64/time64_t or anything longer than
32 bits as is in %p extension)
>> 2) if you look closer to the patches rtc-* you may find cases where
>> wday is also printed so, struct rtc_time still will be in use.
> (And you missed two in rtc-mcp795.c). Honestly, nobody cares about wday,
> you may as well leave it out.
Oops, thanks, indeed. Okay, I will leave it for now with dropped wday
until someone comes with strong opinion why it should be there.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt
From: Alexandre Belloni @ 2017-06-08 18:41 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Arnd Bergmann, Andy Shevchenko, Rasmus Villemoes,
Greg Kroah-Hartman, Andrew Morton, Linux Kernel Mailing List,
Alessandro Zummo, linux-rtc, Bartlomiej Zolnierkiewicz,
Dmitry Torokhov, Geert Uytterhoeven, Guan Xuetao, Ingo Molnar,
Jason Wessel, Jonathan Corbet, Jonathan Hunter,
Krzysztof Kozlowski, Rafael J. Wysocki, Thierry Reding
In-Reply-To: <CAHp75Vfem=tj3esGx+7_8_Ygx+v09uk77rF-RJ34Tt2kLTHvVQ@mail.gmail.com>
On 08/06/2017 at 20:57:05 +0300, Andy Shevchenko wrote:
> On Thu, Jun 8, 2017 at 6:05 PM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
> > On 08/06/2017 at 17:55:12 +0300, Andy Shevchenko wrote:
> >> On Thu, Jun 8, 2017 at 5:49 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Thu, Jun 8, 2017 at 3:47 PM, Andy Shevchenko
> >> > <andriy.shevchenko@linux.intel.com> wrote:
> >> >> There are users which print time and date represented by content of
> >> >> struct rtc_time in human readable format.
> >> >>
> >> >> Instead of open coding that each time introduce %pt[dt][rv] specifier.
> >> >
> >> > I really like the idea, and the implementation seems fine for this use case, but
> >> > before we reserve %pt for rtc_time, could we discuss whether we want
> >> > that for printing struct tm, struct timespec64, time64_t or ktime_t instead?
> >>
> >> How many users? For struct tm it's somelike 4 (which want to print its content).
> >>
> >> > I can see good reasons for pretty-printing any of them, but the namespace for
> >> > format strings is rather limited.
> >> >
> >> > struct rtc_time is almost the same as struct tm (the former has one extra
> >> > member), so maybe we can actually define them to be the same and
> >> > use one format string for both?
> >>
> >> The reason I decide to drop struct tm for now due to they are not
> >> compatible and I have got an interesting bugs.
> >> Verify tm_year member carefully.
> >>
> >
> > I understand this may not fit your debugging needs but what about pretty
> > printing time64_t and using rtc_tm_to_time64?
>
> There are two downsides as I can see:
> 1) conversion to and from just for that;
Those are almost all debug messages, I would be fine with that.
> 2) if you look closer to the patches rtc-* you may find cases where
> wday is also printed so, struct rtc_time still will be in use.
>
(And you missed two in rtc-mcp795.c). Honestly, nobody cares about wday,
you may as well leave it out.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v1 06/25] rtc: Switch to use %pt
From: Andy Shevchenko @ 2017-06-08 18:38 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Andy Shevchenko, Rasmus Villemoes, Andrew Morton,
linux-kernel@vger.kernel.org, Alessandro Zummo, Alexandre Belloni,
linux-rtc
In-Reply-To: <20170608140000.GA21298@kroah.com>
On Thu, Jun 8, 2017 at 5:00 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Jun 08, 2017 at 04:47:52PM +0300, Andy Shevchenko wrote:
>> Use %pt instead of open coded variant to print content of
>> struct rtc_time in human readable format.
>>
>> Arnd Bergmann <arnd@arndb.de>
>
> Cc: ?
Yep!
Fixed locally, will be in next version of the series.
>
>> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thanks!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt
From: Andy Shevchenko @ 2017-06-08 18:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andy Shevchenko, Rasmus Villemoes, Greg Kroah-Hartman,
Andrew Morton, Linux Kernel Mailing List, Alessandro Zummo,
Alexandre Belloni, linux-rtc, Bartlomiej Zolnierkiewicz,
Dmitry Torokhov, Geert Uytterhoeven, Guan Xuetao, Ingo Molnar,
Jason Wessel, Jonathan Corbet, Jonathan Hunter,
Krzysztof Kozlowski, Rafael J. Wysocki, Thierry Reding
In-Reply-To: <CAK8P3a3P4rDqQaNmBR9C9nF3VCqcQOH06Nq8RyDHsNfc0Ms13g@mail.gmail.com>
On Thu, Jun 8, 2017 at 6:33 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Jun 8, 2017 at 4:55 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>> On Thu, Jun 8, 2017 at 5:49 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Thu, Jun 8, 2017 at 3:47 PM, Andy Shevchenko
>>> <andriy.shevchenko@linux.intel.com> wrote:
>>> I really like the idea, and the implementation seems fine for this use case, but
>>> before we reserve %pt for rtc_time, could we discuss whether we want
>>> that for printing struct tm, struct timespec64, time64_t or ktime_t instead?
>>
>> How many users?
>
> It's hard to predict, I would assume we get more users once there is an
> easy way to print the time.
So, at least for now we can guess using existing users, right?
I don't check yet how to calculate those cases of time64_t,
timespec64, ktime_t and alike if they are about pretty ptintong time
and date.
I'm speculating that there are (almost) none.
>> For struct tm it's somelike 4 (which want to print its content).
>
> Good point. I notice that they all convert from time64_t or time_t into
> struct tm immediately before printing it, so we can scratch that one
> as long as there is a way to pretty-print a time64_t. We also don't
> need to print a time_t as we want to kill that one off anyway.
>
> If we only care about printing time64_t and rtc_time, we can easily
> use %pT for one and %pt for the other, but there may still be good
> reasons to print a timespec64 or ktime_t.
No need, we may still use 3rd/4th letter in the format for that.
%pt(t/d) time/date + whatever modifications, like raw, validate, timespec, etc.
's' for timespec64, for example.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt
From: Andy Shevchenko @ 2017-06-08 17:57 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Arnd Bergmann, Andy Shevchenko, Rasmus Villemoes,
Greg Kroah-Hartman, Andrew Morton, Linux Kernel Mailing List,
Alessandro Zummo, linux-rtc, Bartlomiej Zolnierkiewicz,
Dmitry Torokhov, Geert Uytterhoeven, Guan Xuetao, Ingo Molnar,
Jason Wessel, Jonathan Corbet, Jonathan Hunter,
Krzysztof Kozlowski, Rafael J. Wysocki, Thierry Reding
In-Reply-To: <20170608150540.rek7a4akuxm3k36l@piout.net>
On Thu, Jun 8, 2017 at 6:05 PM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> On 08/06/2017 at 17:55:12 +0300, Andy Shevchenko wrote:
>> On Thu, Jun 8, 2017 at 5:49 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Thu, Jun 8, 2017 at 3:47 PM, Andy Shevchenko
>> > <andriy.shevchenko@linux.intel.com> wrote:
>> >> There are users which print time and date represented by content of
>> >> struct rtc_time in human readable format.
>> >>
>> >> Instead of open coding that each time introduce %pt[dt][rv] specifier.
>> >
>> > I really like the idea, and the implementation seems fine for this use case, but
>> > before we reserve %pt for rtc_time, could we discuss whether we want
>> > that for printing struct tm, struct timespec64, time64_t or ktime_t instead?
>>
>> How many users? For struct tm it's somelike 4 (which want to print its content).
>>
>> > I can see good reasons for pretty-printing any of them, but the namespace for
>> > format strings is rather limited.
>> >
>> > struct rtc_time is almost the same as struct tm (the former has one extra
>> > member), so maybe we can actually define them to be the same and
>> > use one format string for both?
>>
>> The reason I decide to drop struct tm for now due to they are not
>> compatible and I have got an interesting bugs.
>> Verify tm_year member carefully.
>>
>
> I understand this may not fit your debugging needs but what about pretty
> printing time64_t and using rtc_tm_to_time64?
There are two downsides as I can see:
1) conversion to and from just for that;
2) if you look closer to the patches rtc-* you may find cases where
wday is also printed so, struct rtc_time still will be in use.
So, I would go not to convert if there is no strong reason to do.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 25/25] PM: Switch to use %pt
From: Rafael J. Wysocki @ 2017-06-08 17:16 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rasmus Villemoes, Greg Kroah-Hartman, Andrew Morton,
Linux Kernel Mailing List, Alessandro Zummo, Alexandre Belloni,
linux-rtc, Rafael J. Wysocki, Linux PM
In-Reply-To: <20170608134811.60786-26-andriy.shevchenko@linux.intel.com>
On Thu, Jun 8, 2017 at 3:48 PM, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> Use %pt instead of open coded variant to print content of
> struct rtc_time in human readable format.
>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: linux-pm@vger.kernel.org
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/base/power/trace.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/base/power/trace.c b/drivers/base/power/trace.c
> index 1cda505d6a85..5e32a4f28a49 100644
> --- a/drivers/base/power/trace.c
> +++ b/drivers/base/power/trace.c
> @@ -118,9 +118,7 @@ static unsigned int read_magic_time(void)
> unsigned int val;
>
> mc146818_get_time(&time);
> - pr_info("RTC time: %2d:%02d:%02d, date: %02d/%02d/%02d\n",
> - time.tm_hour, time.tm_min, time.tm_sec,
> - time.tm_mon + 1, time.tm_mday, time.tm_year % 100);
> + pr_info("RTC time: %ptt, date: %ptd\n", &time, &time);
> val = time.tm_year; /* 100 years */
> if (val > 100)
> val -= 100;
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH v1 20/25] rtc: s5m: Switch to use %pt
From: Krzysztof Kozlowski @ 2017-06-08 16:46 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rasmus Villemoes, Greg Kroah-Hartman, Andrew Morton, linux-kernel,
Alessandro Zummo, Alexandre Belloni, linux-rtc,
Bartlomiej Zolnierkiewicz
In-Reply-To: <20170608134811.60786-21-andriy.shevchenko@linux.intel.com>
On Thu, Jun 08, 2017 at 04:48:06PM +0300, Andy Shevchenko wrote:
> Use %pt instead of open coded variant to print content of
> struct rtc_time in human readable format.
>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/rtc/rtc-s5m.c | 27 ++++++---------------------
> 1 file changed, 6 insertions(+), 21 deletions(-)
>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt
From: Joe Perches @ 2017-06-08 15:48 UTC (permalink / raw)
To: Arnd Bergmann, Andy Shevchenko
Cc: Andy Shevchenko, Rasmus Villemoes, Greg Kroah-Hartman,
Andrew Morton, Linux Kernel Mailing List, Alessandro Zummo,
Alexandre Belloni, linux-rtc, Bartlomiej Zolnierkiewicz,
Dmitry Torokhov, Geert Uytterhoeven, Guan Xuetao, Ingo Molnar,
Jason Wessel, Jonathan Corbet, Jonathan Hunter,
Krzysztof Kozlowski, Rafael J. Wysocki, Thierry Reding
In-Reply-To: <CAK8P3a3P4rDqQaNmBR9C9nF3VCqcQOH06Nq8RyDHsNfc0Ms13g@mail.gmail.com>
On Thu, 2017-06-08 at 17:33 +0200, Arnd Bergmann wrote:
> On Thu, Jun 8, 2017 at 4:55 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Thu, Jun 8, 2017 at 5:49 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Thu, Jun 8, 2017 at 3:47 PM, Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > There are users which print time and date represented by content of
> > > > struct rtc_time in human readable format.
> > > >
> > > > Instead of open coding that each time introduce %pt[dt][rv] specifier.
> > >
> > > I really like the idea, and the implementation seems fine for this use case, but
> > > before we reserve %pt for rtc_time, could we discuss whether we want
> > > that for printing struct tm, struct timespec64, time64_t or ktime_t instead?
> >
> > How many users?
>
> It's hard to predict, I would assume we get more users once there is an
> easy way to print the time.
>
> > For struct tm it's somelike 4 (which want to print its content).
>
> Good point. I notice that they all convert from time64_t or time_t into
> struct tm immediately before printing it, so we can scratch that one
> as long as there is a way to pretty-print a time64_t. We also don't
> need to print a time_t as we want to kill that one off anyway.
>
> If we only care about printing time64_t and rtc_time, we can easily
> use %pT for one and %pt for the other, but there may still be good
> reasons to print a timespec64 or ktime_t.
> > > I can see good reasons for pretty-printing any of them, but the namespace for
> > > format strings is rather limited.
The kernel already uses different types for the same leading
letter. For
instance: %pI4 vs %pI6, %pap vs %pad
A single 't' letter could do reasonably well.
^ permalink raw reply
* Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt
From: Arnd Bergmann @ 2017-06-08 15:33 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Andy Shevchenko, Rasmus Villemoes, Greg Kroah-Hartman,
Andrew Morton, Linux Kernel Mailing List, Alessandro Zummo,
Alexandre Belloni, linux-rtc, Bartlomiej Zolnierkiewicz,
Dmitry Torokhov, Geert Uytterhoeven, Guan Xuetao, Ingo Molnar,
Jason Wessel, Jonathan Corbet, Jonathan Hunter,
Krzysztof Kozlowski, Rafael J. Wysocki, Thierry Reding
In-Reply-To: <CAHp75VfUU9fO-jnY32caKywf8h3bdst9zBf66Wjz6C5+4z1okA@mail.gmail.com>
On Thu, Jun 8, 2017 at 4:55 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Thu, Jun 8, 2017 at 5:49 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Thu, Jun 8, 2017 at 3:47 PM, Andy Shevchenko
>> <andriy.shevchenko@linux.intel.com> wrote:
>>> There are users which print time and date represented by content of
>>> struct rtc_time in human readable format.
>>>
>>> Instead of open coding that each time introduce %pt[dt][rv] specifier.
>>
>> I really like the idea, and the implementation seems fine for this use case, but
>> before we reserve %pt for rtc_time, could we discuss whether we want
>> that for printing struct tm, struct timespec64, time64_t or ktime_t instead?
>
> How many users?
It's hard to predict, I would assume we get more users once there is an
easy way to print the time.
> For struct tm it's somelike 4 (which want to print its content).
Good point. I notice that they all convert from time64_t or time_t into
struct tm immediately before printing it, so we can scratch that one
as long as there is a way to pretty-print a time64_t. We also don't
need to print a time_t as we want to kill that one off anyway.
If we only care about printing time64_t and rtc_time, we can easily
use %pT for one and %pt for the other, but there may still be good
reasons to print a timespec64 or ktime_t.
>> I can see good reasons for pretty-printing any of them, but the namespace for
>> format strings is rather limited.
>>
>> struct rtc_time is almost the same as struct tm (the former has one extra
>> member), so maybe we can actually define them to be the same and
>> use one format string for both?
>
> The reason I decide to drop struct tm for now due to they are not
> compatible and I have got an interesting bugs.
Ok.
Arnd
^ permalink raw reply
* Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt
From: Alexandre Belloni @ 2017-06-08 15:05 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Arnd Bergmann, Andy Shevchenko, Rasmus Villemoes,
Greg Kroah-Hartman, Andrew Morton, Linux Kernel Mailing List,
Alessandro Zummo, linux-rtc, Bartlomiej Zolnierkiewicz,
Dmitry Torokhov, Geert Uytterhoeven, Guan Xuetao, Ingo Molnar,
Jason Wessel, Jonathan Corbet, Jonathan Hunter,
Krzysztof Kozlowski, Rafael J. Wysocki, Thierry Reding
In-Reply-To: <CAHp75VfUU9fO-jnY32caKywf8h3bdst9zBf66Wjz6C5+4z1okA@mail.gmail.com>
On 08/06/2017 at 17:55:12 +0300, Andy Shevchenko wrote:
> On Thu, Jun 8, 2017 at 5:49 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thu, Jun 8, 2017 at 3:47 PM, Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> >> There are users which print time and date represented by content of
> >> struct rtc_time in human readable format.
> >>
> >> Instead of open coding that each time introduce %pt[dt][rv] specifier.
> >
> > I really like the idea, and the implementation seems fine for this use case, but
> > before we reserve %pt for rtc_time, could we discuss whether we want
> > that for printing struct tm, struct timespec64, time64_t or ktime_t instead?
>
> How many users? For struct tm it's somelike 4 (which want to print its content).
>
> > I can see good reasons for pretty-printing any of them, but the namespace for
> > format strings is rather limited.
> >
> > struct rtc_time is almost the same as struct tm (the former has one extra
> > member), so maybe we can actually define them to be the same and
> > use one format string for both?
>
> The reason I decide to drop struct tm for now due to they are not
> compatible and I have got an interesting bugs.
> Verify tm_year member carefully.
>
I understand this may not fit your debugging needs but what about pretty
printing time64_t and using rtc_tm_to_time64?
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv]
From: Andy Shevchenko @ 2017-06-08 15:02 UTC (permalink / raw)
To: Joe Perches
Cc: Andy Shevchenko, Rasmus Villemoes, Greg Kroah-Hartman,
Andrew Morton, linux-kernel@vger.kernel.org, Alessandro Zummo,
Alexandre Belloni, linux-rtc
In-Reply-To: <1496933554.1929.15.camel@perches.com>
On Thu, Jun 8, 2017 at 5:52 PM, Joe Perches <joe@perches.com> wrote:
> On Thu, 2017-06-08 at 16:47 +0300, Andy Shevchenko wrote:
>> Recently I have noticed too many users of struct rtc_time that printing
>> its content field by field.
>>
>> In this series I introduce %pt[dt][rv] specifier to make life a bit
>> easier.
>>
>> There are still users of detailed output of the struct rtc_time, but we
>> can introduce an additional extension for them in the future if needed,
>> otherwise they might be converted to the proposed output format.
>>
>> Some of the changes slightly modify the output. In those cases we are on
>> the safe side since they are pure debug. Nevertheless I tried to leave
>> numbers to be the same or quite close: in some cases year is printed +
>> 1900, though month is left in the range [0,11] instead of [1,12].
>>
>> I didn't compile everything there, though I did a basic smoke test on
>> some x86 hardware. So, I rely on kbuild test robot as well :-)
>>
>> Most of the users currently are RTC drivers, thus the patch series is
>> assumed to go via RTC tree.
>
> What I wonder about this series is how much
> larger it makes a typical kernel and how
> often multiple rtc clocks are built for a
> single kernel?
We may hide it under CONFIG_RTC_??? if we want to reduce kernel for
non RTC cases.
> What is the size impact on an embedded kernel
> that uses a single rtc driver?
I would
> trivia:
Actually not. See my answer to Arnd. I have patches for 4 users of
struct tm, but it should be converted first to struct rtc_time first
(otherwise it might uglify the code due to endianess of tm_year
memeber)
>
> Aren't there also uses of struct tm that are
> nearly identical?
>
> e.g.: drivers/usb/host/xhci-tegra.c
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox