Rather than picking up Giant at the start of these sysctl handlers, push
acquiring Giant down a layer to protect walking the children and also
to add/delete children for the reconfigure.
Sponsored by: Netflix
Reviewed by: mav, jhb
Differential Revision: https://reviews.freebsd.org/D33057
Add bus_topo_assert() and implmement it as GIANT_REQUIRED for the
moment. This will allow us to change more easily to a newbus-specific
lock int he future.
Sponsored by: Netflix
Reviewed by: wulf, mav, jhb
Differential Revision: https://reviews.freebsd.org/D31833
Create a wrapper for newbus to take giant and for busses to take it too.
bus_topo_lock() should be called before interacting with newbus routines
and unlocked with bus_topo_unlock(). If you need the topology lock for
some reason, bus_topo_mtx() will provide that.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D31831
This centralizes the check for valid nonce lengths for AES-GCM.
While here, remove some duplicate checks for valid AES-GCM tag lengths
from ccp(4) and ccr(4).
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33194
(Rest is from the README that came with the firmware)
Version : 1.26.4.0
Date : 12/02/2021
Fixes
-----
BASE:
- Fixed error on setting 25G speed on 100G copper with multiple FEC set in
firmware commands.
- Handle link of unknown optics modules by enabling module tx unconditionally.
- Fixed link not coming up for 25G CRS phys. Firmware incorrectly tried to
bring up the link in RS-FEC but as per IEEE spec, it must be BASER FEC.
- Fixed an issue where firmware doesn't automatically retry next FEC if driver
asks to bring up the link using RS-FEC and link doesn't come up.
Obtained from: Chelsio Communications
MFC after: 1 month
Sponsored by: Chelsio Communications
With various firmware files used by graphics and wireless drivers
we are exceeding the current 32 character module name (file path
in kldxref) length.
In order to overcome this issue bump it to the maximum path length
for the next version.
To be able to MFC provide backward compat support for another version
of the struct as the offsets for the second half change due to the
array size increase.
MAXMODNAME being defined to MAXPATHLEN needs param.h to be
included first. With only 7 modules (or LinuxKPI module.h) not
doing that adjust them rather than including param.h in module.h [1].
Reported by: Greg V (greg unrelenting.technology)
Sponsored by: The FreeBSD Foundation
Suggested by: imp [1]
MFC after: 10 days
Reviewed by: imp (and others to different level)
Differential Revision: https://reviews.freebsd.org/D32383
The controller requires some custom logic to perform MMC tuning
and to later switch to HS400 mode. Implement it supplying mmcbr_tune
and sdhci_set_uhs_timing devmethods respectivly. Since the latter
is called unconditionally when the ios is updated we need to keep
track of the tuning state in sc and execute the HS400 switch logic
only when required.
Two HS200/HS400 related errata were implemented.
1. In HS400 modes the clock divisors are limited to 4, 8, 12.
Apply it by falling back to the closes, higher divider when needed.
2. Hardware tuning procedure can sometimes fails. If that is the case
fallback to the software tuning.
Reviewed by: manu, mw
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential revision: https://reviews.freebsd.org/D33320
As `vqmmc-supply` is an optional Device Tree property, don't skip vccq
reconfiguration when the regulator is not specified. Instead, accept
voltage specified by the `voltage-ranges` property.
The actual voltage switch is done through a hw register in LS1028A.
Add errata flag for other boards, as they are not supported. Return
not supported error code when switching to 1.8V on affected platforms.
Fixes: b08bf4c35c ("sdhci_fsl_fdt: Skip vccq reconfiguration without regulator")
Co-authored-by: Artur Rojek <ar@semihalf.com>
Reviewed by: manu, mw
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential revision: https://reviews.freebsd.org/D33319
The e1000 drivers (em, lem, igb) are currently looking at the
iflib copies of the capabilities bitvectors (scctx->isc_capabilities
and scctx->isc_capenable) rather than the ifnet ones
(ifp->if_capabilities and ifp->if_capenable). However, the latter
are the ones that are actually updated by ifconfig and that should
be used by the drivers during interface operation. The former are
set by the driver on interface attach (for iflib internal use)
and should not be used anymore by the driver.
This patch fixes the e1000 driver to use the correct bitvectors.
PR: 260068
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D33154
Some boards do not detect pulse width reliably.
Implement workaround by writing 0 to special register.
Apply errata for board by adding flag to chosen soc specific data.
Obtained from: Semihalf
Sponsored by: Alstom Group
Reviewed by: mw, manu
Differential Revision: https://reviews.freebsd.org/D33222
In theory we can have multiple concurrent accesses to the MDIO bus,
e.g. link status check tick and ifconfig request.
In that case we need to make sure that all MDIO transaction are
serialized.
Obtained from: Semihalf
Sponsored by: Alstom Group
The hash is calculated by XOR-ing together bits of the VID.
Prepend a statement with "!!" to make sure that we're get bit 0
on both sides of the equation.
Obtained from: Semihalf
Sponsored by: Alstom Group
Try to stop and destroy the dist only if the driver has been successfully
attached. Otherwise a kernel panic will be triggered from disk_destroy.
The issue was observed on a board that missed SPI clock description in DT.
Sweep over potentially unsafe calls to ifnet_byindex() and wrap them
in epoch. Most of the code touched remains unsafe, as the returned
pointer is being used after epoch exit. Mark that with a comment.
Validate the index argument inside the function, reducing argument
validation requirement from the callers and making V_if_index
private to if.c.
Reviewed by: melifaro
Differential revision: https://reviews.freebsd.org/D33263
For AHCI attached devices, we report the location and identification
information of the AHCI controller that we're attached to. We also
don't reprot link speed in that case, since we can't get to the PCIe
config space registers to find that out.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D33287
When an NVME device is attached via a AHCI controller, we have no access
to its config space. So instead of information about the nvme drive
itself, return info about the AHCI controller as the next best
thing. Since the Intel Hardware RAID support looks at these values, this
likely is best.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D33286
Add a quirk to flag AHCI attachment to the controller. This is for any
of the strategies for attaching nvme devices as children of the AHCI
device for Intel's RAID devices. This also has a side effect of cleaning
up resource allocation from failed nvme_attach calls now.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D33285
Prior to NVMe 1.3, Intel produced a series of drives that had
performance alignment data in the vendor specific space since no
standard had been defined. Move testing the versions to a quick so the
NVMe NS code doesn't know about PCI device info.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D33284
Seems like a copy-paste error, or at least this made more sense when the
sio(4) driver still existed. This modifies the debug port name displayed
at boot, but otherwise has no functional change.
Reviewed by: hselasky
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D33278
Currently the type isn't set in the fbtype struct so any userland
program that call the FBIOGTYPE ioctl will think it's a FBTYPE_SUN1BW
which is far from the truth.
No app that I found find checks the type but at least now it's correct.
Reviewed by: emaste, tsoome
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33221
6d1699583d added the FBIOGXINFO,FBIOMONINFO and FBIOPUTCMAPI/FBIOGETCMAPI
ioctls and said that implementation in driver will come later.
Since it was in 2001 I think we can remove this.
Reviewed by: emaste, imp, tsoome
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33218
Differential Revision: https://reviews.freebsd.org/D33219
Differential Revision: https://reviews.freebsd.org/D33220
The cursors related ioctls were added in 1994 with the 4.4 Lite import
but were never implemented in either sc(4), fb(4) or vt(4).
Remove it.
Reviewed by: emaste, tsoome
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33217
Commit 6d1699583d added the FBIOVERTICAL ioctl and said that implementation
in driver will come later.
Since it was in 2001 I think we can remove this.
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
The FBIOSVIDEO/FBIOGVIDEO ioctls were added in 1994 with the 4.4 Lite import
but were never implemented in either sc(4), fb(4) or vt(4).
Remove it.
Reviewed by: emaste, tsoome
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33216
The FBIOSATTR/FBIOGATTR ioctls were added in 1994 with the 4.4 Lite import
but were never implemented in either sc(4), fb(4) or vt(4).
Remove it.
Reviewed by: emaste, tsoome
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33215
Passing up such descriptors to iflib is obviously wasteful.
But the main conern is that we may overrun iri_frags array because of
them. That's been observed in practice.
Also, assert that the number of fragments / descriptors / segments is
less than IFLIB_MAX_RX_SEGS.
Reviewed by: gallatin, pkelsey
MFC after: 3 weeks
Sponsored by: Panzura LLC
Differential Revision: https://reviews.freebsd.org/D33189
According to information found on the internet the following products
use exactly the same hardware but probably different USB IDs:
- Edimax EW-7811Un V2 (v2)
- Edimax EW-7811GLN 2.0A (v2)
I am not adding them as I cannot verify.
PR: 254280
MFC after: 1 week
This is needed on my ASUS motherboard / Intel Comet Lake i5-10500
desktop machine.
This with some work arounds for nvme behind the RST controller
boots and works.
Reviewed by: cognet
