History log of /freebsd-10-stable/sys/dev/acpica/acpi.c
Revision Date Author Comments
# 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.