Pretty much any other device might need to manipulate a gpio pin during its
probe or attach routines, so these devices must be available as early as
possible.
The gpio device is an interrupt controller, but I didn't choose the
INTERRUPT pass for that reason (it works fine as an interrupt controller as
long as it attaches any time before interrupts are enabled). That just
looked like the right place in the passes to ensure that it attaches before
any type of device that might need gpio pin manipulations.
Rename ACPI_IVRS_HARDWARE_NEW to ACPI_IVRS_HARDWARE_EFRSUP, since new definitions add Extended Feature Register support. Use IvrsType to distinguish three types of IVHD - 0x10(legacy), 0x11 and 0x40(with EFR). IVHD 0x40 is also called mixed type since it supports HID device entries.
Fix 2 coverity bugs reported by cem.
Reported by:jkim, cem
Approved by:grehan
Differential Revision://reviews.freebsd.org/D14501
driver requires interrupts to do transfers, and the drivers for the SPI
devices on the bus quite reasonably expect to be able to do IO while probing
and attaching.
Normally after grabbing the lock it has to be verified we got the right one
to begin with. However, if we are recursing, it must not change thus the
check can be avoided. In particular this avoids a lock read for non-recursing
case which found out the lock was changed.
While here avoid an irq trip of this happens.
Tested by: pho (previous version)
of years since the century, so strip the century out when converting to or
from bcd_clocktime format (the conversion routines will infer century by
pivoting on 70).
The code already pays the cost of reading the lock to obtain the waiters
flag. Checking whether there is more than one reader is not a problem and
avoids dirtying the line.
This also fixes a small corner case: if waiters were to show up between
reading the flag and upgrading the lock, the operation would fail even
though it should not. No correctness change here though.
If there were exactly rowner_retries/asx_retries (by default: 10) transitions
between read and write state and the waiters still did not get the lock, the
next owner -> reader transition would result in the code correctly falling
back to turnstile/sleepq where it would incorrectly think it was waiting
for a writer and decide to leave turnstile/sleepq to loop back. From this
point it would take ts/sq trips until the lock gets released.
The bug sometimes manifested itself in stalls during -j 128 package builds.
Refactor the code to fix the bug, while here remove some of the gratituous
differences between rw and sx locks.
POSIX defines no macros for these permissions.
Also remove unneeded headers from synopsis.
PR: 225905
Reviewed by: wblock
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14461
The main routine takes 8 args, 3 of which are almost the same for most uses.
This in particular pushes it above the limit of 6 arguments passable through
registers on amd64 making it impossible to tail call.
This is a prerequisite for further cleanups.
Tested by: pho
the jtag port, so that a tty is not created for it.
This is based on information in the PR and from the vendor website. When
the PR was first opened we had no facility for flagging the jtag ports. I
stumbled across the still-open PR with the idea of closing it, and noticed
that this wee update was needed.
PR: 175893
Before executing a command in a ddb script ddb prints an information
line of the form:
db:1:my-script> command
where 1 is the script's depth level, "my-script" is the scipt's name,
and "command" is the current command in the script.
db_script_exec() uses its 'scriptname' parameter to produce that string.
In the case when db_script_exec() is called from db_run_cmd() the
argument points to db_tok_string that is a global variable used for
command parsing. So, its value changes with every command executed.
This commit changes the code to use the script's name stored in
ds_scriptname to print the line.
MFC after: 2 weeks
than a pointer to Open Firmware by default. This eliminates a number of
potentially unsafe calls to firmware from the kernel and provides better
performance.
This feature is meant to be expanded until it is on by default
unconditionally and, ideally, we can then garbage-collect the
nightmare pile of hacks required to call into Open Firmware from a live
kernel.
Reviewed by: jhibbits
