Within newly launched Realtek RTL8851BE WiFi 6 802.11ax PCIe Adapter,
0x8150 is chosen as usb idProduct, which is already registered for
RTL8150 Fast Ethernet Adapter. The rtl8150 driver may be loaded before
rtw89 does, trying to initialize a RTL8851BE as a RTL8150.
Bus 001 Device 002: ID 0bda:8150 Realtek Semiconductor Corp. RTL8150
Fast Ethernet Adapter
Device Descriptor:
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
idVendor 0x0bda Realtek Semiconductor Corp.
idProduct 0x8150 RTL8150 Fast Ethernet Adapter
bcdDevice 1.00
...
Interface Descriptor: bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 255
Bus 001 Device 005: ID 0bda:8150 Realtek Semiconductor Corp. RTL8150
Fast Ethernet Adapter
Device Descriptor:
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
idVendor 0x0bda Realtek Semiconductor Corp.
idProduct 0x8150 RTL8150 Fast Ethernet Adapter
bcdDevice 0.00
...
Interface Descriptor: bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth
This change adds an additional match for RTL8150, so that it won't match
RTL8851BE anymore.
Signed-off-by: You-Sheng Yang <email address hidden>
40613da52b13 ("PCI: acpiphp: Reassign resources on bridge if necessary")
changed acpiphp hotplug to use pci_assign_unassigned_bridge_resources()
which depends on bridge being available, however enable_slot() can be
called without bridge associated:
1. Legitimate case of hotplug on root bus (widely used in virt world)
2. A (misbehaving) firmware, that sends ACPI Bus Check notifications to
non existing root ports (Dell Inspiron 7352/0W6WV0), which end up at
enable_slot(..., bridge = 0) where bus has no bridge assigned to it.
acpihp doesn't know that it's a bridge, and bus specific 'PCI
subsystem' can't augment ACPI context with bridge information since
the PCI device to get this data from is/was not available.
Issue is easy to reproduce with QEMU's 'pc' machine, which supports PCI
hotplug on hostbridge slots. To reproduce, boot kernel at commit
40613da52b13 in VM started with following CLI (assuming guest root fs is
installed on sda1 partition):
The issue was discovered on Dell Inspiron 7352/0W6WV0 laptop with following
sequence:
1. Suspend to RAM
2. Wake up with the same backtrace being observed:
3. 2nd suspend to RAM attempt makes laptop freeze
Fix it by using __pci_bus_assign_resources() instead of
pci_assign_unassigned_bridge_resources() as we used to do, but only in case
when bus doesn't have a bridge associated (to cover for the case of ACPI
event on hostbridge or non existing root port).
That lets us keep hotplug on root bus working like it used to and at the
same time keeps resource reassignment usable on root ports (and other 1st
level bridges) that was fixed by 40613da52b13.
Fixes: 40613da52b13 ("PCI: acpiphp: Reassign resources on bridge if necessary")
Link: https://<email address hidden>
Reported-by: Woody Suwalski <email address hidden>
Tested-by: Woody Suwalski <email address hidden>
Tested-by: Michal Koutný <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Igor Mammedov <email address hidden>
Signed-off-by: Bjorn Helgaas <email address hidden>
Acked-by: Rafael J. Wysocki <email address hidden>
Acked-by: Michael S. Tsirkin <email address hidden>
(cherry picked from commit cc22522fd55e257c86d340ae9aedc122e705a435)
Signed-off-by: You-Sheng Yang <email address hidden>
In the commit of linux-firmware project, rtl8852cu_fw.bin is updated as
FW v2 format[1]. Consider the case that if driver did not be updated for
FW v2 supported[2], it can not use FW v2.
By Canonical's suggestion, older driver should be able to load FW v1,
so rtl8852cu_fw.bin will be revert to the previous commit as FW v1 and
add rtl8852cu_fw_v2.bin as FW v2. This item will be started on
linux-firmware project.
In this commit, the driver prefers to load FW v2 if available. Fallback to
FW v1 otherwise.
Note that the driver has supported to extract the data for v1 and v2
since the commit[1].
The previous FW format of RTL8852C is v1. After the commit[2], the FW format
was changed to v2. Only RTL8852C suffered the different FW formats, so
we will use rtl8852cu_fw.bin for the original commit as FW v1 and
rtl8852cu_fw_v2.bin for the future maintained as FW v2. Other Realtek chips
will not been impacted by this patch.
To do on linux-firmware project after this commit.
1. revert '55e7448533e7 ("rtl_bt: Update RTL8852C BT USB firmware
to 0x040D_7225")'
=> rtl_bt/rtl8852cu_fw.bin: FW v1 (stay at ver. 0xD7B8_FABF)
2. Add a new commit for rtl8852cu_fw_v2.bin
=>rtl_bt/rtl8852cu_fw_v2.bin: FW v2 (to be maintained)
Reference:
[1]'9a24ce5e29b1 ("Bluetooth: btrtl: Firmware format v2 support")'
[2]'55e7448533e7 ("rtl_bt: Update RTL8852C BT USB firmware
to 0x040D_7225")'
Fixes: 9a24ce5e29b ("Bluetooth: btrtl: Firmware format v2 support")
Suggested-by: Juerg Haefliger <email address hidden>
Tested-by: Hilda Wu <email address hidden>
Signed-off-by: Max Chou <email address hidden>
(cherry-picked from https://patchwork.kernel<email address hidden>/)
Signed-off-by: You-Sheng Yang <email address hidden>
