A recent change in GEOM ordering (c11b701915 -
"geom: Push GEOM sysinit ordering to after devctl" changed the GEOM init
ordering to SI_ORDER_THIRD. However, the FDT slicer / GEOM flash
slice code needs the GEOM subsystem to be initialised before it
starts loading in flash slices from FDT, and will panic because
the mutex isn't initialised.
So bump this now to SI_ORDER_FOURTH, so it occurs after the GEOM
initialisation.
Differential Revision: https://reviews.freebsd.org/D49692
Reviewed by: jhibbits
The Snapdragon X1E / Lenovo T14s device tree has 47 reserved memory
regions. The reserved region parsing doesn't boundary check and will
just end up array bounds smashing, which leads to a reboot before
any console IO is written.
Differential Revision: https://reviews.freebsd.org/D49689
Reviewed by: manu, phk
gcc_sleep_clk_src does not exist, just use sleep_clk directly.
I believe this is what feeds them anyway!
This node isn't in the Linux clock driver (drivers/clk/qcom) ipq401x
clock tree, but there are sleep_clk_src nodes in the tree in
ipq50xx, ipq54xx, ipq60xx, ipq8xxxx, ipq9xxxx, msm8xxx, etc.
Differential Revision: https://reviews.freebsd.org/D49686
The device tree renamed master -> core, so rename the fields here.
Locally tested:
* IPQ4019, ASUS RT-AC58U, USB works (enough for umass!)
Differential Revision: https://reviews.freebsd.org/D49684
Reviewed by: manu
Although the driver structure is almost supportive of multiple
chipsets, there's a lot of subtle hard coded IPQ4018 assumptions
here.
This is a partial refactor of the driver in order to have a single
qcom_gcc driver that will eventually support multiple chipsets.
* rename qcom_gcc_ipq4018 -> qcom_gcc
* remove the ipq4018 specific naming from things
* create a table to drive probe/attach, with a chipset id to
use during attach
* migrate the clock register accessors to not be ipq4018 specific
* migrate the reset register accessors to not be ipq4018 specific
Note this won't compile (yet) for an arm64 kernel because there's
a hard-coded clock tree for an earlier 64 bit MSM part in
sys/arm64/qualcomm/qcom_gcc.c . That will need to be rolled into this
driver.
Differential Revision: https://reviews.freebsd.org/D49683
This change introduces new sysctl handlers that allow the user to change
RX/TX ring sizes. As before, the default ring sizes will come from the
device (usually 1024). We also get the max/min limits from the device.
In the case min values are not provided we have statically defined
constants for the min values. Additionally, if the modify ring option is
not enabled on the device, changing ring sizes via sysctl will not be
possible. When changing ring sizes, the interface turns down
momentarily while allocating/freeing resources as necessary.
Signed-off-by: Vee Agarwal <veethebee@google.com>
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D49428
This change introduces new sysctl handlers that allow the user to change
RX/TX queue counts. As before, the default queue counts will be the max
value the device can support. When chaning queue counts, the interface turns
down momentarily while allocating/freeing resources as necessary.
Signed-off-by: Vee Agarwal <veethebee@google.com>
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D49427
Every tx and rx ring has its own queue-page-list (QPL) that serves as
the bounce buffer. Previously we were allocating QPLs for all queues
before the queues themselves were allocated and later associating a QPL
with a queue. This is avoidable complexity: it is much more natural for
each queue to allocate and free its own QPL.
Signed-off-by: Vee Agarwal <veethebee@google.com>
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D49426
When a device fails to attach, or a module is unloaded, we want to be
able to unregister the xref as the device goes away. While the device_t
may still be valid, it won't be providing whatever functionality the
consumer that follows the xref wants it for and thus, we should not
keep it discoverable.
[Commit message re-worded by kevans@]
Reviewed by: ian, imp
Differential Revision: https://reviews.freebsd.org/D22945
The widest value used with code is 32 bits, other values are smaller.
Reduce this down. Update printfs.
This fixes the build on i386.
Reviewed by: bapt, emast, kevans, adrian
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49634
The new code makes use of FDT/OFW types and interfaces, and obviously
fails to build on amd64. Revert to fix.
Pointy-hat-to: mhorne
This reverts commit e69623451e.
PCIe mandates a 5 second delay between when the "Attention Button" is
pressed and when the associated device is detached; this is to allow
for the button to be pressed a second time to cancel the ejection. On
some systems this 5 second delay may not be desireable; so introduce a
hw.pci.pcie_hp_detach_timeout sysctl (which can also be set as a loader
tunable) which specifies the timeout in milliseconds (default 5000).
If set to zero, the device is detached immediately.
Reviewed by: jhb
MFC after: 2 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D49585
Found on the VisionFive v2 SBC, and similar.
Reviewed by: mhorne
Tested by: mhorne
Discussed with: sos
Differential Revision: https://reviews.freebsd.org/D45600
This is a revival of the old exynos4210 driver, with some additional
bits to configure the apple "s5l" uart (which is actually slightly
different to operate).
This hasn't been tested on anything that would hit the non-s5l path, so
banish it off to the apple/ domain until someone cares to confirm that
none of the other hardware is broken -- it may be that nobody does, but
the complexity isn't too bad: mostly the driver1 construct added to the
uart_bas that we use to avoid having a whole bunch of shims for uart
driver methods and hardcoded references to the cfg structs.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D48120
and the difference between start and entry->start values at this point.
Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Without the wait, mlx5e_destroy_rq() might free mbuf that is passed up
to the network stack on receive in mlx5e_poll_rx_cq().
Sponsored by: NVidia networking
MFC after: 1 week
This driver originates from OpenBSD and was ported to FreeBSD by Future
Crew LLC who kindly provided a source release.
iwx supports many recent Intel WiFi card and this driver should support running
these cards with legacy, HT and VHT rates. There are some issues remaining in
the port, but at this point wider testing is sought.
To avoid breaking deployed WiFi configurations iwx probes with a lower
priority than iwlwifi. This can be changed by blocking iwlwifi with
devmatch.
Reviewed by: adrian
Obtained from: Future Crew LLC
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49259
whu@ cannot reproduce the assertion failure which led to these ifdefs
being added in the first place, and since they appear wrong, i.e., the
assertions ought to apply to all platforms, let's remove them.
This reverts commits 0af5a0cd27 and
6f7b1310b6.
PR: 285681
Tested by: whu
MFC after: 2 weeks
- The BUS_DMA_KEEP_PG_OFFSET flag is needed, since
storvsc_xferbuf_prepare() assumes that only the first segment may have
a non-zero offset, and that all following segments are page-sized and
-aligned.
- storvsc_xferbuf_prepare() handles 64-bit bus addresses, so avoid
unneeded bouncing on i386.
PR: 285681
Reported by: dim
Tested by: dim, whu
MFC after: 2 weeks
This call was meant to be the default case in the first place, but
somehow missed this.
Reported by: glebius
Fixes: 4021fa32d9 ("sound: Simplify pcm/feeder_mixer.c")
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Lock around uses of devclass_*() and replace leftover
CTLFLAG_NEEDGIANTs with CTLFLAG_MPSAFE.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: imp, jhb
Differential Revision: https://reviews.freebsd.org/D46700
Reduce ifdefs, and add aliases for the unsigned formats.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D48009
Even though the OSS manual [1] advises against using AFMT_FLOAT, there
are applications that expect the sound driver to support it, and might
not work properly without it.
This patch adds AFMT_F32_LE|BE (as well as AFMT_FLOAT for OSS
compatibility) in sys/soundcard.h and implements AFMT_F32_LE|BE <->
AFMT_S32_LE|BE conversion functions. As a result, applications can
write/read floats to/from sound(4), but internally, because sound(4)
works with integers, we convert floating point samples to integer ones,
before doing any processing.
The reason for encoding/decoding IEEE754s manually, instead of using
fpu_kern(9), is that fpu_kern(9) is not supported by all architectures,
and also introduces significant overhead.
The IEEE754 encoding/decoding implementation has been written by Ariff
Abdullah [2].
[1] http://manuals.opensound.com/developer/AFMT_FLOAT.html
[2] https://people.freebsd.org/~ariff/utils/ieee754.c
PR: 157050, 184380, 264973, 280612, 281390
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D47638
Make vchanrate and vchanformat reflect the primary channel's software
buffer's rate and format respectively. Fix previous inconsistencies.
Get rid of the initializations in vchan_create() and move them to
chn_init().
Without the feeder_rate_round check in sysctl_dev_pcm_vchanrate(), we
can set the software rate to anything between feeder_rate_min and
feeder_rate_max. If we keep the check, however, the rate is limited to
whatever the driver's min/max is, which can be a problem if, for
example, the driver supports only a single rate, in which case we won't
be able to set anything other than the driver rate.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48961
There is a (very historical) call to pci_assign_interrupt for the
purpose of routing IRQs which may have been set up wrong by x86 BIOS
or firmware. On non-x86 systems, this is unnecessary; and on INTRNG
systems it results in a (synthetic) IRQ leak and ultimately a kernel
panic after many hotplug/unplug cycles.
Suggested by: jhb
Reviewed by: jhb
MFC after: 2 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D49560
Check if CTS bit is set in the mailbox message before waiting for ACK.
Otherwise ACK will never be received causing the function to timeout. Add
a note for ixgbe_write_mbx that it should be called while holding a lock.
Fixes: 6d243d2 ("net/ixgbe/base: introduce new mailbox API")
Cc: stable@dpdk.org
Signed-off-by: Norbert Ciosek <norbertx.ciosek@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Obtained from: DPDK (1f119e4)
MFC after: 1 week
This is the more typical pattern for other capability register sets,
and two of these variables weren't used.
Differential Revision: https://reviews.freebsd.org/D49267
Depend on the PCI bus driver clearing PME# after resume to remove the
need for clearing PME# from DEVICE_RESUME methods.
Use pci_has_pm and pci_enable_pme.
Reviewed by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Differential Revision: https://reviews.freebsd.org/D49251
pci_has_pm is a quick check that returns true if a PCI device supports
the power management capability.
pci_enable_pme can be used in DEVICE_SUSPEND driver methods to enable
PME# during suspend.
Reviewed by: Krzysztof Galazka <krzysztof.galazka@intel.com>x
Differential Revision: https://reviews.freebsd.org/D49250
The PCI power management specification requires that the OS clear any
pending PME# interrupt and generation of PME# interrupts during
"initial operating system load". Note that clearing a pending PME#
interrupt requires writing a 1 to the Read/Write-Clear PME bit in the
power management status register. To handle the boot time case, clear
PME# state in pci_read_cap() when scanning new PCI devices. This
should also cover hotplug devices.
In addition, clear this state on every PCI device after resume from
sleep in pci_resume_child before invoking the driver's DEVICE_RESUME
method.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D49222
Armv4, Armv5, and Armv6 support has been removed. Remove the Marvell
SoCs that used these cores.
Reviewed by: cognet, imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49497
Summary:
OPAL runs in big-endian mode, so we need to byteswap msg_len on little-endian.
MFC after: 1 week
Test Plan: ipmitool lan print
Reviewers: #powerpc
Subscribers: imp
Differential Revision: https://reviews.freebsd.org/D49530
Explicitly set the software ciphers; add support for GCMP-128.
Locally tested:
* AR5523 11abg NIC, 2/5GHz STA operation, GCMP forced
in wpa_supplicant.conf
Differential Revision: https://reviews.freebsd.org/D49370
Reviewed by: bz
I'm testing this with rtwn(4) NICs right now, so enable it here.
Locally tested:
* RTL8812AU / RTL8821AU, STA mode (with some wpa_supplicant.conf
shenanigans to force GCMP as the pairwise key to an OpenWRT AP
configured to use GCMP but without requiring MFP.)
Differential Revision: https://reviews.freebsd.org/D49190
Reviewed by: bz
The xae(9) driver expects that the "memory-region" property is always
provided in its DTS node, but this is not a case for every platform.
If the property is not provided, then no restriction on buffer location
is in place and busdma backend could be used.
Since the Xilinx AXI DMA engine driver does not support busdma(9), then
allocate some memory for buffers manually, so we don't panic.
This fixes operation on Codasip A730.
- add compat table and a string for an older IP
- name driver properly
- depend on ofw_spibus
- add missing ofw_bus_get_node() method
- connect to GENERIC (similar to other Xilinx IP)
Tested on Codasip A730.
GPIO0 needs to be flipped on to enable the amplifier.
The CS4208 looks /sort/ of like previous cirrus logic codecs,
enough for audio to work. This actually provides working audio
on my mbair 6,2 but it doesn't yet detect the jack.
That requires patches to the pin configs, which is going to
need some further work.
Differential Revision: https://reviews.freebsd.org/D49350
Reviewed by: christos
Future firmwares will report these types to the driver. These
transceivers work already but are misidentified as a different type.
MFC after: 1 month
Sponsored by: Chelsio Communications
HS200 mode requires tuning, and there is no code to perform this
tuning at present. Until there is, leave HS200 mode disabled.
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D49400
