MFC r342682:rtwn_pci(4): add support for RTL8188EE chipset.Initially based on https://reviews.freebsd.org/D15692;later deduplicated and improved a bit (Tx reports, IQ calibration support).Submi
MFC r342682:rtwn_pci(4): add support for RTL8188EE chipset.Initially based on https://reviews.freebsd.org/D15692;later deduplicated and improved a bit (Tx reports, IQ calibration support).Submitted by: Farhan Khan <[email protected]>Relnotes: yesDifferential Revision: https://reviews.freebsd.org/D15692
show more ...
MFC: r340090, r342056Merge ACPICA 20181031 and 20181213.
Update ACPICA to 20181003.Approved by: re (gjb)
Revert drm2 removal.Revert r338177, r338176, r338175, r338174, r338172After long consultations with re@, core members and mmacy, revertthese changes. Followup changes will be made to mark them a
Revert drm2 removal.Revert r338177, r338176, r338175, r338174, r338172After long consultations with re@, core members and mmacy, revertthese changes. Followup changes will be made to mark them asdeprecated and prent a message about where to find the up-to-datedriver. Followup commits will be made to make this clear in theinstaller. Followup commits to reduce POLA in ways we're stillexploring.It's anticipated that after the freeze, this will be removed in13-current (with the residual of the drm2 code copied tosys/arm/dev/drm2 for the TEGRA port's use w/o the intel orradeon drivers).Due to the impending freeze, there was no formal core vote forthis. I've been talking to different core members all day, as well asMatt Macey and Glen Barber. Nobody is completely happy, all aregrudgingly going along with this. Work is in progress to mitigatethe negative effects as much as possible.Requested by: re@ (gjb, rgrimes)
r338172 follow - remove firmwares
Merge ACPICA 20180810.
MFV: r335802Merge ACPICA 20180629.
[ath_hal] Return failure if noise floor calibration fails.If we fail noise floor calibration then we may end up with a deaf NICwhich we can't recover without a full chip reset.Earlier chips seem
[ath_hal] Return failure if noise floor calibration fails.If we fail noise floor calibration then we may end up with a deaf NICwhich we can't recover without a full chip reset.Earlier chips seem to get less stuck in this condition versus AR9280/laterand AR9300/later, but whilst here just fix up the AR5212 era chips to alsoreturn NF calibration failures.This HAL routine would only return failure if the channel was not configured.This is a no-op until the driver side code for doing resets and the HALcode for being told about the reset type (and then handling it!) isimplemented.Tested:* AR9280, STA mode* AR2425, STA mode* AR9380, STA mode
MFV: r334448Import ACPICA 20180531.
[ath_hal] migrate the shared HAL_RESET_* pieces out into ath_hal.I'm in the process of reworking how the reset path works with an eyeto better recovery when the chips hang and/or go RF/PHY deaf.T
[ath_hal] migrate the shared HAL_RESET_* pieces out into ath_hal.I'm in the process of reworking how the reset path works with an eyeto better recovery when the chips hang and/or go RF/PHY deaf.This is the first step in a lot of unification and API changes.
Quiesce a couple pages of clang warnings with a cast. Duplicateslinux maintainer commit:https://github.com/torvalds/linux/commit/627871b71c89a6ec12fbed75063f238e0c7127b2#diff-8c6ddb4c3ad69a6fb9f2
Quiesce a couple pages of clang warnings with a cast. Duplicateslinux maintainer commit:https://github.com/torvalds/linux/commit/627871b71c89a6ec12fbed75063f238e0c7127b2#diff-8c6ddb4c3ad69a6fb9f289475821db56ar9300template_aphrodite.h:575:40: warning: implicit conversion from 'int' to 'u_int8_t' (aka 'unsigned char') changes value from 3495 to 167 [-Wconstant-conversion] /* Data[8].ctl_edges[7].bChannel*/FREQ2FBIN(5795, 0)} ^~~~~~~~~~~~~~~~~~ar9300eep.h:142:41: note: expanded from macro 'FREQ2FBIN' (((y) == HAL_FREQ_BAND_2GHZ) ? ((x) - 2300) : (((x) - 4800) / 5))Reviewed by: impMFC after: 1 weekDifferential Revision: https://reviews.freebsd.org/D15476
MFV: r333378Import ACPICA 20180508.
MFV: r333077Merge ACPICA 20180427.
[iwm] Add support for iwm 3168 cards```iwm0@pci0:5:0:0: class=0x028000 card=0x21108086 chip=0x24fb8086rev=0x10 hdr=0x00vendor = 'Intel Corporation'device = 'Dual Band Wireless-AC
[iwm] Add support for iwm 3168 cards```iwm0@pci0:5:0:0: class=0x028000 card=0x21108086 chip=0x24fb8086rev=0x10 hdr=0x00vendor = 'Intel Corporation'device = 'Dual Band Wireless-AC 3168NGW [Stone Peak]'class = network[94829] iwm0: <Intel(R) Dual Band Wireless AC 3168> mem0xef700000-0xef701fff at device 0.0 on pci5[94829] iwm0: hw rev 0x220, fw ver 22.361476.0, address28:c6:3f:15:43:c5```MFC After: 2 weeksReviewed by: ivadasz (over IRC)PR: 224886Differential Revision: https://reviews.freebsd.org/D14865
Merge ACPICA 20180313.
Move the new AMD-Vi IVHD [ACPI_IVRS_HARDWARE_NEW]definitions added in r329360 in contrib ACPI to local files till ACPI code adds new definitions reported by jkim.Rename ACPI_IVRS_HARDWARE_NEW to ACP
Move the new AMD-Vi IVHD [ACPI_IVRS_HARDWARE_NEW]definitions added in r329360 in contrib ACPI to local files till ACPI code adds new definitions reported by jkim.Rename ACPI_IVRS_HARDWARE_NEW to ACPI_IVRS_HARDWARE_EFRSUP, since new definitions add Extended Feature Register support. Use IvrsType to distinguish three types of IVHD - 0x10(legacy), 0x11 and 0x40(with EFR). IVHD 0x40 is also called mixed type since it supports HID device entries.Fix 2 coverity bugs reported by cem.Reported by:jkim, cemApproved by:grehanDifferential Revision://reviews.freebsd.org/D14501
This change fixes duplicate detection of same IOMMU/AMD-Vi device for Ryzen with EFR support.IVRS can have entry of type legacy and non-legacy present at same time for same AMD-Vi device. ivhd driv
This change fixes duplicate detection of same IOMMU/AMD-Vi device for Ryzen with EFR support.IVRS can have entry of type legacy and non-legacy present at same time for same AMD-Vi device. ivhd driver will ignore legacy if new IVHD type is present as specified in AMD-Vi specification. Earlier both of IVHD entries used and two ivhd devices were created.Add support for new IVHD type 0x11 and 0x40 in ACPI. Create new struct of type acpi_ivrs_hardware_new for these new type of IVHDs. Legacy type 0x10 will continue to use acpi_ivrs_hardware.Reviewed by: avgApproved by: grehanDifferential Revision:https://reviews.freebsd.org/D13160
MFV: r329072Merge ACPICA 20180209.
Fix a header inclusion missed in the previous commit.Reported by: Michael Butler (imb at protected-networks dot net)
Merge ACPICA 20180105.
MFC: r326864Merge ACPICA 20171214.
Switch the default firmware for npe(4) from the QOS_VLAN one to theplain-vanilla ETH microcode. The QOS_VLAN firmware added support in microcodefor handling IEEE 802.1q tags, but the npe(4) driver
Switch the default firmware for npe(4) from the QOS_VLAN one to theplain-vanilla ETH microcode. The QOS_VLAN firmware added support in microcodefor handling IEEE 802.1q tags, but the npe(4) driver did not actuallysupport the relevant signalling. As a result, it was impossible to useVLANs with npe(4). Switching to the more basic microcode (same license)removes the on-NIC promisisng and makes vlan(4) work on both NPE interfaces.Ref: https://lists.freebsd.org/pipermail/freebsd-arm/2012-August/003826.html
Move sys/boot to stand. Fix all references to new locationSponsored by: Netflix
MFV: r325668Merge ACPICA 20171110.
Merge ACPICA 20170929 (take 2).
12345678