ixl: Add led(4) identification support
Expose each physical port identification LED through /dev/led/ixl*.
Use the existing GPIO LED helpers for most devices and the PHY
provisioning interface for X710 10GBASE-T adapters.
Preserve and restore the original GPIO or PHY indication mode,
including before the interface is stopped.
MFC after: 2 weeks
ixgbe: Add led(4) identification support
Expose the physical port identification LED through /dev/led/ix*.
Save and restore the NVM-selected LEDCTL value around each request.
The X550 operations also clear their PHY manual override before the
register is restored.
Use the dedicated firmware port-identification command on E610. Its
interface selects between firmware blinking and the original mode
rather than directly controlling LEDCTL.
Restore the normal indication before a device stop or reset.
MFC after: 2 weeks
igc: Remove invalid debug ring pointer iteration
The debug routine reads queue registers by queue index. It also
advanced unused pointers to rings embedded in queue structures. Those
pointers had the wrong stride and could proceed beyond the ring object.
Remove the unused pointer arithmetic.
MFC after: 2 weeks
e1000: Fix the multiqueue debug register dump
The debug routine advanced ring pointers as if rings were contiguous.
They are embedded in queue structures, so rings beyond queue zero had
the wrong stride. The bogus queue index could cause an invalid MMIO
read and panic the machine.
Index the queue arrays first and then select the embedded ring.
MFC after: 2 weeks
e1000: Identify SerDes adapters with LED blink
The generic LED on and off operations do not handle internal SerDes
media, leaving the led(4) device ineffective on my I210 fiber port.
Use the hardware blink operation for the on phase on internal SerDes.
The off phase restores the saved OEM LED configuration as before.
MFC after: 2 weeks
[RISCV][NFC] Move ZacasABIFix Pass Declaration
This change moves them into their own header, as has been done for the
other NewPM passes.
Assisted-by: AI
[RISCV][NFC] Move RISCVCodeGenPrepare Declarations
This change moves them into their own header, as has been done for the
other NewPM passes.
Assisted-by: AI
[RISCV] Port Gather/Scatter Lowering to NewPM (#215669)
This change also adds some missing pass dependencies to the legacy
version of the pass, to reflect some analyses that are already being
used.
Assisted-by: AI
igc: Add led(4) identification support
I225 and I226 expose three programmable LED outputs. Use LED1 for
adapter identification, following the convention in DPDK. Preserve the
OEM configuration across identification requests.
Restore the OEM configuration before a device reset so an active led(4)
pattern cannot leave the output overridden across stop or detach.
The LED mode values follow the Intel I225 Software User Manual.
MFC after: 2 weeks
[TypePromotion][RISCV][ARM] Ignore the condition operand of selects. (#215685)
We don't need to promote the condition operand in order to promote a
select. It must always be an i1 type so it doesn't matter where it comes
from.
The change to pr148084.ll is a regression, but I don't think it's
directly related to select. TypePromotion is using a zero extend
promotion which makes constants that are harder to materialize and
prevents the use of `not`. This kind of thing can happen independent of
selects being involved.
[LoongArch] Fold shifted vector extract comparisons
Fold comparisons of the form:
(shl (extract_vector_elt X, I), GRLen - EleBits) ==/!= 0
into:
(extract_vector_elt X, I) ==/!= 0
When the shift amount equals `GRLen - EleBits`, the left shift only moves
the extracted element into the most significant bits without affecting
whether the value is zero. This canonicalization exposes
EXTRACT_VECTOR_ELT to later combines and enables selecting
VPICKVE2GR_* instructions directly.
igb(4): Document identification LED device nodes
The shared em(4) manual page lists only the em device-node name.
Document the /dev/led/igb* name as well.
MFC after: 2 weeks
iflib: Create led(4) devices
When a driver implements ifdi_led_func, have the framework create its
led(4) device after attach completes and the ifnet and context locks are
released.
PR: 246885
Reported by: jlduran
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D32389
[CIR] Fix a linking problem with a abi_tag deduced lambda (#215702)
This showed up in self build, but only happens when there is a lambda
with a deduced return type inside another lambda, that returns a type
with an abi_tag on it (std::string in this case). The problem was that
we weren't pulling our mangled name out of the cache, and instead were
re-calculating it every time. This takes code effectively-exactly from
classic-codegen an d puts it into CIRGenModule.cpp
Note the teest is a little fragile for the reproducer, so it needs to be
its own file. Also, there are some parts that are not necessary in it to
reproduce (the 'i' in particular) because this avoids us having 'padded'
lambdas, which results in a call-conv NYI. I considered disabling that,
but it is more work to go back and un-do that flag later, than to just
deal with an extra 'i' for the near future.
igc: Fix KASSERT failure when `ifconfig igc%d down`
When we invoke callout_halt(9) for rxr->rx_refill, both in
igc_stop_locked() and igc_free_receive_buffers(), we don't hold
rxr->rxr_lock.
Also, `drvctl -d igc%d` does not trigger KASSERT failure now.
iflib: Defer LED control to the device taskqueue
led(4) invokes driver callbacks while holding its mutex, including
from a callout. iflib_led_func() cannot acquire the sleepable context
lock in those contexts without causing a lock-order reversal or sleeping
from the callout.
Record the latest requested state under the iflib state lock and
enqueue the existing per-device taskqueue. The task can safely take
the context lock before invoking the driver. Coalescing requests also
avoids accumulating stale blink transitions when hardware access is
slow.
Destroy the LED device before draining its task so no new callback can
race driver detach.
MFC after: 2 weeks
