Since ibcore depends on linuxkpi, there is no need to pull in the
linuxkpi dependency in iser.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Reviewed by: trasz
Differential Revision: https://reviews.freebsd.org/D32977
This make the base driver cleaner and the subclassed driver only have
related code.
Kernel config wise this is still only handled by rk805.
No functional changes intended.
Even if for now all the RTC-related register are at the same offset don't
use some hardcoded values for them but set them based on the PMIC type.
No functional changes intended.
On-board devices should be configured via the FDT and overlays.
Hints are primarily useful for external and temporarily attached devices.
Adding hints is much easier and faster than writing and compiling
an overlay.
MFC after: 2 weeks
On-board devices should be configured via the FDT and overlays.
Hints are primarily useful for external and temporarily attached devices.
Adding hints is much easier and faster than writing and compiling
an overlay.
MFC after: 2 weeks
Recent firmwares have support for autonomous FEC selection and a "force"
knob to let the driver control this behavior (or not) in a fine grained
manner. This change adds a driver knob so that all the different ways of
configuring the link FEC can be exercised. Note that this controls the
internal driver/firmware interaction for link configuration and is not
meant for general use.
MFC after: 1 week
Sponsored by: Chelsio Communications
Recent firmwares have more leeway in FEC selection and there is a need
to track the FECs requested by the driver separately from the FEC in use
on the link. The existing dev.<port>.<inst>.fec sysctl can read both but
its behavior depends on the link state and it is sometimes hard to find
out what was requested when the link is up.
Split the fec sysctl into two (requested_fec and link_fec) to get access
to both pieces of information regardless of the link state.
MFC after: 1 week
Sponsored by: Chelsio Communications
Add support for the "snps,dis_rxdet_inp3_quirk" quirk needed
at least on SolidRun's HoneyComb.
Reviewed by: manu, mw
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D32921
This allows the iFeature strings to be properly read by the snd_uaudio(4) driver,
when parsing the audio feature unit descriptors.
Submitted by: Zhichao1.Li@dell.com
MFC after: 1 week
Sponsored by: NVIDIA Networking
Previously, sorele() always required the socket lock and dropped the
lock if the released reference was not the last reference. Many
callers locked the socket lock just before calling sorele() resulting
in a wasted lock/unlock when not dropping the last reference.
Move the previous implementation of sorele() into a new
sorele_locked() function and use it instead of sorele() for various
places in uipc_socket.c that called sorele() while already holding the
socket lock.
The sorele() macro now uses refcount_release_if_not_last() try to drop
the socket reference without locking the socket. If that shortcut
fails, it locks the socket and calls sorele_locked().
Reviewed by: kib, markj
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D32741
In a VF's configuration space, "memory space enable" is hard-wired to 0,
so the existing implementation always returns false. We need to read
the SR-IOV control register from the PF device to get the value of the
MSE bit.
Fix pci_bar_enabled() to read this register instead for VFs. I don't
see any way to access the PF's config space without a backpointer in the
pci device ivars, so I added one.
This fixes a regression where bhyve(8) fails to map the MSI-X table
after commit 7fa2335347 ("bhyve: Map the MSI-X table unconditionally
for passthrough") when a VF is passed through, since with that commit we
use PCIOCBARMMAP to map the table and that ioctl always fails for VFs
without this change. As a bonus, pciconf(8) now correctly reports the
enablement of BARs for VFs.
Reported and tested by: Raúl Muñoz <raul.munoz@custos.es>
Reviewed by: rstone, jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32839
Remove unused file-local static function felix_phyforport()
which was missed in 29cf6a79ac to avoid compile time warning.
Reviewed by: Kornel Duleba (mindal semihalf.com)
Differential Revision: https://reviews.freebsd.org/D32906
Performance counters and overflow interrupts are assumed to be disabled
by default, but this is not guaranteed. Ensure we disable both during
per-cpu initialization, before enabling the PMU. Otherwise, some systems
(such as the Ampere eMAG) would experience an interrupt storm upon
loading the hwpmc module.
Reviewed by: br
MFC after: 5 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32854
Summary:
The previously used software reset routine wasn't sufficient
to reset the PHY if the bootloader hadn't left the device in
an initialized state. This was seen with the onboard igc port
on an 11th-gen Intel NUC.
The software reset isn't used in the Linux driver so all related
code has been removed.
Tested on: Netgate 6100 onboard ports, a discrete PCIe I225-LM card,
and an 11th-gen Intel NUC.
Reported by: woodsb02
Tested by: woodsb02 (NUC)
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC ("Netgate")
Reviewed by: kbowling
Differential Revision: https://reviews.freebsd.org/D32772
sysctl(8) first queries a sysctl to get a size of its value even if the
sysctl is of a fixed size, e.g. it has an integer type.
Only after that sysctl(8) queries an actual value of the sysctl.
Previosuly the driver would needlessly read a sensor in the first step.
MFC after: 1 week
On-board devices should be configured via the FDT and overlays.
Hints are primarily useful for external and temporarily attached devices.
Adding hints is much easier and faster than writing and compiling
an overlay.
MFC after: 1 week
Previously we would only search for a PHY xref in node of the miibus
parent.
That didn't work very well with switches.
Fix that by searching through "ports" subnode, checking if any of its
children have a valid PHY xref.
Since switches tend to have multiple ports we also have multiple
candidates.
Use the PHY address read from mii_attach_args to find the right one.
Obtained from: Semihalf
Sponsored by: Alstom Group
Reviewed by: mw
Differential revision: https://reviews.freebsd.org/D32690
It adds the PIC functionality on top of qoriq_gpio driver.
We need a separate module since the powerpc PIC API is completely
different than on other architectures.
Two types of intr_map_data are supported:
INTR_MAP_DATA_GPIO and INTR_MAP_DATA_FDT.
This way interrupts can be allocated using the userspace gpio
interrupt allocation method, as well as directly from simplebus.
The latter can be used by devices that have its irq routed to a GPIO pin.
Obtained from: Semihalf
Sponsored by: Alstom Group
Expose softc and other necessary things in a separate header.
This is needed for an armv8 specific driver, that will inherit from this
one. Driver mutex was converted to a spin lock, so that it can be later
used in interrupt filter context.
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential revision: https://reviews.freebsd.org/D32587
These macros are not backend-specific but reference a
backend-independent field in struct icl_conn.
Reviewed by: mav
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D32858
SDHCI controllers found in the QorIQ SoCs offer improved accuracy of
the clock frequency selection, compared to the SDHCI standard. Frequency
selection is performed using two divider registers, named prescaler and
divisor, according to the following formula:
frequency = base clock / (prescaler * divisor), where prescaler can be
bypassed (set to 1) and divisor permitted to take odd values.
Rather than depend on clock division precalculated by sdhci core, make
use of this property of the divider registers and achieve frequencies
closer to the ones requested.
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential revision: https://reviews.freebsd.org/D32706
When performing software reset, this controller does not clear all the
required hw registers. In particular, tuning block is left in enabled
state, inhibiting operation of some eMMC cards. The existing solution
was to disable the ability to call SDHCI_RESET_ALL.
As this issue is now better understood, enable the SDHCI_RESET_ALL flag,
provide a custom reset devmethod and clear selected registers by hand.
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential revision: https://reviews.freebsd.org/D32705
Some sdhci controllers require custom software reset logic. Accommodate
this need by introducing a new SDHCI_RESET devmethod. Move the existing
reset logic into sdhci_generic_reset and use it as a default for the
aforementioned method.
Obtained from: Semihalf
Sponsored by: Alstom Group
Differeential revision: https://reviews.freebsd.org/D32704
This is the MVP required to initialise and consume random data from
the QCA PRNG hardware found on the IPQ401x.
Reviewed by: andrew, manu, imp
Differential Revision: https://reviews.freebsd.org/D32723
I made a mistaking in merging the final commits for the devctl changes. This
adds the 'hushed' variable and has the correct dates for the manuals.
Pointy hat to: imp
386BSD provided a MD function sysbeep. This took two arguments (pitch
and period). Pitch was jammed into the PIT's divisor directly (which
means the argument was expected to sound a tone at '1193182 / pitch'
Hz). FreeBSD inherited this interface.
In commit e465985885 (svn 177642, Mar 26 2008), phk changed this
function to take a tone to sound in hz. He converted all in-tree
instances of 1193182 / hz to just hz (and kept the few misguided folks
that passed hz directly unchanged -- this was part of what motivated the
change). He converted the places where we pre-computed the 8254 divisor
from being pitch to 1193182 / pitch (since that converts the divisor to
the frequency and the interfaces that were exposed to userland exposed
it in these units in places, continuing the tradition inherited from SCO
System V/386 Unix in spots).
In 2009, Ed Shouten was contracted by the FreeBSD Foundation to write /
finish newcons. This work was done in perforce and was imported into
subversion in user/ed/newcons in revision 199072
(https://svnweb.freebsd.org/base?view=revision&revision=199072) which
was later imported into FreeBSD by ray@ (Aleksandr Rybalko).
From that earliest import into svn import to this date, we ring the bell
with:
sysbeep(1193182 / VT_BELLPITCH, VT_BELLDURATION);
where VT_BELLPITCH was defined to be 800. This results in a bell
frequency of 1491Hz, more or less today. This is similar to the
frequency that syscons and pcvt used (1493Hz and 1500Hz respectively).
This in turn was inherited from 386BSD, it seems, which used the hard
coded value 0x31b which is 795 -> 1500Hz.
This '800' was intended to be the bell tone (eg 800Hz) and this
interface was one that wasn't converted. The most common terminal prior
to the rise of PCs was the VT100, which had an approximately 800Hz
bell. Ed Shouten has confirmed that the original intent was 800Hz and
changing this was overlooked after the change to -current was made.
This restors that original intent and makes the bell less obnoxious in
the process.
Reviewed by: des, adrian
Differential Revision: https://reviews.freebsd.org/D32594
Sponsored by: Netflix
Generate VT events when the bell beeps. When coupled with disabling the
bell,this allows custom bells to be rung when we'd otherwise beep.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D32656
Add the glue needed to listen to TP_SETBELLPD which teken uses to
inform its client drivers about the results of parsing
\e[=<pitch>;<duration>B. It converts these to a Hz value for the
tone/pitch of the bell and a duration in ms. There's some loss of
precision because <pitch> in the escape seuquence is defined to be
(1193182 / pitch) Hz and <duration> is in 10ms units. Also note that
kbdcontrol also parses 'off' but then doesn't send the proper escape
sequence, leading me to wonder if that's another bug since teken
appears to parse that sequence properly and I've added code here to
treat that as the same as quiet or disabled.
In general, Hz from 100 to 2000 is good. Outside that range is possible,
but even at 100Hz the square wave is starting to sound bad and above
2000Hz the speaker may not respond.
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D32620
Change the 'period' argument to 'duration' and change its type to
sbintime_t so we can more easily express different durations.
Reviewed by: tsoome, glebius
Differential Revision: https://reviews.freebsd.org/D32619
On recent OpenBMC firmware, the onboard ASMEDIA video card framebuffer
address was removed from device tree for security purposes (value is set
to zero to avoid leaking the address).
This patch works around the problem by taking framebuffer base address
from the "ranges" property of a parent node.
Reviewed by: luporl, jhibbits (on IRC)
MFC after: 2 weeks
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D30626
Only build on RISC-V for now, since we're not aware of any other cores
with this IP supported by FreeBSD.
Reviewed by: jrtc27, philip
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D32737
The pic_* interface was used.
Only edge interrupts are supported by this controller.
Driver mutex had to be converted to a spin lock so that it can
be used in the interrupt filter context.
Two types of intr_map_data are supported - INTR_MAP_DATA_GPIO and
INTR_MAP_DATA_FDT. This way interrupts can be allocated using the
userspace gpio interrupt allocation method, as well as directly from
simplebus. The latter can be used by devices that have its irq routed
to a GPIO pin.
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential revision: https://reviews.freebsd.org/D32587
Driver polls status of all PHYs connected to the switch in a
fixed interval.
Add a sysctl that allows to control frequency of that.
The value is expressed in ticks and defaults to "hz", or 1 second.
Obtained from: Semihalf
Sponsored by: Alstom Group
It was previously used by felix(4) for PHY communication.
Since that is not the case anymore this driver is now left unused.
Obtained from: Semihalf
Sponsored by: Alstom Group
Previously we would use an external MDIO device found on the PCI bus.
Switch to using MDIO mapped in a separate BAR of the switch device.
It is much easier this way since we don't have to depend on another
driver anymore.
Obtained from: Semihalf
Sponsored by: Alstom Group
Currently, to support 64-byte contexts, xhci_ctx_[gs]et_le(32|64) take a
pointer to the field within a 32-byte context and, if 64-byte contexts
are in use, compute where the 64-byte context field is and use that
instead by deriving a pointer from the 32-byte field pointer. This is
done by exploiting a combination of 64-byte contexts being the same
layout as their 32-byte counterparts, just with 32 bytes of padding at
the end, and that all individual contexts are either in a device
context or an input context which itself is page-aligned. By masking out
the low 4 bits (which is the offset of the field within the 32-byte
contxt) of the offset within the page, the offset of the invididual
context within the containing device/input context can be determined,
which is itself 32 times the number of preceding contexts. Thus, adding
this value to the pointer again gets 64 times the number of preceding
contexts plus the field offset, which gives the offset of the 64-byte
context plus the field offset, which is the address of the field in the
64-byte context.
However, this involves a fair amount of lying to the compiler when
constructing these intermediate pointers, and is rather difficult to
reason about. In particular, this is problematic for CHERI, where we
compile the kernel with subobject bounds enabled; that is, unless
annotated to opt out (e.g. for C struct inheritance reasons where you
need to be able to downcast, or containerof idioms), a pointer to a
member of a struct is a capability whose bounds only cover that field,
and any attempt to dereference outside those bounds will fault,
protecting against intra-object buffer overflows. Thus the pointer given
to xhci_ctx_[gs]et_le(32|64) is a capability whose bounds only cover the
field in the 32-byte context, and computing the pointer to the 64-byte
context field takes the address out of bounds, resulting in a fault when
later dereferenced.
This can be cleaned up by using a different abstraction. Instead of
doing the 32-byte to 64-byte conversion on access to the field, we can
do the conversion when getting a pointer to the context itself, and
define proper 64-byte versions of contexts in order to let the compiler
do all the necessary arithmetic rather than do it manually ourselves.
This provides a cleaner implementation, works for CHERI and may even be
slightly more performant as it avoids the need to mess with masking
pointers (which cannot in the general case be optimised by compilers to
be reused across accesses to different fields within the same context,
since it does not know that the contexts are over-aligned compared with
the C ABI requirements).
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D32554
This brings it inline with what's in openbsd. I tested it locally
with 2G and 5G association; it seems to work.
Tested: Intel 7260 AC, hw 0x140, STA mode, 2G/5G
Differential Revision: https://reviews.freebsd.org/D32627
Subscribers: imp
Obtainde from: OpenBSD
Summary:
This updates the if_iwmreg.h definitions to;
OpenBSD: if_iwmreg.h,v 1.65 2021/10/11 09:03:22 stsp Exp
A few things haven't been fully converted, namely:
* I left a couple things as enums for now just to reduce the
other diffs needed; but they're the same values
* The IWM_SCD_QUEUE_* macros have different offsets which I
didn't update in case they broke things / changed based on later
firmware. But they also may be real bugfixes which are needed
for later chips. It'll need more testing before flipping this on.
The c file updates are:
* Use the newer names for things if the name changed but the semantics
didn't
* Explicitly use the earlier firmware structs which maintain compat
with the current firmware and code. The newer ones are in here and
they'll get converted when more openbsd code is merged into this tree.
* Use the older iwm rate table for now, which has entries for legacy
rates, HT and VHT. Our code works with that right now, updating it
to openbsd's err, "different" version can be done at a later date
when HT/VHT support is added.
Notably, a bunch of definitions were deleted that weren't used.
They're not used either in the openbsd/dfbsd drivers so I think it's
safe to delete them in the long run.
Test Plan: 7260 hw 0x140
Subscribers: imp
Differential Revision: https://reviews.freebsd.org/D32627
Reviewed by: md5
Obtained From: OpenBSD
According to 11.4.8 in RFC 7143, ExpDataSN MUST be 0 if the response
code is not Command Completed, but we were requiring it to always be
the count of DataIn PDUs regardless of the response code.
In addition, at least one target (OCI Oracle iSCSI block device)
returns an ExpDataSN of 0 when returning a valid completion with an
error status (Check Condition) in response to a SCSI Inquiry. As a
workaround for this target, only warn without resetting the connection
for a 0 ExpDataSN for responses with a non-zero error status.
PR: 259152
Reported by: dch
Reviewed by: dch, mav, emaste
Fixes: 4f0f5bf995 iscsi: Validate DataSN values in Data-In PDUs in the initiator.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D32650
The new iSCSI initiator iscsi(4) was introduced with FreeBSD 10.0, and
the old intiator was marked obsolete shortly thereafter (in commit
d32789d95c, MFC'd to stable/10 in ba54910169c4). Remove it now.
Reviewed by: jhb, mav
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32673
-Each CQ start task queue to poll when completion happens.
This means every rx and tx queue has its own cleanup task
thread to poll the completion.
- Arm EQ everytime no matter it is mana or hwc. CQ arming
depends on the budget.
- Fix a warning in mana_poll_tx_cq() when cqe_read is 0.
- Move cqe_poll from EQ to CQ struct.
- Support EQ sharing up to 8 vPorts.
- Ease linkdown message from mana_info to mana_dbg.
Tested by: whu
MFC after: 2 weeks
Sponsored by: Microsoft
netdev_priv() is a LinuxKPI function which was used with the old ifnet
linux/netdevice.h implementation which was not adaptable to modern
Linux drviers unless rewriting them for ifnet in first place which
defeats the purpose.
Rename the netdev_priv() calls in mlx4 to mlx4_netdev_priv()
returning the ifnet softc to avoid conflicting symbol names
with different implementations in the future.
MFC after: 3 days
Reviewed by: hselasky, kib
Differential Revision: https://reviews.freebsd.org/D32640
Previously the MSR-based timecounter was registered during
SI_SUB_HYPERVISOR, i.e., very early during boot, and before SI_SUB_LOCK.
After commit 621fd9dcb2 this triggers a panic since the timecounter
list lock is not yet initialized.
The hyperv timecounter does not need to be registered so early, so defer
that to SI_SUB_DRIVERS, at the same time the hyperv TSC timecounter is
registered.
Reported by: whu
Approved by: whu
Fixes: 621fd9dcb2 ("timecounter: Lock the timecounter list")
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
When EVDEV_SUPPORT was introduced, the USB transfers may be running
after the main FIFO is closed. In connection to this a race may appear
which can lead to use-after-free scenarios. Fix this for all FIFO
consumers by initializing and resetting the FIFO queues under the
lock used by the client. Then the client driver will see an empty
queue in all cases a race may appear.
Found by: pho@
MFC after: 1 week
Sponsored by: NVIDIA Networking
It seems that clang IAS erronously adds repz prefix which should not be
there. Cpu would try to store around %ecx bytes of random, while we
only expect a word.
PR: 259218
Reported and tested by: Dennis Clarke <dclarke@blastwave.org>
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
The last two drivers that required sppp are cp(4) and ce(4).
These devices are still produced and can be purchased
at Cronyx <http://cronyx.ru/hardware/wan.html>.
Since Roman Kurakin <rik@FreeBSD.org> has quit them, they no
longer support FreeBSD officially. Later they have dropped
support for Linux drivers to. As of mid-2020 they don't even
have a developer to maintain their Windows driver. However,
their support verbally told me that they could provide aid to
a FreeBSD developer with documentaion in case if there appears
a new customer for their devices.
These drivers have a feature to not use sppp(4) and create an
interface, but instead expose the device as netgraph(4) node.
Then, you can attach ng_ppp(4) with help of ports/net/mpd5 on
top of the node and get your synchronous PPP. Alternatively
you can attach ng_frame_relay(4) or ng_cisco(4) for HDLC.
Actually, last time I used cp(4) back in 2004, using netgraph(4)
instead of sppp(4) was already the right way to do.
Thus, remove the sppp(4) related part of the drivers and enable
by default the negraph(4) part. Further maintenance of these
drivers in the tree shouldn't be a big deal.
While doing that, remove some cruft and enable cp(4) compilation
on amd64. The ce(4) for some unknown reason marks its internal
DDK functions with __attribute__ fastcall, which most likely is
safe to remove, but without hardware I'm not going to do that, so
ce(4) remains i386-only.
Reviewed by: emaste, imp, donner
Differential Revision: https://reviews.freebsd.org/D32590
See also: https://reviews.freebsd.org/D23928
Fix clearing of bits in RCTL for the non-bpf/non-allmulti case.
Update RCTL after modifying the multicast filter registers as per
the Linux driver.
This fixes LACP on igc interfaces, where incoming LACP multicasti
control packets were being dropped.
Reviewed by: kbowling
Obtained from: Rubicon Communications, LLC ("Netgate")
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D32574
While IEEE80211_R_BAND was defined, there was no place to store the
band. Add a field for that, adjust ieee80211_lookup_channel_rxstatus()
to require it, and update drivers passing "R_{FREQ|IEEE}" in already to
provide the band as well. For the moment keep the fall-back code
requiring all three fields.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D30662
For some of them, used only when KTR or KMSAN are configured, apply
__unused attribute directly.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Devices in sys/dev should be architecture-independent and NOT #include
intr_machdep.h.
Reviewed by: mhorne royger
Differential Revision: https://reviews.freebsd.org/D29959
Remove page zeroing code from consumers and stop specifying
VM_ALLOC_NOOBJ. In a few places, also convert an allocation loop to
simply use VM_ALLOC_WAITOK.
Similarly, convert vm_page_alloc_domain() callers.
Note that callers are now responsible for assigning the pindex.
Reviewed by: alc, hselasky, kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31986
Bell is either useless if you're working on remote servers or really annoying
when you're working with a local machine that have a loud buzzer.
Switch the default to have it disable.
Reviewed by: imp, pstef, tsoome
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D32543
The condition added in commit 5bdb8b273a excludes plain SHA
transforms, so for such sessions crypto operations would return
incorrect results.
Fixes: 5bdb8b273a ("safexcel: Maintain per-session context records")
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Linux KPIs like pci_resource_start/len assume that BARs have been
allocated, but FreeBSD lazily allocates BARs if it cannot allocate the
firmware-allocated BARs. Thus using the Linux KPIs must force allocation
of the BARs rather than returning 0 for the start and length, which can
crash drm-kmod drivers that assume the BARs are valid. This is needed
for the AMDGPU driver to be able to attach on SiFive's HiFive Unmatched.
Reviewed by: hselasky, jhb, mav
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32447
Previously the body of ktls_tick was a nop when NIC TLS was disabled,
but the callout was still scheduled consuming power on otherwise-idle
systems with Chelsio T6 adapters. Now the callout only runs while NIC
TLS is enabled on at least one interface of an adapter.
Reported by: mav
Reviewed by: np, mav
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D32491
Reduce traffic to doorbell register when processing multiple completion
events at once. Only write it at the end of the loop after we've
processed everything (assuming we found at least one completion,
even if that completion wasn't valid).
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D32470
No functional change intended, but noticed that we could add const here
while adding linuxkpi support for virtio.
Reviewed By: bryanv, imp
Differential Revision: https://reviews.freebsd.org/D32370
Summary:
An error mapping PCI resources results in a panic due to unallocated
resources being freed up. This change puts the appropriate checks in
place to prevent the panic.
PR: 252445
Reported by: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>
Tested by: marcus
MFC after: 1 week
Sponsored by: VMware
Test Plan:
Along with user testing, also simulated error by inserting a ENXIO
return in vmci_map_bars().
Reviewed by: marcus
Subscribers: imp
Differential Revision: https://reviews.freebsd.org/D32016
Change the probe return value from BUS_PROBE_DEFAULT to BUS_PROBE_GENERIC
given this is the "generic" attach method. This allows individual
drivers using XHCI generic but needing their own intialisation to
gain priority for attaching over the generic implementation.
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D32257
We should reserve two descriptors (not MMC_SECTORS) for potentially
unaligned (so bounced) buffer fragments, one for the starting fragment
and one for the ending fragment.
Submitted by: kjopek@gmail.com
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D30387
This is useful for diagnosing problems. In particular, the errata
sheets identify the EEPROM version for many fixes.
Reviewed by: gallatin
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32333
Otherwise results in KASSERT with debug kernels because we rely on the
iflib CTX lock to implement the software serialization to the NVM model
Reviewed by: gallatin
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32333
The tag length is included as one of the values in the flags byte of
block 0 passed to CBC_MAC, so merely copying the first N bytes is
insufficient.
To avoid adding more sideband data to the CBC MAC software context,
pull the generation of block 0, the AAD length, and AAD padding out of
cbc_mac.c and into cryptosoft.c. This matches how GCM/GMAC are
handled where the length block is constructed in cryptosoft.c and
passed as an input to the Update callback. As a result, the CBC MAC
Update() routine is now much simpler and simply performs the
XOR-and-encrypt step on each input block.
While here, avoid a copy to the staging block in the Update routine
when one or more full blocks are passed as input to the Update
callback.
Reviewed by: sef
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32120
Rather than copying crp_iv to a local array on the stack that is then
passed to xform reinit routines, pass crp_iv directly and remove the
local copy.
Reviewed by: markj
Sponsored by: Chelsio Communications, The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32106
Add a 'len' argument to the reinit hook in 'struct enc_xform' to
permit support for AEAD ciphers such as AES-CCM and Chacha20-Poly1305
which support different nonce lengths.
Reviewed by: markj
Sponsored by: Chelsio Communications, The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32105
While here, use crypto_read_iv() in a few more places in ccr(4) that I
missed previously.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D32104
Drop arguments of function prototypes since the file is mixed between
listing arg names and not.
No functional changes
Reviewed by: markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D32329
In some contexts it is illegal to wait for memory allocation, causing
kernel panic. By default sbuf_new passes M_WAITOK to malloc,
which caused crashes when sdhci_dumpcaps or sdhci_dumpregs was callend in
non sutiable context.
Add SBUF_NOWAIT flag to sbuf_new to fix this.
Obtained from: Semihalf
Differential revision: https://reviews.freebsd.org/D32075
This is the same underlying problem as 2624598064, just for bus ranges
rather than windows. SiFive's HiFive Unmatched has the following
topology:
Root Port <---> Bridge <---> Bridge <-+-> Bridge <---> (Unused)
(pcib0) (pcib1) (pcib2) | (pcib3)
+-> Bridge <---> xHCI
| (pcib4)
+-> Bridge <---> M.2 E-key
| (pcib5)
+-> Bridge <---> M.2 M-key
| (pcib6)
+-> Bridge <---> x16 slot
(pcib7)
If a device is plugged into the x16 slot that itself has a bridge, such
as many graphics cards, we currently fail to allocate a bus number for
its child bus (and so pcib_attach_child skips adding a child bus for
further enumeration) as, when the new child bridge attaches, it attempts
to allocate a bus number from its parent (pcib7) which in turn attempts
to grow its own bus range by calling bus_adjust_resource on its own
parent (pcib2) whose bus rman cannot accommodate the request and needs
to itself be extended by calling its own parent (pcib1). Note that
pcib3-7 do not face the same issue when they attach since pcib1 ends up
managing bus numbers 1-255 from the beginning and so never needs to grow
its own range.
Reviewed by: jhb, mav
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32011
We only use nvme_completion_poll in the initialization path. The
commands they queue and wait for finish quickly as they involve no I/O
to the drive's media. These command take about 20-200 microsecnds
each. Set the wait time to 1us and then increase it by 1.5 each
successive iteration (max 1ms). This reduces initialization time by
80ms in cpervica's tests.
Use this same technique waiting for RDY state transitions. This saves
another 20ms. In total we're down from ~330ms to ~2ms.
Tested by: cperciva
Sponsored by: Netflix
Reviewed by: mav
Differential Review: https://reviews.freebsd.org/D32259
The FreeBSD nvme driver has reset the nvme controller twice on attach to
address a theoretical issue assuring the hardware is in a known
state. However, exierence has shown the second reset is unnecessary and
increases the time to boot. Eliminate the second reset. Should there be
a situation when you need a second reset (for buggy or at least somewhat
out of the mainstream hardware), the hardware option NVME_2X_RESET will
restore the old behavior. Document this in nvme(4).
If there's any trouble at all with this, I'll add a sysctl tunable to
control it.
Sponsored by: Netflix
Reviewed by: cperciva, mav
Differential Revision: https://reviews.freebsd.org/D32241
After some study of the code and the standard, I think we can just drop
the pause(), unconditionally. If we're not initialized, then there's
nothing to wait for from a software perspective. If we are initialized,
then there might be outstanding I/O. If so, then the qpair 'recovery
state' will transition to WAITING in nvme_ctrlr_disable_qpairs, which
will ignore any interrupts for items that complete before we complete
the reset by setting cc.en=0.
If we go on to fail the controller, we'll cancel the outstanding I/O
transactions. If we reset the controller, the hardware throws away
pending transactions and we retry all the pending I/O transactions. Any
transactions that happend to complete before cc.en=0 will have the same
effect in the end (doing the same transaction twice is just inefficient,
it won't affect the state of the device any differently than having done
it once).
The standard imposes no wait times here, so it isn't needed from that
perspective.
Unanswered Question: Do we may need to disable interrupts while we
disable in legacy mode since those are level-sensitive.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D32248
The don't touch the mmio of the drive after we do a EN 1->0 transition
is only for a tiny number of dirves that have this unforunate issue.
Sponsored by: Netflix
Rewrite the nested if's using the preferred FreeBSD style for branches
of ifs that return. NFC. Minor tweaks to the comments to better fit new
code layout.
Sponsored by: Netflix
Reviewed by: mav, chuck (prior rev, but comments rolled in)
Differential Revision: https://reviews.freebsd.org/D32245
Remove the 5ms delays after writing the administrative queue
registers. These delays are from the very earliest days of the driver
(they are in the first commit) and were most likely vestiges of the
Chatham NVMe prototype card that was used to create this driver. Many of
the workarounds necessary for it aren't necessary for standards
compliant cards. The original driver had other areas marked for Chatham,
but these were not. They are unneeded. There's three lines of supporting
evidence.
First, the NVMe standards make no mention of a delay time after these
registers are written. Second, the Linux driver doesn't have them, even
as an option. Third, all my nvme cards work w/o them.
To be safe, add a write barrier between setting up the admin queue and
enabling the controller.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D32247
Use correct devclass name, due to the mismatch miibus would attach
to the wrong thing causing mii_attach to silently fail.
Fixes: dfcaa2c18b (enetc_mdio: Support building the driver ...)
Match the PCI simple comm devices (or try to). Be conservative and use
legacy interrupts rather than msi messages by default for this 'catch
all' since it matches what Linux does (it has opt-in generally for MSI,
but also matches more devices because it does a catch-all like
implemented in this commit).
Sponsored by: Netflix
Reviewed by: kbowling
Differential Revision: https://reviews.freebsd.org/D32228
Some setups claim to have one MSI, but they don't actually work. Allow
these to be flagged.
Sponsored by: Netflix
Reviewed by: kbowling
Differential Revision: https://reviews.freebsd.org/D32229
Previously mgb_admin_intr printed a diagnostic message if no interrupt
status bits were set, but it's not valid to call device_printf() from a
filter. Just drop the message as it has no user-facing value.
Also return FILTER_STRAY in this case - there is nothing further for
the driver to do.
Reviewed by: kbowling
MFC after: 1 week
Fixes: 8890ab7758 ("Introduce if_mgb driver...")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32231
Looking for "tsc-tsc" in the pmu tables will fail every time. Instead,
make this an alias for the static TSC event defined in pmc_events.h.
This fixes 'pmcstat -s cycles' on Intel and AMD.
Reviewed by: emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32197
Issue: Devices wont go away after the link down.
Device lost timer functionality in ocs_fc is broken,
`is_target` flag is not set in the target database and target delete is skipped.
Fix: Remove unused flags and delete the device when timer expires.
Reported by: ken@kdm.org
Reviewed by: mav, ken
Proper error recovery depends on freezing the device queue when an
error occurs, so we can recover from an error before sending
additional commands.
The ocs_fc(4) driver was not freezing the device queue for most
SCSI errors, and that broke error recovery.
sys/dev/ocs_fc/ocs_cam.c:
In ocs_scsi_initiator_io_cb(), freeze the device queue if
we're passing back status other than CAM_REQ_CMP.
Submitted by: ken@kdm.org
Reviewed by: mav, ken
In ocs_scsi_initiator_io_cb(), if the SCSI command that is
getting completed had a residual equal to the transfer length,
it was setting the CCB status to CAM_REQ_CMP.
That breaks the expected behavior for commands like READ ATTRIBUTE.
For READ ATTRIBUTE, if the first attribute requested doesn't exist,
the command is supposed to return an error (Illegal Request,
Invalid Field in CDB). The broken behavior for READ ATTRIBUTE
caused LTFS tape formatting to fail. It looks for attribute
0x1623, and expects to see an error if the attribute isn't present.
In addition, if the residual is negative (indicating an overrun),
only set the CCB status to CAM_DATA_RUN_ERR if we have not already
reported an error. The SCSI sense data will have more detail about
what went wrong.
sys/dev/ocs_fc/ocs_cam.c:
In ocs_scsi_initiator_io_cb(), don't set the status to
CAM_REQ_CMP if the residual is equal to the transfer length.
Also, only set CAM_DATA_RUN_ERR if we didn't get SCSI
status.
Submitted by: ken@kdm.org
Reviewed by: mav, ken
Use refcounting to delay the detach rather than device_busy and/or
device_unbusy. fd/fdc is one of the few consumers of device_busy in the
tree for that, and it's not a good fit. Also, nothing is waking 'fd' and
other drivers don't loop like this. Return EBUSY if we still have active
users.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D31830
Add support for ACPI device probing for SDHCI controller found on Marvell chips.
Reviewed by: mw
Sponsored by: Semihalf
Differential revision: https://reviews.freebsd.org/D31600
This patch splits driver code into two seperate files sdhci_xenon.c
and sdhci_xenon_fdt.c. This will allow future implementation of ACPI
discovery of sdhci on Xenon chips.
Reviewed by: mw
Sponsored by: Semihalf
Differential revision: https://reviews.freebsd.org/D31599
The debug register dump routine is not hooked up and is really only
useful to driver developers, so put it under an mgb-specific MGB_DEBUG
rather than general DEBUG.
MFC after: 1 week
Fixes: 8890ab7758 ("Introduce if_mgb driver...")
Sponsored by: The FreeBSD Foundation
The refactoring in 8a8166e5bc introduced a functional change that
breaks booting on the Stratix 10, hanging when it should be attaching
da0. Previously OF_getencprop was called with a pointer to host->f_max,
so if it wasn't present then the existing value was left untouched, but
after that commit it will instead clobber the value with 0. The dwmmc
driver, as used on the Stratix 10, sets a default value before calling
mmc_fdt_parse and so was broken by this functional change. It appears
that aw_mmc also does the same thing, so was presumably also broken on
some boards.
Fixes: 8a8166e5bc ("mmc: switch mmc_helper to device_ api")
Reviewed by: manu, mw
Differential Revision: https://reviews.freebsd.org/D32209
mvneta_find_ethernet_prop_switch() is file-local static to
if_mvneta_fdt.c. Normally we would not need a function declararion
but in case MVNETA_DEBUG is set it becomes public. Move the
function declaration from if_mvneta.c to if_mvneta_fdt.c to avoid
a warning during each compile.
Make sure the completion ID is in the range of [0..num_trackers) since
the values past the end of the act_tr array are never going to be valid
trackers and will lead to pain and suffering if we try to dereference
them to get the tracker or to set the tracker back to NULL as we
complete the I/O.
Sponsored by: Netflix
Reviewed by: mav, chs, chuck
Differential Revision: https://reviews.freebsd.org/D32088
Count the number of times we're asked to process completions, but that
we ignore because the state of the qpair isn't in RECOVERY_NONE.
Sponsored by: Netflix
Reviewed by: mav, chuck
Differential Revision: https://reviews.freebsd.org/D32212
The proper phase for the qpiar right after reset in the first interrupt
is 1. For it, make sure that we're not still in phase 0. This is an
illegal state to be processing interrupts and indicates that we've
failed to properly protect against a race between initializing our state
and processing interrupts. Modify stat resetting code so it resets the
number of interrpts to 1 instead of 0 so we don't trigger a false
positive panic.
Sponsored by: Netflix
Reviewed by: cperciva, mav (prior version)
Differential Revision: https://reviews.freebsd.org/D32211
An interrupt happens on the admin queue right away after the reset, so
as soon as we enable interrupts, we'll get a call to our interrupt
handler. It is safe to ignore this interrupt if we're not yet
initialized, or to process it if we are. If we are initialized, we'll
see there's no completion records and return. If we're not, we'll
process no completion records and return. Either way, nothing is
processed and nothing is lost.
Until we've completely setup the qpair, we need to avoid processing
completion records. Start the qpair in the waiting recovery state so we
return immediately when we try to process completions. The code already
sets it to 'NONE' when we're initialization is complete. It's safe to
defer completion processing here because we don't send any commands
before the initialization of the software state of the qpair is
complete. And even if we were to somehow send a command prior to that
completing, the completion record for that command would be processed
when we send commands to the admin qpair after we've setup the software
state. There's no good central point to add an assert for this last
condition.
This fixes an KASSERT "received completion for unknown cmd" panic on
boot.
Fixes: 502dc84a8b
Sponsored by: Netflix
Reviewed by: mav, cperciva, gallatin
Differential Revision: https://reviews.freebsd.org/D32210
When a usb device is detached, usb_pc_dmamap_destroy() called
bus_dmamap_destroy() while the map was still loaded. That's harmless on x86
architectures, but on all other platforms it causes bus_dmamap_destroy() to
return EBUSY and leak away any memory resources (including bounce buffers)
associated with the mapping, as well as any allocated map structure itself.
This change introduces a new is_loaded flag to the usb_page_cache struct to
track whether a map is loaded or not. If the map is loaded,
bus_dmamap_unload() is called before bus_dmamap_destroy() to avoid leaking
away resources.
MFC after: 7 days
Differential Revision: https://reviews.freebsd.org/D32208
There's not much we can do if mii_mediachg() fails, but KASSERT is not
appropriate.
MFC after: 1 week
Fixes: 8890ab7758 ("Introduce if_mgb driver...")
Sponsored by: The FreeBSD Foundation
