28 Mar, 2009

1 commit


27 Mar, 2009

1 commit


25 Mar, 2009

1 commit

  • This patch implements uevent suppress in kobject and removes it
    from struct device, based on the following ideas:

    1,Uevent sending should be one attribute of kobject, so suppressing it
    in kobject layer is more natural than in device layer. By this way,
    we can do it for other objects embedded with kobject.

    2,It may save several bytes for each instance of struct device.(On my
    omap3(32bit ARM) based box, can save 8bytes per device object)

    This patch also introduces dev_set|get_uevent_suppress() helpers to
    set and query uevent_suppress attribute in case to help kobject
    as private part of struct device in future.

    [This version is against the latest driver-core patch set of Greg,please
    ignore the last version.]

    Signed-off-by: Ming Lei
    Signed-off-by: Greg Kroah-Hartman

    Ming Lei
     

16 Mar, 2009

5 commits


25 Feb, 2009

2 commits


24 Feb, 2009

1 commit


23 Feb, 2009

2 commits


22 Feb, 2009

4 commits


20 Feb, 2009

1 commit

  • Impact: cleanup

    There are two allocated per-cpu accessor macros with almost identical
    spelling. The original and far more popular is per_cpu_ptr (44
    files), so change over the other 4 files.

    tj: kill percpu_ptr() and update UP too

    Signed-off-by: Rusty Russell
    Cc: mingo@redhat.com
    Cc: lenb@kernel.org
    Cc: cpufreq@vger.kernel.org
    Signed-off-by: Tejun Heo

    Rusty Russell
     

15 Feb, 2009

1 commit


09 Feb, 2009

2 commits

  • to prevent wrongly overwriting fixmap that still want to use.

    ACPI used to rely on low mappings being all linearly mapped and
    grew a habit: it never really unmapped certain kinds of tables
    after use.

    This can cause problems - for example the hypothetical case
    when some spurious access still references it.

    v2: remove prev_map and prev_size in __apci_map_table
    v3: let acpi_os_unmap_memory() call early_iounmap too, so remove extral calling to
    early_acpi_os_unmap_memory
    v4: fix typo in one acpi_get_table_with_size calling

    Signed-off-by: Yinghai Lu
    Acked-by: Len Brown
    Signed-off-by: Ingo Molnar

    Yinghai Lu
     
  • On x86, __acpi_map_table uses early_ioremap() to create the mapping,
    replacing the previous mapping with a new one. Once enough of the
    kernel is up an running it switches to using normal ioremap(). At
    that point, we need to clean up the final mapping to avoid a warning
    from the early_ioremap subsystem.

    This can be removed after all the instances in the ACPI code are fixed
    that rely on early-ioremap's implicit overmapping of previously
    mapped tables.

    Signed-off-by: Jeremy Fitzhardinge
    Acked-by: Len Brown
    Signed-off-by: Ingo Molnar

    Jeremy Fitzhardinge
     

07 Feb, 2009

8 commits


06 Feb, 2009

1 commit

  • Currently, netlink_broadcast() reports errors to the caller if no
    messages at all were delivered:

    1) If, at least, one message has been delivered correctly, returns 0.
    2) Otherwise, if no messages at all were delivered due to skb_clone()
    failure, return -ENOBUFS.
    3) Otherwise, if there are no listeners, return -ESRCH.

    With this patch, the caller knows if the delivery of any of the
    messages to the listeners have failed:

    1) If it fails to deliver any message (for whatever reason), return
    -ENOBUFS.
    2) Otherwise, if all messages were delivered OK, returns 0.
    3) Otherwise, if no listeners, return -ESRCH.

    In the current ctnetlink code and in Netfilter in general, we can add
    reliable logging and connection tracking event delivery by dropping the
    packets whose events were not successfully delivered over Netlink. Of
    course, this option would be settable via /proc as this approach reduces
    performance (in terms of filtered connections per seconds by a stateful
    firewall) but providing reliable logging and event delivery (for
    conntrackd) in return.

    This patch also changes some clients of netlink_broadcast() that
    may report ENOBUFS errors via printk. This error handling is not
    of any help. Instead, the userspace daemons that are listening to
    those netlink messages should resync themselves with the kernel-side
    if they hit ENOBUFS.

    BTW, netlink_broadcast() clients include those that call
    cn_netlink_send(), nlmsg_multicast() and genlmsg_multicast() since they
    internally call netlink_broadcast() and return its error value.

    Signed-off-by: Pablo Neira Ayuso
    Signed-off-by: David S. Miller

    Pablo Neira Ayuso
     

04 Feb, 2009

3 commits

  • They were long enough set deprecated...

    Update Documentation/cpu-freq/users-guide.txt:
    The deprecated files listed there seen not to exist for some time anymore
    already.

    Signed-off-by: Thomas Renninger
    Signed-off-by: Len Brown

    Thomas Renninger
     
  • ACPICA exports acpi_os_validate_address() so the OS
    can prevent BIOS AML from accessing specified addresses.

    Start using this interface to prevent AML from accessing
    some well known IO addresses that the OS "owns".

    Signed-off-by: Len Brown

    Len Brown
     
  • on boot, print out the OSI strings the BIOS uses to query the OS.

    To see this output...

    build with CONFIG_ACPI_DEBUG

    boot with
    "acpi.debug_level=4" (ACPI_LV_INFO) (enabled by default)
    and
    "acpi.debug_level=1" (ACPI_UTILITIES) (default is 0)

    example output:

    ACPI: BIOS _OSI(Windows 2001) supported
    ACPI: BIOS _OSI(Windows 2001 SP1) supported
    ACPI: BIOS _OSI(Windows 2001 SP2) supported
    ACPI: BIOS _OSI(Windows 2006) supported
    ACPI: BIOS _OSI(Linux) not-supported
    ACPI: BIOS _OSI(FreeBSD) not-supported

    Signed-off-by: Len Brown

    Len Brown
     

03 Feb, 2009

2 commits

  • eliminate the duplicate the name of "VGA"

    http://bugzilla.kernel.org/show_bug.cgi?id=12514

    Signed-off-by: Zhao Yakui
    Signed-off-by: Len Brown

    Zhao Yakui
     
  • According to the Spec the first two elements in the _BCL package won't be

    regarded as the available brightness level. The first is the brightness when
    full power is connected to the box(It means that the AC adapter is plugged).
    The second is the brightness level when the box is on battery.
    If the first two elements are still used while finding the next brightness
    level, it will fall back to the lowest level when keeping on pressing
    hotkey. (On some boxes the brightness will be changed twice when hotkey is
    pressed once. One is in the ACPI video driver. The other is changed by sys I/F.
    In the ACPI video driver the first two elements will be used while changing
    the brightness. But the first two elements is skipped while using sys I/F.
    In such case there exists the inconsistency).
    So he first two elements had better be skipped while showing the available
    brightness or finding the next brightness level.

    http://bugzilla.kernel.org/show_bug.cgi?id=12450

    Signed-off-by: Zhao Yakui
    Signed-off-by: Len Brown

    Zhao Yakui
     

29 Jan, 2009

2 commits

  • It is true that BM_RLD needs to be set to enable
    bus master activity to wake an older chipset (eg PIIX4) from C3.

    This is contrary to the erroneous wording the ACPI 2.0, 3.0
    specifications that suggests that BM_RLD is an indicator
    rather than a control bit.

    ACPI 1.0's correct wording should be restored in ACPI 4.0:
    http://www.acpica.org/bugzilla/show_bug.cgi?id=689

    But the kernel should not have to clear BM_RLD
    when entering a non C3-type state just to set
    it again when entering a C3-type C-state.

    We should be able to set BM_RLD at boot time
    and leave it alone -- removing the overhead of
    accessing this IO register from the idle entry path.

    Signed-off-by: Len Brown

    Len Brown
     
  • PM1a_STS and PM1b_STS are twins that get OR'd together
    on reads, and all writes are repeated to both.

    The fields in PM1x_STS are single bits only,
    there are no multi-bit fields.

    So it is not necessary to lock PM1x_STS reads against
    writes because it is impossible to read an intermediate
    value of a single bit. It will either be 0 or 1,
    even if a write is in progress during the read.
    Reads are asynchronous to writes no matter if a lock
    is used or not.

    Signed-off-by: Len Brown

    Len Brown
     

18 Jan, 2009

1 commit


17 Jan, 2009

2 commits