Hello Uwe,
On 28/07/2019 21.40, Uwe Kleine-König wrote:
Control: tag -1 + fixed-upstream pending
Hello Oliver,
I tried to reproduce your problem on v5.3 and there the problem doesn't
occur even without CONFIG_RTC_INTF_DEV_UIE_EMUL. The reason can be found
in
Control: tag -1 + fixed-upstream pending
Hello Oliver,
I tried to reproduce your problem on v5.3 and there the problem doesn't
occur even without CONFIG_RTC_INTF_DEV_UIE_EMUL. The reason can be found
in
https://git.kernel.org/linus/c0e12848be091e8410fb427f080f2e0149123443
which got
On 26/07/2019 20.12, Trent Piepho wrote:
On Fri, 2019-07-26 at 12:53 +0200, Oliver Hartkopp wrote:
Just a thought:
There are some of these rtc drivers that set
rtc->rtc->uie_unsupported = 1;
in the case that they can't assign an irq line.
But others set
rtc->rtc->uie_unsupported = 1;
On Fri, 2019-07-26 at 12:53 +0200, Oliver Hartkopp wrote:
> Just a thought:
>
> There are some of these rtc drivers that set
>
> rtc->rtc->uie_unsupported = 1;
>
> in the case that they can't assign an irq line.
>
> But others set
>
> rtc->rtc->uie_unsupported = 1;
>
> when they don't
Just a thought:
There are some of these rtc drivers that set
rtc->rtc->uie_unsupported = 1;
in the case that they can't assign an irq line.
But others set
rtc->rtc->uie_unsupported = 1;
when they don't support an (alarm) trigger with 1 sec accuracy.
Wouldn't it make sense to put
+
Hello Alexandre,
On 26.07.19 11:39, Alexandre Belloni wrote:
Maybe this problem is only relevant for the S35390A and PCF8563 chip which
both lack the UIE support needed by hwclock. Both have only alarm triggers
in a minute accuracy according to the driver source code.
AFAIK the rtc framework
On 26/07/2019 11:27:11+0200, Oliver Hartkopp wrote:
> Hello Uwe,
>
> On 26.07.19 09:27, Uwe Kleine-König wrote:
> > Hello Alexandre,
> >
> > On Thu, Jul 25, 2019 at 04:31:49PM +0200, Oliver Hartkopp wrote:
> > > On 24.07.19 09:07, Uwe Kleine-König wrote:
> > > > On Tue, Jul 23, 2019 at
Hello Uwe,
On 26.07.19 09:27, Uwe Kleine-König wrote:
Hello Alexandre,
On Thu, Jul 25, 2019 at 04:31:49PM +0200, Oliver Hartkopp wrote:
On 24.07.19 09:07, Uwe Kleine-König wrote:
On Tue, Jul 23, 2019 at 10:28:18PM +0200, Oliver Hartkopp wrote:
I'm running a TS-119P+ and a TS-219P II Qnap
Hello Alexandre,
On Thu, Jul 25, 2019 at 04:31:49PM +0200, Oliver Hartkopp wrote:
> On 24.07.19 09:07, Uwe Kleine-König wrote:
> > On Tue, Jul 23, 2019 at 10:28:18PM +0200, Oliver Hartkopp wrote:
> > > I'm running a TS-119P+ and a TS-219P II Qnap NAS with Debian Buster.
> > > Both are now running
Hello Uwe,
On 24.07.19 09:07, Uwe Kleine-König wrote:
Hello Oliver,
On Tue, Jul 23, 2019 at 10:28:18PM +0200, Oliver Hartkopp wrote:
I'm running a TS-119P+ and a TS-219P II Qnap NAS with Debian Buster.
Both are now running a linux-image-4.19.0-5-marvell kernel.
But since my update from Linux
Hello Oliver,
On Tue, Jul 23, 2019 at 10:28:18PM +0200, Oliver Hartkopp wrote:
> I'm running a TS-119P+ and a TS-219P II Qnap NAS with Debian Buster.
> Both are now running a linux-image-4.19.0-5-marvell kernel.
>
> But since my update from Linux 4.9 (Stretch) to Linux 4.19 (Buster) the
>
Package: linux-image-4.19.0-5-marvell
Status: install ok installed
Priority: optional
Section: kernel
Installed-Size: 97721
Maintainer: Debian Kernel Team
Architecture: armel
Source: linux
Version: 4.19.37-5
Depends: kmod, linux-base (>= 4.3~), initramfs-tools (>= 0.120+deb8u2) |
12 matches
Mail list logo
