This patch adds support for restoring backlight after resume and adds models
Macbook3,1
MacbookAir5,1
MacbookAir5,2
It also incorporates fixes for bug #175260, bug #203610 and bug #203512
so those can be closed if this patch is applied.
PR: kern/209156
PR: kern/175260
PR: kern/203610
PR: kern/203512
Submitted by: Johannes Lundberg <johannes@brilliantservice.co.jp>
Implement several small improvements to the suspend/resume Xen sequence:
- Call the power_suspend_early event before stopping all processes.
- Stop all processes. This was done implicitly previously by putting all
the CPUs in a known IPI handler.
- Warm up the timecounter.
- Re-initialize the time of day register.
Sponsored by: Citrix Systems R&D
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
The current resolution of the Xen PV clock is too high, which causes an
adjustment of 5s to be applied to it. Reduce the resolution to be the same
as the RTC plus one, so it's always selected as the best source when
available on x86.
Also don't reset the clock on resume, it's pointless and discards any
previous adjustments.
Sponsoted by: Citrix Systems R&D
Dom0 should be able to set the host time. This is implemented by first
writing to the RTC (as would be done on bare metal), and then using the
XENPF_settime64 hypercall in order to force Xen to update the wallclock
shared page of all domains.
Sponsored by: Citrix Systems R&D
This is going to be used by the Xen clock on Dom0 in order to set the RTC of
the host. The current logic in atrtc_settime is moved to atrtc_set and the
unused device_t parameter is removed from the atrtc_set function call so it
can be safely used by other callers.
Sponsored by: Citrix Systems R&D
Reviewed by: kib, jhb
Differential revision: https://reviews.freebsd.org/D6067
With the removal of the usage of the VCPU_SSHOTTMR_future flag, now
all errors from xentimer_vcpu_start_timer should be considered fatal, and
the loop is no longer needed since in case of setting the timer in the past
we will get an event interrupt right away (instead of returning ETIME).
Sponsored by: Citrix Systems R&D
MFC after : 2 weeks
On slow platforms with unreliable TSC, such as QEMU emulated machines,
it is possible for the FreeBSD kernel to request the next event in the
past. In that case, in the current implementation of
xentimer_vcpu_start_timer, we simply return -ETIME. To be precise Xen
returns -ETIME and we pass it on. As a consequence we need to loop
around to function to make sure that the timer is properly set.
Instead it is better to always ask the hypervisor for a timer event,
even if the timeout is past. To do that, remove the VCPU_SSHOTTMR_future
flag.
Submitted by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed by: royger
MFC after: 2 weeks
the monitored directory as the result of rename(2) operation. The
renames staying in the directory are not reported.
Submitted by: Vladimir Kondratyev <wulf@cicgroup.ru>
MFC after: 2 weeks
rename removing or adding subdirectory entry.
Discussed with and tested by: Vladimir Kondratyev <wulf@cicgroup.ru>
NetBSD PR: 48958 (http://gnats.netbsd.org/48958)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
* break out the operating mode and rx filter into new functions, rather
than them being hard-coded
* if we're in sniffer mode or not associated, set the BSS MAC to all zero,
rather than relying on a chip reset to do it for us
* add comments about .. how interestingly buggy the chip is.
Tested:
* AR9170 + AR9102, STA+monitor mode
Obtained from: linux carl9170 (general chip workings, constant definitions)
Switch to add_channel / add_channel_ht40 + pass channel's TX power
for the last.
Tested by: dhw
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D6141
chunk, enable UDP encapsulation for all those addresses.
This helps clients using a userland stack to support multihoming if
they are not behind a NAT.
MFC after: 1 week
The new bcache code does not know the size of the disk, and therefore may attempt to read past the end of the disk while trying to fill its read-ahead cache.
This is usually not an issue, it fails gracefully on all of my machines, but some BIOSes seem to retry the reads for up to 30 seconds each, resulting in a long stall during boot
Submitted by: Toomas Soome <tsoome@me.com>
Reviewed by: jhb, np
Differential Revision: https://reviews.freebsd.org/D6109
Avoid logging inconsistency for the /dev/mem device at all. The driver
leaves memattr intact, and the corrective action in the device pager
handles it right.
In the logged warning, name the driver we blame, and show memory
attributes values.
Reported and tested by: pho
Reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D6149
driver is (or behaves identically to) /dev/mem. Remove the D_MEM flag
from random drivers.
Note that currently the D_MEM flag does not affect any behaviour, but
this going to change in the next commit.
Noted and reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
X-Differential revision: https://reviews.freebsd.org/D6149
The Linux driver sets the rate_n_flags regardless of whether it's being
sent using firmware rate control or local rate control. This includes
the antenna configuration.
Thanks to Kyle Evans <kevans91@ksu.edu> for pointing this out to me
and doing some investigation/testing on his end.
Tested:
* Intel 7260 STA, 2G and 5G networks
64-bit MIPS, use superpage rather than physical-segment constants, or
we may improperly fail to apply suitable alignment -- yet still allow
mmap() to appear to succeed.
Reviewed by: sson
MFC after: 1 week
Sponsored by: DARPA, AFRL
implementations. Early in the boot the kernel will use an approximate,
however after the timer has been probed it will switch to a more accurate
implementation.
Reviewed by: manu
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D5762
This is currently only a code change without any functional
change. But this allows to set the remote encapsulation port
in a more detailed way, which will be provided in a follow-up
commit.
MFC after: 1 week
FDT overlays is de-facto standard for describing expansion boards like
Beaglebone capes or Raspberry Pi shields. The ides is to have basic
DTB for base board and overlays DTB for shields/capes and to construct
final DTB either using human-readable configuration or some
self-discovery mechanism. I believe this approach can also be expanded
to support dynamically loadable FPGA bitstreams on systems like
Zedboard/Zybo.
Overlaying process is simmilar to executable link process for
binaries: each DTB has "exported" symbols and "undefined" symbols, the
latter are resolved using information for the former obtained from
base DTB or one of the overlays applied earlier (more rare case).
This symbols information is not generated by standard dtc that FreeBSD
has in base system, patched[1] version required to produces
overlay-compatible blobs. So although DTB files generated by
buildkernel do not support overlays there are enough
vendor/community-provided DTB blobs ciruclating around to justify
committing this change to ubldr.
This commit introduces handler for "fdt_overlays" variable that can be
defined either as a loader env variable or U-Boot env variable.
fdt_overlays is comma-separated list of .dtbo files located in
/boot/dtb/ directory along with base .dtb. ubldr loads files and
applies them one-by-one to base .dtb and then passes result blob to
the kernel.
[1] dd6a0533e8
Differential Revision: https://reviews.freebsd.org/D3180
