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:	Thu, 22 May 2008 12:56:14 -0700
From:	David Brownell <david-b@...bell.net>
To:	Stas Sergeev <stsp@...et.ru>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] provide rtc_cmos platform device

On Thursday 22 May 2008, Stas Sergeev wrote:
> David Brownell wrote:
> > 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.
> > 
> I am not sure how could that happen.
> I am always just taking an old kernel
> config and never change the options
> that are not supposed to be changed.
> Was the old RTC driver removed by any
> chance?

The Kconfig was changed to prevent anyone from using
a particular broken configuration:  using legacy RTC
drivers along with the new RTC framework.

Presumably your old config was broken in that way.
So I can see why it'd feel like a regression.

> >> This may also help running the
> >> PNP-enabled kernel on an older PCs.
> > 
> > As in, pre-PNP. That's pretty darn old!
> 
> But... I think they should still be
> supported, unless it is too difficult.

Sure.  Having working hardware to test with is the
usual trouble here.  Do you have such hardware?

(I didn't object to fixing that, at all; I was just
pointing out that hardware where this matters is not
particularly available any more, and hasn't been so
for quite a few years now.)

> > (1) On an ARM build (with no PNP configured):
> 
> OK, but unfortunately I can't help
> with that. I won't touch any non-x86
> arch code, so I'll simply go for
> the #ifdef here, or someone else
> should make the patch instead. :)

Sure you can help; that's why I sent the compiler
messages telling what went wrong.  You were
referencing symbols that are not defined on
non-pnp systems.  All you have to do is provide
enough definitions to compile.  For test builds
you can even #undef the CONFIG_PNP* symbols at
the top of the rtc-cmos code.

I understand Russell King has been sitting on a
similar patch (for the generic bits, not the x86
specific parts) for some time.  Maybe you can get
his patch, which will surely work on ARM.

- Dave

> > 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 ...
> 
> OK, thanks.
> I'll update the patch, in todo for
> the week-end.
> 

--
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/