This patch adds new firmware file for Intel Bluetooth AX201
Also it is known as Intel HarrisonPeak (HrP)
FW Build: REL17535
Release Version: 22.20.0.3
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Josh Boyer <jwboyer@kernel.org>
This patch updates the firmware file for Intel Bluetooth 9560
Also it is known as Intel JeffersonPeak (JfP).
FW Build: REL17064
Release Version: 22.20.0.3
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Josh Boyer <jwboyer@kernel.org>
This patch updates the firmware file for Intel Bluetooth 9260
Also it is known as Intel ThunderPeak (THP).
FW Build: REL17064
Release Version: 22.20.0.3
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Josh Boyer <jwboyer@kernel.org>
This patch adds new firmware file for Intel Bluetooth AX210
Also it is known as Intel TyphoonPeak (TyP)
FW Build: REL15791
Release Version: 22.10.0.2
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Josh Boyer <jwboyer@kernel.org>
This patch adds new firmware file for Intel Bluetooth AX210
Also it is known as Intel TyphoonPeak (TyP)
FW Build: REL14428
Release Version: 22.00.0.0
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Josh Boyer <jwboyer@kernel.org>
Add latest verified version of Mellanox Spectrum-family switch firmware,
for Spectrum (13.2008.2018), Spectrum-2 (29.2008.2018) and Spectrum-3
(30.2008.2018).
This release fixes the following issues (among others):
- Prioritization of trapped control traffic on Spectrum-2 and Spectrum-3.
- Several edge cases where the FW could get stuck on Spectrum-2 and
Spectrum-3.
- FW flash issues on Spectrum-3
- Apparent resource exhaustion on Spectrum-3 due to wrong fencing.
- When trapping dropped packets from several TCs, they would only get
reported under one TC.
- Incorrect rejection of RIF counters with indices over 16 bits.
- An issue where port split might fail after port saw heavy traffic.
- Certain large policer CIR caused effective zero CIR.
- A race that would cause drops due to lack of buffer space.
And includes the following new features:
- Support for shared port headroom
- A new trap for L2 IPv6 DHCP traffic
- On Spectrum-2 and Spectrum-3, support ACL actions that perform ALU
operations between packet fields, immediate values and general-purpose
registers
- Early support for 8-way port split on Spectrum-3
Signed-off-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Josh Boyer <jwboyer@kernel.org>
Update AMD SEV firmware to version 0.17 build 44 for AMD family 17h
processors with models in the range 00h to 0fh.
Update AMD SEV firmware to version 0.24 build 7 for AMD family 17h
processors with models in the range 30h to 3fh.
Signed-off-by: John Allen <john.allen@amd.com>
Signed-off-by: Josh Boyer <jwboyer@kernel.org>
The vendor driver rtl8188C_8192C_usb_linux_v4.0.1_6911.20130308 includes
new firmware files. These were extracted from data statements in that
driver to form these files.
Before this update, with version 80 of the firmware, the USB interface
of the RTL8192CU WLAN controller often locked itself up:
usb 1-2: device descriptor read/64, error -110
usb 1-2: device not accepting address 4, error -110
usb 1-2: device not accepting address 5, error -110
usb usb1-port2: unable to enumerate USB device
usb 2-2: device descriptor read/64, error -110
usb 2-2: device descriptor read/64, error -110
On ARMv5 based GARDENA smart gateways running Linux 4.19.78, this can
be reliably reproduced by rebooting (warm) the gateway multiple times
(max. 50 attempts needed).
Unlike users having this issues on a USB Wi-Fi dongle, resetting of the
chip by replugging is not an option on this gateway due to the lack of
any power cut functionality. Therefore, a (cold) reboot of the whole
gateway is needed.
Updating the firmware of the RTL8192CU WLAN controller from version
v80.0 to v88.2 (as per output of rtl8xxxu) resolves this issue.
The problem did no show up anymore for 1000 restarts.
Please note:
- Only rtl8192cufw_TMSC.bin tested (mainly on rtl8xxxu)
- rtl8192cu seems to work as well as before, but I can not rule out
that this new firmware version brings unwanted changes.
The Realtek drivers containing v88.2 of the firmware
(v4.0.1_6911.20130308 to v4.0.9_25039.20171107) have some changes
compared to the version v3.4.2_3727.20120404, for which I do not know
if those should be reflected in rtl8192cu.
Unrelated of the initially described USB problem, another issue still
remains after updating the firmware: Using the rtl8192cu driver,
scanning for available SSIDs yields no more results after a few hundred
scans (iw wlan0 scan). rtl8xxxu does not suffer from this problem.
Signed-off-by: Reto Schneider <code@reto-schneider.ch>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: Chris Chiu <chiu@endlessos.org>
Signed-off-by: Josh Boyer <jwboyer@kernel.org>
Fix lps and deep ps mode issues.
Add fw feature information for driver.
v2: fix wrong wow firmware, which was the same as the normal firmware
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Josh Boyer <jwboyer@kernel.org>
Current ti-connectivity location for the firmware is not the
correct place. It has all the wireless connectivity related firmwares.
Move the vpdma firmware to the ti specific directory.
Fixes: 5b30b383ce ("linux-firmware: Add new VPDMA firmware 1b8.bin")
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Josh Boyer <jwboyer@kernel.org>
Fix lps and deep ps mode issues.
Add fw feature information for driver.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Josh Boyer <jwboyer@kernel.org>
Brcmfmac driver has firmware files coming from both Broadcom and
Cypress, the former Broadcom IoT BU. To better maintain files from
different sources, add a cypress folder and firmware/clm_blob files for
below chips:
- 43012
- 43340
- 43362
- 4339
- 43430
- 43455
- 4354
- 4356
- 43570
- 4373
- 54591
The clm_blob files are on a generic world-wide safe version with
conservative power settings which is designed to comply with regulatory
but may not provide best performance on all boards. Users should use the
clm_blob files from their board vendors if available.
Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: Josh Boyer <jwboyer@kernel.org>
Kiran K