17 Mar, 2017

1 commit

  • The value passed by the two callers of the function is unsigned anyway.

    Making the parameter unsigned fixes the following warning when building
    with clang:

    drivers/char/hpet.c:588:7: error: overflow converting case value to switch condition type (2149083139 to 18446744071563667459) [-Werror,-Wswitch]
    case HPET_INFO:
    ^
    include/uapi/linux/hpet.h:18:19: note: expanded from macro 'HPET_INFO'
    ^
    include/uapi/asm-generic/ioctl.h:77:28: note: expanded from macro '_IOR'
    ^
    include/uapi/asm-generic/ioctl.h:66:2: note: expanded from macro '_IOC'
    (((dir) << _IOC_DIRSHIFT) | \

    Signed-off-by: Matthias Kaehlcke
    Acked-by: Clemens Ladisch
    Signed-off-by: Greg Kroah-Hartman

    Matthias Kaehlcke
     

02 Mar, 2017

1 commit


25 Dec, 2016

1 commit


17 Feb, 2016

1 commit

  • Looks like the HPET spec at intel.com got moved.
    It isn't hard to find so drop the link, just mention
    the revision assumed.

    Suggested-by: Thomas Gleixner
    Signed-off-by: Michael S. Tsirkin
    Acked-by: Greg Kroah-Hartman
    Cc: Arnd Bergmann
    Cc: Clemens Ladisch
    Cc: Jonathan Corbet
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: linux-doc@vger.kernel.org
    Link: http://lkml.kernel.org/r/1455145462-3877-1-git-send-email-mst@redhat.com
    Signed-off-by: Ingo Molnar

    Michael S. Tsirkin
     

21 Sep, 2015

1 commit

  • The Kconfig currently controlling compilation of this code is:

    char/Kconfig:config HPET
    char/Kconfig: bool "HPET - High Precision Event Timer" if (X86 || IA64)

    ...meaning that it currently is not being built as a module by anyone.

    Lets remove the modular code that is essentially orphaned, so that
    when reading the driver there is no doubt it is builtin-only.

    Since module_init translates to device_initcall in the non-modular
    case, the init ordering remains unchanged with this commit.

    We don't replace module.h with init.h since the file already has that.

    Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.

    We leave some tags like MODULE_AUTHOR for documentation purposes.

    Cc: Arnd Bergmann
    Cc: Clemens Ladisch
    Signed-off-by: Paul Gortmaker
    Signed-off-by: Greg Kroah-Hartman

    Paul Gortmaker
     

26 Jan, 2015

1 commit

  • struct acpi_resource_address and struct acpi_resource_extended_address64 share substracts
    just at different offsets. To unify the parsing functions, OSPMs like Linux
    need a new ACPI_ADDRESS64_ATTRIBUTE as their substructs, so they can
    extract the shared data.

    This patch also synchronizes the structure changes to the Linux kernel.
    The usages are searched by matching the following keywords:
    1. acpi_resource_address
    2. acpi_resource_extended_address
    3. ACPI_RESOURCE_TYPE_ADDRESS
    4. ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS
    And we found and fixed the usages in the following files:
    arch/ia64/kernel/acpi-ext.c
    arch/ia64/pci/pci.c
    arch/x86/pci/acpi.c
    arch/x86/pci/mmconfig-shared.c
    drivers/xen/xen-acpi-memhotplug.c
    drivers/acpi/acpi_memhotplug.c
    drivers/acpi/pci_root.c
    drivers/acpi/resource.c
    drivers/char/hpet.c
    drivers/pnp/pnpacpi/rsparser.c
    drivers/hv/vmbus_drv.c

    Build tests are passed with defconfig/allnoconfig/allyesconfig and
    defconfig+CONFIG_ACPI=n.

    Original-by: Thomas Gleixner
    Original-by: Jiang Liu
    Signed-off-by: Lv Zheng
    Signed-off-by: Rafael J. Wysocki

    Lv Zheng
     

07 Dec, 2013

1 commit

  • Replace direct inclusions of , and
    , which are incorrect, with
    inclusions and remove some inclusions of those files that aren't
    necessary.

    First of all, , and
    should not be included directly from any files that are built for
    CONFIG_ACPI unset, because that generally leads to build warnings about
    undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set,
    includes those files and for CONFIG_ACPI unset it
    provides stub ACPI symbols to be used in that case.

    Second, there are ordering dependencies between those files that always
    have to be met. Namely, it is required that be included
    prior to so that the acpi_pci_root declarations the
    latter depends on are always there. And which provides
    basic ACPICA type declarations should always be included prior to any other
    ACPI headers in CONFIG_ACPI builds. That also is taken care of including
    as appropriate.

    Signed-off-by: Lv Zheng
    Cc: Greg Kroah-Hartman
    Cc: Matthew Garrett
    Cc: Tony Luck
    Cc: "H. Peter Anvin"
    Acked-by: Bjorn Helgaas (drivers/pci stuff)
    Acked-by: Konrad Rzeszutek Wilk (Xen stuff)
    Signed-off-by: Rafael J. Wysocki

    Lv Zheng
     

13 Nov, 2013

1 commit

  • The CONFIG_HPET_MMAP Kconfig option exposes the memory map of the HPET
    registers to userspace. The Kconfig help points out that in some cases
    this can be a security risk as some systems may erroneously configure the
    map such that additional data is exposed to userspace.

    This is a problem for distributions -- some users want the MMAP
    functionality but it comes with a significant security risk. In an effort
    to mitigate this risk, and due to the low number of users of the MMAP
    functionality, I've introduced a kernel parameter, hpet_mmap_enable, that
    is required in order to actually have the HPET MMAP exposed.

    Signed-off-by: Prarit Bhargava
    Acked-by: Matt Wilson
    Signed-off-by: Clemens Ladisch
    Cc: Randy Dunlap
    Cc: Tomas Winkler
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Prarit Bhargava
     

17 Oct, 2013

1 commit


26 Sep, 2013

1 commit

  • fixmem32 is assigned to address of res->data member
    so the address is always valid

    Actually since we are not checking for res != NULL
    static analyzing is complaining about referencing the pointer
    and consequent check for null.
    The code snippet looks confusing also for human eyes.

    Cc: Randy Dunlap
    Signed-off-by: Tomas Winkler
    Signed-off-by: Greg Kroah-Hartman

    Tomas Winkler
     

18 Jun, 2013

1 commit


20 Apr, 2013

1 commit


26 Jan, 2013

1 commit

  • The second argument of ACPI driver .remove() operation is only used
    by the ACPI processor driver and the value passed to that driver
    through it is always available from the given struct acpi_device
    object's removal_type field. For this reason, the second ACPI driver
    .remove() argument is in fact useless, so drop it.

    Signed-off-by: Rafael J. Wysocki
    Reviewed-by: Jiang Liu
    Acked-by: Toshi Kani
    Acked-by: Yinghai Lu

    Rafael J. Wysocki
     

27 Nov, 2012

1 commit

  • use ~0UL for unsigned long variable initialization, instead of -1.

    add check for hdp->hd_nirqs within 32 (HPET_MAX_TIMERS).
    the type of irqp->interrupt_count is u8.
    the git diff not display the relative lines below.
    hdp->hd_irq[hdp->hd_nirqs] = irq;
    hdp->hd_nirqs++;
    please check source code to get more information.

    Signed-off-by: Chen Gang
    Signed-off-by: Greg Kroah-Hartman

    Chen Gang
     

10 Apr, 2012

1 commit

  • A prototype for kmsg records instead of a byte-stream buffer revealed
    a couple of missing printk(KERN_CONT ...) uses. Subsequent calls produce
    one record per printk() call, while all should have ended up in a single
    record.

    Instead of:
    ACPI: (supports S0 S5)
    ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
    hpet0: at MMIO 0xfed00000, IRQs 2 , 8 , 0

    It prints:
    ACPI: (supports S0
    S5
    )
    ACPI: PCI Interrupt Link [LNKA] (IRQs
    5
    *10
    11
    )
    hpet0: at MMIO 0xfed00000, IRQs
    2
    , 8
    , 0

    Cc: Andrew Morton
    Cc: Len Brown
    Signed-off-by: Kay Sievers
    Signed-off-by: Greg Kroah-Hartman

    Kay Sievers
     

29 Mar, 2012

1 commit


23 Jul, 2011

1 commit

  • * '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

    Linus Torvalds
     

15 Jul, 2011

1 commit

  • 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

    Andy Lutomirski
     

16 Jun, 2011

1 commit

  • 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

    Nils Carlson
     

22 Feb, 2011

1 commit


18 Nov, 2010

1 commit


27 Oct, 2010

4 commits

  • 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

    Vasiliy Kulikov
     
  • 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

    Jaswinder Singh Rajput
     
  • 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

    Clemens Ladisch
     
  • 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

    Jiri Slaby
     

16 Sep, 2010

1 commit

  • 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

    Arnd Bergmann
     

17 May, 2010

1 commit

  • These are the last remaining device drivers using
    the ->ioctl file operation in the drivers directory
    (except from v4l drivers).

    [fweisbec: drop i8k pushdown as it has been done from
    procfs pushdown branch already]

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Frederic Weisbecker

    Arnd Bergmann
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

18 Mar, 2010

1 commit


19 Nov, 2009

1 commit


12 Nov, 2009

1 commit

  • Now that sys_sysctl is a wrapper around /proc/sys all of
    the binary sysctl support elsewhere in the tree is
    dead code.

    Cc: Jens Axboe
    Cc: Corey Minyard
    Cc: Greg Kroah-Hartman
    Cc: Matt Mackall
    Cc: Herbert Xu
    Cc: Neil Brown
    Cc: "James E.J. Bottomley"
    Acked-by: Clemens Ladisch for drivers/char/hpet.c
    Signed-off-by: Eric W. Biederman

    Eric W. Biederman
     

24 Sep, 2009

1 commit

  • The periodic interrupt from drivers/char/hpet.c does not work correctly,
    both when using the periodic capability of the hardware and while
    emulating the periodic interrupt (when hardware does not support periodic
    mode).

    With timers capable of periodic interrupts, the comparator field is first
    set with the period value followed by set of hidden accumulator, which has
    the side effect of overwriting the comparator value. This results in
    wrong periodicity for the interrupts. For, periodic interrupts to work,
    following steps are necessary, in that order.

    * Set config with Tn_VAL_SET_CNF bit

    * Write to hidden accumulator, the value written is the time when the
    first interrupt should be generated

    * Write compartor with period interval for subsequent interrupts
    (http://www.intel.com/hardwaredesign/hpetspec_1.pdf )

    When emulating periodic timer with timers not capable of periodic
    interrupt, driver is adding the period to counter value instead of
    comparator value, which causes slow drift when using this emulation.

    Also, driver seems to add hpetp->hp_delta both while setting up periodic
    interrupt and while emulating periodic interrupts with timers not capable
    of doing periodic interrupts. This hp_delta will result in slower than
    expected interrupt rate and should not be used while setting the interval.

    Signed-off-by: Venkatesh Pallipadi
    Signed-off-by: Nils Carlson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nils Carlson
     

28 Apr, 2009

1 commit

  • We want to use dev_to_node() later on, to be aware of the 'home node'
    of the GSI in question.

    [ Impact: cleanup, prepare the IRQ code to be more NUMA aware ]

    Signed-off-by: Yinghai Lu
    Acked-by: Len Brown
    Cc: Andrew Morton
    Cc: Suresh Siddha
    Cc: "Eric W. Biederman"
    Cc: Rusty Russell
    Cc: Len Brown
    Cc: Bjorn Helgaas
    Cc: Tony Luck
    Cc: linux-acpi@vger.kernel.org
    Cc: linux-ia64@vger.kernel.org
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Yinghai Lu
     

22 Apr, 2009

1 commit

  • Pass clocksource pointer to the read() callback for clocksources. This
    allows us to share the callback between multiple instances.

    [hugh@veritas.com: fix powerpc build of clocksource pass clocksource mods]
    [akpm@linux-foundation.org: cleanup]
    Signed-off-by: Magnus Damm
    Acked-by: John Stultz
    Cc: Thomas Gleixner
    Signed-off-by: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Magnus Damm
     

03 Apr, 2009

1 commit

  • hpet_calibrate() has a possibility of miss-calibration due to SMI. If SMI
    interrupts in the while loop of calibration, then return value will be
    big. This change calibrates until stabilizing by the return value with a
    small value.

    [akpm@linux-foundation.org: trivial style tweaks]
    Signed-off-by: Yasunori Goto
    Acked-by: Clemens Ladisch
    Acked-by: Vojtech Pavlik
    Cc: Robert Picco
    Cc: Venkatesh Pallipadi
    Cc: Ingo Molnar
    Acked-by: Paul Gortmaker
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Yasunori Goto
     

24 Nov, 2008

1 commit


02 Nov, 2008

1 commit

  • As it is, all instances of ->release() for files that have ->fasync()
    need to remember to evict file from fasync lists; forgetting that
    creates a hole and we actually have a bunch that *does* forget.

    So let's keep our lives simple - let __fput() check FASYNC in
    file->f_flags and call ->fasync() there if it's been set. And lose that
    crap in ->release() instances - leaving it there is still valid, but we
    don't have to bother anymore.

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

16 Oct, 2008

1 commit


10 Oct, 2008

1 commit

  • On x86 systems with CONFIG_HPET_TIMER enabled, when
    the HPET driver (drivers/char/hpet.c) is loaded,
    an incorrect busy message is printed when the driver
    initializes since the HPET has already been allocated
    by the core timer code. Remove the warning message.

    Signed-off-by: David John
    Acked-by: Venkatesh Pallipadi
    Signed-off-by: Ingo Molnar

    David John
     

01 Aug, 2008

1 commit

  • fix:

    On Thursday 31 July 2008, Ingo Molnar wrote:
    >   drivers/built-in.o: In function `hpet_alloc':
    >   : undefined reference to `__udivdi3'
    >   drivers/built-in.o: In function `hpet_alloc':
    >   : undefined reference to `__umoddi3'

    Signed-off-by: David Brownell
    Signed-off-by: Ingo Molnar

    David Brownell