linux.git/drivers/rtc/rtc-cmos.c, branch v2.6.31

rtc: mark if rtc-cmos drivers were successfully registered

2009-07-30T02:10:35+00:00

rtc-cmos has two drivers, one PNP and one platform.  When PNP has not
succeeded probing, platform is registered.  However, it tries to
unregister both drivers unconditionally, instead of only unregistering
those that were successfully registered.  This causes runtime warnings to
be emitted from the driver core code.

Fix this with a boolean variable for each driver indicating whether
registering was successful.

Signed-off-by: Thadeu Lima de Souza Cascardo 
Cc: David Brownell 
Cc: Bjorn Helgaas 
Cc: Alessandro Zummo 
Cc: Ingo Molnar 
Cc: David Brownell 
Cc: Kay Sievers 
Cc: Greg KH 
Cc: Ozan Caglayan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc-cmos: fix printk output

2009-04-21T20:41:50+00:00

With no IRQ available/defined, RTC-CMOS driver prints something like:
	rtc0: alarms up to one no, y3k, 114 bytes nvram
                              ^^^^
I guess the following is a bit easier to understand:
	rtc0: no alarms, y3k, 114 bytes nvram

Signed-off-by: Krzysztof Halasa 
Cc: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc: move power of 2 periodic frequency check down into drivers

2009-01-06T23:59:24+00:00

Move the power of 2 check on frequencies down into individual rtc drivers

This is to allow for non power of 2 real time clock periodic interrupts
such as those on the pxa27x to be found in the new pxa27x-rtc driver

Signed-off-by: Jonathan Cameron 
Signed-off-by: Alessandro Zummo 
Cc: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc: bunch of drivers: fix 'no irq' case handing

2009-01-06T23:59:23+00:00

This patch fixes a bunch of irq checking misuses.  Most drivers were
getting irq via platform_get_irq(), which returns -ENXIO or r->start.

rtc-cmos.c is special.  It is using PNP and platform bindings.  Hopefully
nobody is using PNP IRQ 0 for RTC.  So the changes should be safe.

rtc-sh.c is using platform_get_irq, but was storing a result into an
unsigned type, then was checking for < 0.  This is fixed now.

Signed-off-by: Anton Vorontsov 
Cc: Alessandro Zummo 
Acked-by: David Brownell 
Acked-by: Paul Mundt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc: struct device: replace bus_id with dev_name(), dev_set_name()

2009-01-06T23:59:23+00:00

Acked-by: Alessandro Zummo 
Acked-By: Greg Kroah-Hartman 
Signed-off-by: Kay Sievers 
Cc: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc-cmos: fix boot log message

2008-11-06T23:41:19+00:00

-rtc0: alarms up to one month, y3k, 114 bytes nvram, , hpet irqs irqs
+rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs

Signed-off-by: Frans Pop 
Cc: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86: sysfs: kill owner field from attribute

2008-10-20T15:52:42+00:00

Tejun's commit 7b595756ec1f49e0049a9e01a1298d53a7faaa15 made sysfs
attribute->owner unnecessary.  But the field was left in the structure to
ease the merge.  It's been over a year since that change and it is now
time to start killing attribute->owner along with its users - one arch at
a time!

This patch is attempt #1 to get rid of attribute->owner only for
CONFIG_X86_64 or CONFIG_X86_32 .  We will deal with other arches later on
as and when possible - avr32 will be the next since that is something I
can test.  Compile (make allyesconfig / make allmodconfig / custom config)
and boot tested.

akpm: the idea is that we put the declaration of sttribute.owner inside
`#ifndef CONFIG_X86'.  But that proved to be too ambitious for now because
new usages kept on turning up in subsystem trees.

[akpm: remove the ifdef for now]
Signed-off-by: Parag Warudkar 
Cc: Greg KH 
Cc: Ingo Molnar 
Cc: Tejun Heo 
Cc: Len Brown 
Cc: Jens Axboe 
Cc: Jean Delvare 
Cc: Roland Dreier 
Cc: David Brownell 
Cc: Alessandro Zummo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

drivers/rtc/: use bcd2bin/bin2bcd

2008-10-20T15:52:41+00:00

Change drivers/rtc/ to use the new bcd2bin/bin2bcd functions instead of
the obsolete BCD_TO_BIN/BIN_TO_BCD/BCD2BIN/BIN2BCD macros.

Signed-off-by: Adrian Bunk 
Acked-by: Alessandro Zummo 
Cc: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc-cmos: export second NVRAM bank

2008-10-20T15:52:36+00:00

Teach rtc-cmos about the second bank of registers found on most modern x86
systems, giving access to 128 bytes more NVRAM.

This version only sees that extra NVRAM when both register banks are
provided as part of *one* PNP resource.  Since BIOS on some systems
presents them using two IO resources, and nothing merges them, this can't
always show all the NVRAM.  (We're supposed to be able to use PNP id
PNP0b01 too, but BIOS tables doesn't often seem to use that particular
option.)

Signed-off-by: David Brownell 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Bjorn Helgaas 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc-cmos: look for PNP RTC first, then for platform RTC

2008-10-14T23:30:14+00:00

We shouldn't rely on "pnp_platform_devices" to tell us whether there
is a PNP RTC device.

I introduced "pnp_platform_devices", but I think it was a mistake.
All it tells us is whether we found any PNPBIOS or PNPACPI devices.
Many machines have some PNP devices, but do not describe the RTC
via PNP.  On those machines, we need to do the platform driver probe
to find the RTC.

We should just register the PNP driver and see whether it claims anything.
If we don't find a PNP RTC, fall back to the platform driver probe.

This (in conjunction with the arch/x86/kernel/rtc.c patch to add
a platform RTC device when PNP doesn't have one) should resolve
these issues:

    http://bugzilla.kernel.org/show_bug.cgi?id=11580
    https://bugzilla.redhat.com/show_bug.cgi?id=451188

Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
Acked-by: David Brownell 
Reported-by: Rik Theys 
Reported-by: shr_msn@yahoo.com.tw
Signed-off-by: Linus Torvalds