Remove existing RSS HENA configuration to make sure that
only config requested by VF is applied and allow VFs to
disable RSS completely.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1573
On receiving a virtual channel request from VF driver tried
to configure and enable Tx and Rx queues without making
sure that they were disabled. It caused issue with reloading
a VF driver without a reset e.g. in case it crashed.
Fix that by always disabling all Rx and Tx queues.
While at that make sure that only queues requested by VF
driver are enabled. VF driver may use less queues than
assigned to the function when it was created.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1573
PF driver needs to tear down and setup VF configuration after
a reset event, e.g. due to reloading a VF driver. Re-use
ice_reset_vf function for that by adding new parameter,
which decides if new reset has to be triggered.
This most likely does not cover all necessary steps
and will be extended in future commits.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1573
VF driver may request to configure MSI-X vectors for less
queues than assigned by PF. Don't try to configure
unassigned vectors to avoid panic.
While at that make the loop process whole array of vectors
received in a VIRTCHNL_OP_CFG_IRQ_MAP message from a VF.
It's not guarantied that vector '0', which is used for other
interrupt causes and is not mapped to a queue, will be always
on the last position. Condition inside the loop already
handles that vector correctly.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1573
Filter for unicast MAC address is configured
with a virtual channel message, but filter for
a broadcast traffic was missing. It caused
issues with e.g. ARP.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1573
The error -1 is actually ERESTART in the context of syscall. It is for
kernel mode only and will not be passed to user mode. When the kernel
sees this error it will restart the syscall.
When the the SFP module data is not available, e.g. the SFP module is
not present, the ioctl handler returns ERESTART and kernel will retry
infinitely, hence the userland `ifconfig -v ql0` will hang forever until
get interrupted. That is apparently wrong.
Fix that by returning error ENODEV to indicate the SFP module data is
not available.
As for the case that ecore_ptt_acquire() fails, it appears to be quite
safe to restart, so keep returning ERESTART.
Reported by: Steve Wheeler
See also: https://redmine.pfsense.org/issues/16248
Reviewed by: kbowling
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D51351
Unmap the IRQ instead of just freeing the map data in the case of an
error. Also don't overwrite the resource's virtual address since the
copy of the map data made by intr_activate_irq is stored there.
Implement gpiobus_release_resource so it can unmap IRQs mapped by
gpio_alloc_intr_resource.
Reviewed by: imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D51325
The TLS RX context had the tcp sequence number of next TLS record set
in resync_tcp_sn parameter instead of in next_record_tcp_sn parameter
during hardware initialization. This prevent the hardware from
synchronizing with the TLS stream, and caused TLS offload to remain
inactive. Set next_record_tcp_sn to the next TCP sequence number and
resync_tcp_sn to zero to enable proper TLS record boundary detection
and activate hardware offload.
Reviewed by: kib, slavash
Sponsored by: NVidia networking
MFC after: 1 week
The ufshci driver tried to allocate a single 256KB segment for the UTP
command descriptor during boot, but failed due to memory fragmentation.
I fixed it to allocate the buffer in 8KB segments instead.
Sponsored by: Samsung Electronics
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D50933
We've done the same in the past to the vnconfig.8->mdconfig.8 link in:
eb5f456981 Remove ancient vnconfig symlink
Reviewed by: bcr, markj, ziaee
Approved by: markj (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D27122
Checking for __LP64__ is non-portable as it assumes that ILP32 and LP64
are the only two ABIs that exist, but CheriBSD supports an additional
ABI where long is still 64-bit but pointers are 128-bit capabilities,
and thus __LP64__ is not defined. We could change this to check the
value of __SIZEOF_LONG__, since the code here only cares about that
aspect of the ABI, however in this instance, the only real reason an
ifdef is used at all is to be able to get log2(sizeof(u_long)), but if
we instead multiply and divide rather than shift, and let the compiler
optimise that to a shift, we can just use sizeof(u_long) instead. Note
also that VMBUS_EVTFLAGS_MAX could always just have been defined as
VMBUS_EVTFLAGS_SIZE / sizeof(u_long).
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D50630
Upon collecting tls information, kernel calls driver to get driver/hw
tls state. Driver calls hw to get its tracking and authentication
states, and dump them into the driver state buffer. This requires a
sleep to wait for the hw response.
Reviewed by: kib
Sponsored by: NVidia networking
Use a timer in the nvmf(4) driver to periodically trigger a devctl
"RECONNECT" notification. A trigger in the /etc/devd/nvmf.conf file
invokes "nvmecontrol reconnect nvmeX" upon each notification. This
differs from iSCSI which uses a dedicated daemon (iscsid(8)) to wait
inside a custom ioctl for an iSCSI initiator event to occur, but I
think this design might be simpler.
Similar to nvme-cli, the interval between reconnection attempts is
specified in seconds by the --reconnect-delay argument to the connect
and reconnect commands. Note that nvme-cli uses -c for short letter
of this command, but that was already taken so nvmecontrol uses -r.
The default is 10 seconds to match Linux.
In addition, a second timeout can be used to force a full detach of a
disconnected the nvmeX device after the controller loss timeout
expires. The timeout for this is specified in seconds by the
--ctrl-loss-tmo/-l options (identical to nvme-cli). The default is
600 seconds.
Either of these timers can be disabled by setting the timer to 0. In
that case, the associated action (devctl notifications or full detach)
will not occur after a disconnect.
Note that this adds a dedicated taskqueue for nvmf tasks instead of
using taskqueue_thread as the controller loss task could deadlock
waiting for the completion of other tasks queued to taskqueue_thread.
(Specifically, tearing down the CAM SIM can trigger
destroy_dev_sched_cb() and waits for the callback to run, but the
callback is scheduled to run in a task on taskqueue_thread. Possibly,
destroy_dev_sched should be using a dedicated taskqueue.)
Reviewed by: imp (earlier version)
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D50222
The entropy queue stores entropy gathered from environmental sources.
Periodically (every 100ms currently), the random kthread will drain this
queue and mix it into the CSPRNG's entropy pool(s).
The old scheme uses a ring buffer with a mutex to serialize producers,
while the sole consumer, the random kthread, avoids using a mutex on the
basis that no serialization is needed since nothing else is updating the
consumer index. On platforms without total store ordering, however,
this isn't sufficient: when a producer inserts a queue entry and updates
`ring.in`, there is no guarantee that the consumer will see the updated
queue entry upon observing the updated producer index. That is, the
update to `ring.in` may be visible before the updated queue entry is
visible. As a result, we could end up mixing in zero'ed queue entries,
though this race is fairly unlikely in practice given how infrequently
the kthread runs.
The easiest way to fix this is to make the kthread acquire the mutex as
well, and hold it while processing queue entries. However, this might
result in a long hold time if there are many queue entries, and we
really want the hold times to be short, e.g., to avoid delaying
interrupt processing.
We could introduce a proper MPSC queue, but this is probably
overcomplicated for a consumer which runs at 10Hz.
Instead, define two buffers, always with one designated as the "active"
buffer. Producers queue entries in the active buffer, and the kthread
uses the mutex to atomically flip the two buffers, so it can process
entries from the inactive buffer without holding the mutex. This
requires more memory, but keeps mutex hold times short and lets us keep
the queue implementation very simple.
Reviewed by: cem
MFC after: 1 month
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51112
Specifying unit numbers is not needed anymore, and half of those weren't
used anymore in the first place.
Sponsored by: The FreeBSD Foundation
Reviewed by: adrian, markj, emaste
Differential Revision: https://reviews.freebsd.org/D50690
This doesn't register all MIDI devices, for example USB ones, and is not
widely used in the first place. In the future all MIDI devices will
register to sndstat, where we already have defined a MIDI device type,
but we haven't made use of it yet.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D50610
The in-kernel MIDI sequencer is not used anymore, since this is done by
userland applications nowadays. It also contains bugs, and we are not
exactly sure how it works, or if it worked properly in the first place.
Sponsored by: The FreeBSD Foundation
Reviewed by: vishwin, markj
Differential Revision: https://reviews.freebsd.org/D50605
Move functions and variables internal to gpiobus to their own header to
avoid namespace pollution and misuse.
Reviewed by: wulf, imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D50872
gpiobus_release_pin is only meant to be used internally by gpiobus. Use
gpio_pin_release instead.
This also fixes a memory leak since gpio_pin_get_by_ofw_idx returns a
malloc'd pointer, which gpio_pin_release now frees.
Reviewed by: wulf, imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D50871
gpiobus_acquire_pin is only meant to be used internally by gpiobus. Use
gpio_pin_acquire instead.
Reviewed by: manu, mmel
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D50870
In some cases, drivers may need to acquire an existing gpio_pin_t. With
the functions gpiobus currently exposes, this isn't possible as they
allocate a new pin then acquire that. Add a new gpio_pin_acquire
function which accepts an existing gpiobus_pin structure.
Reviewed by: mmel, imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D50869
It is a programming error to call this function with an invalid pin.
Also return proper error value on failure.
Suggested by: mmel
Reviewed by: imp, mmel
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D50940
Only attach gpiobus when the controller is fully initialized. Children
of gpiobus expect this to be the case.
Reviewed by: mmel, imp, andrew
Approved by: imp (mentor)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D51088
Some drivers need to postpone the attachment of gpiobus until hardware
init is done. Add a new gpiobus_add_bus function to accommodate this
case.
Suggested by: mmel, andrew
Reviewed by: mmel, imp, andrew
Approved by: imp (mentor)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D51133
In order to be able to use MODULE_DEVICE_TABLE() with multiple bus
attachments, factor out the bus-specfic MODULE_PNP_INFO() and place
it next to the structure defining the table.
As it turns out bnxt(4) has been using the MODULE_DEVICE_TABLE() with
PCI attachments for the "auxillary" bus so far. That makes little sense.
Define the MODULE_PNP_INFO() to nothing for that. We may consider
pulling these LinucKPI bits in semi-native drivers into LinuxKPI
one day as that route is not really sustainabke.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: imp, dumbbell
Differential Revision: https://reviews.freebsd.org/D51049
Such annotations are obsolete, the compiler tells us when parameters are
unused. No functional change intended.
Reviewed by: cem
MFC after: 1 week
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51114
Entropy queue entries always include the low 32 bits of a CPU cycle
count reading. Introduce a macro for this instead of hard-coding
get_cyclecount() calls everywhere; this is handy for testing purposes
since this way, random(4)'s use of the cycle counter (e.g., the number
of bits we use) can be changed in one place.
No functional change intended.
Reviewed by: cem, delphij
MFC after: 1 week
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51113
They can't be used externally, so it makes no sense to have them in a
header. No functional change intended.
Reviewed by: cem
MFC after: 1 week
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51111
