10 Jun, 2011
1 commit
-
Several fixes as well where the +1 was missing.
Done via coccinelle scripts like:
@@
struct resource *ptr;
@@- ptr->end - ptr->start + 1
+ resource_size(ptr)and some grep and typing.
Mostly uncompiled, no cross-compilers.
Signed-off-by: Joe Perches
Signed-off-by: Jiri Kosina
16 Mar, 2011
1 commit
-
…el/git/tip/linux-2.6-tip
* 'x86-platform-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (27 commits)
x86: Clean up apic.c and apic.h
x86: Remove superflous goal definition of tsc_sync
x86: dt: Correct local apic documentation in device tree bindings
x86: dt: Cleanup local apic setup
x86: dt: Fix OLPC=y/INTEL_CE=n build
rtc: cmos: Add OF bindings
x86: ce4100: Use OF to setup devices
x86: ioapic: Add OF bindings for IO_APIC
x86: dtb: Add generic bus probe
x86: dtb: Add support for PCI devices backed by dtb nodes
x86: dtb: Add device tree support for HPET
x86: dtb: Add early parsing of IO_APIC
x86: dtb: Add irq domain abstraction
x86: dtb: Add a device tree for CE4100
x86: Add device tree support
x86: e820: Remove conditional early mapping in parse_e820_ext
x86: OLPC: Make OLPC=n build again
x86: OLPC: Remove extra OLPC_OPENFIRMWARE_DT indirection
x86: OLPC: Cleanup config maze completely
x86: OLPC: Hide OLPC_OPENFIRMWARE config switch
...Fix up conflicts in arch/x86/platform/ce4100/ce4100.c
10 Mar, 2011
3 commits
-
Now that the generic code handles UIE mode irqs via periodic
alarm interrupts, no one calls the
rtc_class_ops->update_irq_enable() method anymore.This patch removes the driver hooks and implementations of
update_irq_enable if no one else is calling it.CC: Thomas Gleixner
CC: Alessandro Zummo
CC: Marcelo Roberto Jimenez
CC: rtc-linux@googlegroups.com
Signed-off-by: John Stultz -
With the generic rtc code now emulating PIE mode irqs via an
hrtimer, no one calls the rtc_class_ops->irq_set_freq call.This patch removes the hook and deletes the driver functions
if no one else calls them.CC: Thomas Gleixner
CC: Alessandro Zummo
CC: Marcelo Roberto Jimenez
CC: rtc-linux@googlegroups.com
Signed-off-by: John Stultz -
With PIE mode interrupts now emulated in generic code via an hrtimer,
no one calls rtc_class_ops->irq_set_state(), so this patch removes it
along with driver implementations.CC: Thomas Gleixner
CC: Alessandro Zummo
CC: Marcelo Roberto Jimenez
CC: rtc-linux@googlegroups.com
Signed-off-by: John Stultz
24 Feb, 2011
1 commit
-
This allows to load the OF driver based informations from the device
tree. Systems without BIOS may need to perform some initialization.
PowerPC creates a PNP device from the OF information and performs this
kind of initialization in their private PCI quirk. This looks more
generic.This patch also avoids registering the platform RTC driver on X86 if
we have a device tree blob. Otherwise we would setup the device based
on the hardcoded information in arch/x86 rather than the device tree
based one.[ tglx: Changed "int of_have_populated_dt()" to bool as recommended by
Grant ]Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Dirk Brandewie
Acked-by: Grant Likely
Cc: sodaville@linutronix.de
Cc: devicetree-discuss@lists.ozlabs.org
Cc: rtc-linux@googlegroups.com
Cc: Alessandro Zummo
LKML-Reference:
Signed-off-by: Thomas Gleixner
14 Jan, 2011
1 commit
-
rtc-cmos was setting suspend/resume hooks at the device_driver level.
However, the platform bus code (drivers/base/platform.c) only looks for
resume hooks at the dev_pm_ops level, or within the platform_driver.Switch rtc_cmos to use dev_pm_ops so that suspend/resume code is executed
again.Paul said:
: The user visible symptom in our (XO laptop) case was that rtcwake would
: fail to wake the laptop. The RTC alarm would expire, but the wakeup
: wasn't unmasked.
:
: As for severity, the impact may have been reduced because if I recall
: correctly, the bug only affected platforms with CONFIG_PNP disabled.Signed-off-by: Paul Fox
Signed-off-by: Daniel Drake
Acked-by: Rafael J. Wysocki
Cc: [2.6.37.x]
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
29 Nov, 2010
1 commit
-
The following warning is seen while compilation of PowerPC kernel:
CC drivers/rtc/rtc-cmos.o
drivers/rtc/rtc-cmos.c:697:2: warning: #warning Assuming 128 bytes
of RTC+NVRAM address space, not 64 bytes.Fix it by adding defined(__powerpc__).
Signed-off-by: Srikanth Krishnakar
Signed-off-by: Benjamin Herrenschmidt
11 Aug, 2010
1 commit
-
Because CONFIG_PM is a precondition to CONFIG_ACPI, the ifdef CONFIG_PM
within ifdef CONFIG_ACPI is redundant.Signed-off-by: Christian Dietrich
Acked-by: Wan ZongShun
Cc: Alessandro Zummo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
25 May, 2010
1 commit
-
The bug is an oops when dev_get_drvdata() returned null in
cmos_update_irq_enable(). The call tree looks like this:
rtc_dev_ioctl()
=> rtc_update_irq_enable()
=> cmos_update_irq_enable()It's caused by a race condition in the module initialization. It is
rtc_device_register() which makes the ioctl operations live so I moved
the call to dev_set_drvdata() before the call to rtc_device_register().Addresses https://bugzilla.kernel.org/show_bug.cgi?id=15963
Reported-by: Randy Dunlap
Signed-off-by: Dan Carpenter
Tested-by: Randy Dunlap
Cc: Alessandro Zummo
Cc: Paul Gortmaker
Cc: Malte Schroder
Cc: Ralf Baechle
Cc: Herton Ronaldo Krzesinski
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
22 May, 2010
2 commits
-
As a follow-up to the thread about RTC support for some Loongson 2E/2F
boards, this patch tries to address the "REVISIT"/"FIXME" comments about
rtc binary mode handling and allow rtc to work with rtc in binary mode.
I've also raised the message about 24-h mode not supported to warning
otherwise, one may end up with no rtc without any message in the kernel
log.Signed-off-by: Arnaud Patard
To: linux-mips@linux-mips.org
To: rtc-linux@googlegroups.com
Cc: david-b@pacbell.net
Cc: a.zummo@towertech.it
Cc: akpm@linux-foundation.org
Patchwork: http://patchwork.linux-mips.org/patch/1158/
Signed-off-by: Ralf Baechle -
This allows bin_attr->read,write,mmap callbacks to check file specific data
(such as inode owner) as part of any privilege validation.Signed-off-by: Chris Wright
Signed-off-by: Greg Kroah-Hartman
12 Jan, 2010
1 commit
-
commit abd6633c67925f90775bb74755f9c547e30f1f20 ("pnp: add a shutdown
method to pnp drivers") adds shutdown method to bus driver blindly. With
it, driver->shutdown is no longer valid.Use pnp_driver->shutdown instead.
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14889
Signed-off-by: OGAWA Hirofumi
Reported-by: Malte Schröder
Cc: "Rafael J. Wysocki"
Cc: Bjorn Helgaas
Cc: David Hardeman
Cc: Dmitry Torokhov
Cc: Alessandro Zummo
Cc: Paul Gortmaker
Cc: [2.6.32.x]
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Dec, 2009
1 commit
-
This patch fixes the following warning with RTC_LIB on MIPS:
drivers/rtc/rtc-cmos.c:697:2: warning: #warning Assuming 128 bytes of
RTC+NVRAM address space, not 64 bytes.Signed-off-by: Wu Zhangjin
Cc: Arnaud Patard
Cc: linux-mips@linux-mips.org
Cc: rtc-linux@googlegroups.com
Cc: Paul Gortmaker
Cc: Alessandro Zummo
Patchwork: http://patchwork.linux-mips.org/patch/570/
Acked-by: Alessandro Zummo
Signed-off-by: Ralf Baechle
16 Dec, 2009
2 commits
-
Drop ioctl function that handles RTC_AIE/RTC_UIE, and use instead the
rtc subsystem API (alarm_irq_enable/update_irq_enable callbacks).Signed-off-by: Herton Ronaldo Krzesinski
Cc: Alessandro Zummo
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
I noticed that rtc wont generate interrupts after a resume from disk.
Here hpet rtc emulation is used.Problem is that rtc hpet comparator, isn't reinitialized after resume.
Easiest way to solve this, is always mask all hpet interrupts on suspend
This is triggered, when suspending with alarm set.Otherwise, hpet driver will think it doesn't need to reinitialize
the rtc comparator, thus rtc interrupts won't work.This emulation isn't need for wakealarm.
Signed-off-by: Maxim Levitsky
Cc: David Brownell
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "Rafael J. Wysocki"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Jul, 2009
1 commit
-
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
22 Apr, 2009
1 commit
-
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 nvramSigned-off-by: Krzysztof Halasa
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Jan, 2009
3 commits
-
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 driverSigned-off-by: Jonathan Cameron
Signed-off-by: Alessandro Zummo
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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 -
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
07 Nov, 2008
1 commit
-
-rtc0: alarms up to one month, y3k, 114 bytes nvram, , hpet irqs irqs
+rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqsSigned-off-by: Frans Pop
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
20 Oct, 2008
3 commits
-
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 -
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 -
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
15 Oct, 2008
2 commits
-
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=451188Signed-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 -
Move rtc_wake_setup() from drivers/acpi/glue.c into the RTC driver
in drivers/rtc/rtc-cmos.c.This removes the ordering constraint between the module_init(acpi_rtc_init)
and the cmos_do_probe() code that depends on it.Signed-off-by: Bjorn Helgaas
Acked-by: Rafael J. Wysocki
Signed-off-by: Linus Torvalds
17 Sep, 2008
1 commit
-
Conflicts:
arch/sparc64/kernel/pci_psycho.c
03 Sep, 2008
1 commit
-
Update rtc-cmos shutdown handling to leave RTC alarms active, resolving
http://bugzilla.kernel.org/show_bug.cgi?id=11411 on several boards. There
are still some systems where the ACPI event handling doesn't cooperate.
(Possibly related to bugid 11312, reporting the spontaneous disabling of
RTC events.)Bug 11411 reported that changes to work around some ACPI event issues
broke wake-from-S5 handling, as used for DVR applications. (They like to
power off, then wake later to record programs.)[yakui.zhao@intel.com: add shutdown for PNP devices]
[dbrownell@users.sourceforge.net: update comments]
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Zhao Yakui
Signed-off-by: Zhang Rui
Signed-off-by: David Brownell
Cc: Stefan Bauer
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Aug, 2008
1 commit
-
Add Sparc to the Kconfig depends list.
Add __sparc___ to address_sparc = 128 ifdef.
Finally, don't be concerned about 24-hour BCD mode support if the RTC
doesn't have a valid IRQ. We won't even use the alarm code in this
case and the Sparc RTCs have this limitation.Signed-off-by: David S. Miller
25 Jul, 2008
3 commits
-
This fixes kernel http://bugzilla.kernel.org/show_bug.cgi?id=11112 (bogus
RTC update IRQs reported) for rtc-cmos, in two ways:- When HPET is stealing the IRQs, use the first IRQ to grab
the seconds counter which will be monitored (instead of
using whatever was previously in that memory);- In sane IRQ handling modes, scrub out old IRQ status before
enabling IRQs.That latter is done by tightening up IRQ handling for rtc-cmos everywhere,
also ensuring that when HPET is used it's the only thing triggering IRQ
reports to userspace; net object shrink.Also fix a bogus HPET message related to its RTC emulation.
Signed-off-by: David Brownell
Report-by: W Unruh
Cc: Andrew Victor
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Resolve http://bugzilla.kernel.org/show_bug.cgi?id=11051 and other bugs
related to the way the HPET glue code in rtc-cmos was incomplete and
inconsistent:* Switch the approach so that the basic driver code flow isn't
changed by having HPET ... instead, just have HPET shadow the
RTC_CONTROL irq enables and RTC_FREQ_SELECT data. It's only
coping with IRQ thievery, after all.* Do that consistently (!!) to avoid problems when the HPET code
is out of sync with the real RTC intent. Examples include:- cmos_procfs(), which now reports correct data
- cmos_irq_set_state() ... also removing the previous PIE_{ON,OFF}
ioctl support so only one code path manages "periodic" IRQs- cmos_do_shutdown() ... currently a "just in case" change.
- cmos_suspend() and cmos_resume() ... also handling a bug that
was specific to HPET's IRQ thievery, where the alarm wasn't
disabled after waking the system* Always call that HPET code under the RTC spinlock (it doesn't do
its own locking)Also clean up the HPET glue:
* Add some comments explaining what's going on.
* Switch to having just one #ifdef for the HPET glue, and inline
functions (not #defines) to avoid some compiler warnings.* Have the probe message also report when HPET IRQs are involved
This still leaves various holes in the HPET glue, like the emulated update
IRQs being out of sync with the RTC, alarms never using day or month
matches, and many extra IRQs (at 64 Hz).[akpm@linux-foundation.org: fix build]
Signed-off-by: David Brownell
Cc: Tomas Janousek
Cc: Bernhard Walle
Cc: Carlos R. Mafra
Acked-by: Alessandro Zummo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
When CONFIG_HPET_EMULATE_RTC is defined the external declaration of
hpet_rtc_interrupt is redundant due to the inclusion of hpet.h.When !CONFIG_HPET_EMULATE_RTC we make it clear that hpet_rtc_interrupt is
not used by defining it to return zero.Signed-off-by: Carlos R. Mafra
Cc: Ingo Molnar
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Jun, 2008
1 commit
-
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.The patch fixes the problem by creating the platform device for the RTC
when PNP is disabled. This may also help running the PNP-enabled kernel
on an older PCs.Signed-off-by: Stas Sergeev
Cc: David Brownell
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Bjorn Helgaas
Cc: Adam Belay
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
29 Apr, 2008
1 commit
-
pnp_resource_table is going away soon, so use the more
generic public interfaces instead.Signed-off-by: Bjorn Helgaas
Acked-By: Rene Herman
Signed-off-by: Len Brown
16 Apr, 2008
1 commit
-
There is a bug in the function of cmos_set_alarm. RTC alarm time for October
can't be set correctly.For October: 0x0A will be written into the RTC region (MONTH_ALARM) in current
kernel. But in fact 0x10 should be written. Wildcards are also not handled
correctly.Signed-off-by: Zhao Yakui
Signed-off-by: Zhang Rui
Signed-off-by: David Brownell
Cc: Alessandro Zummo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Apr, 2008
1 commit
-
Since 43cc71eed1250755986da4c0f9898f9a635cb3bf, the platform modalias is
prefixed with "platform:". Add MODULE_ALIAS() to the hotpluggable RTC
platform drivers, to re-enable module auto loading.[dbrownell@users.sourceforge.net: more drivers, minor fix]
Signed-off-by: Kay Sievers
Signed-off-by: David Brownell
Cc: Greg KH
Cc: Alessandro Zummo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
24 Feb, 2008
1 commit
-
For the "cmos" RTC, have /proc/driver/rtc say whether HPET based IRQ
emulation is in effect. Given the problems we've had with this particular
hardware maldesign (and the fact that most BIOS code seems not to provide
the IRQ routing needed to use the saner HPET modes), this should help
troubleshooting.Signed-off-by: David Brownell
Cc: Alessandro Zummo
Cc: Ingo Molnar
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Feb, 2008
2 commits
-
That patch adds the RTC emulation of the HPET timer to the new RTC_DRV_CMOS.
The old drivers/char/rtc.ko driver had that functionality and it's important
on new systems.[akpm@linux-foundation.org: unbreak alpha build]
Signed-off-by: Bernhard Walle
Cc: Alessandro Zummo
Cc: David Brownell
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Andi Kleen
Cc: john stultz
Cc: Robert Picco
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Start making the rtc-cmos alarm act more like a oneshot alarm by disabling
that alarm after its IRQ fires. (ACPI hooks are also needed.)The Linux RTC framework has previously been a bit vague in this area, but
any other behavior is problematic and not very portable. RTCs with full
YYYY-MM-DD HH:MM[:SS] alarms won't have a problem here. Only ones with
partial match criteria, with the most visible example being the PC RTC, get
confused. (Because the criteria will match repeatedly.)Update comments relating to that oneshot behavior and timezone handling.
(Timezones are another issue that's mostly visible with rtc-cmos. That's
because PCs often dual-boot MS-Windows, which likes its RTC to match local
wall-clock time instead of UTC.)Signed-off-by: David Brownell
Cc: Alessandro Zummo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds