This fixes the driver to load correctly as a module when etherswitch
is also a module.
Differential Revision: https://reviews.freebsd.org/D50027
Reviewed by: imp
to Linux hidraw compatibility API.
Respective Linux commit f43d3870cafa made by Dean Camera message is:
Currently the hidraw module can only read and write feature HID reports on
demand, via dedicated ioctls. Input reports are read from the device through
the read() interface, while output reports are written through the write
interface().
This is insufficient; it is desirable in many situations to be able to read and
write input and output reports through the control interface to cover
additional scenarios:
- Reading an input report by its report ID, to get initial state
- Writing an input report, to set initial input state in the device
- Reading an output report by its report ID, to obtain current state
- Writing an output report by its report ID, out of band
This patch adds these missing ioctl requests to read and write the remaining
HID report types. Note that not all HID backends will neccesarily support this
(e.g. while the USB link layer supports setting Input reports, others may not).
FreeBSD native uhid(4) compatible API already has similar ioctls.
MFC after: 3 days
The SD_F_* flags are supposed to be softc flags, but SD_F_PRIO_RD and
SD_F_PRIO_WR are just generic flags and are only used with
dsp_lock_chans() and dsp_unlock_chans(). Since we already have the
DSP_F_READ() and DSP_F_WRITE() macros, we can re-use them instead.
I am aware the FREAD and FWRITE flags are meant to be used with open(),
but I think their use here is clear enough to not cause confusion.
No functional change intended.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D49978
Prior to 02d4eeabfd ("sound: Allocate vchans on-demand"), the
play.vchans and rec.vchans sysctls corresponded to the value of
d->pvchancount and d->rvchancount respectively, which is also what we
are exporting through SNDST_DSPS_SOUND4_PVCHAN and
SNDST_DSPS_SOUND4_RVCHAN respectively. Since that commit, the sysctls
mentioned have been modified to show whether play/rec vchans are enabled
or not. Modify the sndstat nvlist parameters accordingly.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D49980
The max I/O size that an mpi3mr HBA supports is reported in the IOCFacts
structure (with 0 representing the legacy max I/O size of 1 MB).
By default, set the max I/O size of devices attached to mpi3mr controllers
to the smaller of the HBA's max I/O size and the kernel's maxphys.
Allow this default to be overriden by a global tunable
"hw.mpi3mr.max_sgl_entries" or by a per-controller tunable
"dev.mpi3mr.N.max_sgl_entries".
Sponsored by: Netflix
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D49090
The ctx_hw_stats_ext DMA address was not correctly passed to the
firmware during the HWRM_STAT_CTX_ALLOC allocation, causing stats to not
populate for Thor2. Passing the correct DMA length resolved the issue
MFC-After: 3 days
Differential-Revision: https://reviews.freebsd.org/D49732
The completion event type 76 is not supported by the driver. Instead of
flooding the dmesg with "Unknown event type" messages when this event
occurs, move the print under debug level.
MFC-After: 3 days
Differential-Revision: https://reviews.freebsd.org/D49731
Doorbell offset :
For Thor controllers doorbell offset was always hardcoded to 0x10000 for
PF devices where as for Thor2 controllers doorbell offset will be
legacy_l2_db_size_kb value provided by firmware through hwrm_func_qcfg
command.
CQ Toggle & Epoch bits support :
In order to handle out of order doorbell handling as part of Dropped
Doorbell Recovery, HW expects two changes in the driver in data path.
- First change is the epoch bit changes while updating the producer
indexes of Tx. This epoch bit is toggled by the driver, each time the
queue is wrapped for that specific doorbell.
- The second change is to add a toggle bit pair to each ARM type
doorbell. This includes the CQ_ARMALL, CQ_ARMSE, CQ_ARMENA
doorbells. The toggle bit pair in context is incremented by the chip
each time a new NQE completion is generated by the chip. To keep the
driver in-sync, the toggle bit pair will be passed in the NQE to the
host completion. This will be the toggle bit pair value that the host
must use to setup the next NQE operation. The driver will pass that
latest toggle bit pair value into the ARM type doorbells it generates to
the chip. The doorbell clients will compare the toggle bit pair in each
doorbell with the value in context. If the values match, the doorbell
will be honored. If the values do not match, the doorbell will be
discarded.
MFC-After: 3 days
Differential-Revision: https://reviews.freebsd.org/D49730
Added support for RX V3 completion record types-
CMPL_BASE_TYPE_RX_TPA_START_V3 and CMPL_BASE_TYPE_RX_L2_V3.
MFC-After: 3 days
Differential-Revision: https://reviews.freebsd.org/D49728
Add backing store V2 support.
Thor2 controllers supports only the V2 support.
MFC-After: 3 days
Reviewed-by: Warner Losh <imp@FreeBSD.org>
Differential-Revision: https://reviews.freebsd.org/D49727
INTRng can leak resources when INTx interrupts are re-routed, which is
typically harmless but can be fatal when devices are (repeatedly) hot
plugged into PCI buses on INTRng systems. Re-routing INTx interrupts
is nonetheless still necessary on some systems, and identifying whether
the re-routing should be enabled or disabled seems to be nontrivial.
Add a hw.pci.intx_reroute sysctl/tunable so systems which don't want
legacy PCI interrupt re-routing can turn it off. This is probably not
the best fix but it's something which can be safely included in FreeBSD
14.3.
Co-Authored-by: jhb
Reviewed by: bz, jhb
MFC after: 3 days
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D49849
jrtc27@freebsd.org reported that DHCP wasn't working on some
networks. She dug into it and found that the RTL8812AU/RTL8812AU
NICs seem to be failing UDP frames w/ a zero checksum, which is
a valid "there's no checksum" checksum.
So, just pass those frames up the stack and let the IP stack
deal with it. If the hardware claims the frames did pass TCP/UDP
checksum then still mark those frames with the checksum offload
bits.
PR: kern/285387
Differential Revision: https://reviews.freebsd.org/D49628
The RX filter wasn't enabling BAR frames, so we weren't receiving them
during normal operation.
Jessica noticed we WERE getting BAR frames, but only when promisc mode
is active. Which is a different set of bugs, but it did highlight
the differences here.
Differential Revision: https://reviews.freebsd.org/D49596
PR: kern/285822
As axidma(4) does not support busdma(9) then add local cache flushes,
and map descriptors using default memory attribute (cacheable type).
This fixes operation on Codasip X730.
Sponsored by: UKRI
Any events left over from boot firmware, etc. are not meaningful so
clear pending events during attach. If they are still pending they
should remain asserted when the slot status register is re-read.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D49950
At least some PCI-express bridges exposed by Intel Volume Management
Devices report bogus power faults in their slot status register. As a
workaround, ignore the power fault detected flag if the slot
capability register does not indicate support for a power controller.
While the PCI-e spec does not explicitly state that the PFD flag
should always be zero if a power controller is not present, parts of
the spec do seem to assume this. For example, the flag is included in
the "Power Controller Registers" register group in 6.7.2.4, and the
definition of the value for this flag seems to presume the presence of
a power controller:
If a Power Controller that supports power fault detection is
implemented, this bit is Set when the Power Controller detects a
power fault at this slot. Note that, depending on hardware
capability, it is possible that a power fault can be detected at
any time, independent of the Power Controller Control setting or
the occupancy of the slot. If power fault detection is not
supported, this bit must not be Set.
PR: 285993
Reported by: Jim Long <freebsd-bugzilla@umpquanet.com>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D49949
We call an ACPICA function in the interrupt handler which may attempt to
lock a mutex. If this is done while another instance of the handler
already holds the lock, it would cause a kernel panic since sleeping
isn't allowed.
Reviewed-by: Warner Losh <imp@FreeBSD.org>
Pull-request: https://github.com/freebsd/freebsd-src/pull/1667
Signed-off-by: Ahmad Khalifa <ahmadkhalifa570@gmail.com>
The flags member of gpio_pin_t was only meant for pin flags acquired via
the FDT.
Instead, make an accessor so gpioaei can still access the flags and
remove the now unused gpio_pin_get_by_acpi_index.
Reviewed-by: Warner Losh <imp@FreeBSD.org>
Pull-request: https://github.com/freebsd/freebsd-src/pull/1667
Signed-off-by: Ahmad Khalifa <ahmadkhalifa570@gmail.com>
This message was identical to another a few lines up, making it hard to
tell where the error occurred.
Reviewed-by: Ed Maste <emaste@FreeBSD.org>
Reviewed-by: Warner Losh <imp@FreeBSD.org>
Pull-request: https://github.com/freebsd/freebsd-src/pull/1667
Signed-off-by: Ahmad Khalifa <ahmadkhalifa570@gmail.com>
uether_rxmbuf() assumes the uether_newbuf() model where the caller has
just set m_len to the entire size of the mbuf, and passed the final
size into uether_rxmbuf() for finalization.
In if_ure we're creating our own mbuf chains, and the accounting is all
already accurate. uether_rxmbuf's logic won't work at all for a chain,
so let's add an assertion to that effect (but I think the other callers
were all OK).
This fixes a panic on my Windows DevKit when undergoing any kind of
network stress that surfaces after the bogus mbuf is injected into the
network stack (usually observed in `m_dup`).
markj and I had spent some time investigating it and decided there's
some kind of buffer underrun happening; the rx packet descriptor reports
a length longer than what's actually available. We discard the rest of
the transfer, but then we end up fetching it in a subsequent transfer
and end up casting packet data to a `struct ure_rxpkt` incorrectly. It
would be better to fix the underlying root cause, but this is a
reasonable mitigation in the interim.
Reviewed by: markj
Fixes: 7d5522e16a ("A major update to the ure driver.")
Differential Revision: https://reviews.freebsd.org/D43465
agp_generic_bind_memory and agp_generic_unbind_memory do pctrie
lookups for ranges of consecutive pages. Use iterators to improved the
expected performance of those searches.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D49917
Move the necessary extra logics (i.e., noise_remote_enable() and
TAILQ_INSERT_TAIL()) from wg_ioctl_set() to wg_peer_alloc(), and thus
make it easier to be called. Actually, the updated version is more
asymmetric to wg_peer_destroy() and thus less likely to be misused.
Meanwhile, rename it to wg_peer_create() to look more consistent with
wg_peer_destroy().
Reviewed by: aly_aaronly.me (diff), markj
Obtained from: DragonflyBSD 902964ab24ba (with some changes)
This debugging code was added this log as part of an effort to diagnose
firmware crashes in an earlier version of the driver.
It hasn't been used for a while and I'm not sure how useful it is for
this compared to other methods.
While reorganisation move strings for print mappings into if_iwx_debug.c
to reduce their scope.
Suggested by: bz
Reviewed by: bz
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49783
iwx goes through a couple of steps to match devices to firmware. There
is a default match of pcie device and subdevices and then a secondary
pass to find a template configuration struct.
Previously we were looking up the device not the subdevice and that
led to ax210 cards in some devices (Framework 13) from being matched to
the correct firmware.
PR: 285905
Reviewed by: bz, adrian
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49759
Introduce SPI-mode support which allows an SD card to communicate with a
host system using SPI protocol, as described in the SD Card Specification.
This feature is useful for low-end, FPGA or RISC-V research systems when a
SoC is limited in terms of peripherals available (e.g. lack of a dedicated
MMC controller in hardware). Examples of such systems include Codasip,
lowRISC and CVA6.
Project timeline:
2007: Warner first discussed SPI operational mode in his MMC presentation:
https://people.freebsd.org/~imp/bsdcan2007.pdf
2012: Patrick Kelsey engineered the support.
2025: Ruslan cleaned up, tested on Codasip X730 platform (RISC-V FPGA)
and put the patch to review.
2025: Patrick Kelsey reviewed the patch and aligned with the current MMC
code.
Reviewed by: pkelsey
Sponsored by: UKRI
Differential Revision: https://reviews.freebsd.org/D49248
- Introduce the bus_type accessor, which allows to skip card selection
and timing settings in SPI mode;
- Add MMC_CMD_IS_APP flag for commands followed by the APP command,
which is required by the upcoming MMCSPI driver.
Reviewed by: pkelsey
Sponsored by: UKRI
Differential Revision: https://reviews.freebsd.org/D49249
Replace cable type detection with connector type for more accurate media
type selection. The connector type is queried directly from the PTYS
register and provides more reliable information about the physical port
type compared to cable type.
Reviewed by: slavash
Sponsored by: NVidia networking
MFC after: 1 week
fdt_immr_* are only used by the armv7 Marvell code. Move setting the
variables there as no new code should need to set them.
Reviewed by: cognet
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49535
fdt_data_get and fdt_data_to_res don't change the value of the data
passed to them via a pointer. Add const to these pointers.
Reviewed by: emaste
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49703
These have been replaces with fdt_foreach equivalents so are unused.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49702
As with fdt_foreach_mem_region add a function that calls a callback
for each reserved memory region in /memreserve. This allows us to
exclude this memory from the physical map in a way that is safe from
overflowing a fixed array on the stack.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49699
As with fdt_foreach_mem_region add a function that calls a callback
for each reserved memory region. This allows us to exclude this memory
from the physical map in a way that is safe from overflowing a fixed
array on the stack.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49698
This is used early in the boot to find physical memory. Previously it
needed an array of memory regions to be passed in. We keep finding
hardware where this array is too small causing the kernel to smash the
stack.
Replace with a function that takes a callback that can insert the
memory into the physical map directly.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49697
Some implementations of the virtio 9p transport are implemented on
virtio_mmio, e.g. the Arm FVP. Use the correct macro so the driver
attaches when this is the case.
Reviewed by: markj
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49600
On arm64 we use the iommu base address as an xref. This fails when
the address has the lower 32-bits in common with another iommu as
they will share an xref.
Reviewed by: kib
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48726
