Re: [RESEND PATCH] rtc: rk808: rename rtc-rk808.c to rtc-rk8xx.c
On Mon, 4 Jan 2016 10:45:46 +0100 Alexandre Belloni wrote: > I'm not sure it is useful to do that renaming. It is usual to have one > driver that supports multiple chips named with the forst chip it > supported. > > Also, what would happen if for example rk855 is not compatible at all > with the previous implementations? Alexandre is absolutely right. There's no need to rename a driver, it would just piss off people who are used to that name and have it in their scripts. Like when your eth0 gets renamed to some obscure enXXX . -- Best regards, Alessandro Zummo - CEO, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH] rtc: rk808: rename rtc-rk808.c to rtc-rk8xx.c
On Mon, 4 Jan 2016 10:45:46 +0100 Alexandre Belloni <alexandre.bell...@free-electrons.com> wrote: > I'm not sure it is useful to do that renaming. It is usual to have one > driver that supports multiple chips named with the forst chip it > supported. > > Also, what would happen if for example rk855 is not compatible at all > with the previous implementations? Alexandre is absolutely right. There's no need to rename a driver, it would just piss off people who are used to that name and have it in their scripts. Like when your eth0 gets renamed to some obscure enXXX . -- Best regards, Alessandro Zummo - CEO, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] char: make misc_deregister a void function
On Thu, 30 Jul 2015 15:59:57 -0700 Greg Kroah-Hartman wrote: > If the different subsystem maintainers want to give me an ack for this, > I'd appreciate it. I'd like to just take the single patch in through > the char-misc tree in one piece. RTC Acked-by: Alessandro Zummo -- Best regards, Alessandro Zummo - CEO, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] char: make misc_deregister a void function
On Thu, 30 Jul 2015 15:59:57 -0700 Greg Kroah-Hartman gre...@linuxfoundation.org wrote: If the different subsystem maintainers want to give me an ack for this, I'd appreciate it. I'd like to just take the single patch in through the char-misc tree in one piece. RTC Acked-by: Alessandro Zummo a.zu...@towertech.it -- Best regards, Alessandro Zummo - CEO, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [5/5] drivers/rtc/sa1100: Replace deprecated rtc_tm_to_time() and rtc_time_to_tm()
On Mon, 1 Jun 2015 21:59:09 +0200 Alexandre Belloni wrote: > I feel that we still have a bit of time before having to hurry and find > a proper solution ;) agreed :) -- Best regards, Alessandro Zummo - CEO, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [5/5] drivers/rtc/sa1100: Replace deprecated rtc_tm_to_time() and rtc_time_to_tm()
On Mon, 1 Jun 2015 21:59:09 +0200 Alexandre Belloni alexandre.bell...@free-electrons.com wrote: I feel that we still have a bit of time before having to hurry and find a proper solution ;) agreed :) -- Best regards, Alessandro Zummo - CEO, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: [PATCH 3/3] rtc: hctosys: use function name in the error log
On Tue, 31 Mar 2015 20:18:28 -0700 Joe Perches wrote: > Neither __func__ or __FILE__ is really useful here. > The message is already specific enough without it. > > If anything, it'd probably be better to add > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt Seems reasonable given that pr_fmt is widely used elsewhere. I don't like too much the need to have one define for each file, but it's the way it works :-/ -- Best regards, Alessandro Zummo - CEO, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: [PATCH 3/3] rtc: hctosys: use function name in the error log
On Tue, 31 Mar 2015 20:18:28 -0700 Joe Perches j...@perches.com wrote: Neither __func__ or __FILE__ is really useful here. The message is already specific enough without it. If anything, it'd probably be better to add #define pr_fmt(fmt) KBUILD_MODNAME : fmt Seems reasonable given that pr_fmt is widely used elsewhere. I don't like too much the need to have one define for each file, but it's the way it works :-/ -- Best regards, Alessandro Zummo - CEO, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: [PATCH] MAINTAINERS: Add Alexandre Belloni as an RTC maintainer
On Sat, 28 Mar 2015 22:29:20 +0100 Alexandre Belloni wrote: > I'll keep that in mind. > Could you give me permissions on the rtc-linux patchwork? Sure. Let me find the way to do it :) -- Best regards, Alessandro Zummo - CEO, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: [PATCH] MAINTAINERS: Add Alexandre Belloni as an RTC maintainer
On Sat, 28 Mar 2015 22:29:20 +0100 Alexandre Belloni alexandre.bell...@free-electrons.com wrote: I'll keep that in mind. Could you give me permissions on the rtc-linux patchwork? Sure. Let me find the way to do it :) -- Best regards, Alessandro Zummo - CEO, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: Add Alexandre Belloni as an RTC maintainer
On Wed, 25 Mar 2015 22:57:31 +0100 Alexandre Belloni wrote: > I'd like to propose myself as the RTC susbsystem co-maintainer, to mainly help > Alessandro reviewing incoming patches and maintain a subsystem tree to avoid > having the RTC patches going through trees when they have no particular > dependencies. Thanks :) A few things I consider important: - a driver for a new hardware usually causes no harm to the subsystem - a patch for an existing driver should be approved by the original author, if possible. there are a few chips out there that are quite rare or have multiple wiring configuration and break very easily. -- Best regards, Alessandro Zummo - CEO, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: Add Alexandre Belloni as an RTC maintainer
On Wed, 25 Mar 2015 22:57:31 +0100 Alexandre Belloni alexandre.bell...@free-electrons.com wrote: I'd like to propose myself as the RTC susbsystem co-maintainer, to mainly help Alessandro reviewing incoming patches and maintain a subsystem tree to avoid having the RTC patches going through trees when they have no particular dependencies. Thanks :) A few things I consider important: - a driver for a new hardware usually causes no harm to the subsystem - a patch for an existing driver should be approved by the original author, if possible. there are a few chips out there that are quite rare or have multiple wiring configuration and break very easily. -- Best regards, Alessandro Zummo - CEO, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 0/8] Provide y2038/y2106 safe rtc_class_ops.set_mmss64()
On Wed, 18 Mar 2015 10:37:26 -0700 John Stultz wrote: > On Wed, Jan 28, 2015 at 10:27 AM, Alessandro Zummo > wrote: > > On Thu, 29 Jan 2015 00:12:09 +0800 > > Xunlei Pang wrote: > > > >> ping Alessandro > > > > -EBUSY . saw that, looks fine anyhow, but would like to > > have a deeper look. we have still some time 'till 2038, right? ;) > > Hey Alessandro, > I was hoping to let these go through you (with your review), but if > you're still too busy I can queue them if you'd rather. Looks fine to me. The only thing that I would change is the naming of the drivername_rtc_set_mmss in the drivers: it should end with mmss64 when it's changed. But that's probably just me being pedantic. Acked-by: Alessandro Zummo Can you please queue them? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 0/8] Provide y2038/y2106 safe rtc_class_ops.set_mmss64()
On Wed, 18 Mar 2015 10:37:26 -0700 John Stultz john.stu...@linaro.org wrote: On Wed, Jan 28, 2015 at 10:27 AM, Alessandro Zummo a.zu...@towertech.it wrote: On Thu, 29 Jan 2015 00:12:09 +0800 Xunlei Pang pang.xun...@linaro.org wrote: ping Alessandro -EBUSY . saw that, looks fine anyhow, but would like to have a deeper look. we have still some time 'till 2038, right? ;) Hey Alessandro, I was hoping to let these go through you (with your review), but if you're still too busy I can queue them if you'd rather. Looks fine to me. The only thing that I would change is the naming of the drivername_rtc_set_mmss in the drivers: it should end with mmss64 when it's changed. But that's probably just me being pedantic. Acked-by: Alessandro Zummo a.zu...@towertech.it Can you please queue them? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 0/8] Provide y2038/y2106 safe rtc_class_ops.set_mmss64()
On Wed, 18 Mar 2015 10:37:26 -0700 John Stultz wrote: > Hey Alessandro, > I was hoping to let these go through you (with your review), but if > you're still too busy I can queue them if you'd rather. Hello, will review today and let you know. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 0/8] Provide y2038/y2106 safe rtc_class_ops.set_mmss64()
On Wed, 18 Mar 2015 10:37:26 -0700 John Stultz john.stu...@linaro.org wrote: Hey Alessandro, I was hoping to let these go through you (with your review), but if you're still too busy I can queue them if you'd rather. Hello, will review today and let you know. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 0/8] Provide y2038/y2106 safe rtc_class_ops.set_mmss64()
On Thu, 29 Jan 2015 00:12:09 +0800 Xunlei Pang wrote: > ping Alessandro -EBUSY . saw that, looks fine anyhow, but would like to have a deeper look. we have still some time 'till 2038, right? ;) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 0/8] Provide y2038/y2106 safe rtc_class_ops.set_mmss64()
On Thu, 29 Jan 2015 00:12:09 +0800 Xunlei Pang pang.xun...@linaro.org wrote: ping Alessandro -EBUSY . saw that, looks fine anyhow, but would like to have a deeper look. we have still some time 'till 2038, right? ;) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 3/9] rtc/test: Update driver to address y2038/y2106 issues
On Wed, 14 Jan 2015 23:26:37 +0800 Xunlei Pang wrote: > But on the other hand, we will have no test for set_mmss64(), > because adding the set_mmss64() will make set_mmss() dysfunctional. add a module parameter -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 3/9] rtc/test: Update driver to address y2038/y2106 issues
On Wed, 14 Jan 2015 22:56:15 +0800 Xunlei Pang wrote: > We want to do away with set_mmss() eventually, time64 is the final version, > so I think this would be ok. We'll get rid of set_mmss() from the test driver later on, after everything else has been converted :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 3/9] rtc/test: Update driver to address y2038/y2106 issues
On Wed, 14 Jan 2015 22:56:15 +0800 Xunlei Pang pang.xun...@linaro.org wrote: We want to do away with set_mmss() eventually, time64 is the final version, so I think this would be ok. We'll get rid of set_mmss() from the test driver later on, after everything else has been converted :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 3/9] rtc/test: Update driver to address y2038/y2106 issues
On Wed, 14 Jan 2015 23:26:37 +0800 Xunlei Pang pang.xun...@linaro.org wrote: But on the other hand, we will have no test for set_mmss64(), because adding the set_mmss64() will make set_mmss() dysfunctional. add a module parameter -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 6/9] rtc/mxc: Modify rtc_update_alarm() not to touch the alarm time
On Tue, 13 Jan 2015 23:44:54 +0800 Xunlei Pang wrote: > rtc_class_ops's set_alarm() shouldn't deal with the alarm date, > as this is handled in the rtc core. Please CC the author and ask him. The same applies for the other drivers. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 2/9] time: Provide y2106 safe get_seconds() replacement
On Tue, 13 Jan 2015 23:44:50 +0800 Xunlei Pang wrote: > -EXPORT_SYMBOL(get_seconds); > +EXPORT_SYMBOL(get_seconds64); Please leave get_seconds untouched -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 3/9] rtc/test: Update driver to address y2038/y2106 issues
On Tue, 13 Jan 2015 23:44:51 +0800 Xunlei Pang wrote: > This patch resolves them by: > - Repalce get_seconds() with get_seconds64() > - Replace rtc_time_to_tm() with rtc_time64_to_tm() > - Change test_rtc_set_mmss() to use rtc_class_ops's set_mmss64() so we no more have a non time64 test driver? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 4/9] rtc/ab3100: Update driver to address y2038/y2106 issues
On Tue, 13 Jan 2015 23:44:52 +0800 Xunlei Pang wrote: > From: Xunlei Pang > > This driver has a number of y2038/y2106 issues. This should probably be evaluated by Linus Walleij -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 1/9] rtc: Provide y2038 safe rtc_class_ops.set_mmss() replacement
On Tue, 13 Jan 2015 23:44:49 +0800
Xunlei Pang wrote:
> + else if (rtc->ops->set_mmss64) {
> + ;
> +
> + secs64 = rtc_tm_to_time64(tm);
time64_t secs64 = rtc_tm_to_time64(tm);
would do as well. add spaces, variables
and empty lines only when required for readability.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 1/9] rtc: Provide y2038 safe rtc_class_ops.set_mmss() replacement
On Tue, 13 Jan 2015 23:44:49 +0800
Xunlei Pang xlp...@126.com wrote:
+ else if (rtc-ops-set_mmss64) {
+ ;
+
+ secs64 = rtc_tm_to_time64(tm);
time64_t secs64 = rtc_tm_to_time64(tm);
would do as well. add spaces, variables
and empty lines only when required for readability.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 4/9] rtc/ab3100: Update driver to address y2038/y2106 issues
On Tue, 13 Jan 2015 23:44:52 +0800 Xunlei Pang xlp...@126.com wrote: From: Xunlei Pang pang.xun...@linaro.org This driver has a number of y2038/y2106 issues. This should probably be evaluated by Linus Walleij linus.wall...@stericsson.com -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 3/9] rtc/test: Update driver to address y2038/y2106 issues
On Tue, 13 Jan 2015 23:44:51 +0800 Xunlei Pang xlp...@126.com wrote: This patch resolves them by: - Repalce get_seconds() with get_seconds64() - Replace rtc_time_to_tm() with rtc_time64_to_tm() - Change test_rtc_set_mmss() to use rtc_class_ops's set_mmss64() so we no more have a non time64 test driver? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 6/9] rtc/mxc: Modify rtc_update_alarm() not to touch the alarm time
On Tue, 13 Jan 2015 23:44:54 +0800 Xunlei Pang xlp...@126.com wrote: rtc_class_ops's set_alarm() shouldn't deal with the alarm date, as this is handled in the rtc core. Please CC the author and ask him. The same applies for the other drivers. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 2/9] time: Provide y2106 safe get_seconds() replacement
On Tue, 13 Jan 2015 23:44:50 +0800 Xunlei Pang xlp...@126.com wrote: -EXPORT_SYMBOL(get_seconds); +EXPORT_SYMBOL(get_seconds64); Please leave get_seconds untouched -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCHv2] drivers/rtc/rtc-snvs: Add clock support
On Thu, 04 Dec 2014 13:29:58 +0100 Stefan Agner wrote: > > Acked-by: Alessandro Zummo > > Through which tree is this going upstream? Andrew usually picks up those small patches, unless there's a more appropriate tree. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCHv2] drivers/rtc/rtc-snvs: Add clock support
On Wed, 3 Dec 2014 11:28:55 +0530 Sanchayan Maity wrote: > The clock is not strictly enforced, as this would > break the i.MX devices. The clocking for the i.MX > devices seems to be enabled elsewhere and enabling > RTC SNVS for Vybrid results in a crash. This patch > adds the clock support but also makes it optional > so Vybrid platform can use the clock if defined > while making sure not to break i.MX . > > Signed-off-by: Sanchayan Maity Acked-by: Alessandro Zummo -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCHv2] drivers/rtc/rtc-snvs: Add clock support
On Wed, 3 Dec 2014 11:28:55 +0530 Sanchayan Maity maitysancha...@gmail.com wrote: The clock is not strictly enforced, as this would break the i.MX devices. The clocking for the i.MX devices seems to be enabled elsewhere and enabling RTC SNVS for Vybrid results in a crash. This patch adds the clock support but also makes it optional so Vybrid platform can use the clock if defined while making sure not to break i.MX . Signed-off-by: Sanchayan Maity maitysancha...@gmail.com Acked-by: Alessandro Zummo a.zu...@towertech.it -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCHv2] drivers/rtc/rtc-snvs: Add clock support
On Thu, 04 Dec 2014 13:29:58 +0100 Stefan Agner ste...@agner.ch wrote: Acked-by: Alessandro Zummo a.zu...@towertech.it Through which tree is this going upstream? Andrew usually picks up those small patches, unless there's a more appropriate tree. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 4/4] rtc/imxdi: Update driver to address time issues
On Sat, 29 Nov 2014 00:20:00 +0800 "pang.xunlei" wrote: > Anyway, they are ungraceful being there. I'll refine this patchset carefully > according to your valuable suggestions, and will send out another version. > > Thanks for your review! I have quite the feeling those patches will cause headaches to a lot of people. Too many of this stuff seems a copy & paste work, without actually looking/thinking to the side effects. Is there any particular reason your are pursuing this? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 4/4] rtc/imxdi: Update driver to address time issues
On Sat, 29 Nov 2014 00:20:00 +0800 pang.xunlei pang.xun...@linaro.org wrote: Anyway, they are ungraceful being there. I'll refine this patchset carefully according to your valuable suggestions, and will send out another version. Thanks for your review! I have quite the feeling those patches will cause headaches to a lot of people. Too many of this stuff seems a copy paste work, without actually looking/thinking to the side effects. Is there any particular reason your are pursuing this? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v3] rtc: ds1307: add trickle charger device tree binding
On Mon, 8 Sep 2014 07:26:57 -0400 Jason Cooper wrote: > Most likely, the rtc maintainer will take the series with the DT > maintainers Acks. You made all the binding changes as discussed by Mark > and I, so fwiw, > > Acked-by: Jason Cooper Acked-by: Alessandro Zummo -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v3] rtc: ds1307: add trickle charger device tree binding
On Mon, 8 Sep 2014 07:26:57 -0400 Jason Cooper ja...@lakedaemon.net wrote: Most likely, the rtc maintainer will take the series with the DT maintainers Acks. You made all the binding changes as discussed by Mark and I, so fwiw, Acked-by: Jason Cooper ja...@lakedaemon.net Acked-by: Alessandro Zummo a.zu...@towertech.it -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC V1] mfd: da9063: Add support for AD silicon variant
On Wed, 16 Jul 2014 17:39:20 +0100 "Opensource [Steve Twiss]" wrote: > The DA9063 probe function has been modified to use the compile time > directive CONFIG_MFD_DA9063_AD. This configuration option will allow > AD support only if this boolean is true, otherwise it will default to > support BB (or greater) silicon. any particular reason for not supporting both at the same time, either with a module option, platform data, dt, etc ? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC V1] mfd: da9063: Add support for AD silicon variant
On Wed, 16 Jul 2014 17:39:20 +0100 Opensource [Steve Twiss] stwiss.opensou...@diasemi.com wrote: The DA9063 probe function has been modified to use the compile time directive CONFIG_MFD_DA9063_AD. This configuration option will allow AD support only if this boolean is true, otherwise it will default to support BB (or greater) silicon. any particular reason for not supporting both at the same time, either with a module option, platform data, dt, etc ? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] [PATCH] drivers/rtc/interface.c: check the error after __rtc_read_time()
On Fri, 4 Jul 2014 10:22:26 +0900 Hyogi Gim wrote: > In __rtc_set_alarm(), the error after __rtc_read_time() is not checked. > If rtc device fail to read time, we cannot guarantee the following process. > > Add the verification code for returned __rtc_read_time() error. > > Signed-off-by: Hyogi Gim Acked-by: Alessandro Zummo -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] [PATCH] drivers/rtc/interface.c: check the error after __rtc_read_time()
On Fri, 4 Jul 2014 10:22:26 +0900 Hyogi Gim hyogi@lge.com wrote: In __rtc_set_alarm(), the error after __rtc_read_time() is not checked. If rtc device fail to read time, we cannot guarantee the following process. Add the verification code for returned __rtc_read_time() error. Signed-off-by: Hyogi Gim hyogi@lge.com Acked-by: Alessandro Zummo a.zu...@towertech.it -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2][RFC] Try to handle hctosys w/ rtc modules
On Sat, 28 Jun 2014 20:54:33 +0200 Marc Dietrich wrote: > > Besides that the current hctosys-mechanism doesn't really work with > > hot-plugable devices at all. Guess what N will be when you unplug and > > plug in such a RTC again. > > We have a patch in the kernel which binds the rtc number to the > hw device, so this even works for hotpluggable devices (at least on > systems supporting device-tree). Not sure what your needs are. I'm still not sure about how to solve this, maybe it would be better to identify the hctosys device that should be used at boot with a different identifier than rtcX (and move the option to the kernel command line) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2][RFC] Try to handle hctosys w/ rtc modules
On Sat, 28 Jun 2014 20:54:33 +0200 Marc Dietrich marvi...@gmx.de wrote: Besides that the current hctosys-mechanism doesn't really work with hot-plugable devices at all. Guess what N will be when you unplug and plug in such a RTC again. We have a patch in the kernel which binds the rtc number to the hw device, so this even works for hotpluggable devices (at least on systems supporting device-tree). Not sure what your needs are. I'm still not sure about how to solve this, maybe it would be better to identify the hctosys device that should be used at boot with a different identifier than rtcX (and move the option to the kernel command line) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rtc/hctosys.c Problem during kernel boot
I'm testing them and they're working fine so far. Will handle them the next week. -- Best regards, Alessandro Zummo Tower Technologies Sent from my iPhone, please excuse my brevity. > On 21/giu/2014, at 15:08, Alexander Holler wrote: > > Am 12.06.2014 01:53, schrieb John Stultz: > >> You can read some of the previous discussion here: >> https://lkml.org/lkml/2013/6/17/533 >> >> I'd be very interested in patches to resolve this! > > And the silence as response to my repost of my already working patches just > proved that isn't true. > > So (John Whitmore), I suggest to not post patches, Linux kernel maintainers > don't really have an interest in getting things done or to fix bugs, they > just need fresh meat they can review in order to have job security and prove > their status. > > I really wonder what's their expectation. Do they really think other people > have to incorporate their (often silly) requests, making the maintainers > themself not responsible for their requested changes? Do they think other > people have fun and time to write and post patches again and again just to > make some arbitrary maintainer happy? > > If there really would be an interest, a reasonable approach would be to just > take my patches and put a patch on top with whatever changes someone thinks > are needed. As I don't think there are changes needed, I will not add such > changes using my name as author. > > And don't try to tell me I'm uncooperative. I've spend time to write these > patches and even have written documentation I don't need myself. The > uncooperative people which are blocking almost everthing and which do ignore > bugs have become these people which are calling themself Linux kernel > maintainers which do expect other people have to play remote keyboard and > have to take responsibility for changes maintainers don't want to be > responsible for themself. > > So the above quoted sentence is just another "marketing" verbiage, at least > in my point of view. > > Alexander Holler > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rtc/hctosys.c Problem during kernel boot
I'm testing them and they're working fine so far. Will handle them the next week. -- Best regards, Alessandro Zummo Tower Technologies Sent from my iPhone, please excuse my brevity. On 21/giu/2014, at 15:08, Alexander Holler hol...@ahsoftware.de wrote: Am 12.06.2014 01:53, schrieb John Stultz: You can read some of the previous discussion here: https://lkml.org/lkml/2013/6/17/533 I'd be very interested in patches to resolve this! And the silence as response to my repost of my already working patches just proved that isn't true. So (John Whitmore), I suggest to not post patches, Linux kernel maintainers don't really have an interest in getting things done or to fix bugs, they just need fresh meat they can review in order to have job security and prove their status. I really wonder what's their expectation. Do they really think other people have to incorporate their (often silly) requests, making the maintainers themself not responsible for their requested changes? Do they think other people have fun and time to write and post patches again and again just to make some arbitrary maintainer happy? If there really would be an interest, a reasonable approach would be to just take my patches and put a patch on top with whatever changes someone thinks are needed. As I don't think there are changes needed, I will not add such changes using my name as author. And don't try to tell me I'm uncooperative. I've spend time to write these patches and even have written documentation I don't need myself. The uncooperative people which are blocking almost everthing and which do ignore bugs have become these people which are calling themself Linux kernel maintainers which do expect other people have to play remote keyboard and have to take responsibility for changes maintainers don't want to be responsible for themself. So the above quoted sentence is just another marketing verbiage, at least in my point of view. Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 07/10] regulator: Add driver for Maxim 77802 PMIC regulators
On Wed, 18 Jun 2014 15:10:48 +0100 Lee Jones wrote: > > So I guess you should either a) take the whole patch-set through your mfd > > tree > > or b) merge the mfd patches and create an immutable branch that can be > > pulled by > > Mark, Mike and Alessandro. > > > > I don't know what's the preferred workflow in these cases... > > That's fine. I'm happy to create shared branches when required. mfd tree will be ok. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 07/10] regulator: Add driver for Maxim 77802 PMIC regulators
On Wed, 18 Jun 2014 15:10:48 +0100 Lee Jones lee.jo...@linaro.org wrote: So I guess you should either a) take the whole patch-set through your mfd tree or b) merge the mfd patches and create an immutable branch that can be pulled by Mark, Mike and Alessandro. I don't know what's the preferred workflow in these cases... That's fine. I'm happy to create shared branches when required. mfd tree will be ok. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rtc/hctosys.c Problem during kernel boot
On Thu, 12 Jun 2014 14:01:46 +0200 Alexander Holler wrote: > Unfortunately my expieriences with Linux kernel maintainers became even > worse and I'm not very eager to post patches. But if someone wants these > patches based on 3.15, feel free to notice me. > > To get rid of hctosys, I have 3 patches, and 2 more to implement > rtc_read_timeval() for higher resolution clocks. Yes, I know the experience might be a painful one. Please send the patches and let's see if they fix the issue for John too. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rtc/hctosys.c Problem during kernel boot
On Thu, 12 Jun 2014 14:01:46 +0200 Alexander Holler hol...@ahsoftware.de wrote: Unfortunately my expieriences with Linux kernel maintainers became even worse and I'm not very eager to post patches. But if someone wants these patches based on 3.15, feel free to notice me. To get rid of hctosys, I have 3 patches, and 2 more to implement rtc_read_timeval() for higher resolution clocks. Yes, I know the experience might be a painful one. Please send the patches and let's see if they fix the issue for John too. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] [PATCH] rtc: fix potential race condition and remove build errors
On Mon, 19 May 2014 21:28:20 +0530 Raghavendra Ganiga wrote: > also the sysfs will not create entry for alarm if > irq registration fails in probe > > Signed-off-by: Raghavendra Chandra Ganiga Acked-by: Alessandro Zummo -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] [PATCH] rtc: fix potential race condition and remove build errors
On Mon, 19 May 2014 21:28:20 +0530 Raghavendra Ganiga ravi23gan...@gmail.com wrote: also the sysfs will not create entry for alarm if irq registration fails in probe Signed-off-by: Raghavendra Chandra Ganiga ravi23gan...@gmail.com Acked-by: Alessandro Zummo a.zu...@towertech.it -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: query regarding not returning error if request_irq fails after rtc registration
On Thu, 15 May 2014 22:15:14 +0530 RAGHAVENDRA GANIGA wrote: > my question is that the set_alarm and alarm_irq_enable is still active, > so should i use some flag in the global private variable of the driver > so that if the request irq fails, then using this flag the set_alarm > and alarm_irq_enable can return error since there is no irq handler > for the rtc interrupt > or is there any other solution > or let the set_alarm and alarm_irq_enable routine be as it is and will you can use a flag (or set the irq to -1) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: query regarding not returning error if request_irq fails after rtc registration
On Thu, 15 May 2014 22:15:14 +0530 RAGHAVENDRA GANIGA ravi23gan...@gmail.com wrote: my question is that the set_alarm and alarm_irq_enable is still active, so should i use some flag in the global private variable of the driver so that if the request irq fails, then using this flag the set_alarm and alarm_irq_enable can return error since there is no irq handler for the rtc interrupt or is there any other solution or let the set_alarm and alarm_irq_enable routine be as it is and will you can use a flag (or set the irq to -1) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: Add support for Microchip MCP795
On Tue, 6 May 2014 19:13:18 +0200 a...@atx.name wrote: > Adds driver for SPI RTC Microchip MCP795. Does only support saving/loading > time from the chip (i. e. no alarms/power events/ID). > > Signed-off-by: Josef Gajdusek Acked-by: Alessandro Zummo -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: Add support for Microchip MCP795
On Tue, 6 May 2014 19:13:18 +0200 a...@atx.name wrote: Adds driver for SPI RTC Microchip MCP795. Does only support saving/loading time from the chip (i. e. no alarms/power events/ID). Signed-off-by: Josef Gajdusek a...@atx.name Acked-by: Alessandro Zummo a.zu...@towertech.it -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rtc: add support for maxim dallas rtc ds1343 and ds1344
On Mon, 05 May 2014 23:46:06 +0530 RAGHAVENDRA GANIGA wrote: > 1. glitch filter read and write parameter > 2. alarm status read parameter > 3. alarm mode read parameter > 4. trickle charger read parameter > > and i am removing the proc interface. > > is the above implementation ok as per your last comment > on the proc interface. please provide the feedback. That's sounds like a plan. Please send the code when you're ready. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: X86: Impossible select Enhanced Real Time Clock Support (legacy PC RTC driver)
On Tue, 6 May 2014 00:34:41 +0100 (BST) "Maciej W. Rozycki" wrote: > Well, the handling of update-ended interrupts is still missing, as is > some non-x86 stuff I posted a fix for recently (still pending review, can > you please look into it sometime?). Done, sorry for the delay. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] [PATCH 1/2] RTC: rtc-cmos: drivers/char/rtc.c features for DECstation support
On Sat, 19 Apr 2014 23:58:20 +0100 (BST) "Maciej W. Rozycki" wrote: > This brings in drivers/char/rtc.c functionality required for DECstation > and, should the maintainers decide to switch, Alpha systems to use > rtc-cmos. Seems sane. We need to be sure it doesn't break anything on non-Alpha machines. Did you test it on x86? It would be fine if we can get a couple of Tested-by: -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] [PATCH 1/2] RTC: rtc-cmos: drivers/char/rtc.c features for DECstation support
On Sat, 19 Apr 2014 23:58:20 +0100 (BST) Maciej W. Rozycki ma...@linux-mips.org wrote: This brings in drivers/char/rtc.c functionality required for DECstation and, should the maintainers decide to switch, Alpha systems to use rtc-cmos. Seems sane. We need to be sure it doesn't break anything on non-Alpha machines. Did you test it on x86? It would be fine if we can get a couple of Tested-by: -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: X86: Impossible select Enhanced Real Time Clock Support (legacy PC RTC driver)
On Tue, 6 May 2014 00:34:41 +0100 (BST) Maciej W. Rozycki ma...@linux-mips.org wrote: Well, the handling of update-ended interrupts is still missing, as is some non-x86 stuff I posted a fix for recently (still pending review, can you please look into it sometime?). Done, sorry for the delay. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rtc: add support for maxim dallas rtc ds1343 and ds1344
On Mon, 05 May 2014 23:46:06 +0530 RAGHAVENDRA GANIGA ravi23gan...@gmail.com wrote: 1. glitch filter read and write parameter 2. alarm status read parameter 3. alarm mode read parameter 4. trickle charger read parameter and i am removing the proc interface. is the above implementation ok as per your last comment on the proc interface. please provide the feedback. That's sounds like a plan. Please send the code when you're ready. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: add support for maxim dallas rtc ds1343 and ds1344
On Wed, 30 Apr 2014 21:55:07 +0530
Raghavendra Ganiga wrote:
> +
> +static int ds1343_proc(struct device *dev, struct seq_file *seq)
> +{
> + struct ds1343_priv *priv = dev_get_drvdata(dev);
> + unsigned int data;
> + unsigned char alarm_mode = 0;
> + const char *alarm_str, *diodes = "disabled", *resistors = " ";
> +
> + regmap_read(priv->map, DS1343_CONTROL_REG, );
is this thing really useful? what about having sysfs entries
instead?
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: add support for maxim dallas rtc ds1343 and ds1344
On Wed, 30 Apr 2014 21:55:07 +0530
Raghavendra Ganiga ravi23gan...@gmail.com wrote:
+
+static int ds1343_proc(struct device *dev, struct seq_file *seq)
+{
+ struct ds1343_priv *priv = dev_get_drvdata(dev);
+ unsigned int data;
+ unsigned char alarm_mode = 0;
+ const char *alarm_str, *diodes = disabled, *resistors = ;
+
+ regmap_read(priv-map, DS1343_CONTROL_REG, data);
is this thing really useful? what about having sysfs entries
instead?
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: X86: Impossible select Enhanced Real Time Clock Support (legacy PC RTC driver)
On Mon, 28 Apr 2014 11:16:37 -0700 John Stultz wrote: > >> This breaks the API since there is no more misc device /dev/rtc > >> available without a udev rule or a link to /dev/rtc0. > > So yea.. I feel like that /dev/rtcN renaming (and API) break (which > was a huge and annoying pain) was back in the 2.6.18-ish era? It's very old and linking/renaming is around since then. > But it sounds like the driver/char/rtc bit is dead code, and needs a > cleanup? Or is there some use of that code that you need that the > generic RTC layer doesn't have? as far as I know, no recent distribution is using the old code anymore and the new (well, not so new anymore) framework provides the same functionality. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: X86: Impossible select Enhanced Real Time Clock Support (legacy PC RTC driver)
On Mon, 28 Apr 2014 11:16:37 -0700 John Stultz john.stu...@linaro.org wrote: This breaks the API since there is no more misc device /dev/rtc available without a udev rule or a link to /dev/rtc0. So yea.. I feel like that /dev/rtcN renaming (and API) break (which was a huge and annoying pain) was back in the 2.6.18-ish era? It's very old and linking/renaming is around since then. But it sounds like the driver/char/rtc bit is dead code, and needs a cleanup? Or is there some use of that code that you need that the generic RTC layer doesn't have? as far as I know, no recent distribution is using the old code anymore and the new (well, not so new anymore) framework provides the same functionality. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: [PATCH resend] mfd/rtc: s5m: Do not allocate RTC I2C dummy and regmap for unsupported chipsets
On Thu, 17 Apr 2014 09:08:47 +0100 Lee Jones wrote: > MFD changes look good to me. If Alessandro provides his Ack for the > RTC adaptions I can setup an MFD-RTC branch for him to pull from in > order to save conflicts at merge time. Hello, I do not keep an rtc git, so please add it to mfd or via another tree / next. The patch looks good to m. Acked-by: Alessandro Zummo -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: [PATCH resend] mfd/rtc: s5m: Do not allocate RTC I2C dummy and regmap for unsupported chipsets
On Thu, 17 Apr 2014 09:08:47 +0100 Lee Jones lee.jo...@linaro.org wrote: MFD changes look good to me. If Alessandro provides his Ack for the RTC adaptions I can setup an MFD-RTC branch for him to pull from in order to save conflicts at merge time. Hello, I do not keep an rtc git, so please add it to mfd or via another tree / next. The patch looks good to m. Acked-by: Alessandro Zummo a.zu...@towertech.it -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V1 2/2] rtc: da9063: RTC driver
On Fri, 11 Apr 2014 11:45:33 + "Opensource [Steve Twiss]" wrote: > Is it possible to merge my RTC patch so it appears in linux-next please? > > You originally Acked it around 1 month ago > https://lkml.org/lkml/2014/3/7/112 Please send me (cc to the list) the whole patchset. thanks! -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V1 2/2] rtc: da9063: RTC driver
On Fri, 11 Apr 2014 11:45:33 + Opensource [Steve Twiss] stwiss.opensou...@diasemi.com wrote: Is it possible to merge my RTC patch so it appears in linux-next please? You originally Acked it around 1 month ago https://lkml.org/lkml/2014/3/7/112 Please send me (cc to the list) the whole patchset. thanks! -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC: Fix infinite loop in initializing the alarm.
On Tue, 8 Apr 2014 00:54:42 +0200 Ales Novak wrote: > In __rtc_read_alarm(), if the alarm time retrieved by > rtc_read_alarm_internal() from the device contains invalid values > (e.g. month=2,mday=31) and the year not set (=-1), the initialization > will loop infinitely because the year-fixing loop expects the > time being invalid due to leap year. > > Fix reduces the loop to the leap years and adds final validity check. > > Signed-off-by: Ales Novak Seems reasonable. Acked-by: Alessandro Zummo -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC: Fix infinite loop in initializing the alarm.
On Tue, 8 Apr 2014 00:54:42 +0200 Ales Novak alno...@suse.cz wrote: In __rtc_read_alarm(), if the alarm time retrieved by rtc_read_alarm_internal() from the device contains invalid values (e.g. month=2,mday=31) and the year not set (=-1), the initialization will loop infinitely because the year-fixing loop expects the time being invalid due to leap year. Fix reduces the loop to the leap years and adds final validity check. Signed-off-by: Ales Novak alno...@suse.cz Seems reasonable. Acked-by: Alessandro Zummo a.zu...@towertech.it -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernfs/rtc: circular dependency between kernfs and ops_lock
On Mon, 31 Mar 2014 13:07:10 +0200 Lars-Peter Clausen wrote: > It doesn't really matter where it is unregistered. device_unregister() will > (somewhere down it's callchain) take the kernfs lock, hence it must be > callled with the rtc mutex being held. Maybe device_remove_attrs could be called in the rtc base class, before the device removal? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernfs/rtc: circular dependency between kernfs and ops_lock
On Mon, 31 Mar 2014 11:52:36 +0200 Lars-Peter Clausen wrote: > It's the same bug, device_unregister(>dev) will try to unregister all > sysfs files attached to the device and that function is still called with > the rtc mutex held. rtc-cmos tries to unregister the rtc device in the probe function, which should not be done. the last patches fixes it. I'll keep trying to trigger the bug on my systems. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernfs/rtc: circular dependency between kernfs and ops_lock
On Sun, 30 Mar 2014 12:04:16 -0400
Sasha Levin wrote:
> > Look good, thanks!
>
> Or not...
>
> Hit it again during overnight fuzzing:
>
I think this is a different bug, please try this.
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index cae212f..2c77d8e 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -712,6 +712,20 @@ cmos_do_probe(struct device *dev, struct resource *ports,
int rtc_irq)
}
}
+ spin_lock_irq(_lock);
+ rtc_control = CMOS_READ(RTC_CONTROL);
+ spin_unlock_irq(_lock);
+
+ /* FIXME:
+* doesn't know 12-hour mode either.
+*/
+ if (is_valid_irq(rtc_irq) && !(rtc_control & RTC_24H)) {
+ dev_warn(dev, "only 24-hr supported\n");
+ retval = -ENXIO;
+ goto cleanup0;
+ }
+
+
cmos_rtc.dev = dev;
dev_set_drvdata(dev, _rtc);
@@ -739,49 +753,49 @@ cmos_do_probe(struct device *dev, struct resource *ports,
int rtc_irq)
/* disable irqs */
cmos_irq_disable(_rtc, RTC_PIE | RTC_AIE | RTC_UIE);
- rtc_control = CMOS_READ(RTC_CONTROL);
-
spin_unlock_irq(_lock);
- /* FIXME:
-* doesn't know 12-hour mode either.
-*/
- if (is_valid_irq(rtc_irq) && !(rtc_control & RTC_24H)) {
- dev_warn(dev, "only 24-hr supported\n");
- retval = -ENXIO;
- goto cleanup1;
- }
-
if (is_valid_irq(rtc_irq)) {
- irq_handler_t rtc_cmos_int_handler;
+
+ irq_handler_t rtc_cmos_int_handler = NULL;
if (is_hpet_enabled()) {
- rtc_cmos_int_handler = hpet_rtc_interrupt;
+
retval = hpet_register_irq_handler(cmos_interrupt);
if (retval) {
dev_warn(dev, "hpet_register_irq_handler "
" failed in rtc_init().");
- goto cleanup1;
+ } else {
+ rtc_cmos_int_handler = hpet_rtc_interrupt;
}
- } else
+ } else {
rtc_cmos_int_handler = cmos_interrupt;
+ }
- retval = request_irq(rtc_irq, rtc_cmos_int_handler,
- 0, dev_name(_rtc.rtc->dev),
- cmos_rtc.rtc);
- if (retval < 0) {
- dev_dbg(dev, "IRQ %d is already in use\n", rtc_irq);
- goto cleanup1;
+ if (rtc_cmos_int_handler) {
+ retval = request_irq(rtc_irq, rtc_cmos_int_handler,
+ 0, dev_name(_rtc.rtc->dev),
+ cmos_rtc.rtc);
+ if (retval < 0) {
+
+ dev_err(dev, "IRQ %d is already in use\n",
rtc_irq);
+
+ cmos_rtc.irq = -1;
+
+ if (is_hpet_enabled()) {
+
hpet_unregister_irq_handler(cmos_interrupt);
+ }
+ }
}
}
+
hpet_rtc_timer_init();
/* export at least the first block of NVRAM */
nvram.size = address_space - NVRAM_OFFSET;
retval = sysfs_create_bin_file(>kobj, );
if (retval < 0) {
- dev_dbg(dev, "can't create nvram file? %d\n", retval);
- goto cleanup2;
+ dev_err(dev, "can't create nvram file? %d\n", retval);
}
dev_info(dev, "%s%s, %zd bytes nvram%s\n",
@@ -795,12 +809,6 @@ cmos_do_probe(struct device *dev, struct resource *ports,
int rtc_irq)
return 0;
-cleanup2:
- if (is_valid_irq(rtc_irq))
- free_irq(rtc_irq, cmos_rtc.rtc);
-cleanup1:
- cmos_rtc.dev = NULL;
- rtc_device_unregister(cmos_rtc.rtc);
cleanup0:
release_region(ports->start, resource_size(ports));
return retval;
@@ -823,8 +831,12 @@ static void __exit cmos_do_remove(struct device *dev)
sysfs_remove_bin_file(>kobj, );
if (is_valid_irq(cmos->irq)) {
+
free_irq(cmos->irq, cmos->rtc);
- hpet_unregister_irq_handler(cmos_interrupt);
+
+ if (is_hpet_enabled()) {
+ hpet_unregister_irq_handler(cmos_interrupt);
+ }
}
rtc_device_unregister(cmos->rtc);
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernfs/rtc: circular dependency between kernfs and ops_lock
On Sun, 30 Mar 2014 12:04:16 -0400
Sasha Levin sasha.le...@oracle.com wrote:
Look good, thanks!
Or not...
Hit it again during overnight fuzzing:
I think this is a different bug, please try this.
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index cae212f..2c77d8e 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -712,6 +712,20 @@ cmos_do_probe(struct device *dev, struct resource *ports,
int rtc_irq)
}
}
+ spin_lock_irq(rtc_lock);
+ rtc_control = CMOS_READ(RTC_CONTROL);
+ spin_unlock_irq(rtc_lock);
+
+ /* FIXME:
+* asm-generic/rtc.h doesn't know 12-hour mode either.
+*/
+ if (is_valid_irq(rtc_irq) !(rtc_control RTC_24H)) {
+ dev_warn(dev, only 24-hr supported\n);
+ retval = -ENXIO;
+ goto cleanup0;
+ }
+
+
cmos_rtc.dev = dev;
dev_set_drvdata(dev, cmos_rtc);
@@ -739,49 +753,49 @@ cmos_do_probe(struct device *dev, struct resource *ports,
int rtc_irq)
/* disable irqs */
cmos_irq_disable(cmos_rtc, RTC_PIE | RTC_AIE | RTC_UIE);
- rtc_control = CMOS_READ(RTC_CONTROL);
-
spin_unlock_irq(rtc_lock);
- /* FIXME:
-* asm-generic/rtc.h doesn't know 12-hour mode either.
-*/
- if (is_valid_irq(rtc_irq) !(rtc_control RTC_24H)) {
- dev_warn(dev, only 24-hr supported\n);
- retval = -ENXIO;
- goto cleanup1;
- }
-
if (is_valid_irq(rtc_irq)) {
- irq_handler_t rtc_cmos_int_handler;
+
+ irq_handler_t rtc_cmos_int_handler = NULL;
if (is_hpet_enabled()) {
- rtc_cmos_int_handler = hpet_rtc_interrupt;
+
retval = hpet_register_irq_handler(cmos_interrupt);
if (retval) {
dev_warn(dev, hpet_register_irq_handler
failed in rtc_init().);
- goto cleanup1;
+ } else {
+ rtc_cmos_int_handler = hpet_rtc_interrupt;
}
- } else
+ } else {
rtc_cmos_int_handler = cmos_interrupt;
+ }
- retval = request_irq(rtc_irq, rtc_cmos_int_handler,
- 0, dev_name(cmos_rtc.rtc-dev),
- cmos_rtc.rtc);
- if (retval 0) {
- dev_dbg(dev, IRQ %d is already in use\n, rtc_irq);
- goto cleanup1;
+ if (rtc_cmos_int_handler) {
+ retval = request_irq(rtc_irq, rtc_cmos_int_handler,
+ 0, dev_name(cmos_rtc.rtc-dev),
+ cmos_rtc.rtc);
+ if (retval 0) {
+
+ dev_err(dev, IRQ %d is already in use\n,
rtc_irq);
+
+ cmos_rtc.irq = -1;
+
+ if (is_hpet_enabled()) {
+
hpet_unregister_irq_handler(cmos_interrupt);
+ }
+ }
}
}
+
hpet_rtc_timer_init();
/* export at least the first block of NVRAM */
nvram.size = address_space - NVRAM_OFFSET;
retval = sysfs_create_bin_file(dev-kobj, nvram);
if (retval 0) {
- dev_dbg(dev, can't create nvram file? %d\n, retval);
- goto cleanup2;
+ dev_err(dev, can't create nvram file? %d\n, retval);
}
dev_info(dev, %s%s, %zd bytes nvram%s\n,
@@ -795,12 +809,6 @@ cmos_do_probe(struct device *dev, struct resource *ports,
int rtc_irq)
return 0;
-cleanup2:
- if (is_valid_irq(rtc_irq))
- free_irq(rtc_irq, cmos_rtc.rtc);
-cleanup1:
- cmos_rtc.dev = NULL;
- rtc_device_unregister(cmos_rtc.rtc);
cleanup0:
release_region(ports-start, resource_size(ports));
return retval;
@@ -823,8 +831,12 @@ static void __exit cmos_do_remove(struct device *dev)
sysfs_remove_bin_file(dev-kobj, nvram);
if (is_valid_irq(cmos-irq)) {
+
free_irq(cmos-irq, cmos-rtc);
- hpet_unregister_irq_handler(cmos_interrupt);
+
+ if (is_hpet_enabled()) {
+ hpet_unregister_irq_handler(cmos_interrupt);
+ }
}
rtc_device_unregister(cmos-rtc);
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernfs/rtc: circular dependency between kernfs and ops_lock
On Mon, 31 Mar 2014 11:52:36 +0200 Lars-Peter Clausen l...@metafoo.de wrote: It's the same bug, device_unregister(rtc-dev) will try to unregister all sysfs files attached to the device and that function is still called with the rtc mutex held. rtc-cmos tries to unregister the rtc device in the probe function, which should not be done. the last patches fixes it. I'll keep trying to trigger the bug on my systems. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernfs/rtc: circular dependency between kernfs and ops_lock
On Mon, 31 Mar 2014 13:07:10 +0200 Lars-Peter Clausen l...@metafoo.de wrote: It doesn't really matter where it is unregistered. device_unregister() will (somewhere down it's callchain) take the kernfs lock, hence it must be callled with the rtc mutex being held. Maybe device_remove_attrs could be called in the rtc base class, before the device removal? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernfs/rtc: circular dependency between kernfs and ops_lock
On Tue, 25 Mar 2014 17:52:30 -0400
Sasha Levin wrote:
> >
> > Pretty interesting indeed. One option would be to remove
> > the sys files before acquiring the lock. But I wonder
> > if this could lead to other issues.
> >
>
> Ping? Seems this thing got lost.
What if we move
rtc_sysfs_del_device(rtc);
before acquiring the lock?
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 589351e..a0c19a3 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -261,11 +261,13 @@ EXPORT_SYMBOL_GPL(rtc_device_register);
void rtc_device_unregister(struct rtc_device *rtc)
{
if (get_device(>dev) != NULL) {
+
+ rtc_sysfs_del_device(rtc);
+
mutex_lock(>ops_lock);
/* remove innards of this RTC, then disable it, before
* letting any rtc_class_open() users access it again
*/
- rtc_sysfs_del_device(rtc);
rtc_dev_del_device(rtc);
rtc_proc_del_device(rtc);
device_unregister(>dev);
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernfs/rtc: circular dependency between kernfs and ops_lock
On Tue, 25 Mar 2014 17:52:30 -0400
Sasha Levin sasha.le...@oracle.com wrote:
Pretty interesting indeed. One option would be to remove
the sys files before acquiring the lock. But I wonder
if this could lead to other issues.
Ping? Seems this thing got lost.
What if we move
rtc_sysfs_del_device(rtc);
before acquiring the lock?
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 589351e..a0c19a3 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -261,11 +261,13 @@ EXPORT_SYMBOL_GPL(rtc_device_register);
void rtc_device_unregister(struct rtc_device *rtc)
{
if (get_device(rtc-dev) != NULL) {
+
+ rtc_sysfs_del_device(rtc);
+
mutex_lock(rtc-ops_lock);
/* remove innards of this RTC, then disable it, before
* letting any rtc_class_open() users access it again
*/
- rtc_sysfs_del_device(rtc);
rtc_dev_del_device(rtc);
rtc_proc_del_device(rtc);
device_unregister(rtc-dev);
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] [PATCH] rtc: add support for maxim dallas rtc ds1347
On Fri, 21 Mar 2014 20:05:40 +0530 RAGHAVENDRA GANIGA wrote: > From 0fd7f9ab5c0cb5e857b7b4d6893a8e68ac7763fd Mon Sep 17 00:00:00 2001 > From: Raghavendra Ganiga > Date: Fri, 21 Mar 2014 19:53:36 +0530 > Subject: [PATCH] rtc: add support for maxim dallas rtc ds1347 > > This is a patch to add support for > maxim dallas rtc ds1347 > > Signed-off-by: Raghavendra Chandra Ganiga Acked-by: Alessandro Zummo -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] [PATCH] rtc: add support for maxim dallas rtc ds1347
On Fri, 21 Mar 2014 20:05:40 +0530 RAGHAVENDRA GANIGA ravi23gan...@gmail.com wrote: From 0fd7f9ab5c0cb5e857b7b4d6893a8e68ac7763fd Mon Sep 17 00:00:00 2001 From: Raghavendra Ganiga ravi23gan...@gmail.com Date: Fri, 21 Mar 2014 19:53:36 +0530 Subject: [PATCH] rtc: add support for maxim dallas rtc ds1347 This is a patch to add support for maxim dallas rtc ds1347 Signed-off-by: Raghavendra Chandra Ganiga ravi23gan...@gmail.com Acked-by: Alessandro Zummo a.zu...@towertech.it -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: add support for maxim dallas rtc ds1347
On Thu, 20 Mar 2014 12:19:55 -0700 Joe Perches wrote: > This depends on how long you want to live, but it could be > > while (dt->tm_year >= 100) dt->tm_year % 100 ? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: add support for maxim dallas rtc ds1347
;
> + buf[5] = bin2bcd(dt->tm_mon + 1);
> + buf[6] = bin2bcd(dt->tm_wday + 1);
> +
> + /*year in linux is from 1900 i.e in range of 100
> + in rtc it is from 00 to 99 so subtract
please leave a space after /*
> + the linux year by 100*/
and before */
(ditto for the other comments)
> + if (dt->tm_year >= 100)
> + dt->tm_year -= 100;
> +
> + buf[7] = bin2bcd(dt->tm_year);
> + buf[8] = bin2bcd(0x00);
> +
> + /*write the rtc settings*/
> + return spi_write_then_read(spi, buf, 9, NULL, 0);
> +}
> +
> +
> +
extra white lines
> +static const struct rtc_class_ops ds1347_rtc_ops = {
> + .read_time = ds1347_read_time,
> + .set_time = ds1347_set_time,
> +};
> +
> +static int ds1347_probe(struct spi_device *spi)
> +{
> + struct rtc_device *rtc;
> + unsigned char data;
> + int res;
> +
> + /*spi setup with ds1347 in mode 3 and bits per word as 8*/
> + spi->mode = SPI_MODE_3;
> + spi->bits_per_word = 8;
> + spi_setup(spi);
> +
> + /*RTC Settings*/
> +
unnecessary comment
> + /*check if spi read is successfull*/
unnecessary comment, this is pretty clear
> + res = ds1347_read_reg(>dev, DS1347_SECONDS_REG, );
> + if (res)
> + return res;
> +
> + /*Disable the write protect of rtc*/
> + ds1347_read_reg(>dev, DS1347_CONTROL_REG, );
> + data = data & ~(1<<7);
> + ds1347_write_reg(>dev, DS1347_CONTROL_REG, data);
> +
> + /*Enable the oscillator , disable the oscillator stop flag,
> + and glitch filter to reduce current consumption*/
> + ds1347_read_reg(>dev, DS1347_STATUS_REG, );
> + data = data & 0x1B;
> + ds1347_write_reg(>dev, DS1347_STATUS_REG, data);
> +
> + /*display the settings*/
> + ds1347_read_reg(>dev, DS1347_CONTROL_REG, );
> + dev_info(>dev, "DS1347 RTC CTRL Reg = 0x%02x\n", data);
> +
> + ds1347_read_reg(>dev, DS1347_STATUS_REG, );
> + dev_info(>dev, "DS1347 RTC Status Reg = 0x%02x\n", data);
> +
> + rtc = devm_rtc_device_register(>dev, "ds1347",
> + _rtc_ops, THIS_MODULE);
> +
> + if (IS_ERR(rtc))
> + return PTR_ERR(rtc);
> +
> + spi_set_drvdata(spi, rtc);
> +
> + return 0;
> +}
> +
> +static struct spi_driver ds1347_driver = {
> + .driver = {
> + .name = "ds1347",
> + .owner = THIS_MODULE,
> + },
> + .probe = ds1347_probe,
> +};
> +
> +module_spi_driver(ds1347_driver);
> +
> +MODULE_DESCRIPTION("DS1347 SPI RTC DRIVER");
> +MODULE_AUTHOR("Raghavendra C Ganiga ");
> +MODULE_LICENSE("GPL");
should be GPL v2
as you declared in the comments at the top of the file.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: add support for maxim dallas rtc ds1347
, 9, NULL, 0);
+}
+
+
+
extra white lines
+static const struct rtc_class_ops ds1347_rtc_ops = {
+ .read_time = ds1347_read_time,
+ .set_time = ds1347_set_time,
+};
+
+static int ds1347_probe(struct spi_device *spi)
+{
+ struct rtc_device *rtc;
+ unsigned char data;
+ int res;
+
+ /*spi setup with ds1347 in mode 3 and bits per word as 8*/
+ spi-mode = SPI_MODE_3;
+ spi-bits_per_word = 8;
+ spi_setup(spi);
+
+ /*RTC Settings*/
+
unnecessary comment
+ /*check if spi read is successfull*/
unnecessary comment, this is pretty clear
+ res = ds1347_read_reg(spi-dev, DS1347_SECONDS_REG, data);
+ if (res)
+ return res;
+
+ /*Disable the write protect of rtc*/
+ ds1347_read_reg(spi-dev, DS1347_CONTROL_REG, data);
+ data = data ~(17);
+ ds1347_write_reg(spi-dev, DS1347_CONTROL_REG, data);
+
+ /*Enable the oscillator , disable the oscillator stop flag,
+ and glitch filter to reduce current consumption*/
+ ds1347_read_reg(spi-dev, DS1347_STATUS_REG, data);
+ data = data 0x1B;
+ ds1347_write_reg(spi-dev, DS1347_STATUS_REG, data);
+
+ /*display the settings*/
+ ds1347_read_reg(spi-dev, DS1347_CONTROL_REG, data);
+ dev_info(spi-dev, DS1347 RTC CTRL Reg = 0x%02x\n, data);
+
+ ds1347_read_reg(spi-dev, DS1347_STATUS_REG, data);
+ dev_info(spi-dev, DS1347 RTC Status Reg = 0x%02x\n, data);
+
+ rtc = devm_rtc_device_register(spi-dev, ds1347,
+ ds1347_rtc_ops, THIS_MODULE);
+
+ if (IS_ERR(rtc))
+ return PTR_ERR(rtc);
+
+ spi_set_drvdata(spi, rtc);
+
+ return 0;
+}
+
+static struct spi_driver ds1347_driver = {
+ .driver = {
+ .name = ds1347,
+ .owner = THIS_MODULE,
+ },
+ .probe = ds1347_probe,
+};
+
+module_spi_driver(ds1347_driver);
+
+MODULE_DESCRIPTION(DS1347 SPI RTC DRIVER);
+MODULE_AUTHOR(Raghavendra C Ganiga ravi23gan...@gmail.com);
+MODULE_LICENSE(GPL);
should be GPL v2
as you declared in the comments at the top of the file.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: add support for maxim dallas rtc ds1347
On Thu, 20 Mar 2014 12:19:55 -0700 Joe Perches j...@perches.com wrote: This depends on how long you want to live, but it could be while (dt-tm_year = 100) dt-tm_year % 100 ? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V1 2/2] rtc: da9063: RTC driver
On Thu, 6 Mar 2014 16:40:02 + "Opensource [Steve Twiss]" wrote: > Change History: > > Changes made to this driver since previous RFC V1 > Comments by Alessandro Zummo > - http://www.kernelhub.org/?p=2=426327 > - Use return PTR_ERR(rtc->rtc_dev); instead of goto err; return err. > - Request the interrupt before the RTC device is registered with the > call to devm_rtc_device_register. Acked-by: Alessandro Zummo -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V1 2/2] rtc: da9063: RTC driver
On Thu, 6 Mar 2014 16:40:02 + Opensource [Steve Twiss] stwiss.opensou...@diasemi.com wrote: Change History: Changes made to this driver since previous RFC V1 Comments by Alessandro Zummo - http://www.kernelhub.org/?p=2msg=426327 - Use return PTR_ERR(rtc-rtc_dev); instead of goto err; return err. - Request the interrupt before the RTC device is registered with the call to devm_rtc_device_register. Acked-by: Alessandro Zummo a.zu...@towertech.it -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC V1 2/2] rtc: da9063: RTC driver
On Wed, 5 Mar 2014 12:25:16 +
"Opensource [Steve Twiss]" wrote:
> + if (IS_ERR(rtc->rtc_dev)) {
> + ret = PTR_ERR(rtc->rtc_dev);
> + goto err;
> + }
please,
return PTR_ERR()
> +
> + irq_alarm = platform_get_irq_byname(pdev, "ALARM");
> + ret = devm_request_threaded_irq(>dev, irq_alarm, NULL,
> + da9063_alarm_event,
> + IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> + "ALARM", rtc);
> + if (ret)
> + dev_err(>dev, "Failed to request ALARM IRQ %d: %d\n",
> + irq_alarm, ret);
> +
> + da9063_data_to_tm(data, >alarm_time);
> + rtc->rtc_sync = false;
> +err:
> + return ret;
> +}
if the interrupt is mandatory you should request it before registering
the rtc device. if it isn't, please return 0.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC V1 2/2] rtc: da9063: RTC driver
On Wed, 5 Mar 2014 12:25:16 +
Opensource [Steve Twiss] stwiss.opensou...@diasemi.com wrote:
+ if (IS_ERR(rtc-rtc_dev)) {
+ ret = PTR_ERR(rtc-rtc_dev);
+ goto err;
+ }
please,
return PTR_ERR()
+
+ irq_alarm = platform_get_irq_byname(pdev, ALARM);
+ ret = devm_request_threaded_irq(pdev-dev, irq_alarm, NULL,
+ da9063_alarm_event,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ ALARM, rtc);
+ if (ret)
+ dev_err(pdev-dev, Failed to request ALARM IRQ %d: %d\n,
+ irq_alarm, ret);
+
+ da9063_data_to_tm(data, rtc-alarm_time);
+ rtc-rtc_sync = false;
+err:
+ return ret;
+}
if the interrupt is mandatory you should request it before registering
the rtc device. if it isn't, please return 0.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernfs/rtc: circular dependency between kernfs and ops_lock
On Sat, 22 Feb 2014 15:52:17 -0500 Tejun Heo wrote: > The problem is rtc_device_unregister(). It grabs rtc->ops_lock and > then tries to remove the sysfs files. Some of those sysfs file > implementations acquire rtc->ops_lock, so it of course can lead to > deadlocks. One can't try to delete a sysfs file which acquires a lock > while holding the same lock. Pretty interesting indeed. One option would be to remove the sys files before acquiring the lock. But I wonder if this could lead to other issues. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernfs/rtc: circular dependency between kernfs and ops_lock
On Sat, 22 Feb 2014 15:52:17 -0500 Tejun Heo t...@kernel.org wrote: The problem is rtc_device_unregister(). It grabs rtc-ops_lock and then tries to remove the sysfs files. Some of those sysfs file implementations acquire rtc-ops_lock, so it of course can lead to deadlocks. One can't try to delete a sysfs file which acquires a lock while holding the same lock. Pretty interesting indeed. One option would be to remove the sys files before acquiring the lock. But I wonder if this could lead to other issues. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question about drivers/rtc/rtc-cmos.c
On Wed, 25 Dec 2013 20:32:12 +0100 (CET) Julia Lawall wrote: > Is it intentional that the error code returned by > hpet_register_irq_handler is put ina local variable that will not be seen > at label cleanup1? The return value is retval, which is 0 at this point. Well, I'd say it's an error. Did you got it by hand or with one of your tools? ;) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question about drivers/rtc/rtc-cmos.c
On Wed, 25 Dec 2013 20:32:12 +0100 (CET) Julia Lawall julia.law...@lip6.fr wrote: Is it intentional that the error code returned by hpet_register_irq_handler is put ina local variable that will not be seen at label cleanup1? The return value is retval, which is 0 at this point. Well, I'd say it's an error. Did you got it by hand or with one of your tools? ;) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 13:01:36 -0500 Jason Cooper wrote: > That goes against the whole goal of the arm-soc devicetree conversion. > For the past several years, we've been moving drivers _out_ of arch/arm/ > into the appropriate drivers/ area. The goal of this was to unclutter > arch/arm/, and to more readily see and remove code duplication by > drivers. I meant in drivers/rtc but using another tree. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 18:46:18 +0100 a...@natisbad.org (Arnaud Ebalard) wrote: > > I don't mind routing it though mvebu/arm-soc since the only consumers > > are currently mvebu boards, but I'd like to hear from Andrew that this > > is ok. > > I will do what you think is the best. If the only consumers are mvebu boards, I believe it is correct to route though that tree. imho. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 18:28:16 +0100 a...@natisbad.org (Arnaud Ebalard) wrote: > > Yes, Andrew usually pick those. > > I guess he should be put in the MAINTAINERS file then. Otherwise, > get_maintainer.pl script can not do its job correctly and people > end up thinking you should be the one handling those. That makes sense, I'll leave the decision add his email to Andrew. > > I do not maintain a separate tree due to most RTCs being specifit to a > > subsytem. > > I do not understand: the chip is generic, i.e. this is not a RTC chip > specific to a given SoC (like rtc-mv.c is for instance). Can you be > more specific? Yes, this chip is generic, but most aren't. Some of those who are generic, are strictly connected to a particular system/board, and they end up in that system's tree. Most of the drivers are pretty small. > > Regarding your patch, please do not add entries to /proc. > > Use sysfs if you need. > > Well, this is what is currently described in the documentation > (Documentation/rtc.txt), in drivers/rtc/rtc-test.c driver and what > many drivers do (AFAICT, 22/125). This needs to be fixed as well. Documentation.txt does not suggest to add arbitrary values to the procfs. "many do" does not apply. > Additionally, I only provide some additional info for an existing > file: the /proc entry is created by the drivers/rtc/class.c as > soon as someone selects CONFIG_RTC_INTF_PROC. I know, but that makes the procfs entry a mess. sysfs is the way, > Do you want me to send a v7 w/ the .proc helper removed or leave > things as they are and Ack the patch as is? Unless absolutely needed, I'd prefer if you can remove them or move to sysfs. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 11:46:24 -0500 Jason Cooper wrote: > In the long term, should we seek out a co-maintainer for drivers/rtc? > Can anyone get a hold of Alessandro to get his opinion on this? I'd surely appreciate if someone can take some time to give a look to the patches. Most of them go thru subsystem's tree and, as far as I can see, I saw very relevant comments and fixes in all those years. I'd love to devote more time to Linux but I'd need to find someone that hires me just to do that the whole day :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
