arm64: Add support for Snapdragon X1E battery and charger sensors.
This is a port of a set of drivers from OpenBSD, adapted to use ACPI
instead of FDT bindings. These drivers are required to boot firmware on
the application DSP which is required to read sensors. This is an impressive
collection of work on the OpenBSD side -- big thank you to Patrick for writing
this code and his help with this porting effort.
Firmware is signed and as a result may be board specific. The qcompas(4)
driver looks for firmware files in qcompas/<subsystem> where <subsystem> is
the string returned by the _SUB method on the ADSP device node. For example,
on Lenovo ThinkPad T14s Gen 6 the subsystem ID is "233817AA".
The files "qcadsp8380.mbn" and "adsp_dtbs.elf" must be placed in
this directory to read sensor data. These files can be obtained by
downloading the appropriate OEM drivers for Windows.
When everything is online, the sensors are reported by sysmon_envsys and
the charger creates a sysmon_pswitch of type PSWITCH_TYPE_ACADAPTER. The
[19 lines not shown]
arm: ACPI: Fix EFI_MEMORY_UC memory type.
The UEFI specification says that EFI_MEMORY_UC should be treated as
Device-nGnRnE (UEFI 2.10, 2.3.6.1 AArch64 Platforms - Memory types).
Protect test/clear fs->fs_fmod with um_lock like it is already
protected in ffs_alloc.c.
When writing to disk protect moving superblock to buffer with um_lock.
Set/clear fs->fmod while mounting, updating a mount or unmounting
is safe as these operations run exclusive, either mounting creates
a new file system or the file system is suspended. Assert suspension
for update and unmount.
PR kern/58837 "ffs: Missing locking around fs_fmod/time"
emove comment "we are always called with the filesystem marked `MPBUSY'."
above some xxx_sync() operations. These operations get called without
any exclusive lock.
This comment appeared with "add quota support" on 1990-05-02.
On 1998/02/18 MNT_MPBUSY disappeared when vfs_busy() was changed from
an exclusive lock to a shared lock.
PR kern/58837 "ffs: Missing locking around fs_fmod/time"
reshuffle summitfb_setup():
- remove magic number inits that are no longer magic
- annotate the remaining inits if we know the register names
- zero the attribute plane
while there, cull excessive calls to summitfb_setup()
Fix SPLASHSCREEN_IMAGE handling
This allows a kernel compiled with options:
options SPLASHSCREEN
makeoptions SPLASHSCREEN_IMAGE="path/to/image"
to correctly display the built-in image, which was previously failing to be
initialized by init_main.c. Note that init_main.c was already checking for
makeoptions_SPLASHSCREEN_IMAGE and SPLASHSCREEN_IMAGE inconsistently in two
places, and now it doesn't anymore.
clean up aroound sti_fetchfonts(), mke sure we call wsfont_init() nefore
trying to add s font to the system
while there, allow mmap()in the entire fb aperture, no sense in restricting it
m68k/fpe: Fix FTRAPcc emulation raise the correct trap.
Currently fpu_emul_type1() returns SIGFPE only if FTRAPcc's condition is met,
so this works. But I wish there was a better way..
fputest.x(0.24.10.08) about ftrapcc passed 100%.
m68k/fpe: Reimplement and simplify test_cc().
This logic was analized by Y.Sugahara (in 2016).
Finally fputest.x(0.24.10.08) about fbcc fdbcc fscc (40960 tests) passed 100%!
m68k/fpe: Two bugfixes in test_cc().
- Don't clear the exception byte in FPSR.
According to the manual, all bits except BSUN are "not affected".
- Accumulate AIOP bit always.
XXX Need to look this again later. brcc() looks to have similar one.
m68k/fpe: Several bugfixes in FDBcc and FTRAPcc emulation.
In fpu_emul_type1(),
- If test_cc() returns >0, it's an error, that is an illegal instruction in
this case. So it should just return without doing anything.
By this fix, FTRAPcc with illegal cc now causes SIGILL correctly.
- In result, branch can only be 0 or -1 after that. It makes code simple.
By this cleanup, FDBcc with illegal cc now causes SIGILL correctly.
- FTRAPcc must advance PC regardless of whether the condition is met.
(although FTRAPcc does not work at this point by anothor problem)
m68k/fpe: Fix several FMOVEM FPctl emulation.
- Fix the write order of FMOVEM FPctl,-(An).
For example, "FMOVEM FPCR/FPSR,-(An)" instruction first decrements An by
the total size (4*2 bytes), then writes FPCR and FPSR in this order.
Therefore, it's differs from "FMOVEM FPCR,-(An); FMOVEM FPSR,-(An)" sequence.
- Support multiple immediate case like "FMOVEM #imm/#imm,FPCR/FPIAR".
- Mask writes to FPSR and FPCR registers correctly.
- Support reglist=0 case too. It's not common case but makes code easier.
