linux-toradex.git/drivers/char/hpet.c, branch v3.3.2

Merge branch 'x86-vdso-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

2011-07-23T00:05:15+00:00

* 'x86-vdso-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  x86-64, vdso: Do not allocate memory for the vDSO
  clocksource: Change __ARCH_HAS_CLOCKSOURCE_DATA to a CONFIG option
  x86, vdso: Drop now wrong comment
  Document the vDSO and add a reference parser
  ia64: Replace clocksource.fsys_mmio with generic arch data
  x86-64: Move vread_tsc and vread_hpet into the vDSO
  clocksource: Replace vread with generic arch data
  x86-64: Add --no-undefined to vDSO build
  x86-64: Allow alternative patching in the vDSO
  x86: Make alternative instruction pointers relative
  x86-64: Improve vsyscall emulation CS and RIP handling
  x86-64: Emulate legacy vsyscalls
  x86-64: Fill unused parts of the vsyscall page with 0xcc
  x86-64: Remove vsyscall number 3 (venosys)
  x86-64: Map the HPET NX
  x86-64: Remove kernel.vsyscall64 sysctl
  x86-64: Give vvars their own page
  x86-64: Document some of entry_64.S
  x86-64: Fix alignment of jiffies variable

ia64: Replace clocksource.fsys_mmio with generic arch data

2011-07-15T00:57:09+00:00

Now that clocksource.archdata is available, use it for ia64-specific
code.

Cc: Clemens Ladisch 
Cc: linux-ia64@vger.kernel.org
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: John Stultz 
Cc: Thomas Gleixner 
Signed-off-by: Andy Lutomirski 
Link: http://lkml.kernel.org/r/d31de0ee0842a0e322fb6441571c2b0adb323fa2.1310563276.git.luto@mit.edu
Signed-off-by: H. Peter Anvin

drivers/char/hpet.c: fix periodic-emulation for delayed interrupts

2011-06-16T03:04:02+00:00

When interrupts are delayed due to interrupt masking or due to other
interrupts being serviced the HPET periodic-emuation would fail.  This
happened because given an interval t and a time for the current interrupt
m we would compute the next time as t + m.  This works until we are
delayed for > t, in which case we would be writing a new value which is in
fact in the past.

This can be solved by computing the next time instead as (k * t) + m where
k is large enough to be in the future.  The exact computation of k is
described in a comment to the code.

More detail:

Assuming an interval of 5 between each expected interrupt we have a normal
case of

t0: interrupt, read t0 from comparator, set next interrupt t0 + 5
t5: interrupt, read t5 from comparator, set next interrupt t5 + 5
t10: interrupt, read t10 from comparator, set next interrupt t10 + 5
...

So, what happens when the interrupt is serviced too late?

t0: interrupt, read t0 from comparator, set next interrupt t0 + 5
t11: delayed interrupt serviced, read t5 from comparator, set next
interrupt t5 + 5, which is in the past!
... counter loops ...
t10: Much much later, get the next interrupt.

This can happen either because we have interrupts masked for too long
(some stupid driver goes on a printk rampage) or just because we are
pushing the limits of the interval (too small a period), or both most
probably.

My solution is to read the main counter as well and set the next interrupt
to occur at the right interval, for example:

t0: interrupt, read t0 from comparator, set next interrupt t0 + 5
t11: delayed interrupt serviced, read t5 from comparator, set next
interrupt t15 as t10 has been missed.
t15: back on track.

Signed-off-by: Nils Carlson 
Cc: John Stultz 
Cc: Thomas Gleixner 
Cc: Clemens Ladisch 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ia64: convert to clocksource_register_hz/khz

2011-02-21T21:33:45+00:00

This converts the ia64 clocksources to use clocksource_register_hz/khz

CC: Tony Luck 
CC: Thomas Gleixner 
Tested-by: Tony Luck  [clocksource_itc path]
Signed-off-by: John Stultz

BKL: remove extraneous #include

2010-11-17T16:59:32+00:00

The big kernel lock has been removed from all these files at some point,
leaving only the #include.

Remove this too as a cleanup.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Linus Torvalds

drivers/char/hpet.c: fix information leak to userland

2010-10-26T23:52:11+00:00

Structure info is copied to userland with some padding fields unitialized.
It leads to leaking of stack memory.

[akpm@linux-foundation.org: remove now-unneeded zeroing of info->hi_ireqfreq]
Signed-off-by: Vasiliy Kulikov 
Cc: Clemens Ladisch 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

hpet: fix style problems

2010-10-26T23:52:11+00:00

Fix the following style problems:

WARNING: Use #include  instead of 
WARNING: Use #include  instead of 
ERROR: code indent should use tabs where possible
ERROR: do not initialise statics to 0 or NULL

Signed-off-by: Jaswinder Singh Rajput 
Cc: Clemens Ladisch 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

hpet: fix unwanted interrupt due to stale irq status bit

2010-10-26T23:52:11+00:00

Jaswinder Singh Rajput wrote:
> By executing Documentation/timers/hpet_example.c
>
> for polling, I requested for 3 iterations but it seems iteration work
> for only 2 as first expired time is always very small.
>
> # ./hpet_example poll /dev/hpet 10 3
> -hpet: executing poll
> hpet_poll: info.hi_flags 0x0
> hpet_poll: expired time = 0x13
> hpet_poll: revents = 0x1
> hpet_poll: data 0x1
> hpet_poll: expired time = 0x1868c
> hpet_poll: revents = 0x1
> hpet_poll: data 0x1
> hpet_poll: expired time = 0x18645
> hpet_poll: revents = 0x1
> hpet_poll: data 0x1

Clearing the HPET interrupt enable bit disables interrupt generation
but does not disable the timer, so the interrupt status bit will still
be set when the timer elapses.  If another interrupt arrives before
the timer has been correctly programmed (due to some other device on
the same interrupt line, or CONFIG_DEBUG_SHIRQ), this results in an
extra unwanted interrupt event because the status bit is likely to be
set from comparator matches that happened before the device was opened.

Therefore, we have to ensure that the interrupt status bit is and
stays cleared until we actually program the timer.

Signed-off-by: Clemens Ladisch 
Reported-by: Jaswinder Singh Rajput 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: john stultz 
Cc: Bob Picco 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

hpet: unmap unused I/O space

2010-10-26T23:52:11+00:00

When the initialization code in hpet finds a memory resource and does not
find an IRQ, it does not unmap the memory resource previously mapped.

There are buggy BIOSes which report resources exactly like this and what
is worse the memory region bases point to normal RAM.  This normally would
not matter since the space is not touched.  But when PAT is turned on,
ioremap causes the page to be uncached and sets this bit in page->flags.

Then when the page is about to be used by the allocator, it is reported
as:

BUG: Bad page state in process md5sum  pfn:3ed00
page:ffffea0000dbd800 count:0 mapcount:0 mapping:(null) index:0x0
page flags: 0x20000001000000(uncached)
Pid: 7956, comm: md5sum Not tainted 2.6.34-12-desktop #1
Call Trace:
 [] bad_page+0xb1/0x100
 [] prep_new_page+0x1a5/0x1c0
 [] get_page_from_freelist+0x3a1/0x640
 [] __alloc_pages_nodemask+0x10f/0x6b0
...

In this particular case:

1) HPET returns 3ed00000 as memory region base, but it is not in
reserved ranges reported by the BIOS (excerpt):
 BIOS-e820: 0000000000100000 - 00000000af6cf000 (usable)
 BIOS-e820: 00000000af6cf000 - 00000000afdcf000 (reserved)

2) there is no IRQ resource reported by HPET method. On the other
hand, the Intel HPET specs (1.0a) says (3.2.5.1):
_CRS (
  // Report 1K of memory consumed by this Timer Block
  memory range consumed
  // Optional: only used if BIOS allocates Interrupts [1]
  IRQs consumed
)

[1] For case where Timer Block is configured to consume IRQ0/IRQ8 AND
Legacy 8254/Legacy RTC hardware still exists, the device objects
associated with 8254 & RTC devices should not report IRQ0/IRQ8 as
"consumed resources".

So in theory we should check whether if it is the case and use those
interrupts instead.

Anyway the address reported by the BIOS here is bogus, so non-presence
of IRQ doesn't mean the "optional" part in point 2).

Since I got no reply previously, fix this by simply unmapping the space
when IRQ is not found and memory region was mapped previously.  It would
be probably more safe to walk the resources again and unmap appropriately
depending on type.  But as we now use only ioremap for both 2 memory
resource types, it is not necessarily needed right now.

Addresses https://bugzilla.novell.com/show_bug.cgi?id=629908

Reported-by: Olaf Hering 
Signed-off-by: Jiri Slaby 
Acked-by: Clemens Ladisch 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

hpet: kill BKL, add compat_ioctl

2010-09-15T19:01:40+00:00

hpet uses the big kernel lock in its ioctl and open
functions. Replace this with a private mutex to be
sure. Since we're already touching the ioctl function,
add the compat_ioctl version as well -- all commands
except HPET_INFO are compatible and that one is easy
to add.

Signed-off-by: Arnd Bergmann 
Cc: Clemens Ladisch 
Cc: Bob Picco