e6000sw_write_xmdio() loaded the Clause 45 register address into the
SMI PHY data register a second time, where the value to write belongs,
so every Clause 45 write stored the register address.
Its only caller, e6000sw_serdes_power(), runs at attach for ports 9 and
10 of the 88E6190 and 88E6190X to power one SERDES interface up and the
other down. It wrote 0x2000 to the SGMII control register and 0x1000
to the 10GBASE-R PCS control register instead, so neither interface was
powered down and the rest of each register was overwritten.
Fixes: 9aba06377d ("Add support for the Marvell 88E6190 11 ports switch.")
Sponsored by: Rubicon Communications, LLC ("Netgate")
The need for a separate map for TSO and non-TSO seems to have arisen from
a misunderstanding about the DMA requirements for Intel drivers like
ice/ixl/iavf. Specifically, this Intel hardware has a quirk where no
more than N (=8) segs can be DMA'ed per packet on the wire. This limit
was enforced using a DMA map with a low segment limit for non-TSO and a
driver specific check for TSO. This led to a *lot* of complexity in
iflib (~80 extra lines of code that this change removes) when the
limit can simply be enforced via the existing EFBIG mechanisms.
This change adds a new flag, IFLIB_SPARSE_TX, that drivers for hardware
with this quirk must set. When set, it causes non-TSO sends that
exceed isc_tx_nsegment to be treated as if bus_dmamap_load_mbuf_sg()
had returned EFBIG.
Due to the API/KABI change, I've bumped the FreeBSD version as well.
Note kgalazka suggested the flag, rather than a more awkward
mechanism that I had in my initial patch.
Reviewed by: kbowling
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D60175
In _thr_once, if init_routine fails with exception, the stack allocate
__cup will become invalid when unwinder walk back and free the stack of
thr_once. This cause cleanup linked list be dangling. In here, we give
the cleanup function a landing pad so that we td can correctly point
to previous cleanup function.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D61212
_thr_check_init() is called on hot paths such as pthread_once(), and
the uninitialized case can only happen once. Mark it with
__predict_false so the compiler lays out the initialized case as the
fall-through path.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D61213
The tool is useful for probing any SDIO card, not only the BCM4330. Print the chip ID, report a failed backplane read, and only note when the ID is not the expected REPLY_MAGIC instead of exiting.
Differential Revision: https://reviews.freebsd.org/D61030
Use (void) instead of an empty parameter list, as required by style(9), and let the compiler diagnose calls with unexpected arguments.
Reviewed by: oh
Differential Revision: https://reviews.freebsd.org/D61029
The -f option was parsed but never used. Its argument handling was also broken: getopt(3) binds the argument to the last option letter, so "fu:" made -f take no argument at all. Remove it.
Reviewed by: oh
Differential Revision: https://reviews.freebsd.org/D61028
linux_compat.h redefined bool as int8_t, overriding the _Bool definition provided by sys/types.h. This changes the size and semantics of bool and conflicts with headers that include stdbool.h, such as cam/cam.h. Rely on the system definition instead.
Reviewed by: oh
Differential Revision: https://reviews.freebsd.org/D61027
sdio_write_1() passed 0 as the write flag to sdio_rw_direct(), so every write was performed as a read and the value was never sent to the card. Pass 1 so that the data is actually written.
Reviewed by: oh
Differential Revision: https://reviews.freebsd.org/D61026
The mmc(4) stack waits after powering up a card: mmc_power_up() waits 1 ms
after the supplies are on and 2 ms after the clock is running, before the
first command is sent. The MMCCAM probe had no such wait: it went from the
power_up request to the power_on request to CMD0 without any delay.
Some devices do not answer the first commands if they are sent too early and
then never enumerate, with no error. On a RockPro64 the Broadcom SDIO Wi-Fi
(BCM4359) was not detected on any of 8 boots without a delay. It was
detected on 8 out of 8 with the same waits as mmc_power_up() added to the
probe.
Add the same two waits, once the power_up request and once the power_on
request are done. This replaces the delay that was in mmc_fdt_set_power(),
which was a fixed 10 ms for FDT hosts only; the waits of the legacy stack are
enough and apply to every MMCCAM host.
MFC after: 1 week
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D61077
set_power() enabled the ext_clock on power-on and called clk_stop() on
power-off. This was wrong in three ways:
- clk_stop() is not the counterpart of clk_enable() (it KASSERTs
enable_cnt == 0), so it panics once the clock has been enabled.
- set_power() is driven by the MMC power_mode IOS and is called
repeatedly for the same state during probing and tuning, so the
enable/disable refcount over- or underflows and panics.
- The ext_clock may be a shared PMIC output (e.g. rk808-clkout2 on the
RockPro64, also feeding the companion Bluetooth controller), so gating
it here disturbs the other consumers.
The external clock is a free-running low-power oscillator the device
needs for its whole lifetime, so enable it once at attach and leave it
running. Only act on real power-mode transitions in set_power() and
limit it to driving the reset line, which is what actually sequences the
device.
Tested on a RockPro64 (Broadcom BCM4359 SDIO Wi-Fi): the SDIO function
now enumerates and the module is reachable from userspace.
MFC after: 1 week
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D61023
cam_periph_mapmem() and cam_periph_unmapmem() map the user-provided
struct mmc_data for XPT_MMC_IO CCBs, but use sizeof(struct mmc_data *)
instead of sizeof(struct mmc_data) as the length. Only the pages
covering a pointer are mapped, so accessing a field past the first
pointer-sized region (for instance cmd->data->flags) faults if the
structure happens to straddle a page boundary and the following page is
not mapped.
The failure is intermittent because it depends on where the caller places
the struct mmc_data. Issuing a CMD53 CCB through pass(4) to an MMCCAM
SDIO card whose struct mmc_data lands at the end of a page panics with
"data abort in critical section or under mutex" in the host driver.
Map the whole structure in both the map and unmap paths.
MFC after: 1 week
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D61022
XPT_MMC_IO maps two nested buffers: cmd.data, then cmd.data->data whose
address is derived from cmd.data. cam_periph_unmapmem() restored them in
forward order, so it put cmd.data back to its userspace value and then
dereferenced that pointer to reach cmd.data->data from kernel context,
panicking in vm_fault_lookup().
Unmap in reverse order, mirroring how the mappings were created. This is
a no-op for single-buffer func_codes and for the other two-buffer cases
(XPT_DEV_MATCH, XPT_SMP_IO), whose buffers are independent.
The bug is only reachable via the pass(4) userspace path, which maps and
unmaps CCB buffers; in-kernel MMCCAM consumers never call
cam_periph_{map,unmap}mem(). Triggered by a userspace SDIO CMD53
transfer from sdiotool(8) through pass(4).
MFC after: 1 week
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D61021
Only XPT_MMC_SET_TRAN_SETTINGS was handed to the slot taskqueue.
XPT_SET_TRAN_SETTINGS, which mmc_xpt.c issues too, still called
sdhci_cam_settran_settings() directly from the CAM done thread with the
CAM device lock held. Changing the bus clock can sleep (clk_set_freq()
takes the clock topology sx lock), which panics with "sleeping thread
holds CAM device lock".
Handle both opcodes the same way and complete the request from the
taskqueue.
Differential Revision: https://reviews.freebsd.org/D61013
sdhci_set_clock() compared the requested clock with slot->clock, which holds
the rate that the host driver actually applied. Some drivers do not apply
the requested rate: the RK3568 one maps the 400kHz identification frequency
to 375kHz. The two values then never match and every update_ios call goes
through SDHCI_SET_CLOCK() again, even when the clock did not change.
That ends in clk_set_freq(), which takes a sleepable lock, from the done
context of the mmc probe with the CAM locks held. With another thread
holding the clock topology lock this panics with "sleeping thread holds CAM
device lock".
Remember the last requested clock in a new field and compare against it.
Clear it wherever slot->clock is cleared so that a reset still forces an
update.
Tested on a Quartz64 Model A with an NVMe drive on the PCIe slot, where the
panic was seen: 5 cold boots out of 5 attached everything.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D61012
The divider of the controller is not functional on Rockchip, the card clock
is the rate of the core clock. Request the core clock rounded down so that
the closest available rate is selected and report a failure, which was
ignored before. The eMMC was identified at the wrong clock and was never
detected.
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D60893
The eMMC core clock is a mux without a divider, whose parents provide the
375kHz clock for card identification and the 24MHz to 200MHz clocks for the
other modes. Use RK_CLK_MUX_ROUND_PARENT so that the host driver can change
the card clock, which could not be done before.
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D60892
The sdmmc clocks are muxes without a divider, whose parents provide the
750kHz clock for card identification and the 50MHz and 100MHz clocks for
the bus. Use RK_CLK_MUX_ROUND_PARENT so that the host driver can change the
card clock, which used to fail with EBUSY and left the SD cards at half
speed.
Differential Revision: https://reviews.freebsd.org/D60891
Add RK_CLK_MUX_ROUND_PARENT for muxes whose parents are fixed rate clocks
that can be shared with other consumers. When a rate is requested, pick
the parent with the rate that best fits the rounding flags and never change
the rate of a parent. Without it the request is passed up to the shared
parents, which refuse to change.
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D60890
Pin the xin clock to 200MHz, use the generic UHS timing and tuning
methods, parse the eMMC properties and the vqmmc supply from the device
tree, and set the I/O voltage through the regulator framework instead of
the S18 bit. Limit the RockPro64 to 100MHz.
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D60889
Add the tuning procedure (CMD21 with the standard JEDEC tuning block
patterns), the 1.2V/1.8V/3.3V signaling voltage switch using voltage
bands, a watchdog for stuck requests, controller recovery and DMA fixes
needed to run HS200 reliably.
For the Rockchip glue, implement the tuning hook by sweeping the sample
clock phase over 360 degrees, picking the middle of the widest good window
and restoring the previous phase on failure. The drive phase is set to
180 degrees.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D60888
Describe the SDMMC, SDIO, EMMC and their sample/drive phase clocks so that
host drivers can tune them.
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D60887
Allow HS200 tuning only above 100MHz timings, let the host driver keep a
fixed maximum clock, and stop clearing max_clk in the generic FDT attach so
that a controller driver can set it before attach.
Differential Revision: https://reviews.freebsd.org/D60885
Switch eMMC cards to HS200 when both the card and the host support it,
falling back to high speed on failure. Bus settings changes now wait for
the SIM to complete, which runs from its own taskqueue. Also fix a race
where a new request could be lost when the SIM task cleared the current
request after completing it, and fail bios queued for a partition whose
switch failed.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D60884
cmd_pmc_stat allocated the event descriptor with malloc and then set
only some of its fields, so the rest held whatever was on the heap.
Use calloc() instead.
Reviewed by: mhorne
MFC after: 3 days
Sponsored by: AMD
Signed-off-by: Andre Silva <[email protected]>
Differential Revision: https://reviews.freebsd.org/D59364
The PerfMonV2 start and stop methods set the core enable bit on UMC
counters too, so UMC events never count. Use the UMC enable bit, as
the legacy methods do.
Reviewed by: mhorne, Ali Mashtizadeh <[email protected]>
Fixes: 9d30640105 ("hwpmc_amd: add PerfMonV2 global-control path")
Sponsored by: AMD
Signed-off-by: Osvaldo Janeri Filho <[email protected]>
Differential Revision: https://reviews.freebsd.org/D60770
An Intel display-audio codec was observed to remain in D3 after monitor
sleep on DragonFly BSD. Starting a new stream then produced no sound,
and waking the codec alone left the output pin amplifier muted and other
function configuration unrestored.
Read the audio function power state at stream start. If its requested or
actual state is not D0, use the existing power-up routine before
configuring and starting the stream, then restore the function to a
known state:
Restore selectors, pins, EAPD, GPIO/GPO and direct codec patches, then
replay the cached gain and mute values once the pins are configured.
Split widget configuration out of hdaa_audio_commit() into
hdaa_audio_widget_commit() so the wake path can reuse it without
reinitializing the cached amplifier values. Preserve the existing
volume, mute and forced-mute values.
Re-enable unsolicited responses, refresh ELD, and run jack presence
handling for playback pins. Skip the full presence handler for recording
pins only: its recording path can drop the driver lock to update the
recording source, which is not safe while starting a stream with the
channel lock held. The playback path does not drop the driver lock, so
it is safe to run here, and it is what matters for display audio, whose
pins belong to playback associations.
GET_POWER_STATE reports the actual state in ACT (bits 7:4) and the
requested state in SET (bits 3:0). They can differ during a transition.
Checking both avoids skipping the D0 request when the function is still
actually in D0 but has been requested to power down, or when D0 has been
requested but the actual state has not reached D0 yet. The observed
post-sleep response on DragonFly was 0x233, with both fields reporting
D3.
Despite their names, HDAA_AMP_MUTE_DEFAULT (0xffffffff) and
HDAA_AMP_VOL_DEFAULT (-1) are sentinels meaning "keep the cached
setting" in hdaa_audio_ctl_amp_set(). Passing them leaves ctl->muted,
ctl->left and ctl->right unchanged, then writes the cached values to the
hardware while respecting ctl->forcemute. It does not select factory
defaults or unconditionally unmute the output.
Preserve the existing behavior when the power-state query returns
HDA_INVALID or both fields already report D0, and leave the D0 fast path
and invalid power-state query handling unchanged.
The observed wake-only silence and amplifier recovery were seen on
DragonFly BSD. This FreeBSD adaptation has not been validated on FreeBSD
hardware.
PR: 299139
MFC after: 2 weeks
Reviewed by: christos
Pull-Request: https://github.com/freebsd/freebsd-src/pull/2464
Removed ABS_SET, BSS_SET, and SET_ENTRY. They were initially
introduced in v1.1 to be used with a.out file. After the migration
to ELFs they are equivalent to TEXT_SET and DATA_SET.
Furthermore, these macros are never used in the src tree.
Event: Oslo Hackathon 2026
Reviewed by: des, jhb
Differential Revision: https://reviews.freebsd.org/D61035
378e0c5c89 reduced the number of playback channels from 5 to 1. This
introduced a regression, because the global DMA buffer indexing was not
adapted accordingly, which now results in kernel panics because of
out-of-bounds reads into the buffer. Additionally, because of wrong
indexing, recording channels ended up being serviced by the playback
part of envy24ht_intr().
Register 1 recording channel instead of 2 + sc->adcn, as the recording
DMA buffer only has room for 1 stereo stream. With 1 channel per
direction, give each channel the first index of its direction
(ENVY24HT_CHAN_PLAY_DAC1 and ENVY24HT_CHAN_REC_ADC1).
While here, fix the buffer wrap in envy24ht_r16sl(). It has to be
ch->size / ch->unit, but was copied verbatim from the 32-bit equivalent,
whose samples are twice as large, so 16-bit recording wrapped halfway
through the DMA buffer and never read the second half.
Fixes: 378e0c5c89
PR: 299952
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D61155
For a pshare key, we can actually cache the last one as a fast path
instead of trapping into kernel directly. It makes sense as a lock and
unlock should be a pair on the same key and at the same time. For
example, lock(A) -> unlock(A) -> lock(B) -> unlock(B). Each unlock is
a hit and refresh later (50% hit).
For a single pshare lock, it is evne a 100% hit as the key never
changed.
For nested lock lock(A) -> lock(B) -> lock(C) -> unlock(C) ->
unlock(B) -> unlock(A). It only cache the last one. However, we should
really think about rewritting this logic as it is a pshare lock shared
by many processes and nested should be uncommon.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D60957
Currently, gve_rx_alloc_ring_dqo() and gve_tx_alloc_ring_dqo() request
CACHE_LINE_SIZE alignment when allocating DMA memory for the DQO TX/RX
descriptor and completion rings. The device requires stronger alignment
than cache line alignment, which was incidentally being met due to how
the kernel allocates memory. Explicitly meet this requirement by
requesting page aligned memory.
Signed-off-by: Tim Hostetler <[email protected]>
Reviewed by: markj, Jasper Tran O'Leary <[email protected]>
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D61211
In gve_verify_driver_compatibility(), the driver populates the
gve_driver_info buffer for the device to read. Sync this buffer with
BUS_DMASYNC_PREWRITE instead of BUS_DMASYNC_PREREAD before issuing
the command.
In gve_adminq_describe_device(), the device populates the
gve_device_descriptor buffer for the driver to read. Sync this buffer
with BUS_DMASYNC_PREREAD instead of BUS_DMASYNC_PREWRITE before
issuing the command.
In gve_adminq_get_ptype_map_dqo(), the device populates the
gve_ptype_map buffer for the driver to read. Add the missing
BUS_DMASYNC_PREREAD and BUS_DMASYNC_POSTREAD syncs around the
command.
In normal GCP environments this did not cause a functional failure
because the underlying platforms are DMA cache-coherent and
bus_dmamap_sync() inside gve_adminq_issue_cmd() still provided a
memory barrier before ringing the AdminQ doorbell. However, if bounce
buffers are used, the wrong or missing sync directions would cause the
OS to skip copying between the driver buffer and the bounce buffer in
the expected direction.
Signed-off-by: Tim Hostetler <[email protected]>
Reviewed by: markj, Jasper Tran O'Leary <[email protected]>
Fixes: 54dfc97b0b ("Add gve, the driver for Google Virtual NIC (gVNIC)")
Fixes: d438b4ef0c ("gve: Add DQO RDA support")
Differential Revision: https://reviews.freebsd.org/D61172
Sprinkle it in various drivers which hard-coded the command layout.
No functional change intended.
Reviewed by: dumbbell, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D61045
For 2027 we need to support new, stronger signatures and hashes.
Re-work Makefile.inc and local.trust.mk to define
VE_SIGN_URL_LIST or VE_SIGNATURE_LIST (can be derrived from
VE_SIGN_URL_LIST) containing tuples of sig/method/hash/flags and
for VE_SIGN_URL_LIST the same plus /url.
From VE_SIGNATURE_LIST we derrive VE_SIGNATURE_EXT_LIST used to populate
signature_ext_list which defines the order in which we look for
signatures for a manifest.
We also populate signature_info_list which maps a signature ext to the
needed hash and flags to indicate whether that hash needs to be repeated.
verify_sig will lookup signature_info_list, no match means not
supported. For asc we just call verify_asc() otherwise we call
verify_ec() or verify_rsa() depending on the key type found in the
certificate chain, we pass the signature_info entry to these so they
know which hash to use and whether to repeat it.
The need to repeat the hash is a consequence of sending a hash to a
server using signature methods that insiste on hashing their input.
To-date only our original ECDSA signatures use this.
A FakeHash class added in 2012 avoids that wrinkle.
This is a much more flexible arrangement and should be more
readily usable by others.
Sponsored by: Hewlett Packard Enterprise Development LP.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D61007
Linux drivers find their MSI and MSI-X registers through pdev->msi_cap and
pdev->msix_cap, which hold where those capabilities start in PCI config
space. LinuxKPI never set them, so they stayed 0, and every access meant
for the MSI registers went to the start of config space instead.
Drivers using these fields, e.g. ath11k and amdgpu, are affected.
Fill in both fields from the capability offsets that the native PCI code
already records.
Reviewed by: dumbbell
Differential Revision: https://reviews.freebsd.org/D61125
Event: NetApp/Vendor Summit Hackathon 202611
These were removed by upstream long ago. Nothing in the
tree uses them. Remove them to reduce our diff to upstream.
Reviewed by: carlavilla, wosch
Reported by: Ingo Schwarze <[email protected]>
Differential Revision: https://reviews.freebsd.org/D61198
Most of our drivers setup interrupt(s) and virtqueues are enabled at
that time, but nothing will currently enable them for devices that we're
only going to poll. This most notably affects virtio-random, and the
problem can be observed with qemu's q35 emulation and a random device
attached. The q35 implementation ignores the ring unless it's enabled,
so vtrnd_harvest() will consistently EAGAIN rather than contribute
anything of value, but with this patch it becomes functional.
This can be reproduced with a qemu invocation like so:
qemu-system-x86_64 -machine q35,accel=tcg -cpu max -smp 2 -m 2G \
-drive file=FreeBSD-16.0-CURRENT-amd64-ufs.qcow2,if=virtio \
-device pcie-root-port,id=rp1,bus=pcie.0,chassis=1 \
-object rng-random,id=rng0,filename=/dev/urandom \
-device virtio-rng-pci,rng=rng0,bus=rp1 \
-display curses
Reviewed by: bnovkov, kfv
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D61052
If the device is hung, then polling will block the detach and hang us.
Stop it and drain the queue instead. This fixes a hang on detach in
some circumstances without the upcoming virtio_pci_modern fix.
Reviewed by: bnovkov, kfv
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D61051
On the off chance that we discover more than one virtio-random device,
the second one will deregister the global instance or trip an invariant
when it fails to attach and calls vtrnd_detach().
We don't have that many resources to free, so just inline those. This
is purely a hygiene thing, we haven't seen an instance of this in the
wild (to my knowledge).
Reviewed by: bnovkov, kfv
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D61050
The write reduction code was broken in a few ways:
- It didn't handle non-zero b_dirtyoff.
- It didn't advance the uiop fields such that they could be
backed up for a retry.
- It didn't handle the rare retry case with a partially
written buffer.
This patch fixes the above and now write reduction seems
to be working ok.
MFC after: 1 month
Fixes: 884ee8d6c9 ("nfscl: Add some glue for client side NFS over RDMA")
Include the command code in notification failures and the command code
and execution timeout in completion failures. Capture CRB control
registers on completion timeouts and Pluton mailbox readiness or
acknowledgement timeouts, before cancellation or cleanup changes them.
Include locality registers when present and mailbox registers for the
Pluton start method. The dump contains transport state without command
payloads or response data.
Tested by: olivier, tuexen
MFC after: 2 weeks
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D61128
Pluton's REPLY register indicates readiness for a new notification, not
completion of the notification just sent. Wait for REPLY=1 before
ringing the mailbox, then wait for START=0 when a synchronous state
change needs acknowledgement.
Use a separate command notification callback that waits for mailbox
readiness but leaves command completion to the existing CRB_CTRL_START
polling. Bound readiness waits by TPM_TIMEOUT_C, including asynchronous
idle notifications, while retaining the command's execution timeout.
This resolves reported command timeouts on a Framework AMD laptop.
Tested by: olivier, tuexen
MFC after: 2 weeks
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D61128
When VBE is unavailable, vbe_init() frees the controller information
buffer and sets vbe to NULL. Console initialization still calls
vbe_default_mode(), which reaches an unguarded memset() in
vbe_find_mode_xydm(). Under BTX, the null write can overwrite the
loader's own code and cause a later protection fault.
Guard vbe_default_mode() with vbe_check(), as the other public
functions in vbe.c already do, and return 0 to indicate that no
graphics mode is available. This allows console initialization to
continue on headless systems.
Reviewed by: rmoeller, imp
MFC ater: 2 weeks
Differential Revision: https://reviews.freebsd.org/D61145
DH89xxCC shares the 82580 MAC type but reserves several of its memory
error control and status registers. Accessing the full 82580 register
set breaks normal RX/TX operation on affected adapters.
Give DH89xxCC separate configuration, accounting, and recovery paths.
Use its transmit packet-buffer ECC counter and DMA/LAN parity status
with device-specific masks, avoiding the reserved receive-buffer ECC
and PCIe error registers. Retain the port-reset sequence for fatal
memory-error recovery without waiting for the absent STATUS.RST_DONE.
Tested by: chuck2k (https://github.com/opnsense/src/issues/329)
Fixes: 915c628c4f ("igb: Report 82580 memory ECC errors")
MFC after: 1 day
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D61138
Prior to change 477c594d90, the struct kobj_class has six members but
the DEFINE_CLASS_[0..3] only initialize the first four of them. The
change 477c594d90 intends to initialize the two new members but
actually acts on the wrong ones.
```
error: initialization of pointer of type 'kobj_ops_t' (aka 'struct kobj_ops *') to null from a
constant boolean expression [-Werror,-Wbool-conversion]
```
Fix by initializing the two new members implicitly.
Reported by: clang (-std=gnu23 -Wbool-conversion)
Reviewed by: mmel, kib
Fixes: 477c594d90 kobj: allow multiple inheritance with per-class softc
MFC with: 477c594d90
Differential Revision: https://reviews.freebsd.org/D61173
R. Christian McDonald