* [PATCH 2/2] rtc: puv3: make alarms useful
From: Alexandre Belloni @ 2017-08-22 10:06 UTC (permalink / raw)
To: Guan Xuetao; +Cc: linux-rtc, linux-kernel, Alexandre Belloni
In-Reply-To: <20170822100651.26590-1-alexandre.belloni@free-electrons.com>
Currently, the driver unregisters the IRQs when the rtc character device is
closed. This means that the device needs to stay open to get alarms while
the usual use case will open the device, set the alarm and close the
device.
Move the IRQ requests to puv3_rtc_probe() and use the devm managed versions
so we don't need to free them.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/rtc/rtc-puv3.c | 56 +++++++++++++-------------------------------------
1 file changed, 14 insertions(+), 42 deletions(-)
diff --git a/drivers/rtc/rtc-puv3.c b/drivers/rtc/rtc-puv3.c
index 4f495dee2f48..9e83be32ff43 100644
--- a/drivers/rtc/rtc-puv3.c
+++ b/drivers/rtc/rtc-puv3.c
@@ -157,49 +157,7 @@ static int puv3_rtc_proc(struct device *dev, struct seq_file *seq)
return 0;
}
-static int puv3_rtc_open(struct device *dev)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct rtc_device *rtc_dev = platform_get_drvdata(pdev);
- int ret;
-
- ret = request_irq(puv3_rtc_alarmno, puv3_rtc_alarmirq,
- 0, "pkunity-rtc alarm", rtc_dev);
-
- if (ret) {
- dev_err(dev, "IRQ%d error %d\n", puv3_rtc_alarmno, ret);
- return ret;
- }
-
- ret = request_irq(puv3_rtc_tickno, puv3_rtc_tickirq,
- 0, "pkunity-rtc tick", rtc_dev);
-
- if (ret) {
- dev_err(dev, "IRQ%d error %d\n", puv3_rtc_tickno, ret);
- goto tick_err;
- }
-
- return ret;
-
- tick_err:
- free_irq(puv3_rtc_alarmno, rtc_dev);
- return ret;
-}
-
-static void puv3_rtc_release(struct device *dev)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct rtc_device *rtc_dev = platform_get_drvdata(pdev);
-
- /* do not clear AIE here, it may be needed for wake */
- puv3_rtc_setpie(dev, 0);
- free_irq(puv3_rtc_alarmno, rtc_dev);
- free_irq(puv3_rtc_tickno, rtc_dev);
-}
-
static const struct rtc_class_ops puv3_rtcops = {
- .open = puv3_rtc_open,
- .release = puv3_rtc_release,
.read_time = puv3_rtc_gettime,
.set_time = puv3_rtc_settime,
.read_alarm = puv3_rtc_getalarm,
@@ -259,6 +217,20 @@ static int puv3_rtc_probe(struct platform_device *pdev)
if (IS_ERR(rtc))
return PTR_ERR(rtc);
+ ret = devm_request_irq(&pdev->dev, puv3_rtc_alarmno, puv3_rtc_alarmirq,
+ 0, "pkunity-rtc alarm", rtc);
+ if (ret) {
+ dev_err(&pdev->dev, "IRQ%d error %d\n", puv3_rtc_alarmno, ret);
+ return ret;
+ }
+
+ ret = devm_request_irq(&pdev->dev, puv3_rtc_tickno, puv3_rtc_tickirq,
+ 0, "pkunity-rtc tick", rtc);
+ if (ret) {
+ dev_err(&pdev->dev, "IRQ%d error %d\n", puv3_rtc_tickno, ret);
+ return ret;
+ }
+
/* get the memory region */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
--
2.14.1
^ permalink raw reply related
* [PATCH 1/2] rtc: puv3: switch to devm_rtc_allocate_device()/rtc_register_device()
From: Alexandre Belloni @ 2017-08-22 10:06 UTC (permalink / raw)
To: Guan Xuetao; +Cc: linux-rtc, linux-kernel, Alexandre Belloni
Use managed RTC device allocation as this allows for further cleanup.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/rtc/rtc-puv3.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/rtc/rtc-puv3.c b/drivers/rtc/rtc-puv3.c
index c0a6e638c672..4f495dee2f48 100644
--- a/drivers/rtc/rtc-puv3.c
+++ b/drivers/rtc/rtc-puv3.c
@@ -222,10 +222,6 @@ static void puv3_rtc_enable(struct device *dev, int en)
static int puv3_rtc_remove(struct platform_device *dev)
{
- struct rtc_device *rtc = platform_get_drvdata(dev);
-
- rtc_device_unregister(rtc);
-
puv3_rtc_setpie(&dev->dev, 0);
puv3_rtc_setaie(&dev->dev, 0);
@@ -259,6 +255,10 @@ static int puv3_rtc_probe(struct platform_device *pdev)
dev_dbg(&pdev->dev, "PKUnity_rtc: tick irq %d, alarm irq %d\n",
puv3_rtc_tickno, puv3_rtc_alarmno);
+ rtc = devm_rtc_allocate_device(&pdev->dev);
+ if (IS_ERR(rtc))
+ return PTR_ERR(rtc);
+
/* get the memory region */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
@@ -278,12 +278,10 @@ static int puv3_rtc_probe(struct platform_device *pdev)
puv3_rtc_enable(&pdev->dev, 1);
/* register RTC and exit */
- rtc = rtc_device_register("pkunity", &pdev->dev, &puv3_rtcops,
- THIS_MODULE);
-
- if (IS_ERR(rtc)) {
+ rtc->ops = &puv3_rtcops;
+ ret = rtc_register_device(rtc);
+ if (ret) {
dev_err(&pdev->dev, "cannot attach rtc\n");
- ret = PTR_ERR(rtc);
goto err_nortc;
}
--
2.14.1
^ permalink raw reply related
* [PATCH] rtc: sa1100: fix unbalanced clk_prepare_enable/clk_disable_unprepare
From: Alexandre Belloni @ 2017-08-21 16:00 UTC (permalink / raw)
To: linux-rtc
Cc: Robert Jarzmik, Rob Herring, linux-arm-kernel, linux-kernel,
Alexandre Belloni
In the error path of sa1100_rtc_open(), info->clk is disabled which will
happen again in sa1100_rtc_remove() when the module is removed whereas it
is only enabled once in sa1100_rtc_init().
Fixes: 0cc0c38e9139 ("drivers/rtc/rtc-sa1100.c: move clock enable/disable to probe/remove")
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/rtc/rtc-sa1100.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-sa1100.c b/drivers/rtc/rtc-sa1100.c
index c2187bf6c7e4..fe8ebf47bbe5 100644
--- a/drivers/rtc/rtc-sa1100.c
+++ b/drivers/rtc/rtc-sa1100.c
@@ -104,7 +104,7 @@ static int sa1100_rtc_open(struct device *dev)
ret = request_irq(info->irq_1hz, sa1100_rtc_interrupt, 0, "rtc 1Hz", dev);
if (ret) {
dev_err(dev, "IRQ %d already in use.\n", info->irq_1hz);
- goto fail_ui;
+ return ret;
}
ret = request_irq(info->irq_alarm, sa1100_rtc_interrupt, 0, "rtc Alrm", dev);
if (ret) {
@@ -118,8 +118,6 @@ static int sa1100_rtc_open(struct device *dev)
fail_ai:
free_irq(info->irq_1hz, dev);
- fail_ui:
- clk_disable_unprepare(info->clk);
return ret;
}
--
2.14.1
^ permalink raw reply related
* [PATCH] rtc: pxa: fix possible race condition
From: Alexandre Belloni @ 2017-08-21 15:57 UTC (permalink / raw)
To: linux-rtc; +Cc: Robert Jarzmik, linux-kernel, Alexandre Belloni
pxa_rtc_open() registers the interrupt handler which will access the RTC
registers. However, pxa_rtc_open() is called before the register range is
ioremapped. Instead, call it after devm_ioremap().
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/rtc/rtc-pxa.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-pxa.c b/drivers/rtc/rtc-pxa.c
index fe4985b54608..47304f5664d8 100644
--- a/drivers/rtc/rtc-pxa.c
+++ b/drivers/rtc/rtc-pxa.c
@@ -348,7 +348,7 @@ static int __init pxa_rtc_probe(struct platform_device *pdev)
dev_err(dev, "No alarm IRQ resource defined\n");
return -ENXIO;
}
- pxa_rtc_open(dev);
+
pxa_rtc->base = devm_ioremap(dev, pxa_rtc->ress->start,
resource_size(pxa_rtc->ress));
if (!pxa_rtc->base) {
@@ -356,6 +356,8 @@ static int __init pxa_rtc_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ pxa_rtc_open(dev);
+
sa1100_rtc->rcnr = pxa_rtc->base + 0x0;
sa1100_rtc->rtsr = pxa_rtc->base + 0x8;
sa1100_rtc->rtar = pxa_rtc->base + 0x4;
--
2.14.1
^ permalink raw reply related
* Re: [PATCH] rtc: ds1307: fix regmap config
From: Alexandre Belloni @ 2017-08-21 14:17 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: linux-rtc
In-Reply-To: <2061233f-1187-d03c-51dc-8d7ad2faf90e@gmail.com>
On 25/07/2017 at 18:44:04 +0200, Heiner Kallweit wrote:
> Current max_register setting breaks reading nvram on certain chips and
> also reading the standard registers on RX8130 where register map starts
> at 0x10.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> Fixes: 11e5890b5342 "rtc: ds1307: convert driver to regmap"
> ---
> This fix should make it to 4.13.
> ---
> drivers/rtc/rtc-ds1307.c | 1 -
> 1 file changed, 1 deletion(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] RTC fixes for 4.13
From: Alexandre Belloni @ 2017-08-21 14:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-rtc, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 883 bytes --]
Hi Linus,
Please pull this late fix for 4.13.
The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:
Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-4.13-fixes
for you to fetch changes up to 03619844d81d7459874e88034f0f36d959f0e2df:
rtc: ds1307: fix regmap config (2017-08-21 11:08:03 +0200)
----------------------------------------------------------------
RTC fixes for 4.13:
- ds1307: fix regmap configuration
----------------------------------------------------------------
Heiner Kallweit (1):
rtc: ds1307: fix regmap config
drivers/rtc/rtc-ds1307.c | 1 -
1 file changed, 1 deletion(-)
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [rtc-linux] RTC used as a module
From: Michal Simek @ 2017-08-21 13:00 UTC (permalink / raw)
To: Alexandre Belloni, Michal Simek
Cc: Michal Simek, John Stultz, rtc-linux@googlegroups.com
In-Reply-To: <20170821125344.ch36irhbmuyda7vw@piout.net>
On 21.8.2017 14:53, Alexandre Belloni wrote:
> On 21/08/2017 at 14:47:20 +0200, Alexandre Belloni wrote:
>> On 21/08/2017 at 14:19:07 +0200, Michal Simek wrote:
>>> On 21.8.2017 14:13, Alexandre Belloni wrote:
>>>> On 21/08/2017 at 12:50:34 +0200, Michal Simek wrote:
>>>>> Hi,
>>>>>
>>>>> On 21.8.2017 00:03, Alexandre Belloni wrote:
>>>>>> Hi Michal,
>>>>>>
>>>>>> I've just send a patch to fix this issue (and avoid your other patch).
>>>>>>
>>>>>> Could you test it? (I did test on an atmel platform)
>>>>>>
>>>>>> Sorry it took so long!
>>>>>
>>>>> not a problem but it looks like it is still just temporary solution. I
>>>>> would expect that you can't unload module when this alarm is used. It if
>>>>> it is not used then you should be able to remove it.
>>>>>
>>>>
>>>> Yes, the alarmtimer handling needs to be made more flexible, especially
>>>> in the rtc device selection.
>>>
>>> ok. What about to extend that commit message for the patch you sent to
>>> explicitly say that this is temporary solution and what should be the
>>> right fix?
>>>
>>> Maybe you can also add link that patch which introduced this issue.
>>> It was in that patch I sent.
>>>
>>
>> You didn't pinpoint the correct patch. The patch introducing the issue
>> you were seeing (i.e. being able to remove the module) is
>> 8bc0dafb5cf38a19484dfb16e2c6d29e85820046. Before this patch,
>> rtc_class_open() was called and this prevented the module from being
>> removed (it does try_module_get). For now, this is how the feature has
>> been implemented since 2011 and nobody cared enough to change that
>> behaviour.
>>
>
> To be clear, I'm not saying this should not be done. I'm just try to
> explain that this would not be a fix but rather a feature improvement.
I am not quite sure I agree with this description. It doesn't mean that
none care about this from 2011 that this is correct behavior.
You know much more than I in this area but it seems to me quite normal
that if you have module and features which implement and you are not
using them that you can remove module.
It means your patch is a temporary solution for bug introduced in 2011
and found in 2016/2017.
Thanks,
Michal
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [rtc-linux] RTC used as a module
From: Alexandre Belloni @ 2017-08-21 12:53 UTC (permalink / raw)
To: Michal Simek; +Cc: Michal Simek, John Stultz, rtc-linux@googlegroups.com
In-Reply-To: <20170821124720.cmudjhugpssjuag6@piout.net>
On 21/08/2017 at 14:47:20 +0200, Alexandre Belloni wrote:
> On 21/08/2017 at 14:19:07 +0200, Michal Simek wrote:
> > On 21.8.2017 14:13, Alexandre Belloni wrote:
> > > On 21/08/2017 at 12:50:34 +0200, Michal Simek wrote:
> > >> Hi,
> > >>
> > >> On 21.8.2017 00:03, Alexandre Belloni wrote:
> > >>> Hi Michal,
> > >>>
> > >>> I've just send a patch to fix this issue (and avoid your other patch).
> > >>>
> > >>> Could you test it? (I did test on an atmel platform)
> > >>>
> > >>> Sorry it took so long!
> > >>
> > >> not a problem but it looks like it is still just temporary solution. I
> > >> would expect that you can't unload module when this alarm is used. It if
> > >> it is not used then you should be able to remove it.
> > >>
> > >
> > > Yes, the alarmtimer handling needs to be made more flexible, especially
> > > in the rtc device selection.
> >
> > ok. What about to extend that commit message for the patch you sent to
> > explicitly say that this is temporary solution and what should be the
> > right fix?
> >
> > Maybe you can also add link that patch which introduced this issue.
> > It was in that patch I sent.
> >
>
> You didn't pinpoint the correct patch. The patch introducing the issue
> you were seeing (i.e. being able to remove the module) is
> 8bc0dafb5cf38a19484dfb16e2c6d29e85820046. Before this patch,
> rtc_class_open() was called and this prevented the module from being
> removed (it does try_module_get). For now, this is how the feature has
> been implemented since 2011 and nobody cared enough to change that
> behaviour.
>
To be clear, I'm not saying this should not be done. I'm just try to
explain that this would not be a fix but rather a feature improvement.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [rtc-linux] RTC used as a module
From: Michal Simek @ 2017-08-21 12:50 UTC (permalink / raw)
To: Alexandre Belloni, Michal Simek; +Cc: John Stultz, rtc-linux@googlegroups.com
In-Reply-To: <20170821124720.cmudjhugpssjuag6@piout.net>
[-- Attachment #1.1: Type: text/plain, Size: 2359 bytes --]
On 21.8.2017 14:47, Alexandre Belloni wrote:
> On 21/08/2017 at 14:19:07 +0200, Michal Simek wrote:
>> On 21.8.2017 14:13, Alexandre Belloni wrote:
>>> On 21/08/2017 at 12:50:34 +0200, Michal Simek wrote:
>>>> Hi,
>>>>
>>>> On 21.8.2017 00:03, Alexandre Belloni wrote:
>>>>> Hi Michal,
>>>>>
>>>>> I've just send a patch to fix this issue (and avoid your other patch).
>>>>>
>>>>> Could you test it? (I did test on an atmel platform)
>>>>>
>>>>> Sorry it took so long!
>>>>
>>>> not a problem but it looks like it is still just temporary solution. I
>>>> would expect that you can't unload module when this alarm is used. It if
>>>> it is not used then you should be able to remove it.
>>>>
>>>
>>> Yes, the alarmtimer handling needs to be made more flexible, especially
>>> in the rtc device selection.
>>
>> ok. What about to extend that commit message for the patch you sent to
>> explicitly say that this is temporary solution and what should be the
>> right fix?
>>
>> Maybe you can also add link that patch which introduced this issue.
>> It was in that patch I sent.
>>
>
> You didn't pinpoint the correct patch. The patch introducing the issue
> you were seeing (i.e. being able to remove the module) is
> 8bc0dafb5cf38a19484dfb16e2c6d29e85820046. Before this patch,
> rtc_class_open() was called and this prevented the module from being
> removed (it does try_module_get). For now, this is how the feature has
> been implemented since 2011 and nobody cared enough to change that
> behaviour.
ok but still isn't worth to mentioned it in commit message?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [rtc-linux] RTC used as a module
From: Alexandre Belloni @ 2017-08-21 12:47 UTC (permalink / raw)
To: Michal Simek; +Cc: Michal Simek, John Stultz, rtc-linux@googlegroups.com
In-Reply-To: <ac7f1a06-a20a-3fe8-8ef1-01423d742836@xilinx.com>
On 21/08/2017 at 14:19:07 +0200, Michal Simek wrote:
> On 21.8.2017 14:13, Alexandre Belloni wrote:
> > On 21/08/2017 at 12:50:34 +0200, Michal Simek wrote:
> >> Hi,
> >>
> >> On 21.8.2017 00:03, Alexandre Belloni wrote:
> >>> Hi Michal,
> >>>
> >>> I've just send a patch to fix this issue (and avoid your other patch).
> >>>
> >>> Could you test it? (I did test on an atmel platform)
> >>>
> >>> Sorry it took so long!
> >>
> >> not a problem but it looks like it is still just temporary solution. I
> >> would expect that you can't unload module when this alarm is used. It if
> >> it is not used then you should be able to remove it.
> >>
> >
> > Yes, the alarmtimer handling needs to be made more flexible, especially
> > in the rtc device selection.
>
> ok. What about to extend that commit message for the patch you sent to
> explicitly say that this is temporary solution and what should be the
> right fix?
>
> Maybe you can also add link that patch which introduced this issue.
> It was in that patch I sent.
>
You didn't pinpoint the correct patch. The patch introducing the issue
you were seeing (i.e. being able to remove the module) is
8bc0dafb5cf38a19484dfb16e2c6d29e85820046. Before this patch,
rtc_class_open() was called and this prevented the module from being
removed (it does try_module_get). For now, this is how the feature has
been implemented since 2011 and nobody cared enough to change that
behaviour.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [rtc-linux] RTC used as a module
From: Michal Simek @ 2017-08-21 12:19 UTC (permalink / raw)
To: Alexandre Belloni, Michal Simek
Cc: Michal Simek, John Stultz, rtc-linux@googlegroups.com
In-Reply-To: <20170821121344.emzboqji3hhakzpf@piout.net>
On 21.8.2017 14:13, Alexandre Belloni wrote:
> On 21/08/2017 at 12:50:34 +0200, Michal Simek wrote:
>> Hi,
>>
>> On 21.8.2017 00:03, Alexandre Belloni wrote:
>>> Hi Michal,
>>>
>>> I've just send a patch to fix this issue (and avoid your other patch).
>>>
>>> Could you test it? (I did test on an atmel platform)
>>>
>>> Sorry it took so long!
>>
>> not a problem but it looks like it is still just temporary solution. I
>> would expect that you can't unload module when this alarm is used. It if
>> it is not used then you should be able to remove it.
>>
>
> Yes, the alarmtimer handling needs to be made more flexible, especially
> in the rtc device selection.
ok. What about to extend that commit message for the patch you sent to
explicitly say that this is temporary solution and what should be the
right fix?
Maybe you can also add link that patch which introduced this issue.
It was in that patch I sent.
Thanks,
Michal
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [rtc-linux] RTC used as a module
From: Alexandre Belloni @ 2017-08-21 12:13 UTC (permalink / raw)
To: Michal Simek; +Cc: Michal Simek, John Stultz, rtc-linux@googlegroups.com
In-Reply-To: <44ce48f1-73bb-1b88-1e92-327e80f09f96@monstr.eu>
On 21/08/2017 at 12:50:34 +0200, Michal Simek wrote:
> Hi,
>
> On 21.8.2017 00:03, Alexandre Belloni wrote:
> > Hi Michal,
> >
> > I've just send a patch to fix this issue (and avoid your other patch).
> >
> > Could you test it? (I did test on an atmel platform)
> >
> > Sorry it took so long!
>
> not a problem but it looks like it is still just temporary solution. I
> would expect that you can't unload module when this alarm is used. It if
> it is not used then you should be able to remove it.
>
Yes, the alarmtimer handling needs to be made more flexible, especially
in the rtc device selection.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [rtc-linux] RTC used as a module
From: Michal Simek @ 2017-08-21 10:50 UTC (permalink / raw)
To: Alexandre Belloni, Michal Simek; +Cc: John Stultz, rtc-linux@googlegroups.com
In-Reply-To: <20170820220329.uzx3ryehq75qruwz@piout.net>
[-- Attachment #1.1: Type: text/plain, Size: 954 bytes --]
Hi,
On 21.8.2017 00:03, Alexandre Belloni wrote:
> Hi Michal,
>
> I've just send a patch to fix this issue (and avoid your other patch).
>
> Could you test it? (I did test on an atmel platform)
>
> Sorry it took so long!
not a problem but it looks like it is still just temporary solution. I
would expect that you can't unload module when this alarm is used. It if
it is not used then you should be able to remove it.
Thanks,
Michal
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] rtc: zynqmp: Disable the build as a module
From: Michal Simek @ 2017-08-21 10:49 UTC (permalink / raw)
To: Alexandre Belloni, Michal Simek
Cc: linux-kernel, Sören Brinkmann, linux-rtc, Alessandro Zummo,
linux-arm-kernel
In-Reply-To: <20170821084641.p432yvwciwj6irdk@piout.net>
[-- Attachment #1.1: Type: text/plain, Size: 208 bytes --]
On 21.8.2017 10:46, Alexandre Belloni wrote:
> Hi,
>
> As discussed, I will not apply that patch and instead will push for:
> https://patchwork.kernel.org/patch/9911471/
no problem with this.
M
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] rtc: zynqmp: Disable the build as a module
From: Alexandre Belloni @ 2017-08-21 8:46 UTC (permalink / raw)
To: Michal Simek
Cc: linux-kernel, monstr, Sören Brinkmann, linux-rtc,
Alessandro Zummo, linux-arm-kernel
In-Reply-To: <9881f4ae2afb2cd671715bcd1fcb9035688c40c9.1500464394.git.michal.simek@xilinx.com>
Hi,
As discussed, I will not apply that patch and instead will push for:
https://patchwork.kernel.org/patch/9911471/
On 19/07/2017 at 13:39:57 +0200, Michal Simek wrote:
> The patch:
> "timers: Introduce in-kernel alarm-timer interface"
> (sha1: ff3ead96d17f47ee70c294a5cc2cce9b61e82f0f)
> introduced new requirement that RTC drivers with alarm functionality
> can't be used as a module.
> When module is unloaded there is still a reference that's why
> rtc_device_release() is not called and ida is not freed.
>
> That's why when module is loaded again it can't use the same RTC number
> based on aliases.
>
> Log:
> sh-4.3# modprobe rtc-zynqmp
> [ 42.468565] rtc_zynqmp ffa60000.rtc: rtc core: registered
> ffa60000.rtc as rtc5
> sh-4.3# rmmod rtc-zynqmp
> sh-4.3# modprobe rtc-zynqmp
> [ 48.648222] rtc_zynqmp ffa60000.rtc: /aliases ID 5 not available
> [ 48.654280] rtc_zynqmp ffa60000.rtc: rtc core: registered
> ffa60000.rtc as rtc0
>
> This patch is removing module support which is just a workaround till
> alarm-timer interface is fixed to support device releasing when alarm
> timer is not used.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
>
> Based on discussion:
> https://www.mail-archive.com/rtc-linux@googlegroups.com/msg00908.html
>
> ---
> drivers/rtc/Kconfig | 2 +-
> drivers/rtc/rtc-zynqmp.c | 15 +--------------
> 2 files changed, 2 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 72419ac2c52a..a2bbe7c2cf92 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1225,7 +1225,7 @@ config RTC_DRV_OPAL
> will be called rtc-opal.
>
> config RTC_DRV_ZYNQMP
> - tristate "Xilinx Zynq Ultrascale+ MPSoC RTC"
> + bool "Xilinx Zynq Ultrascale+ MPSoC RTC"
> depends on OF
> help
> If you say yes here you get support for the RTC controller found on
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c
> index da18a8ae3c1d..5fc50145dbd2 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -268,14 +268,6 @@ static int xlnx_rtc_probe(struct platform_device *pdev)
> return PTR_ERR_OR_ZERO(xrtcdev->rtc);
> }
>
> -static int xlnx_rtc_remove(struct platform_device *pdev)
> -{
> - xlnx_rtc_alarm_irq_enable(&pdev->dev, 0);
> - device_init_wakeup(&pdev->dev, 0);
> -
> - return 0;
> -}
> -
> static int __maybe_unused xlnx_rtc_suspend(struct device *dev)
> {
> struct platform_device *pdev = to_platform_device(dev);
> @@ -312,7 +304,6 @@ static int __maybe_unused xlnx_rtc_resume(struct device *dev)
>
> static struct platform_driver xlnx_rtc_driver = {
> .probe = xlnx_rtc_probe,
> - .remove = xlnx_rtc_remove,
> .driver = {
> .name = KBUILD_MODNAME,
> .pm = &xlnx_rtc_pm_ops,
> @@ -320,8 +311,4 @@ static int __maybe_unused xlnx_rtc_resume(struct device *dev)
> },
> };
>
> -module_platform_driver(xlnx_rtc_driver);
> -
> -MODULE_DESCRIPTION("Xilinx Zynq MPSoC RTC driver");
> -MODULE_AUTHOR("Xilinx Inc.");
> -MODULE_LICENSE("GPL v2");
> +builtin_platform_driver(xlnx_rtc_driver);
> --
> 1.9.1
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [rtc-linux] RTC used as a module
From: Alexandre Belloni @ 2017-08-20 22:03 UTC (permalink / raw)
To: Michal Simek; +Cc: John Stultz, monstr, rtc-linux@googlegroups.com
In-Reply-To: <59e7661e-7e1f-a11e-93c2-9a4bbe9ebe1a@xilinx.com>
Hi Michal,
I've just send a patch to fix this issue (and avoid your other patch).
Could you test it? (I did test on an atmel platform)
Sorry it took so long!
On 29/06/2017 at 09:34:14 +0200, Michal Simek wrote:
> Hi John and Alexandre,
>
> On 7.4.2017 09:12, Michal Simek wrote:
> > On 16.3.2017 16:35, Michal Simek wrote:
> >> Hi John and Alexandre,
> >>
> >> On 6.3.2017 15:56, Michal Simek wrote:
> >>> On 3.3.2017 21:04, John Stultz wrote:
> >>>> On Fri, Mar 3, 2017 at 6:46 AM, Michal Simek <monstr@monstr.eu> wrote:
> >>>>> Hi Alexandre,
> >>>>>
> >>>>> On 3.3.2017 10:41, Michal Simek wrote:
> >>>>>> Hi Alexandre,
> >>>>>>
> >>>>>> On 23.2.2017 13:14, Alexandre Belloni wrote:
> >>>>>>> Hi Michal,
> >>>>>>>
> >>>>>>> I've been thinking about this issue (and meaning to actually test).
> >>>>>>>
> >>>>>>> On 08/12/2016 at 14:02:36 +0100, Michal Simek wrote:
> >>>>>>>> Hi guys,
> >>>>>>>>
> >>>>>>>> I am trying to find out reason for this behavior. If rtc-zynqmp is used
> >>>>>>>> as module for the first time it is correctly probed based on aliases
> >>>>>>>> setting. (rtc5 for log below). But then driver is removed and add again
> >>>>>>>> rtc5 is still not freed. rtc_device_release() is not called that's why
> >>>>>>>> rtc->id can't be used again.
> >>>>>>>>
> >>>>>>>> sh-4.3# modprobe rtc-zynqmp
> >>>>>>>> [ 42.468565] rtc_zynqmp ffa60000.rtc: rtc core: registered
> >>>>>>>> ffa60000.rtc as rtc5
> >>>>>>>> sh-4.3# rmmod rtc-zynqmp
> >>>>>>>> sh-4.3# modprobe rtc-zynqmp
> >>>>>>>> [ 48.648222] rtc_zynqmp ffa60000.rtc: /aliases ID 5 not available
> >>>>>>>> [ 48.654280] rtc_zynqmp ffa60000.rtc: rtc core: registered
> >>>>>>>> ffa60000.rtc as rtc0
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I didn't try different rtc drivers but it looks like that someone keeps
> >>>>>>>> reference that's why release function is not called.
> >>>>>>>>
> >>>>>>>> Can someone check this with different RTC module?
> >>>>>>>
> >>>>>>> I'll do that soon.
> >>>>>>
> >>>>>> Have you tried it?
> >>>>>>
> >>>>>>>
> >>>>>>>> Or is this expected behavior?
> >>>>>>>>
> >>>>>>>
> >>>>>>> I don't think so :)
> >>>>>>>
> >>>>>>> Can you clarify a few things:
> >>>>>>> - is this the only rtc with a driver on your system ?
> >>>>>>
> >>>>>> yes only one.
> >>>>>>
> >>>>>>> - is it selected as the RTC_SYSTOHC_DEVICE or RTC_HCTOSYS_DEVICE. I've
> >>>>>>> checked the code and I don't think this is the issue but it is worth
> >>>>>>> testing.
> >>>>>>
> >>>>>> This is the setting.
> >>>>>>
> >>>>>> CONFIG_RTC_HCTOSYS=y
> >>>>>> CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
> >>>>>> CONFIG_RTC_SYSTOHC=y
> >>>>>> CONFIG_RTC_SYSTOHC_DEVICE="rtc0"
> >>>>>>
> >>>>>> What I see is that rtc_device_release is not called which is that
> >>>>>> function which contain ida_simple_remove.
> >>>>>>
> >>>>>> I have alias for rtc0 (rtc0 = &rtc;)
> >>>>>> And here is a log with debug. As you see when driver is removed for the
> >>>>>> first time rtc_device_release is not called. When this is done for the
> >>>>>> second time rtc_device_release is called properly and the same device
> >>>>>> allocated via ida is used.
> >>>>>>
> >>>>>> root@linaro-alip:~# dmesg | grep rtc
> >>>>>> [ 3.372715] [drm] Cannot find any crtc or sizes - going 1024x768
> >>>>>> [ 3.422099] hctosys: unable to open rtc device (rtc0)
> >>>>>> [ 6.578930] rtc_zynqmp ffa60000.rtc: rtc core: registered
> >>>>>> ffa60000.rtc as rtc0
> >>>>>> root@linaro-alip:~#
> >>>>>> root@linaro-alip:~# lsmod
> >>>>>> Module Size Used by
> >>>>>> rtc_zynqmp 16384 0
> >>>>>> uio_pdrv_genirq 16384 0
> >>>>>> root@linaro-alip:~# rmmod rtc_zynqmp
> >>>>>> [ 26.805172] rtc_core: devm_rtc_device_unregister
> >>>>>> [ 26.809794] rtc_core: devm_rtc_device_release
> >>>>>> [ 26.814129] rtc_core: rtc_device_unregister
> >>>>>> root@linaro-alip:~# modprobe rtc_zynqmp
> >>>>>> [ 35.879655] rtc_zynqmp ffa60000.rtc: /aliases ID 0 not available
> >>>>>> [ 35.886002] rtc_zynqmp ffa60000.rtc: rtc core: registered
> >>>>>> ffa60000.rtc as rtc1
> >>>>>> root@linaro-alip:~# rmmod rtc_zynqmp
> >>>>>> [ 122.140487] rtc_core: devm_rtc_device_unregister
> >>>>>> [ 122.145110] rtc_core: devm_rtc_device_release
> >>>>>> [ 122.149443] rtc_core: rtc_device_unregister
> >>>>>> [ 122.153770] rtc_core: rtc_device_release
> >>>>>> root@linaro-alip:~# modprobe rtc_zynqmp
> >>>>>> [ 123.646002] rtc_zynqmp ffa60000.rtc: /aliases ID 0 not available
> >>>>>> [ 123.652249] rtc_zynqmp ffa60000.rtc: rtc core: registered
> >>>>>> ffa60000.rtc as rtc1
> >>>>>> root@linaro-alip:~# rmmod rtc_zynqmp
> >>>>>> [ 125.876188] rtc_core: devm_rtc_device_release
> >>>>>> [ 125.880554] rtc_core: rtc_device_unregister
> >>>>>> [ 125.885163] rtc_core: rtc_device_release
> >>>>>> root@linaro-alip:~#
> >>>>>>
> >>>>>> I have also done experiment to setup rtc alias to rtc1 and this ID is
> >>>>>> used only once. It looks like something is not released properly.
> >>>>>>
> >>>>>> This is out of tree driver but I can't see any specific code which could
> >>>>>> improve behavior.
> >>>>>> I have tested i2c rtc mcp79410 and there is not a visible problem but it
> >>>>>> is not MMIO.
> >>>>>
> >>>>> This is the function which is making the difference.
> >>>>>
> >>>>> It was added by John Stultz:
> >>>>> "timers: Introduce in-kernel alarm-timer interface"
> >>>>> (sha1: ff3ead96d17f47ee70c294a5cc2cce9b61e82f0f)
> >>>>>
> >>>>> Probe function has device_init_wakeup(&pdev->dev, 1);
> >>>>> That's why reference is taken (get_device() below)
> >>>>>
> >>>>> static int alarmtimer_rtc_add_device(struct device *dev,
> >>>>> struct class_interface *class_intf)
> >>>>> {
> >>>>> unsigned long flags;
> >>>>> struct rtc_device *rtc = to_rtc_device(dev);
> >>>>>
> >>>>> if (rtcdev)
> >>>>> return -EBUSY;
> >>>>>
> >>>>> pr_info("%s\n", __func__);
> >>>>>
> >>>>> if (!rtc->ops->set_alarm)
> >>>>> return -1;
> >>>>>
> >>>>> pr_info("%s\n", __func__);
> >>>>>
> >>>>> if (!device_may_wakeup(rtc->dev.parent))
> >>>>> return -1;
> >>>>>
> >>>>> spin_lock_irqsave(&rtcdev_lock, flags);
> >>>>> if (!rtcdev) {
> >>>>> rtcdev = rtc;
> >>>>> /* hold a reference so it doesn't go away */
> >>>>> get_device(dev);
> >>>>> }
> >>>>> spin_unlock_irqrestore(&rtcdev_lock, flags);
> >>>>> return 0;
> >>>>> }
> >>>>>
> >>>>> And in remove function device_init_wakeup(&pdev->dev, 0);
> >>>>> But because there is still a reference rtc_device_release() is not
> >>>>> called and ida is not freed.
> >>>>>
> >>>>> Generic question which I think should be asked if in this situation
> >>>>> driver should be modular or not.
> >>>>> If driver can be modular then somewhere should be put_device().
> >>>>
> >>>> So off the top of my head (sorry, packing for a trip at the moment), I
> >>>> think this was because the alarmtimer subsystem needs to hold onto the
> >>>> rtcdev so it doesn't disappear under it, as it will be needed when
> >>>> setting any alarmtimers on suspend.
> >>>>
> >>>> Part of the issue is the alarmtimer interface will provide an error to
> >>>> userspace if there's no rtcdev, so we don't want a situation where
> >>>> timers successfully set then silently never fire because the rtc was
> >>>> removed.
> >>>
> >>> right I fully understand that.
> >>>
> >>>>
> >>>> That said, there may very well be bugs in how it was handled, and I've
> >>>> not looked closely at it recently.
> >>>
> >>> On the other hand you can have multiple alarms in the system and you can
> >>> remove them at run time. It means I would expect that you can remove rtc
> >>> if alarm is not set. When you run application driver is in use and you
> >>> can't do it.
> >>>
> >>> Anyway by saying this I expect every driver which setup
> >>> device_init_wakeup(..,1); and device_init_wakeup(..,0) in remove has the
> >>> same issue.
> >>> Solution is definitely not making rtc as a module which is in my case
> >>> rtc-zynqmp an option but not the best one.
> >>
> >> I think it is good time to continue on this.
> >
> > Any update on this one?
>
> It is quite some time from my last ping that's hwy I am sending new one.
> If this is not going to be resolve I will send a patch which will simply
> disable module functionality which is reasonable workaround for now.
>
> Thanks,
> Michal
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [RFC 2/3] rtc: Add Realtek RTD1295
From: Andreas Färber @ 2017-08-20 21:12 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alessandro Zummo, Alexandre Belloni, linux-rtc, linux-arm-kernel,
?????????, linux-kernel, Roc He
In-Reply-To: <20170820154017.GD24150@lunn.ch>
Am 20.08.2017 um 17:40 schrieb Andrew Lunn:
>> +static void rtd119x_rtc_set_enabled(struct device *dev, bool enable)
>> +{
>> + struct rtd119x_rtc *data = dev_get_drvdata(dev);
>> + u32 val;
>> +
>> + val = readl_relaxed(data->base + RTD_RTCEN);
>> + dev_info(dev, "%s: rtcen = 0x%08x\n", __func__, val);
>
> dev_dbg()?
>
>> +static int rtd119x_rtc_open(struct device *dev)
>> +{
>> + struct rtd119x_rtc *data = dev_get_drvdata(dev);
>> + u32 val;
>> + int ret;
>> +
>> + ret = clk_prepare_enable(data->clk);
>> + if (ret)
>> + return ret;
>> +
>> + val = readl_relaxed(data->base + RTD_RTCACR);
>> + dev_info(dev, "rtcacr = 0x%08x\n", val);
>
> dev_dbg()?
Yeah, either that or dropping them altogether.
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [RFC 2/3] rtc: Add Realtek RTD1295
From: Andreas Färber @ 2017-08-20 21:10 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Alessandro Zummo, linux-rtc, linux-arm-kernel, linux-kernel,
Roc He, 蒋丽琴
In-Reply-To: <20170820083219.siez3rl2hbjgjgk5@piout.net>
Hi Alexandre,
Am 20.08.2017 um 10:32 schrieb Alexandre Belloni:
> On 20/08/2017 at 03:36:30 +0200, Andreas Färber wrote:
>> +static int rtd119x_rtc_read_time(struct device *dev, struct rtc_time *tm)
>> +{
>> + struct rtd119x_rtc *data = dev_get_drvdata(dev);
>> + time64_t t;
>> + u32 day;
>> +
>> + day = readl_relaxed(data->base + RTD_RTCDATE_LOW);
>> + day |= readl_relaxed(data->base + RTD_RTCDATE_HIGH) << 8;
>
> Is RTD_RTCDATE_HIGH latched when RTD_RTCDATE_LOW is read?
I do not have an answer to that.
> If this is not
> the case, you probably want to handle a possible update between both
> readl_relaxed.
Are you proposing to disable the RTC while reading the registers, or
something related to my choice of _relaxed? (it follows an explanation
by Marc Zyngier on the irq mux series) Inconsistencies might not be
limited to the date.
>> + t = mktime64(data->base_year, 1, 1, 0, 0, 0);
>> + t += day * 24 * 60 * 60;
>> + rtc_time64_to_tm(t, tm);
BTW is there any more efficient way to get from year+days to
day/month/year without going via seconds?
>> + tm->tm_sec = readl_relaxed(data->base + RTD_RTCSEC) >> 1;
>> + tm->tm_min = readl_relaxed(data->base + RTD_RTCMIN);
>> + tm->tm_hour = readl_relaxed(data->base + RTD_RTCHR);
>> +
>> + return rtc_valid_tm(tm);
>> +}
>> +
>> +static int rtd119x_rtc_set_time(struct device *dev, struct rtc_time *tm)
>> +{
>> + struct rtd119x_rtc *data = dev_get_drvdata(dev);
>> + time64_t time_base, new_time, time_delta;
>> + unsigned long day;
>> +
>> + if (tm->tm_year < data->base_year)
>> + return -EINVAL;
>> +
>> + time_base = mktime64(data->base_year, 1, 1, 0, 0, 0);
>> + new_time = rtc_tm_to_time64(tm);
>> + time_delta = new_time - time_base;
>> + day = time_delta / (24 * 60 * 60);
>> + if (day > 0x7fff)
>> + return -EINVAL;
>> +
>> + rtd119x_rtc_set_enabled(dev, false);
>> +
>> + writel_relaxed(tm->tm_sec, data->base + RTD_RTCSEC);
>> + writel_relaxed(tm->tm_min, data->base + RTD_RTCMIN);
>> + writel_relaxed(tm->tm_hour, data->base + RTD_RTCHR);
>> + writel_relaxed(day & 0xff, data->base + RTD_RTCDATE_LOW);
>> + writel_relaxed((day >> 8) & 0x7f, data->base + RTD_RTCDATE_HIGH);
>> +
>> + rtd119x_rtc_set_enabled(dev, true);
>> +
>> + return 0;
>> +}
>> +
>> +static int rtd119x_rtc_open(struct device *dev)
>> +{
>> + struct rtd119x_rtc *data = dev_get_drvdata(dev);
>> + u32 val;
>> + int ret;
>> +
>> + ret = clk_prepare_enable(data->clk);
>> + if (ret)
>> + return ret;
>> +
>> + val = readl_relaxed(data->base + RTD_RTCACR);
>> + dev_info(dev, "rtcacr = 0x%08x\n", val);
>> + if (!(val & BIT(7))) {
>> + }
>
> I don't see the point of reading that register, and not doing anything
> with it.
Thanks for spotting this. The story is that the old downstream has code
for this case, but in my testing I didn't run into that path and forgot.
Explanations are largely missing in the vendor code. That code should
probably be added here in v2 and the dev_info() dropped, rather than
dropping the current no-op expression.
>> +
>> + rtd119x_rtc_set_enabled(dev, true);
>> +
>
> This is certainly not what you want. The RTC device is usually not
> opened so enabling the RTC when open and disabling it when closed will
> not work on most systems. This is probably true for the clock too. i.e
> what you do here should be done in probe.
I did test the probe path to work, but I can change it again. The
downstream code had it in probe, but looking at rtc_class_ops I saw
those hooks and thought they'd serve a purpose - what are they for then?
(Any chance you can improve the documentation comments to avoid such
misunderstandings? :))
>> + return 0;
>> +}
[snip]
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [RFC 2/3] rtc: Add Realtek RTD1295
From: Andrew Lunn @ 2017-08-20 15:40 UTC (permalink / raw)
To: Andreas Färber
Cc: Alessandro Zummo, Alexandre Belloni, linux-rtc, linux-arm-kernel,
?????????, linux-kernel, Roc He
In-Reply-To: <20170820013632.18375-3-afaerber@suse.de>
> +static void rtd119x_rtc_set_enabled(struct device *dev, bool enable)
> +{
> + struct rtd119x_rtc *data = dev_get_drvdata(dev);
> + u32 val;
> +
> + val = readl_relaxed(data->base + RTD_RTCEN);
> + dev_info(dev, "%s: rtcen = 0x%08x\n", __func__, val);
dev_dbg()?
> +static int rtd119x_rtc_open(struct device *dev)
> +{
> + struct rtd119x_rtc *data = dev_get_drvdata(dev);
> + u32 val;
> + int ret;
> +
> + ret = clk_prepare_enable(data->clk);
> + if (ret)
> + return ret;
> +
> + val = readl_relaxed(data->base + RTD_RTCACR);
> + dev_info(dev, "rtcacr = 0x%08x\n", val);
dev_dbg()?
Andrew
^ permalink raw reply
* Re: [RFC 2/3] rtc: Add Realtek RTD1295
From: Alexandre Belloni @ 2017-08-20 8:32 UTC (permalink / raw)
To: Andreas Färber
Cc: Alessandro Zummo, linux-rtc, linux-arm-kernel, linux-kernel,
Roc He, 蒋丽琴
In-Reply-To: <20170820013632.18375-3-afaerber@suse.de>
Hi,
On 20/08/2017 at 03:36:30 +0200, Andreas Färber wrote:
> +static int rtd119x_rtc_read_time(struct device *dev, struct rtc_time *tm)
> +{
> + struct rtd119x_rtc *data = dev_get_drvdata(dev);
> + time64_t t;
> + u32 day;
> +
> + day = readl_relaxed(data->base + RTD_RTCDATE_LOW);
> + day |= readl_relaxed(data->base + RTD_RTCDATE_HIGH) << 8;
Is RTD_RTCDATE_HIGH latched when RTD_RTCDATE_LOW is read? If this is not
the case, you probably want to handle a possible update between both
readl_relaxed.
> + t = mktime64(data->base_year, 1, 1, 0, 0, 0);
> + t += day * 24 * 60 * 60;
> + rtc_time64_to_tm(t, tm);
> + tm->tm_sec = readl_relaxed(data->base + RTD_RTCSEC) >> 1;
> + tm->tm_min = readl_relaxed(data->base + RTD_RTCMIN);
> + tm->tm_hour = readl_relaxed(data->base + RTD_RTCHR);
> +
> + return rtc_valid_tm(tm);
> +}
> +
> +static int rtd119x_rtc_set_time(struct device *dev, struct rtc_time *tm)
> +{
> + struct rtd119x_rtc *data = dev_get_drvdata(dev);
> + time64_t time_base, new_time, time_delta;
> + unsigned long day;
> +
> + if (tm->tm_year < data->base_year)
> + return -EINVAL;
> +
> + time_base = mktime64(data->base_year, 1, 1, 0, 0, 0);
> + new_time = rtc_tm_to_time64(tm);
> + time_delta = new_time - time_base;
> + day = time_delta / (24 * 60 * 60);
> + if (day > 0x7fff)
> + return -EINVAL;
> +
> + rtd119x_rtc_set_enabled(dev, false);
> +
> + writel_relaxed(tm->tm_sec, data->base + RTD_RTCSEC);
> + writel_relaxed(tm->tm_min, data->base + RTD_RTCMIN);
> + writel_relaxed(tm->tm_hour, data->base + RTD_RTCHR);
> + writel_relaxed(day & 0xff, data->base + RTD_RTCDATE_LOW);
> + writel_relaxed((day >> 8) & 0x7f, data->base + RTD_RTCDATE_HIGH);
> +
> + rtd119x_rtc_set_enabled(dev, true);
> +
> + return 0;
> +}
> +
> +static int rtd119x_rtc_open(struct device *dev)
> +{
> + struct rtd119x_rtc *data = dev_get_drvdata(dev);
> + u32 val;
> + int ret;
> +
> + ret = clk_prepare_enable(data->clk);
> + if (ret)
> + return ret;
> +
> + val = readl_relaxed(data->base + RTD_RTCACR);
> + dev_info(dev, "rtcacr = 0x%08x\n", val);
> + if (!(val & BIT(7))) {
> + }
I don't see the point of reading that register, and not doing anything
with it.
> +
> + rtd119x_rtc_set_enabled(dev, true);
> +
This is certainly not what you want. The RTC device is usually not
opened so enabling the RTC when open and disabling it when closed will
not work on most systems. This is probably true for the clock too. i.e
what you do here should be done in probe.
> + return 0;
> +}
> +
> +static void rtd119x_rtc_release(struct device *dev)
> +{
> + struct rtd119x_rtc *data = dev_get_drvdata(dev);
> +
> + rtd119x_rtc_set_enabled(dev, false);
> +
> + clk_disable_unprepare(data->clk);
> +}
> +
> +static const struct rtc_class_ops rtd119x_rtc_ops = {
> + .open = rtd119x_rtc_open,
> + .release = rtd119x_rtc_release,
> + .read_time = rtd119x_rtc_read_time,
> + .set_time = rtd119x_rtc_set_time,
> +};
> +
> +static const struct of_device_id rtd119x_rtc_dt_ids[] = {
> + { .compatible = "realtek,rtd1295-rtc" },
> + { }
> +};
> +
> +static int rtd119x_rtc_probe(struct platform_device *pdev)
> +{
> + struct rtd119x_rtc *data;
> + struct resource *res;
> +
> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, data);
> + data->base_year = 2014;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + data->base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(data->base))
> + return PTR_ERR(data->base);
> +
> + data->clk = of_clk_get(pdev->dev.of_node, 0);
> + if (IS_ERR(data->clk))
> + return PTR_ERR(data->clk);
> +
> + data->rtcdev = devm_rtc_device_register(&pdev->dev, "rtc",
> + &rtd119x_rtc_ops, THIS_MODULE);
> + if (IS_ERR(data->rtcdev)) {
> + dev_err(&pdev->dev, "failed to register rtc device");
> + clk_put(data->clk);
> + return PTR_ERR(data->rtcdev);
> + }
> +
> + return 0;
> +}
> +
> +static struct platform_driver rtd119x_rtc_driver = {
> + .probe = rtd119x_rtc_probe,
> + .driver = {
> + .name = "rtd1295-rtc",
> + .of_match_table = rtd119x_rtc_dt_ids,
> + },
> +};
> +builtin_platform_driver(rtd119x_rtc_driver);
> --
> 2.12.3
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [RFC 3/3] arm64: dts: realtek: Add RTD1295 RTC node
From: Andreas Färber @ 2017-08-20 1:36 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, linux-rtc, linux-arm-kernel
Cc: linux-kernel, Roc He, 蒋丽琴,
Andreas Färber, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, devicetree
In-Reply-To: <20170820013632.18375-1-afaerber@suse.de>
Add RTC node to the Realtek RTD1295 Device Tree.
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
arch/arm64/boot/dts/realtek/rtd1295.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/rtd1295.dtsi b/arch/arm64/boot/dts/realtek/rtd1295.dtsi
index 503e2d5fc334..8ae0949ad89e 100644
--- a/arch/arm64/boot/dts/realtek/rtd1295.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd1295.dtsi
@@ -192,6 +192,12 @@
status = "disabled";
};
+ rtc@9801b600 {
+ compatible = "realtek,rtd1295-rtc";
+ reg = <0x9801b600 0x100>;
+ clocks = <&clkc RTD1295_CLK_EN_MISC_RTC>;
+ };
+
gic: interrupt-controller@ff011000 {
compatible = "arm,gic-400";
reg = <0xff011000 0x1000>,
--
2.12.3
^ permalink raw reply related
* [RFC 2/3] rtc: Add Realtek RTD1295
From: Andreas Färber @ 2017-08-20 1:36 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, linux-rtc, linux-arm-kernel
Cc: linux-kernel, Roc He, 蒋丽琴,
Andreas Färber
In-Reply-To: <20170820013632.18375-1-afaerber@suse.de>
Based on QNAP's mach-rtk119x/driver/rtk_rtc_drv.c code.
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
drivers/rtc/Kconfig | 8 +++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-rtd119x.c | 175 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 184 insertions(+)
create mode 100644 drivers/rtc/rtc-rtd119x.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 72419ac2c52a..882828b1b351 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1765,6 +1765,14 @@ config RTC_DRV_CPCAP
Say y here for CPCAP rtc found on some Motorola phones
and tablets such as Droid 4.
+config RTC_DRV_RTD119X
+ bool "Realtek RTD129x RTC"
+ depends on ARCH_REALTEK || COMPILE_TEST
+ default ARCH_REALTEK
+ help
+ If you say yes here, you get support for the RTD1295 SoC
+ Real Time Clock.
+
comment "HID Sensor RTC drivers"
config RTC_DRV_HID_SENSOR_TIME
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index acd366b41c85..55a0a5ca45b0 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -131,6 +131,7 @@ obj-$(CONFIG_RTC_DRV_RP5C01) += rtc-rp5c01.o
obj-$(CONFIG_RTC_DRV_RS5C313) += rtc-rs5c313.o
obj-$(CONFIG_RTC_DRV_RS5C348) += rtc-rs5c348.o
obj-$(CONFIG_RTC_DRV_RS5C372) += rtc-rs5c372.o
+obj-$(CONFIG_RTC_DRV_RTD119X) += rtc-rtd119x.o
obj-$(CONFIG_RTC_DRV_RV3029C2) += rtc-rv3029c2.o
obj-$(CONFIG_RTC_DRV_RV8803) += rtc-rv8803.o
obj-$(CONFIG_RTC_DRV_RX4581) += rtc-rx4581.o
diff --git a/drivers/rtc/rtc-rtd119x.c b/drivers/rtc/rtc-rtd119x.c
new file mode 100644
index 000000000000..b532e127b56e
--- /dev/null
+++ b/drivers/rtc/rtc-rtd119x.c
@@ -0,0 +1,175 @@
+/*
+ * Realtek RTD129x RTC
+ *
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+
+#define RTD_RTCSEC 0x00
+#define RTD_RTCMIN 0x04
+#define RTD_RTCHR 0x08
+#define RTD_RTCDATE_LOW 0x0c
+#define RTD_RTCDATE_HIGH 0x10
+#define RTD_RTCACR 0x28
+#define RTD_RTCEN 0x2c
+
+struct rtd119x_rtc {
+ void __iomem *base;
+ struct clk *clk;
+ struct rtc_device *rtcdev;
+ unsigned base_year;
+};
+
+static void rtd119x_rtc_set_enabled(struct device *dev, bool enable)
+{
+ struct rtd119x_rtc *data = dev_get_drvdata(dev);
+ u32 val;
+
+ val = readl_relaxed(data->base + RTD_RTCEN);
+ dev_info(dev, "%s: rtcen = 0x%08x\n", __func__, val);
+ if (enable) {
+ if ((val & 0xff) == 0x5a)
+ return;
+ writel_relaxed(0x5a, data->base + RTD_RTCEN);
+ } else {
+ writel_relaxed(0, data->base + RTD_RTCEN);
+ }
+}
+
+static int rtd119x_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct rtd119x_rtc *data = dev_get_drvdata(dev);
+ time64_t t;
+ u32 day;
+
+ day = readl_relaxed(data->base + RTD_RTCDATE_LOW);
+ day |= readl_relaxed(data->base + RTD_RTCDATE_HIGH) << 8;
+ t = mktime64(data->base_year, 1, 1, 0, 0, 0);
+ t += day * 24 * 60 * 60;
+ rtc_time64_to_tm(t, tm);
+ tm->tm_sec = readl_relaxed(data->base + RTD_RTCSEC) >> 1;
+ tm->tm_min = readl_relaxed(data->base + RTD_RTCMIN);
+ tm->tm_hour = readl_relaxed(data->base + RTD_RTCHR);
+
+ return rtc_valid_tm(tm);
+}
+
+static int rtd119x_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+ struct rtd119x_rtc *data = dev_get_drvdata(dev);
+ time64_t time_base, new_time, time_delta;
+ unsigned long day;
+
+ if (tm->tm_year < data->base_year)
+ return -EINVAL;
+
+ time_base = mktime64(data->base_year, 1, 1, 0, 0, 0);
+ new_time = rtc_tm_to_time64(tm);
+ time_delta = new_time - time_base;
+ day = time_delta / (24 * 60 * 60);
+ if (day > 0x7fff)
+ return -EINVAL;
+
+ rtd119x_rtc_set_enabled(dev, false);
+
+ writel_relaxed(tm->tm_sec, data->base + RTD_RTCSEC);
+ writel_relaxed(tm->tm_min, data->base + RTD_RTCMIN);
+ writel_relaxed(tm->tm_hour, data->base + RTD_RTCHR);
+ writel_relaxed(day & 0xff, data->base + RTD_RTCDATE_LOW);
+ writel_relaxed((day >> 8) & 0x7f, data->base + RTD_RTCDATE_HIGH);
+
+ rtd119x_rtc_set_enabled(dev, true);
+
+ return 0;
+}
+
+static int rtd119x_rtc_open(struct device *dev)
+{
+ struct rtd119x_rtc *data = dev_get_drvdata(dev);
+ u32 val;
+ int ret;
+
+ ret = clk_prepare_enable(data->clk);
+ if (ret)
+ return ret;
+
+ val = readl_relaxed(data->base + RTD_RTCACR);
+ dev_info(dev, "rtcacr = 0x%08x\n", val);
+ if (!(val & BIT(7))) {
+ }
+
+ rtd119x_rtc_set_enabled(dev, true);
+
+ return 0;
+}
+
+static void rtd119x_rtc_release(struct device *dev)
+{
+ struct rtd119x_rtc *data = dev_get_drvdata(dev);
+
+ rtd119x_rtc_set_enabled(dev, false);
+
+ clk_disable_unprepare(data->clk);
+}
+
+static const struct rtc_class_ops rtd119x_rtc_ops = {
+ .open = rtd119x_rtc_open,
+ .release = rtd119x_rtc_release,
+ .read_time = rtd119x_rtc_read_time,
+ .set_time = rtd119x_rtc_set_time,
+};
+
+static const struct of_device_id rtd119x_rtc_dt_ids[] = {
+ { .compatible = "realtek,rtd1295-rtc" },
+ { }
+};
+
+static int rtd119x_rtc_probe(struct platform_device *pdev)
+{
+ struct rtd119x_rtc *data;
+ struct resource *res;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, data);
+ data->base_year = 2014;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ data->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(data->base))
+ return PTR_ERR(data->base);
+
+ data->clk = of_clk_get(pdev->dev.of_node, 0);
+ if (IS_ERR(data->clk))
+ return PTR_ERR(data->clk);
+
+ data->rtcdev = devm_rtc_device_register(&pdev->dev, "rtc",
+ &rtd119x_rtc_ops, THIS_MODULE);
+ if (IS_ERR(data->rtcdev)) {
+ dev_err(&pdev->dev, "failed to register rtc device");
+ clk_put(data->clk);
+ return PTR_ERR(data->rtcdev);
+ }
+
+ return 0;
+}
+
+static struct platform_driver rtd119x_rtc_driver = {
+ .probe = rtd119x_rtc_probe,
+ .driver = {
+ .name = "rtd1295-rtc",
+ .of_match_table = rtd119x_rtc_dt_ids,
+ },
+};
+builtin_platform_driver(rtd119x_rtc_driver);
--
2.12.3
^ permalink raw reply related
* [RFC 1/3] dt-bindings: rtc: Add Realtek RTD1295
From: Andreas Färber @ 2017-08-20 1:36 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, linux-rtc, linux-arm-kernel
Cc: linux-kernel, Roc He, 蒋丽琴,
Andreas Färber, Rob Herring, Mark Rutland, devicetree
In-Reply-To: <20170820013632.18375-1-afaerber@suse.de>
Add a binding for the RTC on the Realtek RTD119x/RTD129x SoC families.
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
.../devicetree/bindings/rtc/realtek,rtd119x.txt | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/realtek,rtd119x.txt
diff --git a/Documentation/devicetree/bindings/rtc/realtek,rtd119x.txt b/Documentation/devicetree/bindings/rtc/realtek,rtd119x.txt
new file mode 100644
index 000000000000..bbf1ccb5df31
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/realtek,rtd119x.txt
@@ -0,0 +1,16 @@
+Realtek RTD129x Real-Time Clock
+===============================
+
+Required properties:
+- compatible : Should be "realtek,rtd1295-rtc"
+- reg : Specifies the physical base address and size
+- clocks : Specifies the clock gate
+
+
+Example:
+
+ rtc@9801b600 {
+ compatible = "realtek,rtd1295-clk";
+ reg = <0x9801b600 0x100>;
+ clocks = <&clkc RTD1295_CLK_EN_MISC_RTC>;
+ };
--
2.12.3
^ permalink raw reply related
* [RFC 0/3] arm64: Realtek RTD1295 RTC
From: Andreas Färber @ 2017-08-20 1:36 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, linux-rtc, linux-arm-kernel
Cc: linux-kernel, Roc He, 蒋丽琴,
Andreas Färber, devicetree
Hello,
This series adds the RTC for the Realtek RTD1295 SoC.
Based on my RTD1295 clk series.
There being no public source code for RTD1295, the implementation is based on
register offsets seen in the vendor DT, as well as older mach-rtk119x code
published by QNAP.
The base year is hardcoded - probably should be a DT property like downstream?
The DT node depends on the clk series for clock index and header.
More experimental patches at:
https://github.com/afaerber/linux/commits/rtd1295-next
Have a lot of fun!
Cheers,
Andreas
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: linux-rtc@vger.kernel.org
Cc: Roc He <hepeng@zidoo.tv>
Cc: 蒋丽琴 <jiang.liqin@geniatech.com>
Cc: devicetree@vger.kernel.org
Andreas Färber (3):
dt-bindings: rtc: Add Realtek RTD1295
rtc: Add Realtek RTD1295
arm64: dts: realtek: Add RTD1295 RTC node
.../devicetree/bindings/rtc/realtek,rtd119x.txt | 16 ++
arch/arm64/boot/dts/realtek/rtd1295.dtsi | 6 +
drivers/rtc/Kconfig | 8 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-rtd119x.c | 175 +++++++++++++++++++++
5 files changed, 206 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/realtek,rtd119x.txt
create mode 100644 drivers/rtc/rtc-rtd119x.c
--
2.12.3
^ permalink raw reply
* [PATCH 4/4] rtc: rv3029c2: constify i2c_device_id
From: Arvind Yadav @ 2017-08-19 19:07 UTC (permalink / raw)
To: a.zummo, alexandre.belloni; +Cc: linux-kernel, linux-rtc
In-Reply-To: <1503169678-18078-1-git-send-email-arvind.yadav.cs@gmail.com>
i2c_device_id are not supposed to change at runtime. All functions
working with i2c_device_id provided by <linux/i2c.h> work with
const i2c_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/rtc/rtc-rv3029c2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-rv3029c2.c b/drivers/rtc/rtc-rv3029c2.c
index 85fa1da..aa09771 100644
--- a/drivers/rtc/rtc-rv3029c2.c
+++ b/drivers/rtc/rtc-rv3029c2.c
@@ -868,7 +868,7 @@ static int rv3029_i2c_probe(struct i2c_client *client,
return rv3029_probe(&client->dev, regmap, client->irq, client->name);
}
-static struct i2c_device_id rv3029_id[] = {
+static const struct i2c_device_id rv3029_id[] = {
{ "rv3029", 0 },
{ "rv3029c2", 0 },
{ }
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox