#
306536 |
|
30-Sep-2016 |
jkim |
MFC: r284583, r285797, r285799, r287168, r298714, r298720, r298838, r300879
Merge ACPICA up to 20160527.
Requested by: mav
|
#
303229 |
|
23-Jul-2016 |
jhb |
MFC 298370,298372,298377,298379,298380,298484: Abstract out _OSC handling and invoke it for PCI bridges.
r298370: Add a wrapper for evaluating _OSC methods.
This wrapper does not translate errors in the first word to ACPI error status returns. Use this wrapper in the acpi_cpu(4) driver in place of the existing _OSC code. While here, fix a bug where the wrong count of words was passed when invoking _OSC.
r298372: Invoke _OSC on Host-PCI bridges.
Tell the firmware that we support PCI-express config space access and MSI.
r298377: Remove query flag from acpi_EvaluateOSC(). This function does not support return buffer (yet).
r298379: There is no need to use array any more. No functional change.
r298380: Prefer sizeof(*pointer) over sizeof(type). No funtional change.
r298484: Optionally return the output capabilities list from _OSC.
Both of the callers were expecting the input cap_set to be modified. This fixes them to request cap_set to be updated with the returned buffer.
|
#
295131 |
|
01-Feb-2016 |
jhb |
MFC 278320,278336,278830,285621: Add devctl(8): a utility for manipulating new-bus devices. Note that this version does not include the 'suspend' and 'resume' commands present in HEAD as those depend on larger changes to the suspend and resume code in the kernel.
278320: Add a new device control utility for new-bus devices called devctl. This allows the user to request administrative changes to individual devices such as attach or detaching drivers or disabling and re-enabling devices. - Add a new /dev/devctl2 character device which uses ioctls for device requests. The ioctls use a common 'struct devreq' which is somewhat similar to 'struct ifreq'. - The ioctls identify the device to operate on via a string. This string can either by the device's name, or it can be a bus-specific address. (For unattached devices, a bus address is the only way to locate a device.) Bus drivers register an eventhandler to claim unrecognized device names that the driver recognizes as a valid address. Two buses currently support addresses: ACPI recognizes any device in the ACPI namespace via its full path starting with "\" and the PCI bus driver recognizes an address specification of 'pci[<domain>:]<bus>:<slot>:<func>' (identical to the PCI selector strings supported by pciconf). - To make it easier to cut and paste, change the PnP location string in the PCI bus driver to output a full PCI selector string rather than 'slot=<slot> function=<func>'. - Add a devctl(3) interface in libdevctl which provides a wrapper around the ioctls and is the preferred interface for other userland code. - Add a devctl(8) program which is a simple wrapper around the requests supported by devctl(3). - Add a resource_unset_value() function that can be used to remove a hint from the kernel environment. This is used to clear a hint.<driver>.<unit>.disabled hint when re-enabling a boot-time disabled device.
278336: Unbreak the build (memchr is explicitly required by devctl(9) after r278320)
278830: install the man page...
285621: Fix formatting.
Approved by: re (marius)
|
#
289032 |
|
08-Oct-2015 |
cperciva |
MFC r288446: Disable suspend during shutdown.
|
#
282750 |
|
11-May-2015 |
avg |
MFC r277796: hook userland threads suspend + resume into acpi suspend code
|
#
281910 |
|
23-Apr-2015 |
jhb |
MFC 281159: Move the message complaining about failed system resource allocations under bootverbose. Every example I've seen to date has been due to an ACPI system resource device reserving a range that overlaps with system memory (which ram0 attempts to reserve) or a local or I/O APIC (which apic0 attempts to reserve). These are always harmless but look scary to users.
|
#
281075 |
|
04-Apr-2015 |
dim |
MFC r272444 (by jkim):
Merge ACPICA 20140926.
MFC r278970 (by jkim):
Merge ACPICA 20141107 and 20150204.
Approved by: jkim Relnotes: yes
|
#
279904 |
|
12-Mar-2015 |
scottl |
MFC r271889, 272799, 272800, 274976 This brings in bus_get_domain() and the related reporting via devinfo, dmesg, and sysctl.
Obtained from: adrian, jhb Sponsored by: Netflix, Inc.
|
#
273847 |
|
30-Oct-2014 |
hselasky |
MFC r273733, r273740 and r273773:
The SYSCTL data pointers can come from userspace and must not be directly accessed. Although this will work on some platforms, it can throw an exception if the pointer is invalid and then panic the kernel.
Add a missing SYSCTL_IN() of "SCTP_BASE_STATS" structure.
Sponsored by: Mellanox Technologies
|
#
269038 |
|
23-Jul-2014 |
jhb |
MFC 267883: Expand r261243 even further and ignore any I/O port resources assigned to PCI root bridges except for the one known-valid case on x86 where bridges claim the I/O port registers used for PCI config space access.
|
#
265999 |
|
13-May-2014 |
ian |
MFC r257334, r257336, r257337, r257338, r257341, r257342, r257343, r257370, r257368, r257416
Hints-only devices should return BUS_PROBE_NOWILDCARD from their probe methods.
|
#
263022 |
|
11-Mar-2014 |
jhb |
MFC 261243: Some BIOSes incorrectly use standard memory resource ranges to list the memory ranges that they decode for downstream devices rather than creating ResourceProducer range resource entries. The result is that we allocate the full range to the PCI root bridge device causing allocations in child devices to all fail.
As a workaround, ignore any standard memory resources on a PCI root bridge device. It is normal for a PCI root bridge to allocate an I/O resource for the I/O ports used for PCI config access, but I have not seen any PCI root bridges that legitimately allocate a memory resource.
|
#
282750 |
|
11-May-2015 |
avg |
MFC r277796: hook userland threads suspend + resume into acpi suspend code
|
#
281910 |
|
23-Apr-2015 |
jhb |
MFC 281159: Move the message complaining about failed system resource allocations under bootverbose. Every example I've seen to date has been due to an ACPI system resource device reserving a range that overlaps with system memory (which ram0 attempts to reserve) or a local or I/O APIC (which apic0 attempts to reserve). These are always harmless but look scary to users.
|
#
281075 |
|
04-Apr-2015 |
dim |
MFC r272444 (by jkim):
Merge ACPICA 20140926.
MFC r278970 (by jkim):
Merge ACPICA 20141107 and 20150204.
Approved by: jkim Relnotes: yes
|
#
279904 |
|
12-Mar-2015 |
scottl |
MFC r271889, 272799, 272800, 274976 This brings in bus_get_domain() and the related reporting via devinfo, dmesg, and sysctl.
Obtained from: adrian, jhb Sponsored by: Netflix, Inc.
|
#
273847 |
|
30-Oct-2014 |
hselasky |
MFC r273733, r273740 and r273773:
The SYSCTL data pointers can come from userspace and must not be directly accessed. Although this will work on some platforms, it can throw an exception if the pointer is invalid and then panic the kernel.
Add a missing SYSCTL_IN() of "SCTP_BASE_STATS" structure.
Sponsored by: Mellanox Technologies
|
#
269038 |
|
23-Jul-2014 |
jhb |
MFC 267883: Expand r261243 even further and ignore any I/O port resources assigned to PCI root bridges except for the one known-valid case on x86 where bridges claim the I/O port registers used for PCI config space access.
|
#
265999 |
|
13-May-2014 |
ian |
MFC r257334, r257336, r257337, r257338, r257341, r257342, r257343, r257370, r257368, r257416
Hints-only devices should return BUS_PROBE_NOWILDCARD from their probe methods.
|
#
263022 |
|
11-Mar-2014 |
jhb |
MFC 261243: Some BIOSes incorrectly use standard memory resource ranges to list the memory ranges that they decode for downstream devices rather than creating ResourceProducer range resource entries. The result is that we allocate the full range to the PCI root bridge device causing allocations in child devices to all fail.
As a workaround, ignore any standard memory resources on a PCI root bridge device. It is normal for a PCI root bridge to allocate an I/O resource for the I/O ports used for PCI config access, but I have not seen any PCI root bridges that legitimately allocate a memory resource.
|