02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

28 Jun, 2017

1 commit

  • The run_wake flag in struct acpi_device_wakeup_flags stores the
    information on whether or not the device can generate wakeup
    signals at run time, but in ACPI that really is equivalent to
    being able to generate wakeup signals at all.

    In fact, run_wake will always be set after successful executeion of
    acpi_setup_gpe_for_wake(), but if that fails, the device will not be
    able to use a wakeup GPE at all, so it won't be able to wake up the
    systems from sleep states too. Hence, run_wake actually means that
    the device is capable of triggering wakeup and so it is equivalent
    to the valid flag.

    For this reason, drop run_wake from struct acpi_device_wakeup_flags
    and make sure that the valid flag is only set if
    acpi_setup_gpe_for_wake() has been successful.

    Signed-off-by: Rafael J. Wysocki
    Reviewed-by: Mika Westerberg
    Acked-by: Bjorn Helgaas

    Rafael J. Wysocki
     

25 Dec, 2016

1 commit


15 Sep, 2015

1 commit


05 Feb, 2014

1 commit


06 Jan, 2014

1 commit

  • Include appropriate header file internal.h in proc.c because function
    acpi_sleep_proc_init() has its prototype declaration in internal.h.

    This eliminates the following warning in proc.c:
    drivers/acpi/proc.c:148:12: warning: no previous prototype for ‘acpi_sleep_proc_init’ [-Wmissing-prototypes]

    Signed-off-by: Rashika Kheria
    Reviewed-by: Josh Triplett
    Signed-off-by: Rafael J. Wysocki

    Rashika
     

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
     

12 Oct, 2013

1 commit

  • Alarm proc file provides the info and control of RTC-CMOS alarm and
    RTC CMOS driver provides wakealarm sysfs attribute for the same
    purpose. The alarm file isn't compiled into kernel when RTC CMOS
    driver is selected. The driver is default to be selected for x86
    platform. So alarm file is default not to include. This patch is
    to remove it to prepare remove /proc/acpi directory.

    Signed-off-by: Lan Tianyu
    Signed-off-by: Rafael J. Wysocki

    Lan Tianyu
     

06 Aug, 2013

1 commit

  • The list of physical devices corresponding to an ACPI device
    object is walked by acpi_system_wakeup_device_seq_show() and
    physical_device_enable_wakeup() without taking that object's
    physical_node_lock mutex. Since each of those functions may be
    run at any time as a result of a user space action, the lack of
    appropriate locking in them may lead to a kernel crash if that
    happens during device hot-add or hot-remove involving the device
    object in question.

    Fix the issue by modifying acpi_system_wakeup_device_seq_show() and
    physical_device_enable_wakeup() to use physical_node_lock as
    appropriate.

    Signed-off-by: Rafael J. Wysocki
    Cc: All

    Rafael J. Wysocki
     

10 Apr, 2013

1 commit

  • The only part of proc_dir_entry the code outside of fs/proc
    really cares about is PDE(inode)->data. Provide a helper
    for that; static inline for now, eventually will be moved
    to fs/proc, along with the knowledge of struct proc_dir_entry
    layout.

    Signed-off-by: Al Viro

    Al Viro
     

28 Jan, 2013

1 commit

  • Fix /proc/acpi/wakeup for devices without bus or parent

    This patch fixes printing the wakeup status for devices without a bus
    or parent, such as laptop lid switches and sleep buttons. These devices
    have an empty physical_node_list, because acpi_bind_one is never run
    for them.

    [rjw: White space and coding style.]
    Signed-off-by: Andreas Fleig
    Signed-off-by: Rafael J. Wysocki

    Andreas Fleig
     

23 Nov, 2012

1 commit


22 Sep, 2012

1 commit

  • A USB port's position and connectability can't be identified on some boards
    via USB hub registers. ACPI _UPC and _PLD can help to resolve this issue
    and so it is necessary to bind USB with ACPI. This patch is to allow ACPI
    binding with USB-3.0 hub.

    Current ACPI only can bind one struct-device to one ACPI device node.
    This can not work with USB-3.0 hub, because the USB-3.0 hub has two logical
    devices. Each works for USB-2.0 and USB-3.0 devices. In the Linux USB subsystem,
    those two logical hubs are treated as two seperate devices that have two struct
    devices. But in the ACPI DSDT, these two logical hubs share one ACPI device
    node. So there is a requirement to bind multi struct-devices to one ACPI
    device node. This patch is to resolve such problem.

    Following is the ACPI device nodes' description under xhci hcd.

    Device (XHC)
    Device (RHUB)
    Device (HSP1)
    Device (HSP2)
    Device (HSP3)
    Device (HSP4)
    Device (SSP1)
    Device (SSP2)
    Device (SSP3)
    Device (SSP4)

    Topology in the Linux

    device XHC
    USB-2.0 logical hub USB-3.0 logical hub
    HSP1 SSP1
    HSP2 SSP2
    HSP3 SSP3
    HSP4 SSP4

    This patch also modifies the output of /proc/acpi/wakeup. One ACPI node
    can be associated with multiple devices:

    XHC S4 *enabled pci:0000:00:14.0
    RHUB S0 disabled usb:usb1
    disabled usb:usb2

    Signed-off-by: Lan Tianyu
    Acked-by: Sarah Sharp
    Signed-off-by: Len Brown

    Lan Tianyu
     

01 Nov, 2011

1 commit


07 Jan, 2011

2 commits

  • There are ACPI devices (buttons and the laptop lid) that can wake up
    the system from sleep states and have no "physical" companion
    devices. The ACPI subsystem uses two flags, wakeup.state.enabled and
    wakeup.flags.always_enabled, for handling those devices, but they
    are not accessible through the standard device wakeup infrastructure.
    User space can only control them via the /proc/acpi/wakeup interface
    that is not really convenient (e.g. the way in which devices are
    enabled to wake up the system is not portable between different
    systems, because it requires one to know the devices' "names" used in
    the system's ACPI tables).

    To address this problem, use standard device wakeup flags instead of
    the special ACPI flags for handling those devices. In particular,
    use device_set_wakeup_capable() to mark the ACPI wakeup devices
    during initialization and use device_set_wakeup_enable() to allow
    or disallow them to wake up the system from sleep states. Rework
    the /proc/acpi/wakeup interface to take these changes into account.

    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Len Brown

    Rafael J. Wysocki
     
  • If a device is enabled to wake up the system from sleep states via
    /proc/acpi/wakeup and there are other devices associated with the
    same wakeup GPE, all of these devices are automatically enabled to
    wake up the system. This isn't correct, because the fact the GPE is
    shared need not imply that wakeup power has to be enabled for all the
    devices at the same time (i.e. it is possible that one device will
    have its wakeup power enabled and it will wake up the system from a
    sleep state if the shared wakeup GPE is enabled, while another device
    having its wakeup power disabled will not wake up the system even
    though the GPE is enabled). Rework acpi_system_write_wakeup_device()
    so that it only enables wakeup for one device at a time.

    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Len Brown

    Rafael J. Wysocki
     

15 Aug, 2010

1 commit

  • Rmove deprecated ACPI procfs I/F, including
    /proc/acpi/debug_layer
    /proc/acpi/debug_level
    /proc/acpi/info
    /proc/acpi/dsdt
    /proc/acpi/fadt
    /proc/acpi/sleep

    because the sysfs I/F is already available
    and has been working well for years.

    Signed-off-by: Zhang Rui
    Signed-off-by: Len Brown

    Zhang Rui
     

04 Feb, 2010

1 commit


28 Oct, 2009

1 commit

  • proc.c and video.c are a bit sloppy around types and style,
    confusing gcc for a new feature that'll be in 2.6.33 and will
    cause a warning on the current code.

    This patch changes

    if (foo + 1 > sizeof bar)

    into

    if (foo >= sizeof(bar))

    which is more kernel-style.

    it also changes a variable in proc.c to unsigned; it gets assigned
    a value from an unsigned type, and is then only compared for > not
    for negative, so using unsigned is just outright the right type

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Len Brown

    Arjan van de Ven
     

03 Oct, 2009

1 commit

  • The ACPI /proc write() code takes an unsigned length argument like any write()
    function, but then assigned it to a *signed* integer called "len".
    Only after this is a sanity check for len done to make it not larger than 4.

    Due to the type change a len < 0 is in principle also possible; this patch
    adds a check for this.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Len Brown

    Arjan van de Ven
     

07 Apr, 2009

1 commit


28 Mar, 2009

1 commit

  • This patch makes acpi_init() call acpi_sleep_proc_init() directly.
    Previously, acpi_sleep_proc_init() was a late_initcall (sequence 7),
    apparently to make sure that the /proc hierarchy already exists:

    2003/02/13 12:38:03-06:00 mochel
    acpi sleep: demote sleep proc file creation.

    - Make acpi_sleep_proc_init() a late_initcall(), and not called from
    acpi_sleep_init(). This guarantees that the acpi proc hierarchy is at
    least there when we create the dang file.

    This should no longer be an issue because acpi_bus_init() (called early
    in acpi_init()) creates acpi_root_dir (/proc/acpi).

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Len Brown

    Bjorn Helgaas
     

09 Jan, 2009

2 commits