These are reportedly still in fairly wide use.
We strongly encourage folks with this hardware to post a dmesg on
dmesgd.nycbug.org.
This reverts commit 4591322980.
Discussed with: brooks
Sponsored by: The FreeBSD Foundation
Recent AMD CPUs (SMBus PCI revision ID >= 0x51) can disable port-mapped
IO and only support memory-mapped IO. In practice this was observed on a
Zen 3 CPU where PMIO reads all returned 0xff. Update the driver to use
MMIO for these processors while continuing to use PMIO by default.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1437
The way we got the kernel metadata pointer was by calling
preload_search_by_type with one of the following three: "elf kernel",
"elf32 kernel" and "elf64 kernel". Which one(s) we used wasn't
consistent though. Sometimes we would only try "elf kernel", and other
times we would try one of the latter two if the first failed. However,
the loader only ever sets "elf kernel" as the kernel type.
Now, the kmdp is a global, preload_kmdp, and it's initialized using
preload_initkmdp in machdep.c (or machdep_boot.c on arm/64).
preload_initkmdp takes a single boolean argument that tells us whether
not finding the kmdp is fatal or not.
Reviewed by: imp, kib
Pull Request: https://github.com/freebsd/freebsd-src/pull/1394
Using one taskqueue group with single thread to execute all admin
tasks may lead to unexpected timeouts when long running task (e.g.
handling a reset after FW update) for one interface prevents
tasks from other interfaces being executed. Taskqueue group API
doesn't let to dynamically add threads, and pre-allocating thread
for each CPU as it's done for traffic queues would be a waste
of resources on systems with small number of interfaces. Replace
global taskqueue group for admin tasks with taskqueue allocated
for each interface to allow independent execution.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Reviewed by: imp, jhb
Pull Request: https://github.com/freebsd/freebsd-src/pull/1336
ELECOM EDC-QUA3C is a USB3.1 Gen1 Type-A/C 2.5GBASE-T network adapter.
This also works as a cdce(4) device by:
usbconfig -d X.Y set_config 1
or
usbconfig -d X.Y set_config 2
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
MFC after: 2 weeks
Pull Request: https://github.com/freebsd/freebsd-src/pull/1578
We need to complete calling the ACPI method before marking the interrupt
as complete. If two threads are inspecting the ACPI tables at the same
time they may both try to lock the ACPI mutex causing one to sleep. If
this is the ithread it will panic the kernel as this is not allowed.
Update the ged ithread to allow sleeping as it is expected this lock
will be uncommon enough any sleep will be short.
PR: 283103
Reviewed by: markj (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48284
Save more data associated with a new association including the network
address of the remote controller. This permits reconnecting an
association without providing the address or other details. To use
this new mode, provide only an existing device ID to nvmecontrol's
reconnect command. An address can still be provided to request a
different address or other different settings for the new association.
The saved data includes an entire Discovery Log page entry to aim to
be compatible with other transports in the future. When a remote
controller is connected to via a Discovery Log page entry (nvmecontrol
connect-all), the raw entry is used. When a remote controller is
connected to via an explicit address, an entry is synthesized from the
parameters.
Note that this is a pseudo-ABI break for the ioctls used by nvmf(4) in
that the nvlists for handoff and reconnect now use a slightly
different set of elements. Since this is only present in main I did
not bother implementing compatability shims.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D48214
Add support for the Arm Errata Management Firmware Interface (Errata
ABI) [1]. This provides an interface for the kernel to query the status
of an erratum workaround.
Some errata may be mitigated depending on the other hardware in a SoC,
e.g. Cortex-A78 erratum 2712571 is not affected in systems that use
an Arm interconnect. As there may not be a way for the kernel to know
if this is the case then it would have to implement the workaround
even when not needed.
There are other cases where the needed workaround is implemented in
firmware and if not implemented then the kernel may decide to not use
a feature. In this case we can query the firmware before deciding if
we should use a feature or now.
There is a known issue with some firmware implementations of the Errata
ABI that incorrectly returns a status indicating the erratum is fully
mitigated by the firmware, however there is a kernel component needed,
e.g. Neoverse-N1 erratum 1542419. To handle this case we tell the
caller there is some workaround implemented in the firmware and it can
decide how to handle it. If this is fixed in a way we can detect we can
add a new erratum status value to indicate this.
[1] https://developer.arm.com/documentation/den0100/latest/
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48055
This flag was used as a transition for differing pcib implementations.
Today it is defined for all supported architectures, and can be removed.
Reviewed by: imp, jhb
Differential Revision: https://reviews.freebsd.org/D48485
Expose as read-only the configured transport properties.
Tested on: Arm Morello Board
Reviewed by: andrew
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47428
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Add a few basic traces to track SCMI messages lifecycle.
Tested on: Arm Morello Board
Reviewed by: Andrew
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47427
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Add the core logic to handle the replies to pending command in an
asynchronous manner.
Tested on: Arm Morello Board
Reviewed by: andrew
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47426
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Split scmi_request internals into a TX and an RX phase, which will be
called, anyway, in sequence as before when a normal transmission is
requested.
No functional change.
Tested on: Arm Morello Board
Reviewed by: andrew
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47425
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
During normal operation, the SCMI stack, upon each transmission attempt,
takes care to automatically pick an appropriate, monotonically increasing,
sequence number to fill-in the token field in the egressing message.
This does not cope well with the alternative scenario in which, instead,
a complete and fully formed message is provided upfront: in such a case the
SCMI stack will have to use the already provided sequence number, embedded
in the message, to track such transaction.
Add a method to attempt to reserve a specific sequence number to be used
when a fully firmed (raw) message is handled.
Tested on: Arm Morello Board
Reviewed by: andrew
Sponsored by: Arm Ltd
Pull Request: https://reviews.freebsd.org/D47424
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Refactor allocation logic for scmi_req and introduce new helpers to be able
to obtain an scmi_msg reference to a freshly allocated request.
Tested on: Arm Morello Board
Reviewed by: andrew
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47423
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
SCMI transport characteristics can be optionally described in the
devicetree to override the default build-time values.
Tested on: Arm Morello Board
Reviewed by: andrew
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47422
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
The defined maximum payload size should not include header and status
field. Fix the definition accordingly, so that it matches the
definitions as can be found in the Linux SCMI stack.
The semantic of this define is important since it will then be possible
to override such values from devicetree, like in Linux.
Tested on: Arm Morello Board
Reviewed by: andrew
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47421
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Once a message is received that fits into the RX buffer, update the
msg.rx_len field with the effective length of the message received.
Tested on: Arm Morello Board
Reviewed by: andrew
Sponsored by: Arm Ltd
Pull Request: https://reviews.freebsd.org/D47420
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
When a waited-for outstanding request is determined to have timed out,
mark such request immediately as such, so as to avoid any possible race on
the IRQ path with code path evaluating that same timed out condition.
Tested on: Arm Morello Board
Reviewed by: andrew
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47419
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
By the SCMI specification the message sequence number field is 10-bit long.
Fix accordingly the used bitmask.
Fixes: d220b1cf02 ("scmi: Extend and refactor SCMI shmem support")
Tested on: Arm Morello Board
Reviewed by: andrew
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47418
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
It /looks/ like there's some weirdness in initial frame send after
the chip programming / channel change. Linux rtl8xxxu has no sleeps
here, instead it just retries the auth frame a few times.
My guess is there's some sequencing going on here between finishing
the programming, doing a calibration run and then sending the initial
frame.
Instead of doing sleeps on every write during the RF channel change,
this 10ms sleep at the end is enough to reliably associate in my
test environment (12-core intel laptop, USB-3 port.) It's not
required for an earlier 2-core haswell laptop w/ USB-3.
See the PR for more information.
PR: kern/247528
Differential Revision: https://reviews.freebsd.org/D48517
The Linux rtl8xxxu driver has more delays in the RF read and write
path.
It looks like for writes it's ensuring the hardware is out of
power save and that the transition has properly occured.
And it looks for reads that it wants a delay after some bit setting,
likely some shifting into the RF register space is occuring with
a bit set/clear to trigger a load.
See rtl8xxxu_write_rfreg() and rtl8xxxu_read_rfreg() for more
information.
Differential Revision: https://reviews.freebsd.org/D48512
Obtained from: Linux rtl8xxxu
The RTL8192EU NIC (on older USB 2/USB 3 ports, not on newer
USB 3 ports, that still needs to be fixed!) will attach, scan,
associate fine. However, restarting wpa_supplicant results in the
NIC hanging until you disconnect it.
It turns out early in the power_on sequence - BUT only after a
power_off - the NIC would suddenly stop responding to any USB
transfers. It doesn't require the MCU to be available for USB
transfers - the hardware itself does that - so something had to be
going very sideways.
I traced it down to these steps during the power_off sequence.
They don't exist in the Linux rtl8xxxu driver, and there are commits
earlier in their RTL8192EU bring-up that suggest the author was
facing similar power sequencing / re-sequencing issues.
This likely won't fix the actual channel programming /
power sequencing / deafness issues on later USB-3 ports.
There are other commits / fixes in the rtl8xxxu driver related to
RTL8192EU bring-up that we don't have.
Differential Revision: https://reviews.freebsd.org/D48428
Obtained from: Linux rtl8xxxu driver
When a SYS_RES_IOPORT resource crosses a pci_host_generic bridge, it
is translated into a memory access for an associated range, so use
SYS_RES_MEMORY for the resource allocated from the parent.
Tested by: markj
Differential Revision: https://reviews.freebsd.org/D44207
Commit 27b932e32f ("sound: Safely remove channel from list in one
pass") optimized CHN_REMOVE_SAFE() to perform almost equally to
CHN_REMOVE(), so we can turn CHN_REMOVE_SAFE() into CHN_REMOVE() without
fears of performance regressions, while also being more robust.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D48249
The CHN_REMOVE_SAFE() macro did two traversals of the channel list to
remove a channel, one to check whether the channel is an element of the
list, and a second traversal through SLIST_REMOVE(). Reduce this to one
traversal, while still preventing a NULL dereference in case the channel
in question is not present in the list.
While here, rename the macro arguments to something more descriptive.
MFC after: 1 week
Reviewed by: christos
Differential Revision: https://reviews.freebsd.org/D48207
Main goal is to have a unit test, with sample test data that is verified
against the current macro implementation of pcm sample read and write
functions. With a test in place, we can proceed on a planned refactoring
of the sample read and write code, and confidently check the new code
for regressions.
Implementation of the unit test itself has to avoid any cast or
conversion affected by endianness, to make the tests compatible with all
machine architectures.
MFC after: 1 week
Reviewed by: christos, markj
Differential Revision: https://reviews.freebsd.org/D48330
This includes the port of a driver originally from OpenBSD, later
ported to NetBSD by the author:
* The umb(4) kernel driver
* The umbctl(8) companion tool
This driver supports USB network devices implementing the
Mobile Broadband Interface Model (MBIM), often found in modern
(internal) USB models for 4G/LTE mobile broadband access.
It is currently limited to IPv4.
umbctl has to be used to display or set MBIM cellular modem
interface parameters (4G/LTE).
Differential Revision: https://reviews.freebsd.org/D48167
Approved by: adrian, zlei
Sponsored by: FreeBSD Foundation
PR: kern/263783
Submitted by: Pierre Pronchery <khorben@defora.org>
This is a flag to be used to disable >1 antenna support, even if
the radio supports it.
Also populate sku_cap_11n_enable, which indicates HT is available.
It's a no-op right now; it's one of the requirements for properly
configuring HT support and transmit/receive antenna configurations.
Obtained from: OpenBSD (at a6e25c727a2214219715b51ba6af2221d7e0d674, 22-Oct-2021)
Differential Revision: https://reviews.freebsd.org/D48210
Reviewed by: bz
These are from an earlier version of the driver (22-Oct-2021) which
I started to sync against back in 2021.
These pull in the rest of the VHT and HT rates.
Since that driver has functioning 802.11n support, it makes a good
intermediary checkpoint.
Locally tested:
* 7260, STA mode, 11g and 11a modes
Differential Revision: https://reviews.freebsd.org/D48209
Obtained from: OpenBSD (at a6e25c727a2214219715b51ba6af2221d7e0d674, 22-Oct-2021)
This driver prefers connection speed over sas port speed. On stable/13
branch the stack-allocated CCB is not cleared thus the cam layer may
report weird speed on boot.
```
da0: <VMware Virtual disk 2.0> Fixed Direct Access SPC-4 SCSI device
da0: 4294967.295MB/s transfers
```
-current and stable/14 have the change [1] which clears stack-allocated
CCB thus are not affected, but I want -current and stable/14 to have this
fix in to reduce drift between branches.
1. ec5325dbca cam: make sure to clear even more CCBs allocated on the stack
Reviewed by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D48438
This flag was introduced to ignore bad firmware values. These were
present in older versions of EDK-II that many devices (both Ampere and
Amazon) used. QEMU also used this value, but fixed it. But since it's
tied to the firmware bug not the device name ID it doesn't make sense to
have it flagged there.
Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D47947
Some veresions of EDK-II and QEMU reported the wrong values for the
register shift and the region I/O size. Detect those and set it to the
correct values. In general, anything other than a shift of 2 and a
regio width of 4 (bytes, or 32 bits) is a mistake. However, allow
for overrides in the future by only overriding the buggy values.
Otherwise, we will fail to boot.
PR: 282936
Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D47946
Although there's no RTS/CTS rate control available yet, the support
is enough to enable firmware rate control for experimenting.
This won't be enabled by default - users will need to set a tunable
before loading the driver (eg kenv dev.rtwn.0.ratectl=2) but it is
enough for experimentation, feedback and continued work.
Locally tested:
* RTL8192CU, STA mode
Differential Revision: https://reviews.freebsd.org/D48143
Reviewed by: bz, emaste
* refactor out the r92c path protection (RTS/CTS) decision
* handle firmware rate control being enabled - if DRVRATE isn't
set then the RTSRATE field is ignored and instead RRSR/INIRTS
registers are used (and the firmware/hardware will do RTS
rate adaptation / retry.)
* when making protection decisions with firmware rate control,
default to the channel mode rather than rate index.
This works on RTL8192CU both with firmware rate control and driver
rate control.
Locally tested:
* RTL8192CU, STA - firmware and net80211 rate control
Differential Revision: https://reviews.freebsd.org/D48142
Refactor out the datarate setup and short preamble setup.
These will eventually be slightly different based on whether
firmware rate control is being performed or not.
Locally tested:
* RTL8192CU, STA mode
Differential Revision: https://reviews.freebsd.org/D48141
The NIC/firmware initialises the initial RTS/CTS rate to something
high, like OFDM48. That's not going to be very reliable.
It's not a problem right now as we program in the RTS/CTS value
to use in the TX descriptor setup path based on the control rate
for the given frame TX rate, and like the INIDATA/driver rate
stuff in the TX descriptor, the TX descriptor RTS/CTS rate overrides
the INIRTS rate.
However when it's time to flip on firmware based rate control,
the initial rate needs to not be OFDM48. Yes, the firmware and
hardware does have some rate retry schedule for RTS/CTS frames,
but there's no point in wasting short retries trying to do OFDM48
based RTS/CTS setup.
Add some warning logging if there are no basic or RTS/CTS rates
available, and leave things at default. If this happens in
production for someone then it would be good to know and what
the rate mask was.
Locally tested:
* RTL8192CU, STA mode (with/without firmware rate control enabled locally)
Differential Revision: https://reviews.freebsd.org/D48140
nda(4) has its own shutdown handler that runs at SHUTDOWN_PRI_DEFAULT
that calls ndaflush() that could run after the nvmf handler. Instead,
give a the flush a chance to run before the graceful shutdown of the
controller.
While here, be a bit more defensive in the post-sync case and shutdown
the consumers (sim and /dev/nvmeXnY devices) before destroying the
queue pairs so that if any requests are submitted after the post-sync
handler they fail gracefully instead of trying to use a destroyed
queue pair.
Reported by: Sony Arpita Das <sonyarpitad@chelsio.com>
Sponsored by: Chelsio Communications
<assert.h> now has a usable definition, so we don't need to shim it out
in the nvmf header anymore.
Reviewed by: emaste, jhb
Differential Revision: https://reviews.freebsd.org/D48078
Implement the small amount of MD code required; copied from arm/arm64.
One tweak is made to cpufreq_dt itself: if the opp-shared property is
missing, but there is only one CPU, then we can still attach. This is
relevant for the single-core Allwinner D1.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48124
Some RISC-V CPUs contain a "monitor core" with limited functionality (no
MMU). These cores appear in some device trees, but we don't run the
kernel on them; in early CPU start-up code we skip them, and they have
no impact on mp_ncpu. It seems the new trend is to mark these monitor
cores with a 'status' property of 'disabled'.
However, we still instantiate an ofw_cpu pseudo device for the disabled
core. This is generally harmless, but there is an impact when attempting
to attach the cpufreq_dt driver. It counts more OFW CPU devices (unit
number) than logical CPUs (mp_ncpus), and therefore fails to attach for
the last logical CPU.
The solution is to check the status property in ofw_cpu_probe(), and
fail if the core is marked "disabled". This is subject to the same
exception already in ofw_cpu_early_foreach(); that is, if a disabled CPU
has an 'enable-method' property, it can be used by the kernel.
Reviewed by: andrew, jrtc27
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48123
Mainly, to avoid repeating the list of architectures, #define HAS_CLK.
Further, split the clk code into a helper function, which is a stub in
the !HAS_CLK case. This aids in overall legibility.
While here, add one separating whitespace, again for legibility.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48149
The canonical name is __riscv, not __riscv__. Newer compilers no longer
emit the latter.
This re-enables finding the nominal frequency from the CPU's clock.
I checked, and there are no remaining mistakes like this in the tree.
Reviewed by: jrtc27, imp, jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48122
