linux-kernel - Re: [patch] provide rtc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 May 2008 16:05:39 -0700
From:	David Brownell <david-b@...bell.net>
To:	Stas Sergeev <stsp@...et.ru>
Cc:	Linux kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [patch] provide rtc_cmos platform device

On Tuesday 20 May 2008, Stas Sergeev wrote:
> Hello.
> 
> Recently (around 2.6.25) I've noticed
> that RTC no longer works for me.
> It turned out this is because I use
> pnpacpi=off kernel option to work
> around the parport_pc bugs.
> I always did so, but RTC used to work
> fine in the past, and now it have
> regressed.

Well, "regression" is the wrong phrase.  You've switched
drivers (from the legacy RTC to the new one), so this is
not the thing which worked for you before.

Nonetheless, this should get fixed soonish; it just happens
to be something nobody reported before.

See two comments about patch brokenness below, though ...
this patch is broken and should not be merged.

> The attached patch fixes the problem
> by creating the platform device for
> the RTC when PNP is disabled.

If I had realized there was a "pnpacpi=off" option, I'd
have sent in my patch addressing this problem way back
when the rtc-cmos code merged!  I was deluded into thinking
this was a non-problem once ACPI and PNPACPI entered the
"always selected" mode, right about that time.

> This may also help running the
> PNP-enabled kernel on an older PCs.

As in, pre-PNP.  That's pretty darn old!  Although one
person mentioned an example of a system with broken PNP
support, which didn't report the RTC device (just stuck
its resources in the middle of a bunch of reserved
addresses).  So you might want to consider looking at
the case where PNP exists, but an RTC device doesn't ...

- Dave

(1) On an ARM build (with no PNP configured):

  CC      drivers/rtc/rtc-cmos.o
drivers/rtc/rtc-cmos.c: In function 'cmos_init':
drivers/rtc/rtc-cmos.c:949: error: 'pnp_platform_devices' undeclared (first use in this function)
drivers/rtc/rtc-cmos.c:949: error: (Each undeclared identifier is reported only once
drivers/rtc/rtc-cmos.c:949: error: for each function it appears in.)
drivers/rtc/rtc-cmos.c:950: error: implicit declaration of function 'pnp_register_driver'
drivers/rtc/rtc-cmos.c:950: error: 'cmos_pnp_driver' undeclared (first use in this function)
drivers/rtc/rtc-cmos.c: In function 'cmos_exit':
drivers/rtc/rtc-cmos.c:959: error: 'pnp_platform_devices' undeclared (first use in this function)
drivers/rtc/rtc-cmos.c:960: error: implicit declaration of function 'pnp_unregister_driver'
drivers/rtc/rtc-cmos.c:960: error: 'cmos_pnp_driver' undeclared (first use in this function)
make[1]: *** [drivers/rtc/rtc-cmos.o] Error 1
make: *** [drivers/rtc/rtc-cmos.o] Error 2

(2)

> --- a/include/asm-x86/rtc.h
> +++ b/include/asm-x86/rtc.h
> @@ -1 +1,5 @@
>  #include <asm-generic/rtc.h>
> +
> +#define RTC_PORT_START 0x70
> +#define RTC_PORT_END 0x71
> +#define RTC_IRQ 8

You shouldn't define those symbols; the right values are already
defined in <asm/mc146818rtc.h>.  RTC_PORT(0) and RTC_PORT(1) are
the symbolss to use; RTC_IRQ is already defined.  All this stuff
is used in the <asm-generic/rtc.h> code ...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/