Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1661309 > unrolled thread
| Started by | Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
|---|---|
| First post | 2017-06-08 16:10 +0200 |
| Last post | 2017-06-09 07:10 +0200 |
| Articles | 4 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv] Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2017-06-08 16:10 +0200
Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv] Joe Perches <joe@perches.com> - 2017-06-08 17:00 +0200
Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv] Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-06-08 17:10 +0200
Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv] Joe Perches <joe@perches.com> - 2017-06-09 07:10 +0200
| From | Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
|---|---|
| Date | 2017-06-08 16:10 +0200 |
| Subject | [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv] |
| Message-ID | <tQ5Z1-4WL-35@gated-at.bofh.it> |
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. Andy Shevchenko (25): lib/vsprintf: Remove useless NULL checks lib/vsprintf: Make decspec global lib/vsprintf: Make strspec global lib/vsprintf: Print time and date in human readable format via %pt ds1302: Switch to use %pt rtc: Switch to use %pt rtc: at91rm9200: Switch to use %pt rtc: at91sam9: Switch to use %pt rtc: m41t80: Switch to use %pt rtc: m48t59: Switch to use %pt rtc: mcp795: Switch to use %pt rtc: pcf50633: Switch to use %pt rtc: pic32: Switch to use %pt rtc: pm8xxx: Switch to use %pt rtc: puv3: Switch to use %pt rtc: rk808: Switch to use %pt rtc: rx6110: Switch to use %pt rtc: rx8025: Switch to use %pt rtc: s3c: Switch to use %pt rtc: s5m: Switch to use %pt rtc: tegra: Switch to use %pt mk68/mac: Switch to use %pt Input: hp_sdc_rtc - Switch to use %pt kdb: Switch to use %pt PM: Switch to use %pt Documentation/printk-formats.txt | 17 ++++ arch/m68k/mac/misc.c | 8 +- drivers/base/power/trace.c | 4 +- drivers/char/ds1302.c | 38 +++------ drivers/char/rtc.c | 7 +- drivers/input/misc/hp_sdc_rtc.c | 8 +- drivers/rtc/hctosys.c | 8 +- drivers/rtc/interface.c | 8 +- drivers/rtc/rtc-at91rm9200.c | 16 +--- drivers/rtc/rtc-at91sam9.c | 16 +--- drivers/rtc/rtc-m41t80.c | 6 +- drivers/rtc/rtc-m48t59.c | 8 +- drivers/rtc/rtc-mcp795.c | 18 ++--- drivers/rtc/rtc-pcf50633.c | 8 +- drivers/rtc/rtc-pic32.c | 18 +---- drivers/rtc/rtc-pm8xxx.c | 16 ++-- drivers/rtc/rtc-proc.c | 36 ++------- drivers/rtc/rtc-puv3.c | 18 +---- drivers/rtc/rtc-rk808.c | 20 ++--- drivers/rtc/rtc-rx6110.c | 12 +-- drivers/rtc/rtc-rx8025.c | 19 +---- drivers/rtc/rtc-s3c.c | 21 ++--- drivers/rtc/rtc-s5m.c | 27 ++----- drivers/rtc/rtc-sysfs.c | 12 +-- drivers/rtc/rtc-tegra.c | 30 +------ kernel/debug/kdb/kdb_main.c | 7 +- lib/vsprintf.c | 167 ++++++++++++++++++++++++++++++++------- 27 files changed, 248 insertions(+), 325 deletions(-) -- 2.11.0
[toc] | [next] | [standalone]
| From | Joe Perches <joe@perches.com> |
|---|---|
| Date | 2017-06-08 17:00 +0200 |
| Message-ID | <tQ74J-5AT-1@gated-at.bofh.it> |
| In reply to | #1661309 |
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? What is the size impact on an embedded kernel that uses a single rtc driver? trivia: Aren't there also uses of struct tm that are nearly identical? e.g.: drivers/usb/host/xhci-tegra.c
[toc] | [prev] | [next] | [standalone]
| From | Andy Shevchenko <andy.shevchenko@gmail.com> |
|---|---|
| Date | 2017-06-08 17:10 +0200 |
| Message-ID | <tQ7ep-5TV-3@gated-at.bofh.it> |
| In reply to | #1661353 |
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
[toc] | [prev] | [next] | [standalone]
| From | Joe Perches <joe@perches.com> |
|---|---|
| Date | 2017-06-09 07:10 +0200 |
| Message-ID | <tQklk-5JZ-21@gated-at.bofh.it> |
| In reply to | #1661360 |
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?
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web