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
https://git.kernel.org/lin
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 into
Processing control commands:
> tag -1 + fixed-upstream pending
Bug #932845 [src:linux] TS-219 RTC issue with Debian Buster
Added tag(s) pending and fixed-upstream.
--
932845: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932845
Debian Bug Tracking System
Contact ow...@bugs.debian.org with pr
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;
whe
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 support
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
+ se
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 10:28:18PM
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 NAS
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
> hardwar
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) |
linux-initramfs
13 matches
Mail list logo
