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]
Message-Id: <200701091601.51830.david-b@pacbell.net>
Date:	Tue, 9 Jan 2007 16:01:51 -0800
From:	David Brownell <david-b@...bell.net>
To:	Woody Suwalski <woodys@...dros.com>
Cc:	Alessandro Zummo <alessandro.zummo@...ertech.it>,
	rtc-linux@...glegroups.com,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>
Subject: Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver

On Tuesday 09 January 2007 8:37 am, Woody Suwalski wrote:

> As to the patch: applied to 2.6.20-rc4, both on PC and ARM, commented 
> out "EXPERIMENTAL"...
> 
> To build your new patch for ARM I have modified the line "depends on 
> RTC_CLASS && (X86_PC || ACPI || ARM)"...
> 
> On Netwinder ARM - can not build (see: rtc_build.log)

Heh, so it's a good thing I disabled the build there.  :)


> OK, changed the include/asm/rtc.h to look like i386 == include 
> asm-generic/rtc.h

In drivers/rtc/rtc-cmos.c I hope ...  <asm/rtc.h> seems to not
give equivalent functionality even on platforms which have it.

Looks to me like <asm-generic/rtc.h> is the right solution, though
that still implies arch-level support for <asm/mc146818rtc.h> which
does not exist on all platforms.

So the attached version of the rtc-cmos patch uses asm-generic
and also adds Kconfig dependencies for architectures with usable
versions of that header.

Of course, the "right" answer is to make this be like any other
driver and allow the registers to go anywhere in the address space,
not hard-wiring them to a platform-specific I/O space address.
That is, CMOS_READ/CMOS_WRITE are legacy baggage.  But that's not
an issue to be addressed by this particular patch.


> Still does not build - see rtc_build2.log
> 
> Could you please check what other defs are missing on ARM?

I'm not sure what you changed.  I updated the rtc-cmos patch to
use <asm-generic/rtc.h> directly, then did an ARM build which
configured that driver as a module.  No compile-time problems.
(I think you changed the wrong file...)

But at link time I ran into the problem that arm/kernel/time.c
defines "rtc_lock" but only exports it to an obsolete SA1100
driver.  See attached "rtc-arm.patch".

But static linking was no problem ... of course, I didn't add
any code to define the platform_device (with or without the
platform_data teling about extra registers) and couldn't test
anything other than the build.


>  >>>
> <anderson@...sweng.com>
> As for the RTC patch, it does work on the shark, and is needed.
> <<<
> 
> So is there a reason to have RTC build blocked on all ARM?

The original reason was that it's not known to work.  Given
the attached patches, that issue is resolved at least from
the build perspective.

- Dave

View attachment "rtc-arm.patch" of type "text/x-diff" (886 bytes)

View attachment "rtc-cmos-2.patch" of type "text/x-diff" (23292 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ