sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

acpi: Remove unused devclass arguments to DRIVER_MODULE.

Make CPU children explicitly share parent unit numbers.

Before this device unit number match was coincidental and broke if I
disabled some CPU device(s). Aside of cosmetics, for some drivers
(may be considered broken) it caused talking to wrong CPUs.

Remove misc NULL checks after M_WAITOK allocations.

MFC after: 1 month
Sponsored by: The FreeBSD Foundation

Use DEVMETHOD_END macro defined in sys/bus.h instead of {0, 0} sentinel on device_method_t arrays

Reviewed by: cognet
Approved by: cognet

This isn't functionally identical. In some cases a hint to disable
unit 0 would in fact disable all units.

This reverts r241856

Approved by: cperciva (implicit)

Now that device disabling is generic, remove extraneous code from the
device drivers that used to provide this feature.

Reviewed by: des
Approved by: cperciva
MFC after: 1 week

Mark MALLOC_DEFINEs static that have no corresponding MALLOC_DECLAREs.

This means that their use is restricted to a single C file.

A new jail(8) with a configuration file, to replace the work currently done
by /etc/rc.d/jail.

Import ACPICA 20090521.

Chase ACPICA API changes (for kernel and boot loader).

- Import the HEAD csup code which is the basis for the cvsmode work.

Catch up with ACPI-CA 20070320 import.

Re-work Cx handling to be per-cpu and asymmetrical, fixing support on
modern dual-core systems as well.

- Parse the _CST packages for each cpu and track all the states individually,
on a per-cpu basis.

- Revert to generic FADT/P_BLK based Cx control if the _CST package
is not present on all cpus. In that case, the new driver will
still support per-cpu Cx state handling. The driver will determine the
highest Cx level that can be supported by all the cpus and configure the
available Cx state based on that.

- Fixed the case where multiple cpus in the system share the same
registers for Cx state handling. To do that, added a new flag
parameter to the acpi_PkgGas and acpi_bus_alloc_gas functions that
enable the caller to add the RF_SHAREABLE flag. This flag could also be
useful to other callers (acpi_throttle?) in the tree but this change is
not yet made.

- For Core Duo cpus, both cores seems to be taken out of C3 state when
any one of the cores need to transition out. This broke the short sleep
detection logic. It is disabled now if there is more than one cpu in
the system for now as it fixed it in my case. This quirk may need to
be re-enabled later differently.

- Added support to control cx_lowest on a per-cpu basis. There is still
a generic cx_lowest to enable changing cx_lowest for all cpus with a single
sysctl and for ease of use. Sample output for the new sysctl:

dev.cpu.0.cx_supported: C1/1 C2/1 C3/57
dev.cpu.0.cx_lowest: C3
dev.cpu.0.cx_usage: 0.00% 43.16% 56.83%
dev.cpu.1.cx_supported: C1/1 C2/1 C3/57
dev.cpu.1.cx_lowest: C3
dev.cpu.1.cx_usage: 0.00% 45.65% 54.34%
hw.acpi.cpu.cx_lowest: C3

This work was done by Stephane E. Potvin with some simple reworking by
myself. Thank you.

Submitted by: Stephane E. Potvin <sepotvin / videotron.ca>
MFC after: 2 weeks

Eliminate duplicate p-states entries

Reported and tested by: ales dot rom at kabelnet dot net
Reviewed by: njl
Approved by: njl, imp (mentor)
MFC after: 3 days

Don't flood kernel logs with "invalid _PSS package" messages.

Approved by: njl, imp (mentor)

Canonize the include of acpi.h.

Remove bus_{mem,p}io.h and related code for a micro-optimization on i386
and amd64. The optimization is a trivial on recent machines.

Reviewed by: -arch (imp, marcel, dfr)

Revert part of 1.19. We do want to set the count to 0 since otherwise
it would give false info to other parts of the driver.

Don't free the _PSS buffer until after we check to see if we have no valid
states as otherwise we will try to free the buffer twice.

Clean up resources properly if acpi_perf fails to attach. First, change
acpi_bus_alloc_gas() to delete the resource it set if alloc fails. Then,
change acpi_perf to delete the resource after releasing it if alloc fails.
This should make probe and attach both fully restartable if either fails.

Check for invalid frequencies after parsing the package. Keep a running
count of valid frequencies and use that as the final package count, don't
give up when the first invalid state is found. Also, add 0x9999 and expand
our upper check to >= 0xffff Mhz [2].

Submitted by: Bruno Ducrot, Jung-uk Kim [2]

Attach acpi_perf early. Especially when it is being used to provide info
to other devices, it needs to be attached first. (Multi-pass newbus
probes would be a better solution.)

Check for some impossible frequencies that some systems use to indicate
they don't actually support Px states.

Make a pass through all drivers checking specs for desired behavior on
SMP systems. It appears all drivers except ichss should attach to each
CPU and that settings should be performed on each CPU. Add comments about
this. Also, add a guard for p4tcc's identify method being called more than
once.

Don't bother with cpufreq_register if we're info-only.

Suggested by: Jung-uk Kim

Increase the maximum to wait for a transition from 1 to 10 ms. In some
modes, systems may take longer. If the status values don't match, try
matching just the lowest 8 bits if no bits above 8 are set in the desired
value. The IBM R32 has other bits set in the status register that are
irrelevant to the expected value.

Support disabling individual cpufreq drivers with hints, e.g.,
hint.ichss.0.disabled="1"

Add a new field to struct cf_setting for special values. These are driver-
specific values that other components may want to use. Add support to
acpi_perf(4) to export the control and status values via this field.

Introduce a new method, cpufreq_drv_type(), that returns the type of the
driver. This used to be handled by cpufreq_drv_settings() but it's
useful to get the type/flags separately from getting the settings.
(For example, you don't have to pass an array of cf_setting just to find
the driver type.)

Use this new method in our in-tree drivers to detect reliably if acpi_perf
is present and owns the hardware. This simplifies logic in drivers as well
as fixing a bug introduced in my last commit where too many drivers attached.

The correct error value for not having enough storage is E2BIG, not
ENOMEM. The manpage and ichss(4) are correct.

Add support for the CPUFREQ_FLAG_INFO_ONLY flag. Devices that report this
are not added to the list(s) of available settings. However, other drivers
can call the CPUFREQ_DRV_SETTINGS() method on those devices directly to
get info about available settings.

Update the acpi_perf(4) driver to use this flag in the presence of
"functional fixed hardware." Thus, future drivers like Powernow can
query acpi_perf for platform info but perform frequency transitions
themselves.

Attach an acpi_perf device for every processor that offers the right
methods.

Remove handling _PSS notifies from acpi_cpu and let acpi_perf handle them.

Notify the OS that we're taking over Px states in acpi_perf(4) instead of
doing it in the cpu driver. The previous code was incorrect anyway since
this value controls Px states, not throttling as the comment said. Since
we didn't support Px states before, there was no impact. Also, note that
we delay the write to SMI_CMD until after booting is complete since it
sometimes triggers a change in the frequency and we want to have all
drivers ready to detect/handle this.

Convert to the new GAS APIs to allow for detach in the future. Also, check
the PERF_CTRL register in our probe method so that we can tell earlier
that another driver should handle this device due to FFixedHW. This avoids
scaring users when attach failed when we really wanted probe to fail.

Don't print out a failure message when an attach for FFixedHW fails.
Instead, just fail to attach so another hardware-specific driver can
claim the device. Also, clean up some small memory leaks in the failure
case.

Add the ACPI Performance states driver. This driver offers two or more
settings as exported via the ACPI _PSS method. OEMs use this interface
to encapsulate chipset or processor-specific methods (e.g., SpeedStep or
Powernow) and export their settings in a standard way. On systems that
have valid ACPI Performance states and a hardware-specific driver (e.g.,
ichss), acpi_perf(4) is preferred.