Commit Graph

1229 Commits

Author SHA1 Message Date
Andrew Turner
0e68afe553 Add support to read the _CLS entry if it's present. It is used by
memory-mapped devices that are normally PCIe drives. Devices can then use
the existing pci_get_class, etc. accessors to query this data.

The ivar values are different enough from the existing ACPI and ISA values
to not conflict.

Reviewed by:	jhb
Obtained from:	ABT Systems Ltd
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D8721
2016-12-16 10:40:00 +00:00
Ed Schouten
3fd335bcc7 Attach a "thermal_zone" label to the ACPI thermal zone sysctls.
In order to make Prometheus do graphing/alerting on thermal sensors in a
generic fashion, we should attach the name of the thermal zone device as
a label. That way there is only a single metric for the temperature of a
thermal zone, with its name attached as a label.

Reviewed by:	cem
Differential Revision:	https://reviews.freebsd.org/D8775
2016-12-14 13:00:27 +00:00
Andrew Turner
f9a22a068d On non-Intel platforms don't ignore the PCI root bridge mapping in
acpi_set_resource, the mappings are needed on arm64.

Obtained from:	ABT Systenms Ltd
Sponsored by:	The FreeBSD Foundation
2016-12-12 16:53:55 +00:00
John Baldwin
a1eff92bc8 Don't attach to Host-PCI bridges with a bad bus number.
If the bus number assigned to a Host-PCI bridge doesn't match the first
bus number in the associated producer range from _CRS, print a warning and
fail to attach rather than panicking due to an assertion failure.

At least one single-socket Dell machine leaves a "ghost" Host-PCI bridge
device in the ACPI namespace that seems to correspond to the I/O hub in
the second socket of a two-socket machine.  However, the BIOS doesn't
configure the settings for this "ghost" bridge correctly, nor does it have
any PCI devices behind it.

Tested by:	royger
MFC after:	2 weeks
2016-12-06 00:36:02 +00:00
Hans Petter Selasky
c6e6b4fe3b Fix for endless recursion in the ACPI GPE handler during boot.
When handling a GPE ACPI interrupt object the EcSpaceHandler()
function can be called which checks the EC_EVENT_SCI bit and then
recurse on the EcGpeQueryHandler() function. If there are multiple GPE
events pending the EC_EVENT_SCI bit will be set at the next call to
EcSpaceHandler() causing it to recurse again via the
EcGpeQueryHandler() function. This leads to a slow never ending
recursion during boot which prevents proper system startup, because
the EC_EVENT_SCI bit never gets cleared in this scenario.

The behaviour is reproducible with the ALASKA AMI in combination with
a newer Skylake based mainboard in the following way:

Enter BIOS and adjust the clock one hour forward. Save and exit the
BIOS. System fails to boot due to the above mentioned bug in
EcGpeQueryHandler() which was observed recursing multiple times.

This patch adds a simple recursion guard to the EcGpeQueryHandler()
function and also also adds logic to detect if new GPE events occurred
during the execution of EcGpeQueryHandler() and then loop on this
function instead of recursing.

Reviewed by:		jhb
MFC after:		2 weeks
2016-12-02 08:21:08 +00:00
Jung-uk Kim
493deb390b Merge ACPICA 20160930. 2016-10-04 20:27:15 +00:00
Konstantin Belousov
1680854946 Implement userspace gettimeofday(2) with HPET timecounter.
Right now, userspace (fast) gettimeofday(2) on x86 only works for
RDTSC.  For older machines, like Core2, where RDTSC is not C2/C3
invariant, and which fall to HPET hardware, this means that the call
has both the penalty of the syscall and of the uncached hw behind the
QPI or PCIe connection to the sought bridge.  Nothing can me done
against the access latency, but the syscall overhead can be removed.
System already provides mappable /dev/hpetX devices, which gives
straight access to the HPET registers page.

Add yet another algorithm to the x86 'vdso' timehands. Libc is updated
to handle both RDTSC and HPET.  For HPET, the index of the hpet device
to mmap is passed from kernel to userspace, index might be changed and
libc invalidates its mapping as needed.

Remove cpu_fill_vdso_timehands() KPI, instead require that
timecounters which can be used from userspace, to provide
tc_fill_vdso_timehands{,32}() methods.  Merge i386 and amd64
libc/<arch>/sys/__vdso_gettc.c into one source file in the new
libc/x86/sys location.  __vdso_gettc() internal interface is changed
to move timecounter algorithm detection into the MD code.

Measurements show that RDTSC even with the syscall overhead is faster
than userspace HPET access.  But still, userspace HPET is three-four
times faster than syscall HPET on several Core2 and SandyBridge
machines.

Tested by:	Howard Su <howard0su@gmail.com>
Sponsored by:	The FreeBSD Foundation
MFC after:	1 month
Differential revision:	https://reviews.freebsd.org/D7473
2016-08-17 09:52:09 +00:00
Konstantin Belousov
51c762d172 By default, allow all to read the HPET registers pages. At the same
time, by, by default disallow writes to the mmaped HPET pages.

Intent is to allow userspace to use HPET as fast (i.e. no-syscall)
timecounter for gettimeofday(2).  Unfortunately, the permission model
does not make it possible to safely unhide /dev/hpet in the jails even
if default mode is set to 0444, because untrusted jailed root may
change device permissions to writeable.

Sponsored by:	The FreeBSD Foundation
MFC after:	3 weeks
2016-08-17 09:20:04 +00:00
Jung-uk Kim
0aed566c32 Remove a tunable and always reset system clock while resuming with ACPI.
Requested by:	bde (long ago)
2016-07-13 19:16:32 +00:00
Conrad Meyer
00ee4cd78a Fix a minor leak in ACPI thermal
Introduced in r301518.

Reported by:	Coverity
CID:		1356266
Sponsored by:	EMC / Isilon Storage Division
2016-06-07 19:08:13 +00:00
John Baldwin
9f70e94e68 Defer the creation of ACPI thermal kthreads to a startup sysinit.
The SYSINIT runs at SI_SUB_KICK_SCHEDULER after the scheduler is fully
initialized and timers are working.  This fixes booting in the
EARLY_AP_STARTUP case.
2016-06-06 20:28:53 +00:00
Adrian Chadd
85cb8105ab [acpi] graphics drivers want access to acpi lid handle
the graphics drivers can benefit from access to the lid handle for querying and getting notifications

Submitted by:	kmacy
Differential Revision:	https://reviews.freebsd.org/D6643
2016-06-05 02:02:51 +00:00
Luiz Otavio O Souza
9d6672e13b Fix the deciKelvin to Celsius conversion in kernel.
After r285994, sysctl(8) was fixed to use 273.15 instead of 273.20 as 0C
reference and as result, the temperature read in sysctl(8) now exibits a
+0.1C difference.

This commit fix the kernel references to match the reference value used in
sysctl(8) after r285994.

Sponsored by:	Rubicon Communications (Netgate)
2016-05-22 13:58:32 +00:00
John Baldwin
6f33eaa5f0 Implement a proper detach method for the PCI-PCI bridge driver.
- Add a pcib_detach() function for the PCI-PCI bridge driver.  It
  tears down the NEW_PCIB and hotplug state including destroying
  resource managers, deleting child devices, and disabling hotplug
  events.
- Add a detach method to the ACPI PCI-PCI bridge driver which calls
  pcib_detach() and then frees the copy of the _PRT interrupt routing
  table.
- Add a detach method to the PCI-Cardbus bridge driver which frees
  the PCI bus resources in addition to calling cbb_detach().
- Explicitly clear any pending hotplug events during attach to ensure
  future events will generate an interrupt.
- If a the Command Completed bit is set in the slot status register
  when the command completion timeout fires, treat it as if the
  command completed and the completion interrupt was just lost rather
  than forcing a detach.
- Don't wait for a Command Completed notification if Command Completion
  interrupts are disabled.  The spec explicitly says no interrupt is
  enabled when clearing CCIE, and on my T400 no interrupt is generated
  when CCIE is changed from cleared to set, either.  In addition, the
  T400 doesn't appear to set the Command Completed bit in the cases
  where it doesn't generate an interrupt, so don't schedule the timer
  either.  (If the CC bit were always set, one could always set the timer
  and rely on the logic of treating CC set as a missed interrupt.)

Reviewed by:	imp (older version)
Differential Revision:	https://reviews.freebsd.org/D6424
2016-05-20 00:03:22 +00:00
John Baldwin
ce83de10cb Use polling spin loops for timeouts during early boot.
Some ACPI operations such as mutex acquires and event waits accept a
timeout.  The ACPI OSD layer implements these timeouts by using regular
sleep timeouts.  However, this doesn't work during early boot before
event timers are setup.  Instead, use polling combined with DELAY()
to spin.

This fixes booting on upcoming Intel systems with Kaby Lake processors.

Tested by:	"Jeffrey E Pieper" <jeffrey.e.pieper@intel.com>
Reviewed by:	jimharris
MFC after:	1 week
2016-05-16 21:33:31 +00:00
John Baldwin
fdce57a042 Add an EARLY_AP_STARTUP option to start APs earlier during boot.
Currently, Application Processors (non-boot CPUs) are started by
MD code at SI_SUB_CPU, but they are kept waiting in a "pen" until
SI_SUB_SMP at which point they are released to run kernel threads.
SI_SUB_SMP is one of the last SYSINIT levels, so APs don't enter
the scheduler and start running threads until fairly late in the
boot.

This change moves SI_SUB_SMP up to just before software interrupt
threads are created allowing the APs to start executing kernel
threads much sooner (before any devices are probed).  This allows
several initialization routines that need to perform initialization
on all CPUs to now perform that initialization in one step rather
than having to defer the AP initialization to a second SYSINIT run
at SI_SUB_SMP.  It also permits all CPUs to be available for
handling interrupts before any devices are probed.

This last feature fixes a problem on with interrupt vector exhaustion.
Specifically, in the old model all device interrupts were routed
onto the boot CPU during boot.  Later after the APs were released at
SI_SUB_SMP, interrupts were redistributed across all CPUs.

However, several drivers for multiqueue hardware allocate N interrupts
per CPU in the system.  In a system with many CPUs, just a few drivers
doing this could exhaust the available pool of interrupt vectors on
the boot CPU as each driver was allocating N * mp_ncpu vectors on the
boot CPU.  Now, drivers will allocate interrupts on their desired CPUs
during boot meaning that only N interrupts are allocated from the boot
CPU instead of N * mp_ncpu.

Some other bits of code can also be simplified as smp_started is
now true much earlier and will now always be true for these bits of
code.  This removes the need to treat the single-CPU boot environment
as a special case.

As a transition aid, the new behavior is available under a new kernel
option (EARLY_AP_STARTUP).  This will allow the option to be turned off
if need be during initial testing.  I plan to enable this on x86 by
default in a followup commit in the next few days and to have all
platforms moved over before 11.0.  Once the transition is complete,
the option will be removed along with the !EARLY_AP_STARTUP code.

These changes have only been tested on x86.  Other platform maintainers
are encouraged to port their architectures over as well.  The main
things to check for are any uses of smp_started in MD code that can be
simplified and SI_SUB_SMP SYSINITs in MD code that can be removed in
the EARLY_AP_STARTUP case (e.g. the interrupt shuffling).

PR:		kern/199321
Reviewed by:	markj, gnn, kib
Sponsored by:	Netflix
2016-05-14 18:22:52 +00:00
Edward Tomasz Napierala
084d207584 Remove misc NULL checks after M_WAITOK allocations.
MFC after:	1 month
Sponsored by:	The FreeBSD Foundation
2016-05-10 10:26:07 +00:00
John Baldwin
8d791e5af1 Add a new bus method to fetch device-specific CPU sets.
bus_get_cpus() returns a specified set of CPUs for a device.  It accepts
an enum for the second parameter that indicates the type of cpuset to
request.  Currently two valus are supported:

 - LOCAL_CPUS (on x86 this returns all the CPUs in the package closest to
   the device when DEVICE_NUMA is enabled)
 - INTR_CPUS (like LOCAL_CPUS but only returns 1 SMT thread for each core)

For systems that do not support NUMA (or if it is not enabled in the kernel
config), LOCAL_CPUS fails with EINVAL.  INTR_CPUS is mapped to 'all_cpus'
by default.  The idea is that INTR_CPUS should always return a valid set.

Device drivers which want to use per-CPU interrupts should start using
INTR_CPUS instead of simply assigning interrupts to all available CPUs.
In the future we may wish to add tunables to control the policy of
INTR_CPUS (e.g. should it be local-only or global, should it ignore
SMT threads or not).

The x86 nexus driver exposes the internal set of interrupt CPUs from the
the x86 interrupt code via INTR_CPUS.

The ACPI bus driver and PCI bridge drivers use _PXM to return a suitable
LOCAL_CPUS set when _PXM exists and DEVICE_NUMA is enabled.  They also and
the global INTR_CPUS set from the nexus driver with the per-domain set from
_PXM to generate a local INTR_CPUS set for child devices.

Compared to the r298933, this version uses 'struct _cpuset' in
<sys/bus.h> instead of 'cpuset_t' to avoid requiring <sys/param.h>
(<sys/_cpuset.h> still requires <sys/param.h> for MAXCPU even though
<sys/_bitset.h> does not after recent changes).
2016-05-09 20:50:21 +00:00
John Baldwin
82cb5c3b5b Native PCI-express HotPlug support.
PCI-express HotPlug support is implemented via bits in the slot
registers of the PCI-express capability of the downstream port along
with an interrupt that triggers when bits in the slot status register
change.

This is implemented for FreeBSD by adding HotPlug support to the
PCI-PCI bridge driver which attaches to the virtual PCI-PCI bridges
representing downstream ports on HotPlug slots. The PCI-PCI bridge
driver registers an interrupt handler to receive HotPlug events. It
also uses the slot registers to determine the current HotPlug state
and drive an internal HotPlug state machine. For simplicty of
implementation, the PCI-PCI bridge device detaches and deletes the
child PCI device when a card is removed from a slot and creates and
attaches a PCI child device when a card is inserted into the slot.

The PCI-PCI bridge driver provides a bus_child_present which claims
that child devices are present on HotPlug-capable slots only when a
card is inserted. Rather than requiring a timeout in the RC for
config accesses to not-present children, the pcib_read/write_config
methods fail all requests when a card is not present (or not yet
ready).

These changes include support for various optional HotPlug
capabilities such as a power controller, mechanical latch,
electro-mechanical interlock, indicators, and an attention button.
It also includes support for devices which require waiting for
command completion events before initiating a subsequent HotPlug
command. However, it has only been tested on ExpressCard systems
which support surprise removal and have none of these optional
capabilities.

PCI-express HotPlug support is conditional on the PCI_HP option
which is enabled by default on arm64, x86, and powerpc.

Reviewed by:	adrian, imp, vangyzen (older versions)
Relnotes:	yes
Differential Revision:	https://reviews.freebsd.org/D6136
2016-05-05 22:26:23 +00:00
Jung-uk Kim
c19e9bb3b0 Fix intmax_t to uintptr_t casting on 32-bit platforms. Found by GCC.
Submitted by:	bde
2016-05-05 18:43:31 +00:00
Pedro F. Giffuni
453130d9bf sys/dev: minor spelling fixes.
Most affect comments, very few have user-visible effects.
2016-05-03 03:41:25 +00:00
John Baldwin
8a08b7d36b Revert bus_get_cpus() for now.
I really thought I had run this through the tinderbox before committing,
but many places need <sys/types.h> -> <sys/param.h> for <sys/bus.h> now.
2016-05-03 01:17:40 +00:00
John Baldwin
bc153c692f Add a new bus method to fetch device-specific CPU sets.
bus_get_cpus() returns a specified set of CPUs for a device.  It accepts
an enum for the second parameter that indicates the type of cpuset to
request.  Currently two valus are supported:

 - LOCAL_CPUS (on x86 this returns all the CPUs in the package closest to
   the device when DEVICE_NUMA is enabled)
 - INTR_CPUS (like LOCAL_CPUS but only returns 1 SMT thread for each core)

For systems that do not support NUMA (or if it is not enabled in the kernel
config), LOCAL_CPUS fails with EINVAL.  INTR_CPUS is mapped to 'all_cpus'
by default.  The idea is that INTR_CPUS should always return a valid set.

Device drivers which want to use per-CPU interrupts should start using
INTR_CPUS instead of simply assigning interrupts to all available CPUs.
In the future we may wish to add tunables to control the policy of
INTR_CPUS (e.g. should it be local-only or global, should it ignore
SMT threads or not).

The x86 nexus driver exposes the internal set of interrupt CPUs from the
the x86 interrupt code via INTR_CPUS.

The ACPI bus driver and PCI bridge drivers use _PXM to return a suitable
LOCAL_CPUS set when _PXM exists and DEVICE_NUMA is enabled.  They also and
the global INTR_CPUS set from the nexus driver with the per-domain set from
_PXM to generate a local INTR_CPUS set for child devices.

Reviewed by:	wblock (manpage)
Differential Revision:	https://reviews.freebsd.org/D5519
2016-05-02 18:00:38 +00:00
John Baldwin
8d07a66d77 Only count CPU devices that are using the ACPI CPU driver.
Arguably we should only be doing the probe/attach to children of
these devices as well.

Tested by:	Michal Stanek <mst_semihalf.com> (arm64)
Differential Revision:	https://reviews.freebsd.org/D6133
2016-04-28 18:53:14 +00:00
John Baldwin
1b424b5655 Adjust prototypes for NUMA-related functions to match the style of the
rest of this file.
2016-04-27 21:12:05 +00:00
Jung-uk Kim
f8146b882b Merge ACPICA 20160422. 2016-04-27 19:09:21 +00:00
John Baldwin
67e7d085ae Add a pcib_attach_child() method to manage adding the child "pci" device.
This allows the PCI-PCI bridge driver to save a reference to the child
device in its softc.

Note that this required moving the "pci" device creation out of
acpi_pcib_attach().  Instead, acpi_pcib_attach() is renamed to
acpi_pcib_fetch_prt() as it's sole action now is to fetch the PCI
interrupt routing table.

Differential Revision:	https://reviews.freebsd.org/D6021
2016-04-27 16:39:05 +00:00
John Baldwin
4c26ac696c 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.

Reviewed by:	jkim
Differential Revision:	https://reviews.freebsd.org/D6040
2016-04-22 17:51:19 +00:00
John Baldwin
f8887b894c Queue the CPU-probing task after all acpi_cpu devices are attached.
Eventually with earlier AP startup this code will change to call the
startup function synchronously instead of queueing the task.  Moving
the time we queue the task should be a no-op since taskqueue threads
don't start executing tasks until much later, but this reduces the diff
with the earlier AP startup patches.

Sponsored by:	Netflix
2016-04-21 18:27:05 +00:00
Jung-uk Kim
e5f7701025 Prefer sizeof(*pointer) over sizeof(type). No funtional change. 2016-04-20 21:30:56 +00:00
Jung-uk Kim
87f0a4bf1f There is no need to use array any more. No functional change. 2016-04-20 21:26:59 +00:00
Jung-uk Kim
cad6d22280 Remove query flag from acpi_EvaluateOSC(). This function does not support
return buffer (yet).
2016-04-20 21:21:47 +00:00
John Baldwin
508c21b669 Invoke _OSC on Host-PCI bridges.
Tell the firmware that we support PCI-express config space access
and MSI.

Reviewed by:	jkim
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D6023
2016-04-20 20:58:30 +00:00
John Baldwin
5f3dd91a8f 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.

Reviewed by:	jkim
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D6022
2016-04-20 20:55:58 +00:00
John Baldwin
6cd99ae86d Add a new PCI bus interface method to alloc the ivars (dinfo) for a device.
The ACPI and OFW PCI bus drivers as well as CardBus override this to
allocate the larger ivars to hold additional info beyond the stock PCI ivars.

This removes the need to pass the size to functions like pci_add_iov_child()
and pci_read_device() simplifying IOV and bus rescanning implementations.

As a result of this and earlier changes, the ACPI PCI bus driver no longer
needs its own device_attach and pci_create_iov_child methods but can use
the methods in the stock PCI bus driver instead.

Differential Revision:	https://reviews.freebsd.org/D5891
2016-04-15 03:42:12 +00:00
John Baldwin
62d70a8174 Add more fine-grained kernel options for NUMA support.
VM_NUMA_ALLOC is used to enable use of domain-aware memory allocation in
the virtual memory system.  DEVICE_NUMA is used to enable affinity
reporting for devices such as bus_get_domain().

MAXMEMDOM must still be set to a value greater than for any NUMA support
to be effective.  Note that 'cpuset -gd' always works if MAXMEMDOM is
enabled and the system supports NUMA.

Reviewed by:	kib
Differential Revision:	https://reviews.freebsd.org/D5782
2016-04-09 13:58:04 +00:00
John Baldwin
652523175b Associate device_t objects with ACPI handles via PCI_CHILD_ADDED().
Previously, the ACPI PCI bus driver did a single pass over the devices in
the namespace that were a child of a given PCI bus to associate the
PCI bus-enumerated device_t devices with the corresponding ACPI handles.
However, this meant that handles were only established at runtime for devices
found during the initial PCI bus scan.

PCI_IOV adds devices that show up after the initial PCI bus scan, and coming
changes to add a bus rescan can also add devices after the initial scan.

This change adds a pci_child_added() callback to the ACPI PCI bus that walks
the namespace to find the ACPI handle for each device that is added.  Using
a callback means that the handle is correctly set for any device no matter
how it is added (initial scan, IOV, or a bus rescan).
2016-04-07 17:15:16 +00:00
John Baldwin
496dfa89a6 Convert pci_delete_child() to a bus_child_deleted() method.
Instead of providing a wrapper around device_delete_child() that the PCI
bus and child bus drivers must call explicitly, move the bulk of the logic
from pci_delete_child() into a bus_child_deleted() method
(pci_child_deleted()).  This allows PCI devices to be safely deleted via
device_delete_child().
- Add a bus_child_deleted method to the ACPI PCI bus which clears the
  device_t associated with the corresponding ACPI handle in addition to
  the normal PCI bus cleanup.
- Change cardbus_detach_card to call device_delete_children() and move
  CardBus-specific delete logic into a new cardbus_child_deleted() method.
- Use device_delete_child() instead of pci_delete_child() in the SRIOV code.
- Add a bus_child_deleted method to the OpenFirmware PCI bus drivers which
  frees the OpenFirmware device info for each PCI device.

Reviewed by:	imp
Tested on:	amd64 (CardBus and PCI-e hotplug)
Differential Revision:	https://reviews.freebsd.org/D5831
2016-04-06 04:10:22 +00:00
Justin Hibbits
da1b038af9 Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.
On some architectures, u_long isn't large enough for resource definitions.
Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but
type `long' is only 32-bit.  This extends rman's resources to uintmax_t.  With
this change, any resource can feasibly be placed anywhere in physical memory
(within the constraints of the driver).

Why uintmax_t and not something machine dependent, or uint64_t?  Though it's
possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on
32-bit architectures.  64-bit architectures should have plenty of RAM to absorb
the increase on resource sizes if and when this occurs, and the number of
resources on memory-constrained systems should be sufficiently small as to not
pose a drastic overhead.  That being said, uintmax_t was chosen for source
clarity.  If it's specified as uint64_t, all printf()-like calls would either
need casts to uintmax_t, or be littered with PRI*64 macros.  Casts to uintmax_t
aren't horrible, but it would also bake into the API for
resource_list_print_type() either a hidden assumption that entries get cast to
uintmax_t for printing, or these calls would need the PRI*64 macros.  Since
source code is meant to be read more often than written, I chose the clearest
path of simply using uintmax_t.

Tested on a PowerPC p5020-based board, which places all device resources in
0xfxxxxxxxx, and has 8GB RAM.
Regression tested on qemu-system-i386
Regression tested on qemu-system-mips (malta profile)

Tested PAE and devinfo on virtualbox (live CD)

Special thanks to bz for his testing on ARM.

Reviewed By: bz, jhb (previous)
Relnotes:	Yes
Sponsored by:	Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D4544
2016-03-18 01:28:41 +00:00
Justin Hibbits
e8cf8358d0 Remove default initializations for rman, a'la r296331 2016-03-04 01:25:45 +00:00
Jung-uk Kim
2f977ab449 Silence PVS-Studio warning (V595). 2016-02-23 23:09:45 +00:00
Jung-uk Kim
8444599e1e Silence PVS-Studio warning (V595). 2016-02-23 22:55:44 +00:00
Jung-uk Kim
7054df7f5b Remove brightness notify handler before reinstalling new one. 2016-02-23 22:50:45 +00:00
Jung-uk Kim
3e4f6cc6c7 Fix white spaces. 2016-02-23 22:30:45 +00:00
Jung-uk Kim
8d4a1dbf7b Fix style(9) bugs. 2016-02-23 22:22:15 +00:00
Konstantin Belousov
2fe1339ea2 Some BIOSes ACPI bytecode needs to take (sleepable) acpi mutex for
acpi_GetInteger() execution.  Intel DMAR interrupt remapping code
needs to know UID of the HPET to properly route the FSB interrupts
from the HPET, even when interrupt remapping is disabled, and the code
is executed under some non-sleepable mutexes.

Cache HPET UIDs in the device softc at the attach time and provide
lock-less method to get UID, use the method from the dmar hpet
handling code instead of calling GetInteger().

Reported and tested by:	Larry Rosenman <ler@lerctr.org>
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
2016-02-20 13:37:04 +00:00
Konstantin Belousov
94a4ee3be7 Switch /dev/hpet to use make_dev_s(9). Device needs si_drv1
initializated, do it correctly even though hpet cannot be loaded as
module.

Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
2016-02-20 13:21:59 +00:00
Justin Hibbits
7915adb560 Introduce a RMAN_IS_DEFAULT_RANGE() macro, and use it.
This simplifies checking for default resource range for bus_alloc_resource(),
and improves readability.

This is part of, and related to, the migration of rman_res_t from u_long to
uintmax_t.

Discussed with:	jhb
Suggested by:	marcel
2016-02-20 01:32:58 +00:00
Adrian Chadd
ad73b30173 document some ACPI related sysctls.
Submitted by:	Oliver Pinter <oliver.pinter@hardenedbsd.org>
Sponsored by:	HardenedBSD
Differential Revision:	https://reviews.freebsd.org/D5263
2016-02-19 05:02:17 +00:00
Jung-uk Kim
bfe2514a08 Remove a bogus bzero() call.
Found by:	PVS-Studio
2016-02-18 23:32:11 +00:00