[PATCH v3 0/3] lib/vsprintf: Introduce %ptT for time64_t

[PATCH v3 0/3] lib/vsprintf: Introduce %ptT for time64_t

[Andy Shevchenko]

It is a logical continuation of previously applied %ptR for struct rtc_time.
We have few users of time64_t that would like to print it.

Andrew, since Petr can't pay attention on this perhaps it can be passed thru
your tree?

Sergey, Steven, what do you think?

In v3:
- added tag (Alexandre)
- dropped for now USB Tegra patch (Thierry wasn't clear about)

In v2:
- drop #ifdef CONFIG_RTC_LIB with time64_to_rtc_time() altogether
  (Petr, Alexandre)
- update default error path message along with test case for it
- add Hans' Ack for patch 3

Andy Shevchenko (3):
  lib/vsprintf: Print time64_t in human readable format
  ARM: bcm2835: Switch to use %ptT
  [media] usb: pulse8-cec: Switch to use %ptT

 Documentation/core-api/printk-formats.rst | 22 ++++++++--------
 drivers/firmware/raspberrypi.c            | 12 +++------
 drivers/media/usb/pulse8-cec/pulse8-cec.c |  6 +----
 lib/test_printf.c                         | 13 +++++++---
 lib/vsprintf.c                            | 31 +++++++++++++++++++++--
 5 files changed, 55 insertions(+), 29 deletions(-)

-- 
2.25.1

[PATCH v3 1/3] lib/vsprintf: Print time64_t in human readable format

[Andy Shevchenko]

There are users which print time and date represented by content of
time64_t type in human readable format.

Instead of open coding that each time introduce %ptT[dt][r] specifier.

Few test cases for %ptT specifier has been added as well.

Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
 Documentation/core-api/printk-formats.rst | 22 ++++++++--------
 lib/test_printf.c                         | 13 +++++++---
 lib/vsprintf.c                            | 31 +++++++++++++++++++++--
 3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst
index 8ebe46b1af39..a407cdd09083 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -468,21 +468,23 @@ Examples (OF)::
 	%pfwf	/ocp@68000000/i2c@48072000/camera@10/port/endpoint - Full name
 	%pfwP	endpoint				- Node name
 
-Time and date (struct rtc_time)
--------------------------------
+Time and date
+-------------
 
 ::
 
-	%ptR		YYYY-mm-ddTHH:MM:SS
-	%ptRd		YYYY-mm-dd
-	%ptRt		HH:MM:SS
-	%ptR[dt][r]
+	%pt[RT]			YYYY-mm-ddTHH:MM:SS
+	%pt[RT]d		YYYY-mm-dd
+	%pt[RT]t		HH:MM:SS
+	%pt[RT][dt][r]
 
-For printing date and time as represented by struct rtc_time structure in
-human readable format.
+For printing date and time as represented by
+	R  struct rtc_time structure
+	T  time64_t type
+in human readable format.
 
-By default year will be incremented by 1900 and month by 1. Use %ptRr (raw)
-to suppress this behaviour.
+By default year will be incremented by 1900 and month by 1.
+Use %pt[RT]r (raw) to suppress this behaviour.
 
 Passed by reference.
 
diff --git a/lib/test_printf.c b/lib/test_printf.c
index 2d9f520d2f27..6dc0a6c33b8c 100644
--- a/lib/test_printf.c
+++ b/lib/test_printf.c
@@ -478,7 +478,7 @@ struct_va_format(void)
 }
 
 static void __init
-struct_rtc_time(void)
+time_and_date(void)
 {
 	/* 1543210543 */
 	const struct rtc_time tm = {
@@ -489,14 +489,21 @@ struct_rtc_time(void)
 		.tm_mon = 10,
 		.tm_year = 118,
 	};
+	/* 2019-01-04T15:32:23 */
+	time64_t t = 1546615943;
 
-	test("(%ptR?)", "%pt", &tm);
+	test("(%pt?)", "%pt", &tm);
 	test("2018-11-26T05:35:43", "%ptR", &tm);
 	test("0118-10-26T05:35:43", "%ptRr", &tm);
 	test("05:35:43|2018-11-26", "%ptRt|%ptRd", &tm, &tm);
 	test("05:35:43|0118-10-26", "%ptRtr|%ptRdr", &tm, &tm);
 	test("05:35:43|2018-11-26", "%ptRttr|%ptRdtr", &tm, &tm);
 	test("05:35:43 tr|2018-11-26 tr", "%ptRt tr|%ptRd tr", &tm, &tm);
+
+	test("2019-01-04T15:32:23", "%ptT", &t);
+	test("0119-00-04T15:32:23", "%ptTr", &t);
+	test("15:32:23|2019-01-04", "%ptTt|%ptTd", &t, &t);
+	test("15:32:23|0119-00-04", "%ptTtr|%ptTdr", &t, &t);
 }
 
 static void __init
@@ -661,7 +668,7 @@ test_pointer(void)
 	uuid();
 	dentry();
 	struct_va_format();
-	struct_rtc_time();
+	time_and_date();
 	struct_clk();
 	bitmap();
 	netdev_features();
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 7c488a1ce318..adbcca9c9cba 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -34,6 +34,7 @@
 #include <linux/dcache.h>
 #include <linux/cred.h>
 #include <linux/rtc.h>
+#include <linux/time.h>
 #include <linux/uuid.h>
 #include <linux/of.h>
 #include <net/addrconf.h>
@@ -1819,6 +1820,29 @@ char *rtc_str(char *buf, char *end, const struct rtc_time *tm,
 	return buf;
 }
 
+static noinline_for_stack
+char *time64_str(char *buf, char *end, const time64_t time,
+		 struct printf_spec spec, const char *fmt)
+{
+	struct rtc_time rtc_time;
+	struct tm tm;
+
+	time64_to_tm(time, 0, &tm);
+
+	rtc_time.tm_sec = tm.tm_sec;
+	rtc_time.tm_min = tm.tm_min;
+	rtc_time.tm_hour = tm.tm_hour;
+	rtc_time.tm_mday = tm.tm_mday;
+	rtc_time.tm_mon = tm.tm_mon;
+	rtc_time.tm_year = tm.tm_year;
+	rtc_time.tm_wday = tm.tm_wday;
+	rtc_time.tm_yday = tm.tm_yday;
+
+	rtc_time.tm_isdst = 0;
+
+	return rtc_str(buf, end, &rtc_time, spec, fmt);
+}
+
 static noinline_for_stack
 char *time_and_date(char *buf, char *end, void *ptr, struct printf_spec spec,
 		    const char *fmt)
@@ -1826,8 +1850,10 @@ char *time_and_date(char *buf, char *end, void *ptr, struct printf_spec spec,
 	switch (fmt[1]) {
 	case 'R':
 		return rtc_str(buf, end, (const struct rtc_time *)ptr, spec, fmt);
+	case 'T':
+		return time64_str(buf, end, *(const time64_t *)ptr, spec, fmt);
 	default:
-		return error_string(buf, end, "(%ptR?)", spec);
+		return error_string(buf, end, "(%pt?)", spec);
 	}
 }
 
@@ -2143,8 +2169,9 @@ char *fwnode_string(char *buf, char *end, struct fwnode_handle *fwnode,
  * - 'd[234]' For a dentry name (optionally 2-4 last components)
  * - 'D[234]' Same as 'd' but for a struct file
  * - 'g' For block_device name (gendisk + partition number)
- * - 't[R][dt][r]' For time and date as represented:
+ * - 't[RT][dt][r]' For time and date as represented by:
  *      R    struct rtc_time
+ *      T    time64_t
  * - 'C' For a clock, it prints the name (Common Clock Framework) or address
  *       (legacy clock framework) of the clock
  * - 'Cn' For a clock, it prints the name (Common Clock Framework) or address
-- 
2.25.1

[PATCH v3 2/3] ARM: bcm2835: Switch to use %ptT

[Andy Shevchenko]

Use %ptT instead of open coded variant to print content of
time64_t type in human readable format.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/firmware/raspberrypi.c | 12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index da26a584dca0..a3e85186f8e6 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -182,16 +182,10 @@ rpi_firmware_print_firmware_revision(struct rpi_firmware *fw)
 					RPI_FIRMWARE_GET_FIRMWARE_REVISION,
 					&packet, sizeof(packet));
 
-	if (ret == 0) {
-		struct tm tm;
-
-		time64_to_tm(packet, 0, &tm);
+	if (ret)
+		return;
 
-		dev_info(fw->cl.dev,
-			 "Attached to firmware from %04ld-%02d-%02d %02d:%02d\n",
-			 tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
-			 tm.tm_hour, tm.tm_min);
-	}
+	dev_info(fw->cl.dev, "Attached to firmware from %ptT\n", &packet);
 }
 
 static void
-- 
2.25.1

[PATCH v3 3/3] [media] usb: pulse8-cec: Switch to use %ptT

[Andy Shevchenko]

Use %ptT instead of open coded variant to print content of
time64_t type in human readable format.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
---
 drivers/media/usb/pulse8-cec/pulse8-cec.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/media/usb/pulse8-cec/pulse8-cec.c b/drivers/media/usb/pulse8-cec/pulse8-cec.c
index 0655aa9ecf28..beae6aa12638 100644
--- a/drivers/media/usb/pulse8-cec/pulse8-cec.c
+++ b/drivers/media/usb/pulse8-cec/pulse8-cec.c
@@ -661,7 +661,6 @@ static int pulse8_setup(struct pulse8 *pulse8, struct serio *serio,
 	u8 *data = pulse8->data + 1;
 	u8 cmd[2];
 	int err;
-	struct tm tm;
 	time64_t date;
 
 	pulse8->vers = 0;
@@ -682,10 +681,7 @@ static int pulse8_setup(struct pulse8 *pulse8, struct serio *serio,
 	if (err)
 		return err;
 	date = (data[0] << 24) | (data[1] << 16) | (data[2] << 8) | data[3];
-	time64_to_tm(date, 0, &tm);
-	dev_info(pulse8->dev, "Firmware build date %04ld.%02d.%02d %02d:%02d:%02d\n",
-		 tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
-		 tm.tm_hour, tm.tm_min, tm.tm_sec);
+	dev_info(pulse8->dev, "Firmware build date %ptT\n", &date);
 
 	dev_dbg(pulse8->dev, "Persistent config:\n");
 	cmd[0] = MSGCODE_GET_AUTO_ENABLED;
-- 
2.25.1

Re: [PATCH v3 0/3] lib/vsprintf: Introduce %ptT for time64_t

[Steven Rostedt]

On Wed, 15 Apr 2020 20:00:43 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> It is a logical continuation of previously applied %ptR for struct rtc_time.
> We have few users of time64_t that would like to print it.
> 
> Andrew, since Petr can't pay attention on this perhaps it can be passed thru
> your tree?
> 
> Sergey, Steven, what do you think?

I'm fine with these changes. Sergey, what do you think?

-- Steve

Re: [PATCH v3 1/3] lib/vsprintf: Print time64_t in human readable format

[Sergey Senozhatsky]

On (20/04/15 20:00), Andy Shevchenko wrote:
[..]
>  #include <linux/of.h>
>  #include <net/addrconf.h>
> @@ -1819,6 +1820,29 @@ char *rtc_str(char *buf, char *end, const struct rtc_time *tm,
>  	return buf;
>  }
>  
> +static noinline_for_stack
> +char *time64_str(char *buf, char *end, const time64_t time,
> +		 struct printf_spec spec, const char *fmt)
> +{
> +	struct rtc_time rtc_time;
> +	struct tm tm;
> +
> +	time64_to_tm(time, 0, &tm);
> +
> +	rtc_time.tm_sec = tm.tm_sec;
> +	rtc_time.tm_min = tm.tm_min;
> +	rtc_time.tm_hour = tm.tm_hour;
> +	rtc_time.tm_mday = tm.tm_mday;
> +	rtc_time.tm_mon = tm.tm_mon;
> +	rtc_time.tm_year = tm.tm_year;
> +	rtc_time.tm_wday = tm.tm_wday;
> +	rtc_time.tm_yday = tm.tm_yday;
> +
> +	rtc_time.tm_isdst = 0;

Here you convert time64_t (signed, we also have unsigned version - timeu64_t)
to tm first and then convert tm to rtc_time. Will rtc_time64_to_tm() do the
trick?

	-ss

Re: [PATCH v3 0/3] lib/vsprintf: Introduce %ptT for time64_t

[Sergey Senozhatsky]

On (20/04/15 13:20), Steven Rostedt wrote:
> On Wed, 15 Apr 2020 20:00:43 +0300
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> 
> > It is a logical continuation of previously applied %ptR for struct rtc_time.
> > We have few users of time64_t that would like to print it.
> > 
> > Andrew, since Petr can't pay attention on this perhaps it can be passed thru
> > your tree?
> > 
> > Sergey, Steven, what do you think?
> 
> I'm fine with these changes. Sergey, what do you think?

I'm not against it in general, I'm slightly concerned if "two users"
is enough of a justification for new vsprintf() specifier.

	-ss

Re: [PATCH v3 0/3] lib/vsprintf: Introduce %ptT for time64_t

[Joe Perches]

On Thu, 2020-04-16 at 11:34 +0900, Sergey Senozhatsky wrote:
> On (20/04/15 13:20), Steven Rostedt wrote:
> > On Wed, 15 Apr 2020 20:00:43 +0300
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > 
> > > It is a logical continuation of previously applied %ptR for struct rtc_time.
> > > We have few users of time64_t that would like to print it.
> > > 
> > > Andrew, since Petr can't pay attention on this perhaps it can be passed thru
> > > your tree?
> > > 
> > > Sergey, Steven, what do you think?
> > 
> > I'm fine with these changes. Sergey, what do you think?
> 
> I'm not against it in general, I'm slightly concerned if "two users"
> is enough of a justification for new vsprintf() specifier.

Me too as separate functions could be used here.

Re: [PATCH v3 2/3] ARM: bcm2835: Switch to use %ptT

[Sergey Senozhatsky]

On (20/04/15 20:00), Andy Shevchenko wrote:
[..]
> diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> index da26a584dca0..a3e85186f8e6 100644
> --- a/drivers/firmware/raspberrypi.c
> +++ b/drivers/firmware/raspberrypi.c
> @@ -182,16 +182,10 @@ rpi_firmware_print_firmware_revision(struct rpi_firmware *fw)
>  					RPI_FIRMWARE_GET_FIRMWARE_REVISION,
>  					&packet, sizeof(packet));
>  
> -	if (ret == 0) {
> -		struct tm tm;
> -
> -		time64_to_tm(packet, 0, &tm);
> +	if (ret)
> +		return;
>  
> -		dev_info(fw->cl.dev,
> -			 "Attached to firmware from %04ld-%02d-%02d %02d:%02d\n",
> -			 tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
> -			 tm.tm_hour, tm.tm_min);
> -	}
> +	dev_info(fw->cl.dev, "Attached to firmware from %ptT\n", &packet);
>  }

So can this be instead:

	struct rtc_time tm;

	rtc_time64_to_tm(time, &tm);
	dev_info(.... "%ptR", &tm);

?

If it can, then I'd probably say something like "can we then just use
rtc_time64_to_tm()"?

	-ss

Re: [PATCH v3 2/3] ARM: bcm2835: Switch to use %ptT

[Sergey Senozhatsky]

On (20/04/16 11:53), Sergey Senozhatsky wrote:
> > +	if (ret)
> > +		return;
> >  
> > -		dev_info(fw->cl.dev,
> > -			 "Attached to firmware from %04ld-%02d-%02d %02d:%02d\n",
> > -			 tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
> > -			 tm.tm_hour, tm.tm_min);
> > -	}
> > +	dev_info(fw->cl.dev, "Attached to firmware from %ptT\n", &packet);
> >  }
> 
> So can this be instead:
> 
> 	struct rtc_time tm;
> 
> 	rtc_time64_to_tm(time, &tm);
> 	dev_info(.... "%ptR", &tm);
                       ^^^^
			%ptRdt  ?

P.S. I wonder what's the longest English word which can be constructed
from a valid vsprintf() specifiers sequence (consecutive specifiers).

	-ss

Re: [PATCH v3 0/3] lib/vsprintf: Introduce %ptT for time64_t

[Andy Shevchenko]

On Wed, Apr 15, 2020 at 07:46:27PM -0700, Joe Perches wrote:
> On Thu, 2020-04-16 at 11:34 +0900, Sergey Senozhatsky wrote:
> > On (20/04/15 13:20), Steven Rostedt wrote:
> > > On Wed, 15 Apr 2020 20:00:43 +0300
> > > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > 
> > > > It is a logical continuation of previously applied %ptR for struct rtc_time.
> > > > We have few users of time64_t that would like to print it.
> > > > 
> > > > Andrew, since Petr can't pay attention on this perhaps it can be passed thru
> > > > your tree?
> > > > 
> > > > Sergey, Steven, what do you think?
> > > 
> > > I'm fine with these changes. Sergey, what do you think?
> > 
> > I'm not against it in general, I'm slightly concerned if "two users"
> > is enough of a justification for new vsprintf() specifier.
> 
> Me too as separate functions could be used here.

If we drop T in favour of ' ' (space) as delimiter, we will immediately get 5
or 6 users (I didn't check for new ones during last couple of years though).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 1/3] lib/vsprintf: Print time64_t in human readable format

[Andy Shevchenko]

On Thu, Apr 16, 2020 at 11:32:19AM +0900, Sergey Senozhatsky wrote:
> On (20/04/15 20:00), Andy Shevchenko wrote:
> [..]
> >  #include <linux/of.h>
> >  #include <net/addrconf.h>
> > @@ -1819,6 +1820,29 @@ char *rtc_str(char *buf, char *end, const struct rtc_time *tm,
> >  	return buf;
> >  }
> >  
> > +static noinline_for_stack
> > +char *time64_str(char *buf, char *end, const time64_t time,
> > +		 struct printf_spec spec, const char *fmt)
> > +{
> > +	struct rtc_time rtc_time;
> > +	struct tm tm;
> > +
> > +	time64_to_tm(time, 0, &tm);
> > +
> > +	rtc_time.tm_sec = tm.tm_sec;
> > +	rtc_time.tm_min = tm.tm_min;
> > +	rtc_time.tm_hour = tm.tm_hour;
> > +	rtc_time.tm_mday = tm.tm_mday;
> > +	rtc_time.tm_mon = tm.tm_mon;
> > +	rtc_time.tm_year = tm.tm_year;
> > +	rtc_time.tm_wday = tm.tm_wday;
> > +	rtc_time.tm_yday = tm.tm_yday;
> > +
> > +	rtc_time.tm_isdst = 0;
> 
> Here you convert time64_t (signed, we also have unsigned version - timeu64_t)
> to tm first and then convert tm to rtc_time. Will rtc_time64_to_tm() do the
> trick?

You missed v2 round. The RTC is configuration dependent and Alexandre in favour
of removing those from RTC completely by replacing with always enabled
time64_to_tm().

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 2/3] ARM: bcm2835: Switch to use %ptT

[Andy Shevchenko]

On Thu, Apr 16, 2020 at 11:53:58AM +0900, Sergey Senozhatsky wrote:
> On (20/04/15 20:00), Andy Shevchenko wrote:
> [..]
> > diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> > index da26a584dca0..a3e85186f8e6 100644
> > --- a/drivers/firmware/raspberrypi.c
> > +++ b/drivers/firmware/raspberrypi.c
> > @@ -182,16 +182,10 @@ rpi_firmware_print_firmware_revision(struct rpi_firmware *fw)
> >  					RPI_FIRMWARE_GET_FIRMWARE_REVISION,
> >  					&packet, sizeof(packet));
> >  
> > -	if (ret == 0) {
> > -		struct tm tm;
> > -
> > -		time64_to_tm(packet, 0, &tm);
> > +	if (ret)
> > +		return;
> >  
> > -		dev_info(fw->cl.dev,
> > -			 "Attached to firmware from %04ld-%02d-%02d %02d:%02d\n",
> > -			 tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
> > -			 tm.tm_hour, tm.tm_min);
> > -	}
> > +	dev_info(fw->cl.dev, "Attached to firmware from %ptT\n", &packet);
> >  }
> 
> So can this be instead:
> 
> 	struct rtc_time tm;
> 
> 	rtc_time64_to_tm(time, &tm);
> 	dev_info(.... "%ptR", &tm);
> 
> ?
> 
> If it can, then I'd probably say something like "can we then just use
> rtc_time64_to_tm()"?

Same comment as per previous patch (TL;DR: no, it can't).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 1/3] lib/vsprintf: Print time64_t in human readable format

[Sergey Senozhatsky]

On (20/04/21 16:08), Andy Shevchenko wrote:
[..]
> > Here you convert time64_t (signed, we also have unsigned version - timeu64_t)
> > to tm first and then convert tm to rtc_time. Will rtc_time64_to_tm() do the
> > trick?
>
> You missed v2 round. The RTC is configuration dependent and Alexandre in favour
> of removing those from RTC completely by replacing with always enabled
> time64_to_tm().

I see.
I don't think I was Cc-ed on v1/v2.

	-ss

Re: [PATCH v3 1/3] lib/vsprintf: Print time64_t in human readable format

[Andy Shevchenko]

On Thu, Apr 23, 2020 at 10:54:31AM +0900, Sergey Senozhatsky wrote:
> On (20/04/21 16:08), Andy Shevchenko wrote:
> [..]
> > > Here you convert time64_t (signed, we also have unsigned version - timeu64_t)
> > > to tm first and then convert tm to rtc_time. Will rtc_time64_to_tm() do the
> > > trick?
> >
> > You missed v2 round. The RTC is configuration dependent and Alexandre in favour
> > of removing those from RTC completely by replacing with always enabled
> > time64_to_tm().
> 
> I see.
> I don't think I was Cc-ed on v1/v2.

It was in v1 [1], but yes, by some reason you were not in Cc, my apology.

[1]: https://lore.kernel.org/patchwork/patch/1029110/

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 0/3] lib/vsprintf: Introduce %ptT for time64_t

[Petr Mladek]

On Wed 2020-04-15 20:00:43, Andy Shevchenko wrote:
> It is a logical continuation of previously applied %ptR for struct rtc_time.
> We have few users of time64_t that would like to print it.

It seems that everything was explained and the patches look good to
me. If we allowed %ptR then it makes sense to allow %ptT as well.

For all three patches:

Rewieved-by: Petr Mladek <pmladek@suse.com>

Best Regards,
Petr

Re: [PATCH v3 0/3] lib/vsprintf: Introduce %ptT for time64_t

[Sergey Senozhatsky]

On (20/05/15 18:02), Petr Mladek wrote:
> On Wed 2020-04-15 20:00:43, Andy Shevchenko wrote:
> > It is a logical continuation of previously applied %ptR for struct rtc_time.
> > We have few users of time64_t that would like to print it.
> 
> It seems that everything was explained and the patches look good to
> me. If we allowed %ptR then it makes sense to allow %ptT as well.
> 
> For all three patches:
> 
> Rewieved-by: Petr Mladek <pmladek@suse.com>

Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>

	-ss

Re: [PATCH v3 0/3] lib/vsprintf: Introduce %ptT for time64_t

[Petr Mladek]

On Wed 2020-05-20 20:43:33, Sergey Senozhatsky wrote:
> On (20/05/15 18:02), Petr Mladek wrote:
> > On Wed 2020-04-15 20:00:43, Andy Shevchenko wrote:
> > > It is a logical continuation of previously applied %ptR for struct rtc_time.
> > > We have few users of time64_t that would like to print it.
> > 
> > It seems that everything was explained and the patches look good to
> > me. If we allowed %ptR then it makes sense to allow %ptT as well.
> > 
> > For all three patches:
> > 
> > Rewieved-by: Petr Mladek <pmladek@suse.com>
> 
> Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>

This patchset has been committed into printk/linux.git,
branch for-5.8-printf-time64_t.

Note that it is a new git repo with shared write access.

Best Regards,
Petr

Re: [PATCH v3 2/3] ARM: bcm2835: Switch to use %ptT

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

Hi,

On Wed, 2020-04-15 at 20:00 +0300, Andy Shevchenko wrote:
> Use %ptT instead of open coded variant to print content of
> time64_t type in human readable format.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---

as originally reported by Stefan Wahren, this patch is likely to be the cause
for a regression on RPi3b+ 32bit mode (multi_v7_defconfig,
5.8.0-rc1-00019-ga5dc8300df75):

[    3.759892] raspberrypi-firmware soc:firmware: Attached to firmware from 18446744073709048425-02-19T15:52:16

Whereas the same doesn't seem to happen in 64bit mode:

[    1.584126] raspberrypi-firmware soc:firmware: Attached to firmware from 2020-02-12T12:39:27

Regards,
Nicolas



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 2/3] ARM: bcm2835: Switch to use %ptT

[Andy Shevchenko]

On Tue, Jun 16, 2020 at 05:53:23PM +0200, Nicolas Saenz Julienne wrote:
> On Wed, 2020-04-15 at 20:00 +0300, Andy Shevchenko wrote:
> > Use %ptT instead of open coded variant to print content of
> > time64_t type in human readable format.
> > 
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > ---
> 
> as originally reported by Stefan Wahren, this patch is likely to be the cause
> for a regression on RPi3b+ 32bit mode (multi_v7_defconfig,
> 5.8.0-rc1-00019-ga5dc8300df75):
> 
> [    3.759892] raspberrypi-firmware soc:firmware: Attached to firmware from 18446744073709048425-02-19T15:52:16
> 
> Whereas the same doesn't seem to happen in 64bit mode:
> 
> [    1.584126] raspberrypi-firmware soc:firmware: Attached to firmware from 2020-02-12T12:39:27

Had you chance to run test_printf on that machine and see if it reports any failure?
If no, can you provide a raw date which makes this happen?

Ah, I think I have an idea what is going on... stay tuned!

Does below fix it?

--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -181,6 +181,7 @@ EXPORT_SYMBOL_GPL(rpi_firmware_property);
 static void
 rpi_firmware_print_firmware_revision(struct rpi_firmware *fw)
 {
+	time64_t date_and_time;
 	u32 packet;
 	int ret = rpi_firmware_property(fw,
 					RPI_FIRMWARE_GET_FIRMWARE_REVISION,
@@ -189,7 +190,8 @@ rpi_firmware_print_firmware_revision(struct rpi_firmware *fw)
 	if (ret)
 		return;
 
-	dev_info(fw->cl.dev, "Attached to firmware from %ptT\n", &packet);
+	date_and_time = packet;
+	dev_info(fw->cl.dev, "Attached to firmware from %ptT\n", &date_and_time);
 }

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 2/3] ARM: bcm2835: Switch to use %ptT

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]

On Tue, 2020-06-16 at 19:13 +0300, Andy Shevchenko wrote:
> On Tue, Jun 16, 2020 at 05:53:23PM +0200, Nicolas Saenz Julienne wrote:
> > On Wed, 2020-04-15 at 20:00 +0300, Andy Shevchenko wrote:
> > > Use %ptT instead of open coded variant to print content of
> > > time64_t type in human readable format.
> > > 
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > ---
> > 
> > as originally reported by Stefan Wahren, this patch is likely to be the
> > cause
> > for a regression on RPi3b+ 32bit mode (multi_v7_defconfig,
> > 5.8.0-rc1-00019-ga5dc8300df75):
> > 
> > [    3.759892] raspberrypi-firmware soc:firmware: Attached to firmware from
> > 18446744073709048425-02-19T15:52:16
> > 
> > Whereas the same doesn't seem to happen in 64bit mode:
> > 
> > [    1.584126] raspberrypi-firmware soc:firmware: Attached to firmware from
> > 2020-02-12T12:39:27
> 
> Had you chance to run test_printf on that machine and see if it reports any
> failure?
> If no, can you provide a raw date which makes this happen?
> 
> Ah, I think I have an idea what is going on... stay tuned!
> 
> Does below fix it?

Yes :)

> --- a/drivers/firmware/raspberrypi.c
> +++ b/drivers/firmware/raspberrypi.c
> @@ -181,6 +181,7 @@ EXPORT_SYMBOL_GPL(rpi_firmware_property);
>  static void
>  rpi_firmware_print_firmware_revision(struct rpi_firmware *fw)
>  {
> +	time64_t date_and_time;
>  	u32 packet;
>  	int ret = rpi_firmware_property(fw,
>  					RPI_FIRMWARE_GET_FIRMWARE_REVISION,
> @@ -189,7 +190,8 @@ rpi_firmware_print_firmware_revision(struct rpi_firmware
> *fw)
>  	if (ret)
>  		return;
>  
> -	dev_info(fw->cl.dev, "Attached to firmware from %ptT\n", &packet);
> +	date_and_time = packet;
> +	dev_info(fw->cl.dev, "Attached to firmware from %ptT\n",
> &date_and_time);
>  }
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 2/3] ARM: bcm2835: Switch to use %ptT

[Andy Shevchenko]

On Tue, Jun 16, 2020 at 06:22:17PM +0200, Nicolas Saenz Julienne wrote:
> On Tue, 2020-06-16 at 19:13 +0300, Andy Shevchenko wrote:
> > On Tue, Jun 16, 2020 at 05:53:23PM +0200, Nicolas Saenz Julienne wrote:
> > > On Wed, 2020-04-15 at 20:00 +0300, Andy Shevchenko wrote:
> > > > Use %ptT instead of open coded variant to print content of
> > > > time64_t type in human readable format.
> > > > 
> > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > > ---
> > > 
> > > as originally reported by Stefan Wahren, this patch is likely to be the
> > > cause
> > > for a regression on RPi3b+ 32bit mode (multi_v7_defconfig,
> > > 5.8.0-rc1-00019-ga5dc8300df75):
> > > 
> > > [    3.759892] raspberrypi-firmware soc:firmware: Attached to firmware from
> > > 18446744073709048425-02-19T15:52:16
> > > 
> > > Whereas the same doesn't seem to happen in 64bit mode:
> > > 
> > > [    1.584126] raspberrypi-firmware soc:firmware: Attached to firmware from
> > > 2020-02-12T12:39:27
> > 
> > Had you chance to run test_printf on that machine and see if it reports any
> > failure?
> > If no, can you provide a raw date which makes this happen?
> > 
> > Ah, I think I have an idea what is going on... stay tuned!
> > 
> > Does below fix it?
> 
> Yes :)

Patch has been just sent. I hope it can go via printk tree, because MAINTAINERS keeps silent for this file.

-- 
With Best Regards,
Andy Shevchenko