if no hidbus and hidbus clients were attached and opened by users.
iichid(4) enables interrupts before hidbus is attached and sending
packets to it at this time leads to panic at boot time.
Fixes: daa098cc37 ("Wait for RESET command response while attaching")
Tested by: dch
PR: 286045
MFC with: daa098cc37
Only export the array of ID names if either _WANT_SFF_8024_ID or
_WANT_SFF_8472_ID is defined. Exporting them unconditionally can
trigger unused variable warnings if a consumer doesn't use the array.
Reviewed by: olce, bz, brooks
Differential Revision: https://reviews.freebsd.org/D49955
qThis change was made after feedback from upstream, aiming to align with
the style guide for consistent log formatting. No functional changes
were made to the driver, only the formatting of the log messages.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49799
The driver version has been updated to 8.14.0.2.0 to reflect the
latest release. This is a version-only update with no functional
code changes.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49753
All driver source files have been updated to reflect the year 2025.
This change is cosmetic and does not affect functionality.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49752
The driver now processes LOG Data events in the interrupt top
half instead of the bottom half. This allows LOG events to be
handled immediately upon receipt, reducing latency and enabling
early notification to the Library or applications.
This change ensures LOG event handling occurs closer to the
firmware's generation point, improving alignment with event-driven
diagnostic and monitoring mechanisms.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49751
This patch ensures the driver sets the Diag Save bit for all
diagnostic fault conditions before issuing a Diagnostic Fault Reset.
The firmware now incorporates logic to manage snapdump saving
and requires the driver to always set the Diag Save bit to enable
this feature. This change supports improved diagnostic data
collection and fault handling.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49750
The driver previously blocked I/Os only for OS-initiated task
management commands. This patch extends the behavior to also
block I/Os during application-initiated task management
operations (excluding Task Abort).
Before submitting such commands to the firmware, I/O
submissions are paused for the respective device. Once the
command completes, I/O operations are resumed.
This ensures safe and consistent task management handling.
[[ Note: Warner landed this with the pending suggestion
since this change is good enough for 14.3, but chs' suggestion
for better atomics needs to be implemented soon ]]
Discussed with: imp, chs
Differential Revision: https://reviews.freebsd.org/D49749
The driver now retrieves the Time Stamp value from Driver Page 1
during load and after controller reset. If the value is valid, it
is used to enable periodic host timestamp synchronization.
This adds a tunable NVData parameter to control the behavior of
host time sync, enhancing flexibility and platform-specific control.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49748
The driver now checks for insufficient power faults during the load
phase and immediately fails initialization instead of retrying.
Additionally, if an insufficient power fault is detected by the watchdog
after the controller is up, the controller is marked as unrecoverable
instead of triggering a reset.
This improves fault handling and avoids unnecessary recovery attempts
in low-power conditions.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49747
This patch improves the retry logic during the IOC enable process.
If a controller faults or if the reset history bit is detected during
the ready status check, the driver will retry initialization up to three
times or until 510 seconds have passed.
A soft reset will also be issued if the controller is detected while
waiting for the ready status.
This enhances reliability during controller initialization.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49746
This patch updates the driver to set the OSExposure field in DriverCapability
during IOCInit to MPI3_IOCINIT_DRIVERCAP_OSEXPOSURE_NO_SPECIAL(0x1), aligning
with the latest MPI specification version 36.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49745
Updated the MPI header files to version 36 to align with the latest
MPI specification. This includes updated structures, field definitions,
and constants required for compatibility with updated firmware.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49743
This adds the minimum support required to probe/attach the 88E6190X.
I've tested this against an AT&T ATT-150 OCP device (Silicom i3000)
with local changes to export MDIO via ixge(4).
Hints are required to probe/attach/configure the switch on amd64,
but with the mentioned diffs, it does work.
Thanks to Stas Alekseev <stas@alekseev.us> for the pull request
and Stas / Jason Hensler <omegadraconis@gmail.com> for chasing
down information about the chipset, linux stuff and AT&T OCP
hardware information.
PR: kern/281211
Pull Request: https://github.com/freebsd/freebsd-src/pull/1408
Differential Revision: https://reviews.freebsd.org/D50044
Reviewed by: imp
Although all the machinery is present, the tick routine only ran once.
It was never rescheduled. So, reschedule it.
However in practice I've discovered that the tick routine is running
whilst a bunch of phys are actually being probe/attached on each per-port
MII bus being created and probed off of the switch itself.
Until that's debugged (and likely the whole PHY management stuff is
cleaned up here), just add a NULL check and thus don't panic.
Differential Revision: https://reviews.freebsd.org/D50031
Reviewed by: imp
Although the tick isn't running every hz right now, when it /is/
running at hz, the shutdown path will race with an existing running
tick routine, causing unpredictable panics.
* Introduce a shutdown flag which will abort doing the tick work if set
* set the shutdown flag and start cancel/draining the taskqueue during
detach.
Differential Revision: https://reviews.freebsd.org/D50030
The driver sleep lock was being held during most of the error paths,
and not unlocking it will panic the kernel during detach. So, fix it.
Differential Revision: https://reviews.freebsd.org/D50029
Reviewed by: imp
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
