* [rtc-linux] Re: [PATCH 32/51] rtc: pcap: stop using rtc deprecated functions
From: kbuild test robot @ 2017-06-21 5:07 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: kbuild-all, benjamin.gaignard, linaro-kernel, Alessandro Zummo,
Alexandre Belloni, rtc-linux, linux-kernel
In-Reply-To: <1497951359-13334-33-git-send-email-benjamin.gaignard@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1898 bytes --]
Hi Benjamin,
[auto build test ERROR on abelloni/rtc-next]
[also build test ERROR on v4.12-rc6 next-20170620]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Benjamin-Gaignard/rtc-stop-using-rtc-deprecated-functions/20170621-044455
base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git rtc-next
config: arm-ezx_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `pcap_rtc_set_mmss64':
>> hid-generic.c:(.text+0xac5b8): undefined reference to `__aeabi_ldivmod'
hid-generic.c:(.text+0xac5dc): undefined reference to `__aeabi_ldivmod'
drivers/built-in.o: In function `pcap_rtc_set_alarm':
>> hid-generic.c:(.text+0xac61c): undefined reference to `__aeabi_uldivmod'
hid-generic.c:(.text+0xac640): undefined reference to `__aeabi_uldivmod'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
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: .config.gz --]
[-- Type: application/gzip, Size: 19642 bytes --]
^ permalink raw reply
* [rtc-linux] Re: [PATCH 07/51] rtc: ab8500: stop using rtc deprecated functions
From: kbuild test robot @ 2017-06-21 6:57 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: kbuild-all, benjamin.gaignard, linaro-kernel, Linus Walleij,
Alessandro Zummo, Alexandre Belloni, rtc-linux, linux-kernel,
linux-arm-kernel
In-Reply-To: <1497951359-13334-8-git-send-email-benjamin.gaignard@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 3021 bytes --]
Hi Benjamin,
[auto build test ERROR on abelloni/rtc-next]
[also build test ERROR on v4.12-rc6 next-20170620]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Benjamin-Gaignard/rtc-stop-using-rtc-deprecated-functions/20170621-044455
base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git rtc-next
config: arm-u8500_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `ab8540_rtc_set_alarm':
>> drivers/rtc/rtc-ab8500.c:299: undefined reference to `__aeabi_uldivmod'
drivers/rtc/rtc-ab8500.c:301: undefined reference to `__aeabi_uldivmod'
drivers/built-in.o: In function `ab8500_rtc_set_time':
drivers/rtc/rtc-ab8500.c:158: undefined reference to `__aeabi_uldivmod'
drivers/rtc/rtc-ab8500.c:160: undefined reference to `__aeabi_uldivmod'
drivers/built-in.o: In function `ab8500_rtc_set_alarm':
drivers/rtc/rtc-ab8500.c:263: undefined reference to `__aeabi_uldivmod'
vim +299 drivers/rtc/rtc-ab8500.c
45a9f91a Benjamin Gaignard 2017-06-20 293 secs = rtc_tm_to_time64(&alarm->time);
25d053cf Alexandre Torgue 2013-07-03 294
25d053cf Alexandre Torgue 2013-07-03 295 /*
25d053cf Alexandre Torgue 2013-07-03 296 * Convert it to the number of seconds since 01-01-2000 00:00:00
25d053cf Alexandre Torgue 2013-07-03 297 */
25d053cf Alexandre Torgue 2013-07-03 298 secs -= get_elapsed_seconds(AB8500_RTC_EPOCH);
25d053cf Alexandre Torgue 2013-07-03 @299 mins = secs / 60;
25d053cf Alexandre Torgue 2013-07-03 300
25d053cf Alexandre Torgue 2013-07-03 301 buf[3] = secs % 60;
25d053cf Alexandre Torgue 2013-07-03 302 buf[2] = mins & 0xFF;
:::::: The code at line 299 was first introduced by commit
:::::: 25d053cf1040e6430fff679854b3710edb0b7fee drivers/rtc/rtc-ab8500.c: add second resolution to rtc driver
:::::: TO: Alexandre Torgue <alexandre.torgue@st.com>
:::::: CC: Linus Torvalds <torvalds@linux-foundation.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
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: .config.gz --]
[-- Type: application/gzip, Size: 22400 bytes --]
^ permalink raw reply
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Pavel Machek @ 2017-06-21 7:51 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Alexandre Belloni, Russell King - ARM Linux, Benjamin Gaignard,
Baruch Siach, patches@opensource.wolfsonmicro.com, Linus Walleij,
linux-tegra@vger.kernel.org, Thierry Reding, x86@kernel.org,
Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux,
Sebastian Hesselbarth, Len Brown, linaro-kernel@lists.linaro.org,
Jason Cooper, rtc-linux@googlegroups.com,
linux-pm@vger.kernel.org, Hans Ulli Kroll,
adi-buildroot-devel@lists.sourceforge.net, Vladimir Zapolskiy,
John Stultz, Gregory Clement, Michael Chan,
linux-arm-kernel@lists.infradead.org, Alessandro Zummo,
Barry Song, Support Opensource, netdev@vger.kernel.org,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Steve Twiss,
Maxime Ripard
In-Reply-To: <alpine.DEB.2.20.1706202343120.2157@nanos>
[-- Attachment #1: Type: text/plain, Size: 1835 bytes --]
Hi!
> > I agree with that but not the android guys. They seem to mandate an RTC
> > that can store time from 01/01/1970. I don't know much more than that
> > because they never cared to explain why that was actually necessary
> > (apart from a laconic "this will result in a bad user experience")
> >
> > I think tglx had a plan for offsetting the time at some point so 32-bit
> > platform can pass 2038 properly.
>
> Yes, but there are still quite some issues to solve there:
>
> 1) How do you tell the system that it should apply the offset in the
> first place, i.e at boot time before NTP or any other mechanism can
> correct it?
I'd not do offset. Instead, I'd select a threshold (perhaps year of
release of given kernel?) and
if (rtc_time < year_of_release_of_kernel)
rtc_time += 0x100000000;
Ok, we'll have to move away from "rtc_time == 0 indicates zero", as
seen in some drivers.
> 2) Deal with creative vendors who have their own idea about the 'start
> of the epoch'
If someone uses different threshold, well, there will be
confusion. But only for users that have their rtc set to the past,
which is quite unusual.
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 --]
^ permalink raw reply
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Alexandre Belloni @ 2017-06-21 8:39 UTC (permalink / raw)
To: Pavel Machek
Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard,
Baruch Siach, patches@opensource.wolfsonmicro.com, Linus Walleij,
linux-tegra@vger.kernel.org, Thierry Reding, x86@kernel.org,
Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux,
Sebastian Hesselbarth, Len Brown, linaro-kernel@lists.linaro.org,
Jason Cooper, rtc-linux@googlegroups.com,
linux-pm@vger.kernel.org, Hans Ulli Kroll,
adi-buildroot-devel@lists.sourceforge.net, Vladimir Zapolskiy,
John Stultz, Gregory Clement, Michael Chan,
linux-arm-kernel@lists.infradead.org, Alessandro Zummo,
Barry Song, Support Opensource, netdev@vger.kernel.org,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Steve Twiss,
Maxime Ripard
In-Reply-To: <20170621075152.GA15996@amd>
On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote:
> Hi!
>
> > > I agree with that but not the android guys. They seem to mandate an RTC
> > > that can store time from 01/01/1970. I don't know much more than that
> > > because they never cared to explain why that was actually necessary
> > > (apart from a laconic "this will result in a bad user experience")
> > >
> > > I think tglx had a plan for offsetting the time at some point so 32-bit
> > > platform can pass 2038 properly.
> >
> > Yes, but there are still quite some issues to solve there:
> >
> > 1) How do you tell the system that it should apply the offset in the
> > first place, i.e at boot time before NTP or any other mechanism can
> > correct it?
>
> I'd not do offset. Instead, I'd select a threshold (perhaps year of
> release of given kernel?) and
>
> if (rtc_time < year_of_release_of_kernel)
> rtc_time += 0x100000000;
>
> Ok, we'll have to move away from "rtc_time == 0 indicates zero", as
> seen in some drivers.
>
> > 2) Deal with creative vendors who have their own idea about the 'start
> > of the epoch'
>
> If someone uses different threshold, well, there will be
> confusion. But only for users that have their rtc set to the past,
> which is quite unusual.
>
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.
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.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Benjamin Gaignard @ 2017-06-21 9:14 UTC (permalink / raw)
To: Pavel Machek
Cc: Alexandre Belloni, Steve Twiss, linaro-kernel@lists.linaro.org,
adi-buildroot-devel@lists.sourceforge.net, Alessandro Zummo,
Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Linus Walleij, Michael Chan,
netdev@vger.kernel.org, rtc-linux@googlegroups.com,
Sebastian Hesselbarth, Support Opensource, Thomas Gleixner,
x86@kernel.org, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy,
Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai,
Thierry Reding, Jonathan Hunter, linux-tegra@vger.kernel.org,
patches@opensource.wolfsonmicro.com, Rafael J. Wysocki, Len Brown,
linux-pm@vger.kernel.org
In-Reply-To: <20170620220805.GA11195@amd>
2017-06-21 0:08 GMT+02:00 Pavel Machek <pavel@ucw.cz>:
> Hi!
>
>> >> > This is it.
>> >> > https://patchwork.kernel.org/patch/6219401/
>> >>
>> >> Thanks.
>> >>
>> >> Yes, that's argument against changing rtc _drivers_ for hardware that
>> >> can not do better than 32bit. For generic code (such as 44/51 sysfs,
>> >> 51/51 suspend test), the change still makes sense.
>>
>> What I had in mind when writing those patches was to remove the limitations
>> coming from those functions usage, even more since they been marked has
>> deprecated.
>>
>> I agree that will change nothing of hardware limitation but at least
>> the limit will
>> not come from the framework.
>
>> > Yes, we agree on that but I won't cherry pick working patches from a 51
>> > patches series.
>
> Well, it would be actually nice for you to do the cherry
> picking. That's something maintainers do, because it is hard for
> contributors to guess maintainer's taste.
>
> Anyway, it looks like someone should go through all the RTC drivers,
> and document their limitations of each driver (date in future when
> hardware ceases to be useful). If Benjamin has time to do that, I
> guess that removes all the objections to the series.
Without the datasheet I can check in driver code what they do in read/set
time functions to understand their limitations. All drivers using BCD
like system
or spliting day and time should be fixed. I can do a subset of my patches
including those driver + the acked ones.
Alexandre does that sound reasonable for you ?
> 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.
^ permalink raw reply
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Russell King - ARM Linux @ 2017-06-21 9:19 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Pavel Machek, Thomas Gleixner, Benjamin Gaignard, Baruch Siach,
patches@opensource.wolfsonmicro.com, Linus Walleij,
linux-tegra@vger.kernel.org, Thierry Reding, x86@kernel.org,
Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux,
Sebastian Hesselbarth, Len Brown, linaro-kernel@lists.linaro.org,
Jason Cooper, rtc-linux@googlegroups.com,
linux-pm@vger.kernel.org, Hans Ulli Kroll,
adi-buildroot-devel@lists.sourceforge.net, Vladimir Zapolskiy,
John Stultz, Gregory Clement, Michael Chan,
linux-arm-kernel@lists.infradead.org, Alessandro Zummo,
Barry Song, Support Opensource, netdev@vger.kernel.org,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Steve Twiss,
Maxime Ripard
In-Reply-To: <20170621083907.y3gadsmsoufa5niv@piout.net>
On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote:
> On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote:
> > If someone uses different threshold, well, there will be
> > confusion. But only for users that have their rtc set to the past,
> > which is quite unusual.
> >
>
> 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.
... and that basically means you can't use hardware that stores RTC
time as a 32-bit number of seconds past 2106.
> 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.
Not for the case being discussed. A 32-bit counter of seconds knows
nothing about leap years - all that is handled by the conversion
functions.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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
* [rtc-linux] RE: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: David Laight @ 2017-06-21 9:26 UTC (permalink / raw)
To: 'Russell King - ARM Linux', Benjamin Gaignard
Cc: Alexandre Belloni, Baruch Siach,
patches@opensource.wolfsonmicro.com, Linus Walleij,
linux-tegra@vger.kernel.org, Thierry Reding, Pavel Machek,
Thomas Gleixner, x86@kernel.org, Jonathan Hunter, Chen-Yu Tsai,
Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown,
linaro-kernel@lists.linaro.org, Jason Cooper,
rtc-linux@googlegroups.com, linux-pm@vger.kernel.org,
Hans Ulli Kroll, adi-buildroot-devel@lists.sourceforge.net,
Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan,
linux-arm-kernel@lists.infradead.org, Alessandro Zummo,
Barry Song, Support Opensource, netdev@vger.kernel.org,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Steve Twiss,
Maxime Ripard
In-Reply-To: <20170620211536.GM4902@n2100.armlinux.org.uk>
From: Russell King - ARM Linux
> Sent: 20 June 2017 22:16
..
> Consider that at the moment, we define the 32-bit RTC representation to
> start at a well known epoch. We _could_ decide that when it wraps to
> 0x80000000 seconds, we'll define the lower 0x40000000 seconds to mean
> dates in the future - and keep rolling that forward each time we cross
> another 0x40000000 seconds. Unless someone invents a real time machine,
> we shouldn't need to set a modern RTC back to 1970.
True, just treating the value as unsigned gives another 67 years.
If a 32bit RTC is programmed with the low 32bits of the 64bit 'seconds
since 1970' the kernel should have no real difficulty sorting out the
high bits from other available information.
Problems with things like the x86 bios setting the rtc to stupid values
are another matter.
ISTR the rtc chip has a bit for 'summertime' that is never set, on a
multi-os system you can get multiple summer time changes.
David
--
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
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Russell King - ARM Linux @ 2017-06-21 9:35 UTC (permalink / raw)
To: David Laight
Cc: Benjamin Gaignard, Alexandre Belloni, Baruch Siach,
patches@opensource.wolfsonmicro.com, Linus Walleij,
linux-tegra@vger.kernel.org, Thierry Reding, Pavel Machek,
Thomas Gleixner, x86@kernel.org, Jonathan Hunter, Chen-Yu Tsai,
Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown,
linaro-kernel@lists.linaro.org, Jason Cooper,
rtc-linux@googlegroups.com, linux-pm@vger.kernel.org,
Hans Ulli Kroll, adi-buildroot-devel@lists.sourceforge.net,
Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan,
linux-arm-kernel@lists.infradead.org, Alessandro Zummo,
Barry Song, Support Opensource, netdev@vger.kernel.org,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Steve Twiss,
Maxime Ripard
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD00278C0@AcuExch.aculab.com>
On Wed, Jun 21, 2017 at 09:26:51AM +0000, David Laight wrote:
> From: Russell King - ARM Linux
> > Sent: 20 June 2017 22:16
> ..
> > Consider that at the moment, we define the 32-bit RTC representation to
> > start at a well known epoch. We _could_ decide that when it wraps to
> > 0x80000000 seconds, we'll define the lower 0x40000000 seconds to mean
> > dates in the future - and keep rolling that forward each time we cross
> > another 0x40000000 seconds. Unless someone invents a real time machine,
> > we shouldn't need to set a modern RTC back to 1970.
>
> True, just treating the value as unsigned gives another 67 years.
We _already_ do treat it as an unsigned number, so already the panicing
about 2038 is complete and utter nonsense - that's why I've been
consistently stating the 2106 date.
> If a 32bit RTC is programmed with the low 32bits of the 64bit 'seconds
> since 1970' the kernel should have no real difficulty sorting out the
> high bits from other available information.
Right, but converting all the 32-bit conversion functions to 64-bit
means that rather than "sorting out" that from the core RTC driver,
we have to implement solutions in each and every driver.
While that may appear to be a good idea, many RTCs that are 32-bit
counters do not themselves have additional non-volatile storage, so
it means that we're ending up with a lot of RTC specific hacks to
go and get the additional information from some other driver elsewhere
in the system.
> Problems with things like the x86 bios setting the rtc to stupid values
> are another matter.
Forget x86, the RTC there does not store time as a 32-bit integer, it's
stored as its component values, and there's non-volatile memory attached
to the RTC. Hence, it's out of scope of "what to do about RTCs that
store time in 32-bit format" and also out of scope of "what to do about
RTC drivers that use the 32-bit time conversion function."
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Alexandre Belloni @ 2017-06-21 9:41 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Pavel Machek, Thomas Gleixner, Benjamin Gaignard, Baruch Siach,
patches@opensource.wolfsonmicro.com, Linus Walleij,
linux-tegra@vger.kernel.org, Thierry Reding, x86@kernel.org,
Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux,
Sebastian Hesselbarth, Len Brown, linaro-kernel@lists.linaro.org,
Jason Cooper, rtc-linux@googlegroups.com,
linux-pm@vger.kernel.org, Hans Ulli Kroll,
adi-buildroot-devel@lists.sourceforge.net, Vladimir Zapolskiy,
John Stultz, Gregory Clement, Michael Chan,
linux-arm-kernel@lists.infradead.org, Alessandro Zummo,
Barry Song, Support Opensource, netdev@vger.kernel.org,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Steve Twiss,
Maxime Ripard
In-Reply-To: <20170621091948.GP4902@n2100.armlinux.org.uk>
On 21/06/2017 at 10:19:49 +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote:
> > On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote:
> > > If someone uses different threshold, well, there will be
> > > confusion. But only for users that have their rtc set to the past,
> > > which is quite unusual.
> > >
> >
> > 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.
>
> ... and that basically means you can't use hardware that stores RTC
> time as a 32-bit number of seconds past 2106.
>
And I guess it will not matter much for us anyway ;)
> > 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.
>
> Not for the case being discussed. A 32-bit counter of seconds knows
> nothing about leap years - all that is handled by the conversion
> functions.
>
Well, the patch series touches some RTCs that are not using 32 bit
counter so I though I might as well raise the issue now.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Pavel Machek @ 2017-06-21 6:34 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard,
Baruch Siach, patches@opensource.wolfsonmicro.com, Linus Walleij,
linux-tegra@vger.kernel.org, Thierry Reding, x86@kernel.org,
Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux,
Sebastian Hesselbarth, Len Brown, linaro-kernel@lists.linaro.org,
Jason Cooper, rtc-linux@googlegroups.com,
linux-pm@vger.kernel.org, Hans Ulli Kroll,
adi-buildroot-devel@lists.sourceforge.net, Vladimir Zapolskiy,
John Stultz, Gregory Clement, Michael Chan,
linux-arm-kernel@lists.infradead.org, Alessandro Zummo,
Barry Song, Support Opensource, netdev@vger.kernel.org,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Steve Twiss,
Maxime Ripard
In-Reply-To: <20170621083907.y3gadsmsoufa5niv@piout.net>
Hi!
> > > > I think tglx had a plan for offsetting the time at some point so 32-bit
> > > > platform can pass 2038 properly.
> > >
> > > Yes, but there are still quite some issues to solve there:
> > >
> > > 1) How do you tell the system that it should apply the offset in the
> > > first place, i.e at boot time before NTP or any other mechanism can
> > > correct it?
> >
> > I'd not do offset. Instead, I'd select a threshold (perhaps year of
> > release of given kernel?) and
> >
> > if (rtc_time < year_of_release_of_kernel)
> > rtc_time += 0x100000000;
> >
> > Ok, we'll have to move away from "rtc_time == 0 indicates zero", as
> > seen in some drivers.
> >
> > > 2) Deal with creative vendors who have their own idea about the 'start
> > > of the epoch'
> >
> > If someone uses different threshold, well, there will be
> > confusion. But only for users that have their rtc set to the past,
> > which is quite unusual.
> >
>
> 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.
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.
--
(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.
^ permalink raw reply
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Alexandre Belloni @ 2017-06-21 12:35 UTC (permalink / raw)
To: Pavel Machek
Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard,
Baruch Siach, patches@opensource.wolfsonmicro.com, Linus Walleij,
linux-tegra@vger.kernel.org, Thierry Reding, x86@kernel.org,
Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux,
Sebastian Hesselbarth, Len Brown, linaro-kernel@lists.linaro.org,
Jason Cooper, rtc-linux@googlegroups.com,
linux-pm@vger.kernel.org, Hans Ulli Kroll,
adi-buildroot-devel@lists.sourceforge.net, Vladimir Zapolskiy,
John Stultz, Gregory Clement, Michael Chan,
linux-arm-kernel@lists.infradead.org, Alessandro Zummo,
Barry Song, Support Opensource, netdev@vger.kernel.org,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Steve Twiss,
Maxime Ripard
In-Reply-To: <20170621063443.GA4862@localhost>
On 21/06/2017 at 08:34:43 +0200, Pavel Machek wrote:
> Hi!
>
> > > > > I think tglx had a plan for offsetting the time at some point so 32-bit
> > > > > platform can pass 2038 properly.
> > > >
> > > > Yes, but there are still quite some issues to solve there:
> > > >
> > > > 1) How do you tell the system that it should apply the offset in the
> > > > first place, i.e at boot time before NTP or any other mechanism can
> > > > correct it?
> > >
> > > I'd not do offset. Instead, I'd select a threshold (perhaps year of
> > > release of given kernel?) and
> > >
> > > if (rtc_time < year_of_release_of_kernel)
> > > rtc_time += 0x100000000;
> > >
> > > Ok, we'll have to move away from "rtc_time == 0 indicates zero", as
> > > seen in some drivers.
> > >
> > > > 2) Deal with creative vendors who have their own idea about the 'start
> > > > of the epoch'
> > >
> > > If someone uses different threshold, well, there will be
> > > confusion. But only for users that have their rtc set to the past,
> > > which is quite unusual.
> > >
> >
> > 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.
There is currently one rtc doing that kind of trick but it is used as a
simple time counter from the beginning. Transitioning is the difficult
part.
> 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.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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
* [PATCH] rtc: ds3232: add temperature support
From: Kirill Esipov @ 2017-06-21 14:49 UTC (permalink / raw)
To: a.zummo, alexandre.belloni; +Cc: linux-rtc, linux-kernel, Kirill Esipov
DS3232/DS3234 has the temperature registers with a resolution of
0.25 degree celsius. This enables to get the value through hwmon.
# cat /sys/class/hwmon/hwmon0/temp1_input
37250
Signed-off-by: Kirill Esipov <yesipov@gmail.com>
---
drivers/rtc/Kconfig | 9 ++++++
drivers/rtc/rtc-ds3232.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 93 insertions(+)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 8d3b95728326..b4a6a916d4df 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -791,6 +791,15 @@ config RTC_DRV_DS3232
This driver can also be built as a module. If so, the module
will be called rtc-ds3232.
+config RTC_DRV_DS3232_HWMON
+ bool "HWMON support for Dallas/Maxim DS3232/DS3234"
+ depends on RTC_DRV_DS3232 && HWMON
+ depends on !(RTC_DRV_DS3232=y && HWMON=m)
+ default y
+ help
+ Say Y here if you want to expose temperature sensor data on
+ rtc-ds3232
+
config RTC_DRV_PCF2127
tristate "NXP PCF2127"
depends on RTC_I2C_AND_SPI
diff --git a/drivers/rtc/rtc-ds3232.c b/drivers/rtc/rtc-ds3232.c
index deff431a37c4..f94ff0685942 100644
--- a/drivers/rtc/rtc-ds3232.c
+++ b/drivers/rtc/rtc-ds3232.c
@@ -22,6 +22,8 @@
#include <linux/bcd.h>
#include <linux/slab.h>
#include <linux/regmap.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
#define DS3232_REG_SECONDS 0x00
#define DS3232_REG_MINUTES 0x01
@@ -275,6 +277,86 @@ static int ds3232_update_alarm(struct device *dev, unsigned int enabled)
return ret;
}
+/*----------------------------------------------------------------------*/
+
+#ifdef CONFIG_RTC_DRV_DS3232_HWMON
+
+/*
+ * Temperature sensor support for ds3232/ds3234 devices.
+ */
+
+#define DS3232_REG_TEMPERATURE 0x11
+
+/*
+ * A user-initiated temperature conversion is not started by this function,
+ * so the temperature is updated once every 64 seconds.
+ */
+static int ds3232_hwmon_read_temp(struct device *dev, s32 *mC)
+{
+ struct ds3232 *ds3232 = dev_get_drvdata(dev);
+ u8 temp_buf[2];
+ s16 temp;
+ int ret;
+
+ ret = regmap_bulk_read(ds3232->regmap, DS3232_REG_TEMPERATURE, temp_buf,
+ sizeof(temp_buf));
+
+ if (ret < 0)
+ return ret;
+
+ /*
+ * Temperature is represented as a 10-bit code with a resolution of
+ * 0.25 degree celsius and encoded in two's complement format.
+ */
+ temp = (temp_buf[0] << 8) | temp_buf[1];
+ temp >>= 6;
+ *mC = temp * 250;
+
+ return 0;
+}
+
+static ssize_t ds3232_hwmon_show_temp(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int ret;
+ s32 temp;
+
+ ret = ds3232_hwmon_read_temp(dev, &temp);
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "%d\n", temp);
+}
+static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, ds3232_hwmon_show_temp,
+ NULL, 0);
+
+static struct attribute *ds3232_hwmon_attrs[] = {
+ &sensor_dev_attr_temp1_input.dev_attr.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(ds3232_hwmon);
+
+static void ds3232_hwmon_register(struct device *dev, const char *name)
+{
+ struct ds3232 *ds3232 = dev_get_drvdata(dev);
+ struct device *hwmon_dev;
+
+ hwmon_dev = devm_hwmon_device_register_with_groups(dev, name, ds3232,
+ ds3232_hwmon_groups);
+ if (IS_ERR(hwmon_dev)) {
+ dev_warn(dev, "unable to register hwmon device %ld\n",
+ PTR_ERR(hwmon_dev));
+ }
+}
+
+#else
+
+static void ds3232_hwmon_register(struct ds3232 *ds3232)
+{
+}
+
+#endif
+
static int ds3232_alarm_irq_enable(struct device *dev, unsigned int enabled)
{
struct ds3232 *ds3232 = dev_get_drvdata(dev);
@@ -366,6 +448,8 @@ static int ds3232_probe(struct device *dev, struct regmap *regmap, int irq,
if (ds3232->irq > 0)
device_init_wakeup(dev, 1);
+ ds3232_hwmon_register(dev, name);
+
ds3232->rtc = devm_rtc_device_register(dev, name, &ds3232_rtc_ops,
THIS_MODULE);
if (IS_ERR(ds3232->rtc))
--
2.7.4
^ permalink raw reply related
* [rtc-linux] Re: [PATCH 35/51] rtc: pm8xxx: stop using rtc deprecated functions
From: kbuild test robot @ 2017-06-21 16:54 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: kbuild-all, benjamin.gaignard, linaro-kernel, Alessandro Zummo,
Alexandre Belloni, rtc-linux, linux-kernel
In-Reply-To: <1497951359-13334-36-git-send-email-benjamin.gaignard@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]
Hi Benjamin,
[auto build test ERROR on abelloni/rtc-next]
[also build test ERROR on v4.12-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Benjamin-Gaignard/rtc-stop-using-rtc-deprecated-functions/20170621-044455
base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git rtc-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> ERROR: "__udivdi3" [drivers/rtc/rtc-pcap.ko] undefined!
>> ERROR: "__umoddi3" [drivers/rtc/rtc-pcap.ko] undefined!
>> ERROR: "__divdi3" [drivers/rtc/rtc-pcap.ko] undefined!
>> ERROR: "__moddi3" [drivers/rtc/rtc-pcap.ko] undefined!
ERROR: "__umoddi3" [drivers/rtc/rtc-cpcap.ko] undefined!
ERROR: "__udivdi3" [drivers/rtc/rtc-cpcap.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
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: .config.gz --]
[-- Type: application/gzip, Size: 60103 bytes --]
^ permalink raw reply
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Pavel Machek @ 2017-06-21 18:08 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard,
Baruch Siach, patches@opensource.wolfsonmicro.com, Linus Walleij,
linux-tegra@vger.kernel.org, Thierry Reding, x86@kernel.org,
Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux,
Sebastian Hesselbarth, Len Brown, linaro-kernel@lists.linaro.org,
Jason Cooper, rtc-linux@googlegroups.com,
linux-pm@vger.kernel.org, Hans Ulli Kroll,
adi-buildroot-devel@lists.sourceforge.net, Vladimir Zapolskiy,
John Stultz, Gregory Clement, Michael Chan,
linux-arm-kernel@lists.infradead.org, Alessandro Zummo,
Barry Song, Support Opensource, netdev@vger.kernel.org,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Steve Twiss,
Maxime Ripard
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 --]
^ permalink raw reply
* Re: rtc: ds3232: add temperature support
From: Guenter Roeck @ 2017-06-21 22:24 UTC (permalink / raw)
To: Kirill Esipov; +Cc: a.zummo, alexandre.belloni, linux-rtc, linux-kernel
In-Reply-To: <1498056583-16551-1-git-send-email-yesipov@gmail.com>
On Wed, Jun 21, 2017 at 05:49:43PM +0300, Kirill Esipov wrote:
> DS3232/DS3234 has the temperature registers with a resolution of
> 0.25 degree celsius. This enables to get the value through hwmon.
>
> # cat /sys/class/hwmon/hwmon0/temp1_input
> 37250
>
> Signed-off-by: Kirill Esipov <yesipov@gmail.com>
> ---
> drivers/rtc/Kconfig | 9 ++++++
> drivers/rtc/rtc-ds3232.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 93 insertions(+)
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 8d3b95728326..b4a6a916d4df 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -791,6 +791,15 @@ config RTC_DRV_DS3232
> This driver can also be built as a module. If so, the module
> will be called rtc-ds3232.
>
> +config RTC_DRV_DS3232_HWMON
> + bool "HWMON support for Dallas/Maxim DS3232/DS3234"
> + depends on RTC_DRV_DS3232 && HWMON
> + depends on !(RTC_DRV_DS3232=y && HWMON=m)
> + default y
> + help
> + Say Y here if you want to expose temperature sensor data on
> + rtc-ds3232
> +
> config RTC_DRV_PCF2127
> tristate "NXP PCF2127"
> depends on RTC_I2C_AND_SPI
> diff --git a/drivers/rtc/rtc-ds3232.c b/drivers/rtc/rtc-ds3232.c
> index deff431a37c4..f94ff0685942 100644
> --- a/drivers/rtc/rtc-ds3232.c
> +++ b/drivers/rtc/rtc-ds3232.c
> @@ -22,6 +22,8 @@
> #include <linux/bcd.h>
> #include <linux/slab.h>
> #include <linux/regmap.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
>
> #define DS3232_REG_SECONDS 0x00
> #define DS3232_REG_MINUTES 0x01
> @@ -275,6 +277,86 @@ static int ds3232_update_alarm(struct device *dev, unsigned int enabled)
> return ret;
> }
>
> +/*----------------------------------------------------------------------*/
> +
> +#ifdef CONFIG_RTC_DRV_DS3232_HWMON
> +
> +/*
> + * Temperature sensor support for ds3232/ds3234 devices.
> + */
> +
> +#define DS3232_REG_TEMPERATURE 0x11
> +
> +/*
> + * A user-initiated temperature conversion is not started by this function,
> + * so the temperature is updated once every 64 seconds.
> + */
> +static int ds3232_hwmon_read_temp(struct device *dev, s32 *mC)
> +{
> + struct ds3232 *ds3232 = dev_get_drvdata(dev);
> + u8 temp_buf[2];
> + s16 temp;
> + int ret;
> +
> + ret = regmap_bulk_read(ds3232->regmap, DS3232_REG_TEMPERATURE, temp_buf,
> + sizeof(temp_buf));
> +
> + if (ret < 0)
> + return ret;
> +
> + /*
> + * Temperature is represented as a 10-bit code with a resolution of
> + * 0.25 degree celsius and encoded in two's complement format.
> + */
> + temp = (temp_buf[0] << 8) | temp_buf[1];
> + temp >>= 6;
> + *mC = temp * 250;
> +
> + return 0;
> +}
> +
> +static ssize_t ds3232_hwmon_show_temp(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + int ret;
> + s32 temp;
> +
> + ret = ds3232_hwmon_read_temp(dev, &temp);
> + if (ret < 0)
> + return ret;
> +
> + return sprintf(buf, "%d\n", temp);
> +}
> +static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, ds3232_hwmon_show_temp,
> + NULL, 0);
> +
> +static struct attribute *ds3232_hwmon_attrs[] = {
> + &sensor_dev_attr_temp1_input.dev_attr.attr,
> + NULL,
> +};
> +ATTRIBUTE_GROUPS(ds3232_hwmon);
> +
> +static void ds3232_hwmon_register(struct device *dev, const char *name)
> +{
> + struct ds3232 *ds3232 = dev_get_drvdata(dev);
> + struct device *hwmon_dev;
> +
> + hwmon_dev = devm_hwmon_device_register_with_groups(dev, name, ds3232,
> + ds3232_hwmon_groups);
Any reason for not using devm_hwmon_device_register_with_info() ?
Guenter
> + if (IS_ERR(hwmon_dev)) {
> + dev_warn(dev, "unable to register hwmon device %ld\n",
> + PTR_ERR(hwmon_dev));
> + }
> +}
> +
> +#else
> +
> +static void ds3232_hwmon_register(struct ds3232 *ds3232)
> +{
> +}
> +
> +#endif
> +
> static int ds3232_alarm_irq_enable(struct device *dev, unsigned int enabled)
> {
> struct ds3232 *ds3232 = dev_get_drvdata(dev);
> @@ -366,6 +448,8 @@ static int ds3232_probe(struct device *dev, struct regmap *regmap, int irq,
> if (ds3232->irq > 0)
> device_init_wakeup(dev, 1);
>
> + ds3232_hwmon_register(dev, name);
> +
> ds3232->rtc = devm_rtc_device_register(dev, name, &ds3232_rtc_ops,
> THIS_MODULE);
> if (IS_ERR(ds3232->rtc))
^ permalink raw reply
* Re: [PATCH] rtc: ds3232: add temperature support
From: kbuild test robot @ 2017-06-21 23:51 UTC (permalink / raw)
To: Kirill Esipov
Cc: kbuild-all, a.zummo, alexandre.belloni, linux-rtc, linux-kernel,
Kirill Esipov
In-Reply-To: <1498056583-16551-1-git-send-email-yesipov@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]
Hi Kirill,
[auto build test ERROR on abelloni/rtc-next]
[also build test ERROR on v4.12-rc6 next-20170621]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Kirill-Esipov/rtc-ds3232-add-temperature-support/20170622-065247
base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git rtc-next
config: x86_64-randconfig-x008-201725 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/rtc/rtc-ds3232.c: In function 'ds3232_probe':
>> drivers/rtc/rtc-ds3232.c:451:24: error: passing argument 1 of 'ds3232_hwmon_register' from incompatible pointer type [-Werror=incompatible-pointer-types]
ds3232_hwmon_register(dev, name);
^~~
drivers/rtc/rtc-ds3232.c:354:13: note: expected 'struct ds3232 *' but argument is of type 'struct device *'
static void ds3232_hwmon_register(struct ds3232 *ds3232)
^~~~~~~~~~~~~~~~~~~~~
>> drivers/rtc/rtc-ds3232.c:451:2: error: too many arguments to function 'ds3232_hwmon_register'
ds3232_hwmon_register(dev, name);
^~~~~~~~~~~~~~~~~~~~~
drivers/rtc/rtc-ds3232.c:354:13: note: declared here
static void ds3232_hwmon_register(struct ds3232 *ds3232)
^~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/ds3232_hwmon_register +451 drivers/rtc/rtc-ds3232.c
445 if (ret)
446 return ret;
447
448 if (ds3232->irq > 0)
449 device_init_wakeup(dev, 1);
450
> 451 ds3232_hwmon_register(dev, name);
452
453 ds3232->rtc = devm_rtc_device_register(dev, name, &ds3232_rtc_ops,
454 THIS_MODULE);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 26277 bytes --]
^ permalink raw reply
* Re: [PATCH] rtc: ds3232: add temperature support
From: kbuild test robot @ 2017-06-22 1:29 UTC (permalink / raw)
To: Kirill Esipov
Cc: kbuild-all, a.zummo, alexandre.belloni, linux-rtc, linux-kernel,
Kirill Esipov
In-Reply-To: <1498056583-16551-1-git-send-email-yesipov@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]
Hi Kirill,
[auto build test WARNING on abelloni/rtc-next]
[also build test WARNING on v4.12-rc6 next-20170621]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Kirill-Esipov/rtc-ds3232-add-temperature-support/20170622-065247
base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git rtc-next
config: x86_64-randconfig-h0-06220808 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/rtc/rtc-ds3232.c: In function 'ds3232_probe':
>> drivers/rtc/rtc-ds3232.c:451:24: warning: passing argument 1 of 'ds3232_hwmon_register' from incompatible pointer type
ds3232_hwmon_register(dev, name);
^
drivers/rtc/rtc-ds3232.c:354:13: note: expected 'struct ds3232 *' but argument is of type 'struct device *'
static void ds3232_hwmon_register(struct ds3232 *ds3232)
^
drivers/rtc/rtc-ds3232.c:451:2: error: too many arguments to function 'ds3232_hwmon_register'
ds3232_hwmon_register(dev, name);
^
drivers/rtc/rtc-ds3232.c:354:13: note: declared here
static void ds3232_hwmon_register(struct ds3232 *ds3232)
^
vim +/ds3232_hwmon_register +451 drivers/rtc/rtc-ds3232.c
435 ds3232 = devm_kzalloc(dev, sizeof(*ds3232), GFP_KERNEL);
436 if (!ds3232)
437 return -ENOMEM;
438
439 ds3232->regmap = regmap;
440 ds3232->irq = irq;
441 ds3232->dev = dev;
442 dev_set_drvdata(dev, ds3232);
443
444 ret = ds3232_check_rtc_status(dev);
445 if (ret)
446 return ret;
447
448 if (ds3232->irq > 0)
449 device_init_wakeup(dev, 1);
450
> 451 ds3232_hwmon_register(dev, name);
452
453 ds3232->rtc = devm_rtc_device_register(dev, name, &ds3232_rtc_ops,
454 THIS_MODULE);
455 if (IS_ERR(ds3232->rtc))
456 return PTR_ERR(ds3232->rtc);
457
458 if (ds3232->irq > 0) {
459 ret = devm_request_threaded_irq(dev, ds3232->irq, NULL,
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 20328 bytes --]
^ permalink raw reply
* Re: rtc: ds3232: add temperature support
From: Kirill Esipov @ 2017-06-22 12:07 UTC (permalink / raw)
To: Guenter Roeck
Cc: Alessandro Zummo, alexandre.belloni, linux-rtc, linux-kernel
In-Reply-To: <20170621222421.GA23791@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 5113 bytes --]
2017-06-22 1:24 GMT+03:00 Guenter Roeck <linux@roeck-us.net>:
> On Wed, Jun 21, 2017 at 05:49:43PM +0300, Kirill Esipov wrote:
> > DS3232/DS3234 has the temperature registers with a resolution of
> > 0.25 degree celsius. This enables to get the value through hwmon.
> >
> > # cat /sys/class/hwmon/hwmon0/temp1_input
> > 37250
> >
> > Signed-off-by: Kirill Esipov <yesipov@gmail.com>
> > ---
> > drivers/rtc/Kconfig | 9 ++++++
> > drivers/rtc/rtc-ds3232.c | 84 ++++++++++++++++++++++++++++++
> ++++++++++++++++++
> > 2 files changed, 93 insertions(+)
> >
> > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> > index 8d3b95728326..b4a6a916d4df 100644
> > --- a/drivers/rtc/Kconfig
> > +++ b/drivers/rtc/Kconfig
> > @@ -791,6 +791,15 @@ config RTC_DRV_DS3232
> > This driver can also be built as a module. If so, the module
> > will be called rtc-ds3232.
> >
> > +config RTC_DRV_DS3232_HWMON
> > + bool "HWMON support for Dallas/Maxim DS3232/DS3234"
> > + depends on RTC_DRV_DS3232 && HWMON
> > + depends on !(RTC_DRV_DS3232=y && HWMON=m)
> > + default y
> > + help
> > + Say Y here if you want to expose temperature sensor data on
> > + rtc-ds3232
> > +
> > config RTC_DRV_PCF2127
> > tristate "NXP PCF2127"
> > depends on RTC_I2C_AND_SPI
> > diff --git a/drivers/rtc/rtc-ds3232.c b/drivers/rtc/rtc-ds3232.c
> > index deff431a37c4..f94ff0685942 100644
> > --- a/drivers/rtc/rtc-ds3232.c
> > +++ b/drivers/rtc/rtc-ds3232.c
> > @@ -22,6 +22,8 @@
> > #include <linux/bcd.h>
> > #include <linux/slab.h>
> > #include <linux/regmap.h>
> > +#include <linux/hwmon.h>
> > +#include <linux/hwmon-sysfs.h>
> >
> > #define DS3232_REG_SECONDS 0x00
> > #define DS3232_REG_MINUTES 0x01
> > @@ -275,6 +277,86 @@ static int ds3232_update_alarm(struct device *dev,
> unsigned int enabled)
> > return ret;
> > }
> >
> > +/*---------------------------------------------------------
> -------------*/
> > +
> > +#ifdef CONFIG_RTC_DRV_DS3232_HWMON
> > +
> > +/*
> > + * Temperature sensor support for ds3232/ds3234 devices.
> > + */
> > +
> > +#define DS3232_REG_TEMPERATURE 0x11
> > +
> > +/*
> > + * A user-initiated temperature conversion is not started by this
> function,
> > + * so the temperature is updated once every 64 seconds.
> > + */
> > +static int ds3232_hwmon_read_temp(struct device *dev, s32 *mC)
> > +{
> > + struct ds3232 *ds3232 = dev_get_drvdata(dev);
> > + u8 temp_buf[2];
> > + s16 temp;
> > + int ret;
> > +
> > + ret = regmap_bulk_read(ds3232->regmap, DS3232_REG_TEMPERATURE,
> temp_buf,
> > + sizeof(temp_buf));
> > +
> > + if (ret < 0)
> > + return ret;
> > +
> > + /*
> > + * Temperature is represented as a 10-bit code with a resolution of
> > + * 0.25 degree celsius and encoded in two's complement format.
> > + */
> > + temp = (temp_buf[0] << 8) | temp_buf[1];
> > + temp >>= 6;
> > + *mC = temp * 250;
> > +
> > + return 0;
> > +}
> > +
> > +static ssize_t ds3232_hwmon_show_temp(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + int ret;
> > + s32 temp;
> > +
> > + ret = ds3232_hwmon_read_temp(dev, &temp);
> > + if (ret < 0)
> > + return ret;
> > +
> > + return sprintf(buf, "%d\n", temp);
> > +}
> > +static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, ds3232_hwmon_show_temp,
> > + NULL, 0);
> > +
> > +static struct attribute *ds3232_hwmon_attrs[] = {
> > + &sensor_dev_attr_temp1_input.dev_attr.attr,
> > + NULL,
> > +};
> > +ATTRIBUTE_GROUPS(ds3232_hwmon);
> > +
> > +static void ds3232_hwmon_register(struct device *dev, const char *name)
> > +{
> > + struct ds3232 *ds3232 = dev_get_drvdata(dev);
> > + struct device *hwmon_dev;
> > +
> > + hwmon_dev = devm_hwmon_device_register_with_groups(dev, name,
> ds3232,
> > +
> ds3232_hwmon_groups);
>
> Any reason for not using devm_hwmon_device_register_with_info() ?
>
>
Just to keep uniformity, because other rtc drivers with hwmon (rtc-ds1307,
rtc-rv3029c2) use
devm_hwmon_device_register_with_groups().
> Guenter
>
> > + if (IS_ERR(hwmon_dev)) {
> > + dev_warn(dev, "unable to register hwmon device %ld\n",
> > + PTR_ERR(hwmon_dev));
> > + }
> > +}
> > +
> > +#else
> > +
> > +static void ds3232_hwmon_register(struct ds3232 *ds3232)
> > +{
> > +}
> > +
> > +#endif
> > +
> > static int ds3232_alarm_irq_enable(struct device *dev, unsigned int
> enabled)
> > {
> > struct ds3232 *ds3232 = dev_get_drvdata(dev);
> > @@ -366,6 +448,8 @@ static int ds3232_probe(struct device *dev, struct
> regmap *regmap, int irq,
> > if (ds3232->irq > 0)
> > device_init_wakeup(dev, 1);
> >
> > + ds3232_hwmon_register(dev, name);
> > +
> > ds3232->rtc = devm_rtc_device_register(dev, name, &ds3232_rtc_ops,
> > THIS_MODULE);
> > if (IS_ERR(ds3232->rtc))
>
--
Kirill Esipov
[-- Attachment #2: Type: text/html, Size: 7444 bytes --]
^ permalink raw reply
* Re: rtc: ds3232: add temperature support
From: Kirill Esipov @ 2017-06-22 12:13 UTC (permalink / raw)
To: Guenter Roeck
Cc: Alessandro Zummo, alexandre.belloni, linux-rtc, linux-kernel
In-Reply-To: <20170621222421.GA23791@roeck-us.net>
2017-06-22 1:24 GMT+03:00 Guenter Roeck <linux@roeck-us.net>:
> On Wed, Jun 21, 2017 at 05:49:43PM +0300, Kirill Esipov wrote:
>> DS3232/DS3234 has the temperature registers with a resolution of
>> 0.25 degree celsius. This enables to get the value through hwmon.
>>
>> # cat /sys/class/hwmon/hwmon0/temp1_input
>> 37250
>>
>> Signed-off-by: Kirill Esipov <yesipov@gmail.com>
>> ---
>> drivers/rtc/Kconfig | 9 ++++++
>> drivers/rtc/rtc-ds3232.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 93 insertions(+)
>>
>> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
>> index 8d3b95728326..b4a6a916d4df 100644
>> --- a/drivers/rtc/Kconfig
>> +++ b/drivers/rtc/Kconfig
>> @@ -791,6 +791,15 @@ config RTC_DRV_DS3232
>> This driver can also be built as a module. If so, the module
>> will be called rtc-ds3232.
>>
>> +config RTC_DRV_DS3232_HWMON
>> + bool "HWMON support for Dallas/Maxim DS3232/DS3234"
>> + depends on RTC_DRV_DS3232 && HWMON
>> + depends on !(RTC_DRV_DS3232=y && HWMON=m)
>> + default y
>> + help
>> + Say Y here if you want to expose temperature sensor data on
>> + rtc-ds3232
>> +
>> config RTC_DRV_PCF2127
>> tristate "NXP PCF2127"
>> depends on RTC_I2C_AND_SPI
>> diff --git a/drivers/rtc/rtc-ds3232.c b/drivers/rtc/rtc-ds3232.c
>> index deff431a37c4..f94ff0685942 100644
>> --- a/drivers/rtc/rtc-ds3232.c
>> +++ b/drivers/rtc/rtc-ds3232.c
>> @@ -22,6 +22,8 @@
>> #include <linux/bcd.h>
>> #include <linux/slab.h>
>> #include <linux/regmap.h>
>> +#include <linux/hwmon.h>
>> +#include <linux/hwmon-sysfs.h>
>>
>> #define DS3232_REG_SECONDS 0x00
>> #define DS3232_REG_MINUTES 0x01
>> @@ -275,6 +277,86 @@ static int ds3232_update_alarm(struct device *dev, unsigned int enabled)
>> return ret;
>> }
>>
>> +/*----------------------------------------------------------------------*/
>> +
>> +#ifdef CONFIG_RTC_DRV_DS3232_HWMON
>> +
>> +/*
>> + * Temperature sensor support for ds3232/ds3234 devices.
>> + */
>> +
>> +#define DS3232_REG_TEMPERATURE 0x11
>> +
>> +/*
>> + * A user-initiated temperature conversion is not started by this function,
>> + * so the temperature is updated once every 64 seconds.
>> + */
>> +static int ds3232_hwmon_read_temp(struct device *dev, s32 *mC)
>> +{
>> + struct ds3232 *ds3232 = dev_get_drvdata(dev);
>> + u8 temp_buf[2];
>> + s16 temp;
>> + int ret;
>> +
>> + ret = regmap_bulk_read(ds3232->regmap, DS3232_REG_TEMPERATURE, temp_buf,
>> + sizeof(temp_buf));
>> +
>> + if (ret < 0)
>> + return ret;
>> +
>> + /*
>> + * Temperature is represented as a 10-bit code with a resolution of
>> + * 0.25 degree celsius and encoded in two's complement format.
>> + */
>> + temp = (temp_buf[0] << 8) | temp_buf[1];
>> + temp >>= 6;
>> + *mC = temp * 250;
>> +
>> + return 0;
>> +}
>> +
>> +static ssize_t ds3232_hwmon_show_temp(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + int ret;
>> + s32 temp;
>> +
>> + ret = ds3232_hwmon_read_temp(dev, &temp);
>> + if (ret < 0)
>> + return ret;
>> +
>> + return sprintf(buf, "%d\n", temp);
>> +}
>> +static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, ds3232_hwmon_show_temp,
>> + NULL, 0);
>> +
>> +static struct attribute *ds3232_hwmon_attrs[] = {
>> + &sensor_dev_attr_temp1_input.dev_attr.attr,
>> + NULL,
>> +};
>> +ATTRIBUTE_GROUPS(ds3232_hwmon);
>> +
>> +static void ds3232_hwmon_register(struct device *dev, const char *name)
>> +{
>> + struct ds3232 *ds3232 = dev_get_drvdata(dev);
>> + struct device *hwmon_dev;
>> +
>> + hwmon_dev = devm_hwmon_device_register_with_groups(dev, name, ds3232,
>> + ds3232_hwmon_groups);
>
> Any reason for not using devm_hwmon_device_register_with_info() ?
>
Just to keep uniformity, because other rtc drivers with hwmon
(rtc-ds1307, rtc-rv3029c2) use
devm_hwmon_device_register_with_groups().
> Guenter
>
>> + if (IS_ERR(hwmon_dev)) {
>> + dev_warn(dev, "unable to register hwmon device %ld\n",
>> + PTR_ERR(hwmon_dev));
>> + }
>> +}
>> +
>> +#else
>> +
>> +static void ds3232_hwmon_register(struct ds3232 *ds3232)
>> +{
>> +}
>> +
>> +#endif
>> +
>> static int ds3232_alarm_irq_enable(struct device *dev, unsigned int enabled)
>> {
>> struct ds3232 *ds3232 = dev_get_drvdata(dev);
>> @@ -366,6 +448,8 @@ static int ds3232_probe(struct device *dev, struct regmap *regmap, int irq,
>> if (ds3232->irq > 0)
>> device_init_wakeup(dev, 1);
>>
>> + ds3232_hwmon_register(dev, name);
>> +
>> ds3232->rtc = devm_rtc_device_register(dev, name, &ds3232_rtc_ops,
>> THIS_MODULE);
>> if (IS_ERR(ds3232->rtc))
--
Kirill Esipov
^ permalink raw reply
* Re: rtc: ds3232: add temperature support
From: Guenter Roeck @ 2017-06-22 13:44 UTC (permalink / raw)
To: Kirill Esipov
Cc: Alessandro Zummo, alexandre.belloni, linux-rtc, linux-kernel
In-Reply-To: <CAJcpCzGWiRRY2gZzNZVJOG2oLTsGjh9+DCn=vuY1A0szZf2Vjw@mail.gmail.com>
On 06/22/2017 05:07 AM, Kirill Esipov wrote:
>
>
> 2017-06-22 1:24 GMT+03:00 Guenter Roeck <linux@roeck-us.net <mailto:linux@roeck-us.net>>:
>
> On Wed, Jun 21, 2017 at 05:49:43PM +0300, Kirill Esipov wrote:
> > DS3232/DS3234 has the temperature registers with a resolution of
> > 0.25 degree celsius. This enables to get the value through hwmon.
> >
> > # cat /sys/class/hwmon/hwmon0/temp1_input
> > 37250
> >
> > Signed-off-by: Kirill Esipov <yesipov@gmail.com <mailto:yesipov@gmail.com>>
> > ---
> > drivers/rtc/Kconfig | 9 ++++++
> > drivers/rtc/rtc-ds3232.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 93 insertions(+)
> >
> > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> > index 8d3b95728326..b4a6a916d4df 100644
> > --- a/drivers/rtc/Kconfig
> > +++ b/drivers/rtc/Kconfig
> > @@ -791,6 +791,15 @@ config RTC_DRV_DS3232
> > This driver can also be built as a module. If so, the module
> > will be called rtc-ds3232.
> >
> > +config RTC_DRV_DS3232_HWMON
> > + bool "HWMON support for Dallas/Maxim DS3232/DS3234"
> > + depends on RTC_DRV_DS3232 && HWMON
> > + depends on !(RTC_DRV_DS3232=y && HWMON=m)
> > + default y
> > + help
> > + Say Y here if you want to expose temperature sensor data on
> > + rtc-ds3232
> > +
> > config RTC_DRV_PCF2127
> > tristate "NXP PCF2127"
> > depends on RTC_I2C_AND_SPI
> > diff --git a/drivers/rtc/rtc-ds3232.c b/drivers/rtc/rtc-ds3232.c
> > index deff431a37c4..f94ff0685942 100644
> > --- a/drivers/rtc/rtc-ds3232.c
> > +++ b/drivers/rtc/rtc-ds3232.c
> > @@ -22,6 +22,8 @@
> > #include <linux/bcd.h>
> > #include <linux/slab.h>
> > #include <linux/regmap.h>
> > +#include <linux/hwmon.h>
> > +#include <linux/hwmon-sysfs.h>
> >
> > #define DS3232_REG_SECONDS 0x00
> > #define DS3232_REG_MINUTES 0x01
> > @@ -275,6 +277,86 @@ static int ds3232_update_alarm(struct device *dev, unsigned int enabled)
> > return ret;
> > }
> >
> > +/*----------------------------------------------------------------------*/
> > +
> > +#ifdef CONFIG_RTC_DRV_DS3232_HWMON
> > +
> > +/*
> > + * Temperature sensor support for ds3232/ds3234 devices.
> > + */
> > +
> > +#define DS3232_REG_TEMPERATURE 0x11
> > +
> > +/*
> > + * A user-initiated temperature conversion is not started by this function,
> > + * so the temperature is updated once every 64 seconds.
> > + */
> > +static int ds3232_hwmon_read_temp(struct device *dev, s32 *mC)
> > +{
> > + struct ds3232 *ds3232 = dev_get_drvdata(dev);
> > + u8 temp_buf[2];
> > + s16 temp;
> > + int ret;
> > +
> > + ret = regmap_bulk_read(ds3232->regmap, DS3232_REG_TEMPERATURE, temp_buf,
> > + sizeof(temp_buf));
> > +
> > + if (ret < 0)
> > + return ret;
> > +
> > + /*
> > + * Temperature is represented as a 10-bit code with a resolution of
> > + * 0.25 degree celsius and encoded in two's complement format.
> > + */
> > + temp = (temp_buf[0] << 8) | temp_buf[1];
> > + temp >>= 6;
> > + *mC = temp * 250;
> > +
> > + return 0;
> > +}
> > +
> > +static ssize_t ds3232_hwmon_show_temp(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + int ret;
> > + s32 temp;
> > +
> > + ret = ds3232_hwmon_read_temp(dev, &temp);
> > + if (ret < 0)
> > + return ret;
> > +
> > + return sprintf(buf, "%d\n", temp);
> > +}
> > +static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, ds3232_hwmon_show_temp,
> > + NULL, 0);
> > +
> > +static struct attribute *ds3232_hwmon_attrs[] = {
> > + &sensor_dev_attr_temp1_input.dev_attr.attr,
> > + NULL,
> > +};
> > +ATTRIBUTE_GROUPS(ds3232_hwmon);
> > +
> > +static void ds3232_hwmon_register(struct device *dev, const char *name)
> > +{
> > + struct ds3232 *ds3232 = dev_get_drvdata(dev);
> > + struct device *hwmon_dev;
> > +
> > + hwmon_dev = devm_hwmon_device_register_with_groups(dev, name, ds3232,
> > + ds3232_hwmon_groups);
>
> Any reason for not using devm_hwmon_device_register_with_info() ?
>
>
>
> Just to keep uniformity, because other rtc drivers with hwmon (rtc-ds1307, rtc-rv3029c2) use
> devm_hwmon_device_register_with_groups().
>
Hmm. Odd reason. With this line of argument, a new API should never be used because
"everyone else uses the old API". How about converting the other drivers to use
new API instead ?
The idea behind the new API was to simplify drivers and make them independent
of the sysfs ABI. That doesn't mean that drivers _have_ to use that API, though,
so feel free to stick with the above.
Guenter
>
> Guenter
>
> > + if (IS_ERR(hwmon_dev)) {
> > + dev_warn(dev, "unable to register hwmon device %ld\n",
> > + PTR_ERR(hwmon_dev));
> > + }
> > +}
> > +
> > +#else
> > +
> > +static void ds3232_hwmon_register(struct ds3232 *ds3232)
> > +{
> > +}
> > +
> > +#endif
> > +
> > static int ds3232_alarm_irq_enable(struct device *dev, unsigned int enabled)
> > {
> > struct ds3232 *ds3232 = dev_get_drvdata(dev);
> > @@ -366,6 +448,8 @@ static int ds3232_probe(struct device *dev, struct regmap *regmap, int irq,
> > if (ds3232->irq > 0)
> > device_init_wakeup(dev, 1);
> >
> > + ds3232_hwmon_register(dev, name);
> > +
> > ds3232->rtc = devm_rtc_device_register(dev, name, &ds3232_rtc_ops,
> > THIS_MODULE);
> > if (IS_ERR(ds3232->rtc))
>
>
>
>
> --
> Kirill Esipov
^ permalink raw reply
* Re: rtc: ds3232: add temperature support
From: Kirill Esipov @ 2017-06-22 16:17 UTC (permalink / raw)
To: Guenter Roeck
Cc: Alessandro Zummo, alexandre.belloni, linux-rtc, linux-kernel
In-Reply-To: <8491fe94-16f2-e7a4-0cd9-385b5e0b600a@roeck-us.net>
2017-06-22 16:44 GMT+03:00 Guenter Roeck <linux@roeck-us.net>:
> On 06/22/2017 05:07 AM, Kirill Esipov wrote:
>>
>>
>>
>> 2017-06-22 1:24 GMT+03:00 Guenter Roeck <linux@roeck-us.net
>> <mailto:linux@roeck-us.net>>:
>>
>> On Wed, Jun 21, 2017 at 05:49:43PM +0300, Kirill Esipov wrote:
>> > DS3232/DS3234 has the temperature registers with a resolution of
>> > 0.25 degree celsius. This enables to get the value through hwmon.
>> >
>> > # cat /sys/class/hwmon/hwmon0/temp1_input
>> > 37250
>> >
>> > Signed-off-by: Kirill Esipov <yesipov@gmail.com
>> <mailto:yesipov@gmail.com>>
>>
>> > ---
>> > drivers/rtc/Kconfig | 9 ++++++
>> > drivers/rtc/rtc-ds3232.c | 84
>> ++++++++++++++++++++++++++++++++++++++++++++++++
>> > 2 files changed, 93 insertions(+)
>> >
>> > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
>> > index 8d3b95728326..b4a6a916d4df 100644
>> > --- a/drivers/rtc/Kconfig
>> > +++ b/drivers/rtc/Kconfig
>> > @@ -791,6 +791,15 @@ config RTC_DRV_DS3232
>> > This driver can also be built as a module. If so, the
>> module
>> > will be called rtc-ds3232.
>> >
>> > +config RTC_DRV_DS3232_HWMON
>> > + bool "HWMON support for Dallas/Maxim DS3232/DS3234"
>> > + depends on RTC_DRV_DS3232 && HWMON
>> > + depends on !(RTC_DRV_DS3232=y && HWMON=m)
>> > + default y
>> > + help
>> > + Say Y here if you want to expose temperature sensor data on
>> > + rtc-ds3232
>> > +
>> > config RTC_DRV_PCF2127
>> > tristate "NXP PCF2127"
>> > depends on RTC_I2C_AND_SPI
>> > diff --git a/drivers/rtc/rtc-ds3232.c b/drivers/rtc/rtc-ds3232.c
>> > index deff431a37c4..f94ff0685942 100644
>> > --- a/drivers/rtc/rtc-ds3232.c
>> > +++ b/drivers/rtc/rtc-ds3232.c
>> > @@ -22,6 +22,8 @@
>> > #include <linux/bcd.h>
>> > #include <linux/slab.h>
>> > #include <linux/regmap.h>
>> > +#include <linux/hwmon.h>
>> > +#include <linux/hwmon-sysfs.h>
>> >
>> > #define DS3232_REG_SECONDS 0x00
>> > #define DS3232_REG_MINUTES 0x01
>> > @@ -275,6 +277,86 @@ static int ds3232_update_alarm(struct device
>> *dev, unsigned int enabled)
>> > return ret;
>> > }
>> >
>> >
>> +/*----------------------------------------------------------------------*/
>> > +
>> > +#ifdef CONFIG_RTC_DRV_DS3232_HWMON
>> > +
>> > +/*
>> > + * Temperature sensor support for ds3232/ds3234 devices.
>> > + */
>> > +
>> > +#define DS3232_REG_TEMPERATURE 0x11
>> > +
>> > +/*
>> > + * A user-initiated temperature conversion is not started by this
>> function,
>> > + * so the temperature is updated once every 64 seconds.
>> > + */
>> > +static int ds3232_hwmon_read_temp(struct device *dev, s32 *mC)
>> > +{
>> > + struct ds3232 *ds3232 = dev_get_drvdata(dev);
>> > + u8 temp_buf[2];
>> > + s16 temp;
>> > + int ret;
>> > +
>> > + ret = regmap_bulk_read(ds3232->regmap,
>> DS3232_REG_TEMPERATURE, temp_buf,
>> > + sizeof(temp_buf));
>> > +
>> > + if (ret < 0)
>> > + return ret;
>> > +
>> > + /*
>> > + * Temperature is represented as a 10-bit code with a
>> resolution of
>> > + * 0.25 degree celsius and encoded in two's complement
>> format.
>> > + */
>> > + temp = (temp_buf[0] << 8) | temp_buf[1];
>> > + temp >>= 6;
>> > + *mC = temp * 250;
>> > +
>> > + return 0;
>> > +}
>> > +
>> > +static ssize_t ds3232_hwmon_show_temp(struct device *dev,
>> > + struct device_attribute *attr, char
>> *buf)
>> > +{
>> > + int ret;
>> > + s32 temp;
>> > +
>> > + ret = ds3232_hwmon_read_temp(dev, &temp);
>> > + if (ret < 0)
>> > + return ret;
>> > +
>> > + return sprintf(buf, "%d\n", temp);
>> > +}
>> > +static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO,
>> ds3232_hwmon_show_temp,
>> > + NULL, 0);
>> > +
>> > +static struct attribute *ds3232_hwmon_attrs[] = {
>> > + &sensor_dev_attr_temp1_input.dev_attr.attr,
>> > + NULL,
>> > +};
>> > +ATTRIBUTE_GROUPS(ds3232_hwmon);
>> > +
>> > +static void ds3232_hwmon_register(struct device *dev, const char
>> *name)
>> > +{
>> > + struct ds3232 *ds3232 = dev_get_drvdata(dev);
>> > + struct device *hwmon_dev;
>> > +
>> > + hwmon_dev = devm_hwmon_device_register_with_groups(dev, name,
>> ds3232,
>> > +
>> ds3232_hwmon_groups);
>>
>> Any reason for not using devm_hwmon_device_register_with_info() ?
>>
>>
>>
>> Just to keep uniformity, because other rtc drivers with hwmon
>> (rtc-ds1307, rtc-rv3029c2) use
>> devm_hwmon_device_register_with_groups().
>>
>
> Hmm. Odd reason. With this line of argument, a new API should never be used
> because "everyone else uses the old API".
Well, I had task to add temperature feature to my device, and the
cheapest (easiest)
way was to make it as in same device drivers. I did it and decided to share.
> How about converting the other drivers to use new API instead ?
Ok, at first I'll try to use new hwmon API for current driver (rtc-ds3232) .
> The idea behind the new API was to simplify drivers and make them
> independent
> of the sysfs ABI. That doesn't mean that drivers _have_ to use that API,
> though,
> so feel free to stick with the above.
>
> Guenter
>
>
>>
>> Guenter
>>
>> > + if (IS_ERR(hwmon_dev)) {
>> > + dev_warn(dev, "unable to register hwmon device
>> %ld\n",
>> > + PTR_ERR(hwmon_dev));
>> > + }
>> > +}
>> > +
>> > +#else
>> > +
>> > +static void ds3232_hwmon_register(struct ds3232 *ds3232)
>> > +{
>> > +}
>> > +
>> > +#endif
>> > +
>> > static int ds3232_alarm_irq_enable(struct device *dev, unsigned
>> int enabled)
>> > {
>> > struct ds3232 *ds3232 = dev_get_drvdata(dev);
>> > @@ -366,6 +448,8 @@ static int ds3232_probe(struct device *dev,
>> struct regmap *regmap, int irq,
>> > if (ds3232->irq > 0)
>> > device_init_wakeup(dev, 1);
>> >
>> > + ds3232_hwmon_register(dev, name);
>> > +
>> > ds3232->rtc = devm_rtc_device_register(dev, name,
>> &ds3232_rtc_ops,
>> > THIS_MODULE);
>> > if (IS_ERR(ds3232->rtc))
>>
>>
>>
>>
>> --
>> Kirill Esipov
>
>
--
Kirill Esipov
^ permalink raw reply
* [PATCH v2] rtc: ds3232: add temperature support
From: Kirill Esipov @ 2017-06-22 16:58 UTC (permalink / raw)
To: a.zummo, alexandre.belloni; +Cc: linux-rtc, linux-kernel, Kirill Esipov
DS3232/DS3234 has the temperature registers with a resolution of 0.25
degree celsius. This enables to get the value through hwmon.
# cat /sys/class/hwmon/hwmon0/temp1_input
37250
Signed-off-by: Kirill Esipov <yesipov@gmail.com>
---
drivers/rtc/Kconfig | 9 ++++
drivers/rtc/rtc-ds3232.c | 134 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 143 insertions(+)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 8d3b95728326..b4a6a916d4df 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -791,6 +791,15 @@ config RTC_DRV_DS3232
This driver can also be built as a module. If so, the module
will be called rtc-ds3232.
+config RTC_DRV_DS3232_HWMON
+ bool "HWMON support for Dallas/Maxim DS3232/DS3234"
+ depends on RTC_DRV_DS3232 && HWMON
+ depends on !(RTC_DRV_DS3232=y && HWMON=m)
+ default y
+ help
+ Say Y here if you want to expose temperature sensor data on
+ rtc-ds3232
+
config RTC_DRV_PCF2127
tristate "NXP PCF2127"
depends on RTC_I2C_AND_SPI
diff --git a/drivers/rtc/rtc-ds3232.c b/drivers/rtc/rtc-ds3232.c
index deff431a37c4..4e7913c2ed79 100644
--- a/drivers/rtc/rtc-ds3232.c
+++ b/drivers/rtc/rtc-ds3232.c
@@ -22,6 +22,7 @@
#include <linux/bcd.h>
#include <linux/slab.h>
#include <linux/regmap.h>
+#include <linux/hwmon.h>
#define DS3232_REG_SECONDS 0x00
#define DS3232_REG_MINUTES 0x01
@@ -275,6 +276,137 @@ static int ds3232_update_alarm(struct device *dev, unsigned int enabled)
return ret;
}
+/*----------------------------------------------------------------------*/
+
+#ifdef CONFIG_RTC_DRV_DS3232_HWMON
+
+/*
+ * Temperature sensor support for ds3232/ds3234 devices.
+ */
+
+#define DS3232_REG_TEMPERATURE 0x11
+
+/*
+ * A user-initiated temperature conversion is not started by this function,
+ * so the temperature is updated once every 64 seconds.
+ */
+static int ds3232_hwmon_read_temp(struct device *dev, long int *mC)
+{
+ struct ds3232 *ds3232 = dev_get_drvdata(dev);
+ u8 temp_buf[2];
+ s16 temp;
+ int ret;
+
+ ret = regmap_bulk_read(ds3232->regmap, DS3232_REG_TEMPERATURE, temp_buf,
+ sizeof(temp_buf));
+
+ if (ret < 0)
+ return ret;
+
+ /*
+ * Temperature is represented as a 10-bit code with a resolution of
+ * 0.25 degree celsius and encoded in two's complement format.
+ */
+ temp = (temp_buf[0] << 8) | temp_buf[1];
+ temp >>= 6;
+ *mC = temp * 250;
+
+ return 0;
+}
+
+static umode_t ds3232_hwmon_is_visible(const void *data,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ if (type != hwmon_temp)
+ return 0;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ return 0444;
+ default:
+ return 0;
+ }
+}
+
+static int ds3232_hwmon_read(struct device *dev,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel, long *temp)
+{
+ int err;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ ds3232_hwmon_read_temp(dev, temp);
+ err = 0;
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return err;
+}
+
+
+static u32 ds3232_hwmon_chip_config[] = {
+ HWMON_C_REGISTER_TZ,
+ 0
+};
+
+static const struct hwmon_channel_info ds3232_hwmon_chip = {
+ .type = hwmon_chip,
+ .config = ds3232_hwmon_chip_config,
+};
+
+static u32 ds3232_hwmon_temp_config[] = {
+ HWMON_T_INPUT,
+ 0
+};
+
+static const struct hwmon_channel_info ds3232_hwmon_temp = {
+ .type = hwmon_temp,
+ .config = ds3232_hwmon_temp_config,
+};
+
+static const struct hwmon_channel_info *ds3232_hwmon_info[] = {
+ &ds3232_hwmon_chip,
+ &ds3232_hwmon_temp,
+ NULL
+};
+
+static const struct hwmon_ops ds3232_hwmon_hwmon_ops = {
+ .is_visible = ds3232_hwmon_is_visible,
+ .read = ds3232_hwmon_read,
+};
+
+static const struct hwmon_chip_info ds3232_hwmon_chip_info = {
+ .ops = &ds3232_hwmon_hwmon_ops,
+ .info = ds3232_hwmon_info,
+};
+
+static void ds3232_hwmon_register(struct device *dev, const char *name)
+{
+ struct ds3232 *ds3232 = dev_get_drvdata(dev);
+ struct device *hwmon_dev;
+
+ hwmon_dev = devm_hwmon_device_register_with_info(dev, name, ds3232,
+ &ds3232_hwmon_chip_info,
+ NULL);
+
+ if (IS_ERR(hwmon_dev)) {
+ dev_warn(dev, "unable to register hwmon device %ld\n",
+ PTR_ERR(hwmon_dev));
+ }
+}
+
+#else
+
+static void ds3232_hwmon_register(struct device *dev, const char *name)
+{
+}
+
+#endif
+
static int ds3232_alarm_irq_enable(struct device *dev, unsigned int enabled)
{
struct ds3232 *ds3232 = dev_get_drvdata(dev);
@@ -366,6 +498,8 @@ static int ds3232_probe(struct device *dev, struct regmap *regmap, int irq,
if (ds3232->irq > 0)
device_init_wakeup(dev, 1);
+ ds3232_hwmon_register(dev, name);
+
ds3232->rtc = devm_rtc_device_register(dev, name, &ds3232_rtc_ops,
THIS_MODULE);
if (IS_ERR(ds3232->rtc))
--
2.7.4
^ permalink raw reply related
* [PATCH] rtc: rtc-nuc900: fix loop timeout test
From: Dan Carpenter @ 2017-06-23 8:29 UTC (permalink / raw)
To: Wan ZongShun
Cc: Alessandro Zummo, Alexandre Belloni, linux-rtc, kernel-janitors
We should change this post-op to a pre-op because we want the loop to
exit with "timeout" set to zero.
Fixes: 0a89b55364e0 ("nuc900/rtc: change the waiting for device ready implement")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/rtc/rtc-nuc900.c b/drivers/rtc/rtc-nuc900.c
index b1b6b3041bfb..4ed81117cf5f 100644
--- a/drivers/rtc/rtc-nuc900.c
+++ b/drivers/rtc/rtc-nuc900.c
@@ -93,7 +93,7 @@ static int *check_rtc_access_enable(struct nuc900_rtc *nuc900_rtc)
__raw_writel(AERPOWERON, nuc900_rtc->rtc_reg + REG_RTC_AER);
while (!(__raw_readl(nuc900_rtc->rtc_reg + REG_RTC_AER) & AERRWENB)
- && timeout--)
+ && --timeout)
mdelay(1);
if (!timeout)
^ permalink raw reply related
* [rtc-linux] Re: [PATCH 1/2] dt-bindings: Document the Broadcom STB wake-up timer node
From: Rob Herring @ 2017-06-23 18:40 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Alessandro Zummo, Alexandre Belloni, 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-2-f.fainelli@gmail.com>
On Thu, Jun 15, 2017 at 12:59:03PM -0700, Florian Fainelli wrote:
> 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
Acked-by: Rob Herring <robh@kernel.org>
--
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
* [rtc-linux] Re: [PATCH v2 0/3] rtc: make st-lpc robust against y2038/2106 bug
From: Shuah Khan @ 2017-06-23 19:40 UTC (permalink / raw)
To: Benjamin Gaignard, john.stultz, tglx, sboyd, linux-kernel,
linux-kselftest, patrice.chotard, a.zummo, alexandre.belloni,
linux-arm-kernel, rtc-linux
Cc: linaro-kernel, Shuah Khan
In-Reply-To: <1497864982-29284-1-git-send-email-benjamin.gaignard@linaro.org>
On 06/19/2017 03:36 AM, Benjamin Gaignard wrote:
> 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 one RTC test file 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.
>
> On this version 2 I add check of problematics years in rtctest like suggest
> by Alexandre.
>
> Finally that had allowed me to test and fix rtc-st-lpc driver.
>
> Benjamin Gaignard (3):
> tools: timer: add rtctest_setdate
> tool: timer: rtctest add check for problematic dates
> rtc: st-lpc: make it robust against y2038/2106 bug
>
> drivers/rtc/rtc-st-lpc.c | 19 ++--
> tools/testing/selftests/timers/Makefile | 2 +-
> tools/testing/selftests/timers/rtctest.c | 121 ++++++++++++++++++++++-
> tools/testing/selftests/timers/rtctest_setdate.c | 86 ++++++++++++++++
> 4 files changed, 212 insertions(+), 16 deletions(-)
> create mode 100644 tools/testing/selftests/timers/rtctest_setdate.c
>
Hi Thomas/John,
I can take the first two patches in this series through linux-kselftest
with your or John's Ack. Please review and let me know one way or the
other.
The third one is a rtc driver patch. Please let me know how do you want
to handle this series soon we can get this into 4.13-rc1.
thanks,
-- Shah
--
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
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