interface. Make MII drivers forget about 'struct ifnet'.
Later plan is to provide an administrative downcall from ifnet
layer into drivers, to inform them about administrative status
change. If someone thinks that processing MII events for an
administratively down interface is a big problem, then drivers
would turn MII processing off.
The following MII drivers do evil things, like strcmp() on
driver name, so they still need knowledge of ifnet and thus
include if_var.h. They all need to be fixed:
sys/dev/mii/brgphy.c
sys/dev/mii/e1000phy.c
sys/dev/mii/ip1000phy.c
sys/dev/mii/jmphy.c
sys/dev/mii/nsphy.c
sys/dev/mii/rgephy.c
sys/dev/mii/truephy.c
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
/chosen, following the list of allowed console properties in ePAPR. Also
do not require that stdin be defined and equal to stdout: stdin is
nonstandard (for ePAPR) and console in an unexpected place is after all
better than no console.
to this event, adding if_var.h to files that do need it. Also, include
all includes that now are included due to implicit pollution via if_var.h
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
When using DW UART with BUSY detection it is necessary to wait
until all serial transfers are finished before manipulating the
line control. LCR will not be affected when UART is busy.
In addition, if Divisor Latch Access Bit is being set in order to
modify UART divisors:
1. We will get BUSY interrupt if interrupts are enabled.
2. Because LCR will not be affected the THR and (even worse) IER
contents will be corrupted. This will lead to console hang.
Approved by: cognet (mentor)
This is "STA invalid". I saw it during some 4965 testing (kern/183260)
and I still have no idea what is causing it.
Obtained from: Linux drivers/net/wireless/iwlegacy
Some firmware versions seem to get very unhappy if they're sent btcoex
commands when they don't actually have bluetooth hardware in them.
So, disable sending them those commands.
Tested:
* 5100 (which has bluetooth, no problems)
* 4965 (which doesn't have bluetooth, but didn't seem to crash)
* 6200 (no bluetooth, seems to get unhappy being sent bluetooth commands.)
index lookups.
* My recent(ish) change to iwn(4) and the net80211 rate control API to
support 11n rates broke the link quality table use. So, until I or
someone else decides to fix it, let's just disable it for now.
* Teach iwn_tx_data_raw() to use the iwn_rate_to_plcp() function.
* Eliminate two uses of the net80211 rate index lookup functions - they
are only for legacy rates and they're not needed here.
This fixes some invalid looking rate control TX issues that showed up
on my 4965 but it doesn't fix the two TX hangs I've noticed. Those look
like DMA related issues.
Tested:
* 4965, STA mode
* 5100, STA mode
associates compat strings with arbitrary values that mean something to
the driver. This is handy for drivers that support several variations
of similar hardware and need to know which one matched.
Reviewed by: imp, jmg, nwhitehorn
negative diff that should improve reliability somewhat. There should be
no differences in behavior -- please report any that crop up. This has been
tested on ARM and PPC systems.
Tested by: ray
referenced by pointer, making it non-static should not have even the
negligible impact on the existing code.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
BUS_PROBE_GENERIC and not BUS_PROBE_SPECIFIC (0) so the OFW SPI bus can
attach when enabled. Export the spibus devclass_t and driver_t
declarations.
Submitted by: ray
Approved by: adrian (mentor)
buffer. While here, make the code flow somewhat nicer.
Thanks to mav@ for tracking it down.
Tested by: mav
MFC after: 3 days
Sponsored by: FreeBSD Foundation
- ofw_bus_map_intr()
Maps an (iparent, IRQ) tuple to a system-global interrupt number in some
platform dependent way. This is meant to be implemented as a replacement
for [FDT_]MAP_IRQ() that is an MI interface that knows about the bus
hierarchy.
- ofw_bus_config_intr()
Configures an interrupt (previously mapped) based on firmware sense flags.
This replaces manual interpretation of the sense field in bus drivers and
will, in a follow-up, allow that interpretation to be redirected to the PIC
drivers where it belongs. This will eventually replace the tables in
/sys/dev/fdt/fdt_ARCH.c
The PowerPC/AIM code has been converted to use these globally, with an
implementation in terms of MAP_IRQ() and powerpc_config_intr(), assuming
OpenPIC, at the bus root in nexus(4). The ofw_bus_config_intr() will shortly
be integrated into pic_if.m and bounced through nexus into the PIC tree.
FDT integration will happen significantly later due to larger testing
requirements. This patch in general also lays the groundwork for the removal
of /sys/dev/fdt/fdt_ARCH.c and machine/fdt.h.
and OF_searchencprop(). I thought about using the element size parameter
to OF_getprop_alloc() to do endian-switching automatically, but it breaks
use with structs and a *lot* of FDT code (which can hopefully be moved to
these new APIs).
MFC after: 2 weeks
by encode-int. Specifically, it takes a set of 32-bit cell values and
changes them to host byte order. Most non-string instances of OF_getprop()
should be using this function, which is a no-op on big-endian platforms.
230523, 1123614
Implement a driver for Robert Norton's PIC as an FDT interrupt
controller. Devices whose interrupt-parent property points to a beripic
device will have their interrupt allocation, activation , and setup
operations routed through the IC rather than down the traditional bus
hierarchy.
This driver largely abstracts the underlying CPU away allowing the
PIC to be implemented on CPU's other than BERI. Due to insufficient
abstractions a small amount of MIPS specific code is currently required
in fdt_mips.c and to implement counters.
MFC after: 3 days
Sponsored by: DARPA/AFRL
- Use bus reference phandles in place of FDT offsets as IRQ domain keys
- Unify the identical macio/fdt/mambo OpenPIC drivers into one
- Be more forgiving (following ePAPR) about what we need from the device
tree to identify an OpenPIC
- Correctly map all IRQs into an interrupt domain
- Set IRQ_*_CONFORM for interrupts on an unknown PIC type instead of
failing attachment for that device.
When safety requirements are met, it allows to avoid passing I/O requests
to GEOM g_up/g_down thread, executing them directly in the caller context.
That allows to avoid CPU bottlenecks in g_up/g_down threads, plus avoid
several context switches per I/O.
The defined now safety requirements are:
- caller should not hold any locks and should be reenterable;
- callee should not depend on GEOM dual-threaded concurency semantics;
- on the way down, if request is unmapped while callee doesn't support it,
the context should be sleepable;
- kernel thread stack usage should be below 50%.
To keep compatibility with GEOM classes not meeting above requirements
new provider and consumer flags added:
- G_CF_DIRECT_SEND -- consumer code meets caller requirements (request);
- G_CF_DIRECT_RECEIVE -- consumer code meets callee requirements (done);
- G_PF_DIRECT_SEND -- provider code meets caller requirements (done);
- G_PF_DIRECT_RECEIVE -- provider code meets callee requirements (request).
Capable GEOM class can set them, allowing direct dispatch in cases where
it is safe. If any of requirements are not met, request is queued to
g_up or g_down thread same as before.
Such GEOM classes were reviewed and updated to support direct dispatch:
CONCAT, DEV, DISK, GATE, MD, MIRROR, MULTIPATH, NOP, PART, RAID, STRIPE,
VFS, ZERO, ZFS::VDEV, ZFS::ZVOL, all classes based on g_slice KPI (LABEL,
MAP, FLASHMAP, etc).
To declare direct completion capability disk(9) KPI got new flag equivalent
to G_PF_DIRECT_SEND -- DISKFLAG_DIRECT_COMPLETION. da(4) and ada(4) disk
drivers got it set now thanks to earlier CAM locking work.
This change more then twice increases peak block storage performance on
systems with manu CPUs, together with earlier CAM locking changes reaching
more then 1 million IOPS (512 byte raw reads from 16 SATA SSDs on 4 HBAs to
256 user-level threads).
Sponsored by: iXsystems, Inc.
MFC after: 2 months
This shuld have been a problem since r230587. Not exactly sure why it
was not detected the last weeks with the tinderbox. I would assume
r255744 is what started to cause it.
MFC after: 1 week
the cfi(4) driver. It remained in the tree longer than would be ideal
due to the time required to bring cfi(4) to feature parity.
Sponsored by: DARPA/AFRL
MFC after: 3 days
