From: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
To: Alexandre Belloni
<alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Russell King - ARM Linux
<linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>,
Benjamin Gaignard
<benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>,
"patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org"
<patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>,
Linus Walleij
<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
<x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Jonathan Hunter
<jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>,
Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Sylvain Lemieux
<slemieux.tyco-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Sebastian Hesselbarth
<sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org"
<linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>,
Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
"rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org"
<rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>,
"linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-pm-u79uwXL29TaqPxH82wqD4g@public.gmane.org>
Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
Date: Wed, 21 Jun 2017 20:08:47 +0200 [thread overview]
Message-ID: <20170621180847.GA24175@amd> (raw)
In-Reply-To: <20170621123535.b5fvwlydfhnhuqll-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2294 bytes --]
Hi!
> > > Or not, having an RTC set in the past is actually quite common. I'd find
> > > it weird to have a new device boot and be set to a date in the future.
> >
> > ...but still better than board stuck in the past, no?
> >
> > > Also note that the threshold or offset thing may seem like a good idea
> > > but fails with many RTCs because of how they handle leap years.
> >
> > Well, you can still convert time from rtc to unix time, then do adjustment
> > there.
> >
>
> You can only if your machine is running when that happens. If that is
> not the case, then you lost and your time is not correct anymore.
I don't see why that should be a case... as long as you know what RTC
does in event of overflow, and it is not something completely crazy.
> > Anyway, I guess it would be cool for rtc drivers to annotate what limits
> > underlying storage has to the common code, so that we can do fixups once
> > per class, not once per driver.
>
> Yes, I'm in the middle of the whole rework that allows that.
>
> I don't understand the sudden urgency of fixing that and the amount of
> bikeshedding, seeing that the closest cutoff date is actually 31st of
> december 2069 in the rtc subsystem and that anyway the current 32bit
> userspace will explode in february 2038.
>
> My plan from the beginning was to have something for the next stable. I
> know nobody can read my mind but again, I don't think there is currently
> any urgency to change anything.
Yes, mind reading is a problem. I can only read minds of ferungulates,
and only if they are physicaly near me :-).
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
Benjamin Gaignard <benjamin.gaignard@linaro.org>,
Baruch Siach <baruch@tkos.co.il>,
"patches@opensource.wolfsonmicro.com"
<patches@opensource.wolfsonmicro.com>,
Linus Walleij <linus.walleij@linaro.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
"x86@kernel.org" <x86@kernel.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
Chen-Yu Tsai <wens@csie.org>, Ingo Molnar <mingo@redhat.com>,
Sylvain Lemieux <slemieux.tyco@gmail.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Len Brown <len.brown@intel.com>,
"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
Jason Cooper <jason@lakedaemon.net>,
"rtc-linux@googlegroups.com" <rtc-linux@googlegroups.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Hans Ulli Kroll <ulli.kroll@googlemail.com>,
"adi-buildroot-devel@lists.sourceforge.net"
<adi-buildroot-devel@lists.sourceforge.net>,
Vladimir Zapolskiy <vz@mleia.com>,
John Stultz <john.stultz@linaro.org>,
Gregory Clement <gregory.clement@free-electrons.com>,
Michael Chan <michael.chan@broadcom.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Alessandro Zummo <a.zummo@towertech.it>,
Barry Song <baohua@kernel.org>,
Support Opensource <Support.Opensource@diasemi.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Steve Twiss <stwiss.opensource@diasemi.com>,
Maxime Ripard <maxime.ripard@free-electrons.com>
Subject: [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
Date: Wed, 21 Jun 2017 20:08:47 +0200 [thread overview]
Message-ID: <20170621180847.GA24175@amd> (raw)
In-Reply-To: <20170621123535.b5fvwlydfhnhuqll@piout.net>
[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]
Hi!
> > > Or not, having an RTC set in the past is actually quite common. I'd find
> > > it weird to have a new device boot and be set to a date in the future.
> >
> > ...but still better than board stuck in the past, no?
> >
> > > Also note that the threshold or offset thing may seem like a good idea
> > > but fails with many RTCs because of how they handle leap years.
> >
> > Well, you can still convert time from rtc to unix time, then do adjustment
> > there.
> >
>
> You can only if your machine is running when that happens. If that is
> not the case, then you lost and your time is not correct anymore.
I don't see why that should be a case... as long as you know what RTC
does in event of overflow, and it is not something completely crazy.
> > Anyway, I guess it would be cool for rtc drivers to annotate what limits
> > underlying storage has to the common code, so that we can do fixups once
> > per class, not once per driver.
>
> Yes, I'm in the middle of the whole rework that allows that.
>
> I don't understand the sudden urgency of fixing that and the amount of
> bikeshedding, seeing that the closest cutoff date is actually 31st of
> december 2069 in the rtc subsystem and that anyway the current 32bit
> userspace will explode in february 2038.
>
> My plan from the beginning was to have something for the next stable. I
> know nobody can read my mind but again, I don't think there is currently
> any urgency to change anything.
Yes, mind reading is a problem. I can only read minds of ferungulates,
and only if they are physicaly near me :-).
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: pavel@ucw.cz (Pavel Machek)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/51] rtc: stop using rtc deprecated functions
Date: Wed, 21 Jun 2017 20:08:47 +0200 [thread overview]
Message-ID: <20170621180847.GA24175@amd> (raw)
In-Reply-To: <20170621123535.b5fvwlydfhnhuqll@piout.net>
Hi!
> > > Or not, having an RTC set in the past is actually quite common. I'd find
> > > it weird to have a new device boot and be set to a date in the future.
> >
> > ...but still better than board stuck in the past, no?
> >
> > > Also note that the threshold or offset thing may seem like a good idea
> > > but fails with many RTCs because of how they handle leap years.
> >
> > Well, you can still convert time from rtc to unix time, then do adjustment
> > there.
> >
>
> You can only if your machine is running when that happens. If that is
> not the case, then you lost and your time is not correct anymore.
I don't see why that should be a case... as long as you know what RTC
does in event of overflow, and it is not something completely crazy.
> > Anyway, I guess it would be cool for rtc drivers to annotate what limits
> > underlying storage has to the common code, so that we can do fixups once
> > per class, not once per driver.
>
> Yes, I'm in the middle of the whole rework that allows that.
>
> I don't understand the sudden urgency of fixing that and the amount of
> bikeshedding, seeing that the closest cutoff date is actually 31st of
> december 2069 in the rtc subsystem and that anyway the current 32bit
> userspace will explode in february 2038.
>
> My plan from the beginning was to have something for the next stable. I
> know nobody can read my mind but again, I don't think there is currently
> any urgency to change anything.
Yes, mind reading is a problem. I can only read minds of ferungulates,
and only if they are physicaly near me :-).
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170621/cd332894/attachment.sig>
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
Benjamin Gaignard <benjamin.gaignard@linaro.org>,
Baruch Siach <baruch@tkos.co.il>,
"patches@opensource.wolfsonmicro.com"
<patches@opensource.wolfsonmicro.com>,
Linus Walleij <linus.walleij@linaro.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
"x86@kernel.org" <x86@kernel.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
Chen-Yu Tsai <wens@csie.org>, Ingo Molnar <mingo@redhat.com>,
Sylvain Lemieux <slemieux.tyco@gmail.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Len Brown <len.brown@intel.com>,
"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
Jason Cooper <jason@lakedaemon.net>,
"rtc-linux@googlegroups.com" <rtc-linux@googlegroups.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Hans Ulli Kroll <ulli.kroll@googlemail.com>,
"adi-buildroot-devel@lists.sourceforge.net"
<adi-buildroot-devel@lists.sourceforge.net>,
Vladimir Zapolskiy <vz@mleia.com>,
John Stultz <john.stultz@linaro.org>,
Gregory Clement <gregory.clement@free-electrons.com>,
Michael Chan <michael.chan@broadcom.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Alessandro Zummo <a.zummo@towertech.it>,
Barry Song <baohua@kernel.org>,
Support Opensource <Support.Opensource@diasemi.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Steve Twiss <stwiss.opensource@diasemi.com>,
Maxime Ripard <maxime.ripard@free-electrons.com>
Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
Date: Wed, 21 Jun 2017 20:08:47 +0200 [thread overview]
Message-ID: <20170621180847.GA24175@amd> (raw)
In-Reply-To: <20170621123535.b5fvwlydfhnhuqll@piout.net>
[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]
Hi!
> > > Or not, having an RTC set in the past is actually quite common. I'd find
> > > it weird to have a new device boot and be set to a date in the future.
> >
> > ...but still better than board stuck in the past, no?
> >
> > > Also note that the threshold or offset thing may seem like a good idea
> > > but fails with many RTCs because of how they handle leap years.
> >
> > Well, you can still convert time from rtc to unix time, then do adjustment
> > there.
> >
>
> You can only if your machine is running when that happens. If that is
> not the case, then you lost and your time is not correct anymore.
I don't see why that should be a case... as long as you know what RTC
does in event of overflow, and it is not something completely crazy.
> > Anyway, I guess it would be cool for rtc drivers to annotate what limits
> > underlying storage has to the common code, so that we can do fixups once
> > per class, not once per driver.
>
> Yes, I'm in the middle of the whole rework that allows that.
>
> I don't understand the sudden urgency of fixing that and the amount of
> bikeshedding, seeing that the closest cutoff date is actually 31st of
> december 2069 in the rtc subsystem and that anyway the current 32bit
> userspace will explode in february 2038.
>
> My plan from the beginning was to have something for the next stable. I
> know nobody can read my mind but again, I don't think there is currently
> any urgency to change anything.
Yes, mind reading is a problem. I can only read minds of ferungulates,
and only if they are physicaly near me :-).
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
To: Alexandre Belloni
<alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Russell King - ARM Linux
<linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>,
Benjamin Gaignard
<benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>,
"patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org"
<patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>,
Linus Walleij
<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
<x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Jonathan Hunter
<jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>,
Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Sylvain Lemieux
<slemieux.tyco-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Sebastian Hesselbarth
<sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org"
<linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>,
Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
"rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org"
<rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>,
"linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-pm-u79uwXL29TaqPxH82wqD4g@public.gmane.org
Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
Date: Wed, 21 Jun 2017 20:08:47 +0200 [thread overview]
Message-ID: <20170621180847.GA24175@amd> (raw)
In-Reply-To: <20170621123535.b5fvwlydfhnhuqll-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2294 bytes --]
Hi!
> > > Or not, having an RTC set in the past is actually quite common. I'd find
> > > it weird to have a new device boot and be set to a date in the future.
> >
> > ...but still better than board stuck in the past, no?
> >
> > > Also note that the threshold or offset thing may seem like a good idea
> > > but fails with many RTCs because of how they handle leap years.
> >
> > Well, you can still convert time from rtc to unix time, then do adjustment
> > there.
> >
>
> You can only if your machine is running when that happens. If that is
> not the case, then you lost and your time is not correct anymore.
I don't see why that should be a case... as long as you know what RTC
does in event of overflow, and it is not something completely crazy.
> > Anyway, I guess it would be cool for rtc drivers to annotate what limits
> > underlying storage has to the common code, so that we can do fixups once
> > per class, not once per driver.
>
> Yes, I'm in the middle of the whole rework that allows that.
>
> I don't understand the sudden urgency of fixing that and the amount of
> bikeshedding, seeing that the closest cutoff date is actually 31st of
> december 2069 in the rtc subsystem and that anyway the current 32bit
> userspace will explode in february 2038.
>
> My plan from the beginning was to have something for the next stable. I
> know nobody can read my mind but again, I don't think there is currently
> any urgency to change anything.
Yes, mind reading is a problem. I can only read minds of ferungulates,
and only if they are physicaly near me :-).
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2017-06-21 18:08 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-20 21:35 [PATCH 00/51] rtc: stop using rtc deprecated functions Alexandre Belloni
2017-06-20 21:35 ` Alexandre Belloni
2017-06-20 21:35 ` Alexandre Belloni
2017-06-20 21:35 ` [rtc-linux] " Alexandre Belloni
[not found] ` <20170620213507.urobmtg34vzubrdq-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
2017-06-20 22:00 ` Thomas Gleixner
2017-06-20 22:00 ` Thomas Gleixner
2017-06-20 22:00 ` Thomas Gleixner
2017-06-20 22:00 ` Thomas Gleixner
2017-06-20 22:00 ` [rtc-linux] " Thomas Gleixner
2017-06-20 22:38 ` Russell King - ARM Linux
2017-06-20 22:38 ` Russell King - ARM Linux
2017-06-20 22:38 ` Russell King - ARM Linux
2017-06-20 22:38 ` Russell King - ARM Linux
2017-06-20 22:38 ` [rtc-linux] " Russell King - ARM Linux
2017-06-21 7:51 ` Pavel Machek
2017-06-21 7:51 ` Pavel Machek
2017-06-21 7:51 ` Pavel Machek
2017-06-21 7:51 ` Pavel Machek
2017-06-21 7:51 ` [rtc-linux] " Pavel Machek
2017-06-21 8:39 ` Alexandre Belloni
2017-06-21 8:39 ` Alexandre Belloni
2017-06-21 8:39 ` Alexandre Belloni
2017-06-21 8:39 ` Alexandre Belloni
2017-06-21 8:39 ` [rtc-linux] " Alexandre Belloni
[not found] ` <20170621083907.y3gadsmsoufa5niv-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
2017-06-21 6:34 ` Pavel Machek
2017-06-21 6:34 ` Pavel Machek
2017-06-21 6:34 ` Pavel Machek
2017-06-21 6:34 ` Pavel Machek
2017-06-21 6:34 ` [rtc-linux] " Pavel Machek
2017-06-21 12:35 ` Alexandre Belloni
2017-06-21 12:35 ` Alexandre Belloni
2017-06-21 12:35 ` Alexandre Belloni
2017-06-21 12:35 ` Alexandre Belloni
2017-06-21 12:35 ` [rtc-linux] " Alexandre Belloni
[not found] ` <20170621123535.b5fvwlydfhnhuqll-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
2017-06-21 18:08 ` Pavel Machek [this message]
2017-06-21 18:08 ` Pavel Machek
2017-06-21 18:08 ` Pavel Machek
2017-06-21 18:08 ` Pavel Machek
2017-06-21 18:08 ` [rtc-linux] " Pavel Machek
2017-06-21 9:19 ` Russell King - ARM Linux
2017-06-21 9:19 ` Russell King - ARM Linux
2017-06-21 9:19 ` Russell King - ARM Linux
2017-06-21 9:19 ` [rtc-linux] " Russell King - ARM Linux
[not found] ` <20170621091948.GP4902-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
2017-06-21 9:41 ` Alexandre Belloni
2017-06-21 9:41 ` Alexandre Belloni
2017-06-21 9:41 ` Alexandre Belloni
2017-06-21 9:41 ` Alexandre Belloni
2017-06-21 9:41 ` [rtc-linux] " Alexandre Belloni
-- strict thread matches above, loose matches on Subject: below --
2017-06-20 9:35 Benjamin Gaignard
2017-06-20 9:35 ` Benjamin Gaignard
2017-06-20 9:35 ` Benjamin Gaignard
2017-06-20 9:35 ` Benjamin Gaignard
[not found] ` <1497951359-13334-1-git-send-email-benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-06-20 10:03 ` Alexandre Belloni
2017-06-20 10:03 ` Alexandre Belloni
2017-06-20 10:03 ` Alexandre Belloni
2017-06-20 10:03 ` Alexandre Belloni
[not found] ` <20170620100348.zh4ygvjjgnhxvmvl-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
2017-06-20 10:07 ` Alexandre Belloni
2017-06-20 10:07 ` Alexandre Belloni
2017-06-20 10:07 ` Alexandre Belloni
2017-06-20 10:07 ` Alexandre Belloni
2017-06-20 12:10 ` Pavel Machek
2017-06-20 12:10 ` Pavel Machek
2017-06-20 12:10 ` Pavel Machek
2017-06-20 12:10 ` Pavel Machek
2017-06-20 12:24 ` Alexandre Belloni
2017-06-20 12:24 ` Alexandre Belloni
2017-06-20 12:24 ` Alexandre Belloni
2017-06-20 12:24 ` Alexandre Belloni
[not found] ` <20170620122400.sm7qqvwyj6cuzarw-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
2017-06-20 13:26 ` Pavel Machek
2017-06-20 13:26 ` Pavel Machek
2017-06-20 13:26 ` Pavel Machek
2017-06-20 13:26 ` Pavel Machek
2017-06-20 13:37 ` Steve Twiss
2017-06-20 13:37 ` Steve Twiss
2017-06-20 13:37 ` Steve Twiss
2017-06-20 13:37 ` Steve Twiss
[not found] ` <6ED8E3B22081A4459DAC7699F3695FB7018CD96FCD-68WUHU125fLzLL1Oxlh9IgLouzNaz+3S@public.gmane.org>
2017-06-20 13:44 ` Pavel Machek
2017-06-20 13:44 ` Pavel Machek
2017-06-20 13:44 ` Pavel Machek
2017-06-20 13:44 ` Pavel Machek
2017-06-20 13:48 ` Alexandre Belloni
2017-06-20 13:48 ` Alexandre Belloni
2017-06-20 13:48 ` Alexandre Belloni
2017-06-20 13:48 ` Alexandre Belloni
[not found] ` <20170620134827.ubvzhh25klaotupv-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
2017-06-20 15:07 ` Benjamin Gaignard
2017-06-20 15:07 ` Benjamin Gaignard
2017-06-20 15:07 ` Benjamin Gaignard
2017-06-20 15:07 ` Benjamin Gaignard
[not found] ` <CA+M3ks68+z6nDtYM8CDpso7SxjB6Nt5E=rOc1yxx=kDz6PUeVQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-20 21:15 ` Russell King - ARM Linux
2017-06-20 21:15 ` Russell King - ARM Linux
2017-06-20 21:15 ` Russell King - ARM Linux
2017-06-20 21:15 ` Russell King - ARM Linux
[not found] ` <20170620211536.GM4902-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
2017-06-21 9:26 ` David Laight
2017-06-21 9:26 ` David Laight
2017-06-21 9:26 ` David Laight
2017-06-21 9:26 ` David Laight
[not found] ` <063D6719AE5E284EB5DD2968C1650D6DD00278C0-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
2017-06-21 9:35 ` Russell King - ARM Linux
2017-06-21 9:35 ` Russell King - ARM Linux
2017-06-21 9:35 ` Russell King - ARM Linux
2017-06-20 22:08 ` Pavel Machek
2017-06-20 22:08 ` Pavel Machek
2017-06-20 22:08 ` Pavel Machek
2017-06-20 22:08 ` Pavel Machek
2017-06-21 9:14 ` Benjamin Gaignard
2017-06-21 9:14 ` Benjamin Gaignard
2017-06-21 9:14 ` Benjamin Gaignard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170621180847.GA24175@amd \
--to=pavel-+zi9xunit7i@public.gmane.org \
--cc=alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
--cc=baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org \
--cc=benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org \
--cc=jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
--cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org \
--cc=linux-pm-u79uwXL29TaqPxH82wqD4g@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
--cc=rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
--cc=sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=slemieux.tyco-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=wens-jdAy2FN1RRM@public.gmane.org \
--cc=x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.