| Age | Commit message (Collapse) | Author |
|---|
|
Convert straightforward mutex_lock() and mutex_unlock() usages for
hotkey_mutex, tpacpi_inputdev_send_mutex, kbdlight_mutex, lcdshadow_dev
lock, and dytc_mutex to guard(mutex) and scoped_guard(mutex) helpers
from linux/cleanup.h.
This improves code readability and ensures that mutexes are
automatically released when exiting their respective scopes.
Assisted-by: Antigravity:gemini-3.6-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Ali Ahmet Memiş <aliamemis@disroot.org>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Link: https://patch.msgid.link/20260806061925.625482-1-dmitry.torokhov@gmail.com
[ij: converted hotkey_poll_setup() as well]
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Use the new helper. Inspecting input device's 'users' member needs to be
done under device's mutex, so add appropriate invocations.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Link: https://lore.kernel.org/r/20200608112211.12125-7-andrzej.p@collabora.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Link: https://patch.msgid.link/anK1j7hbMyFHGBUS@google.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
ThinkPad X1 Fold 16 Gen 1 firmware reports whether the keyboard is
magnetically attached (on the screen), but thinkpad-acpi does not expose
this to userspace. The state can be obtained via ACPI methods: GDST (get
device state).
Add a read-only keyboard_attached_on_screen sysfs attribute, gated by
a DMI match.
Cache the state and emit a sysfs notification on
TP_HKEY_EV_TABLET_CHANGED (0x60c0) when it changes. Initialize the
cache during hotkey setup and refresh it before the resume notification
to keep the state consistent across suspend and resume.
Signed-off-by: Pit Henrich <pithenrich2d@gmail.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Link: https://patch.msgid.link/20260825191210.55090-1-pithenrich2d@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Some systems only support USB-C but can still enter performance mode
if connected to a charger. Such systems usually do not support
WMI_FN_SYSTEM_AC_TYPE, so bitland_check_performance_capability()
currently always fails on them.
Fix this by treating WMI_FN_SYSTEM_AC_TYPE as optional and skip
the AC type check if WMI_FN_SYSTEM_AC_TYPE is not supported.
Tested-by: Martiya Aryan Mehr <martiya.ar@gmail.com>
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260904224516.8893-3-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The first 16-bit field inside the output data of a Mifs method call
contains a return code that specifies if the method call succeeded
(0x8000) or failed due to missing support (0xE000). The second 16-bit
field should then contain the previously executed function id.
Rework the layout of both input and output data to match the format
used by the Mifs firmware and check the return code.
Tested-by: Martiya Aryan Mehr <martiya.ar@gmail.com>
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260904224516.8893-2-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The F9 "Mode" key emits WMI fn-key event 0x46, which the keymap does not
cover, so it reaches userspace as KEY_UNKNOWN and cannot be remapped from
there. Under Windows it opens a performance profile chooser. The Fn+Q
button already cycles platform_profile through
ideapad_check_special_buttons(), so map 0x46 to KEY_PROG4 as a
user-assignable key rather than cycling the profile a second way.
Signed-off-by: Navon John Lukose <navonjohnlukose@gmail.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Link: https://patch.msgid.link/20260914134216.1295740-1-navonjohnlukose@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
QCC2072 has a Peripheral (PERI) subsystem to support the BT function
unit, the transport wire is owned by PERI and carries both BT-HCI and
PERI-HCI frames, as shown below:
_______________________________
USB I/F | internal link |
BTHOST -------- |---- PERI -------------- BT |
|_______________________________|
(other on-chip subsystems omitted)
PERI has its own command/event/ACL traffic, memdump, and firmware
(PATCH and NVM), all different from BT's own, and BTHOST needs to
interact with PERI directly.
To support multi-subsystem controllers, add btusb_qcom.c/.h as a new
transport-specific design:
- Multi-subsystem memdump collection.
- Generic PERI event handling, and sending a PERI frame then
syncing an event sequence.
- Downloading PERI firmware (rampatch and NVM).
- Recovery on command timeout or hardware error event.
BTW, it also supports BT-only chips.
/sys/kernel/debug/usb/devices:
T: Bus=03 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=ea00 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms
I: If#= 1 Alt= 7 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 65 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 65 Ivl=1ms
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Allow the driver to include vendor USB-transport-specific source files by:
- renaming btusb.c to btusb_main.c
- making btusb.o a composite object
Used by Qualcomm QCC2072 support.
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
To allow a vendor driver to assemble and handle its non-BT frames
from the interrupt endpoint.
Used by Qualcomm QCC2072 support.
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
In btmtksdio_fw_pmctrl(), if an early operation fails (like clearing
the mailbox ACK), it jumps to the `out:` label and spuriously prints
"Cannot return ownership to device".
Evaluate the ownership return errors locally to ensure the error log is
only printed if the actual ownership transaction fails.
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
MediaTek controllers may emit a firmware debug event on the ACL channel
using the reserved handle 0x0efd, which shows up in the ACL header as
0x2efd once the start fragment flag is included.
Neither btmtk_usb_recv_acl() nor btmtksdio_recv_acl() recognizes it, so
the packet is passed to the HCI core, which has no connection with that
handle and complains:
Bluetooth: hci0: ACL packet for unknown connection handle 3837
Handle it the same way as the existing firmware debug logging packets and
forward it to the diagnostic channel instead.
Confirmed with MTK internally that this event's wire format is fixed:
firmware always sends it as a single ACL_START packet and never splits
it into a continuation (ACL_CONT, which would show up as 0x1efd). Add a
comment above the switch spelling that out for this and the other
vendor-reserved handles already handled here (0xfc6f, 0x05ff, 0x05fe),
so review tooling doesn't keep flagging the apparent lack of a matching
continuation case.
Verified on MT7922: under the condition that triggers this firmware
debug event, it is now routed to the diag channel instead of reaching
the host as an unknown ACL packet.
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
checkpatch.pl flags the zero-length array members in struct
qca_dump_hdr:
ERROR: Use C99 flexible arrays - see
https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays
#3110: FILE: drivers/bluetooth/btusb.c:3110:
+ u8 data0[0];
Replace them with DECLARE_FLEX_ARRAY(), since C99 flexible array
members are not permitted inside unions or as the sole member of
a struct.
The struct layout is unchanged, and everything compiles with the
change.
Link: https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays
Signed-off-by: Jeremy Dean <deaner92@yahoo.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
The flag field of a BTMTK_WMT_PATCH_DWNLD packet tells the device where
the packet sits in the download sequence, but both download loops write
the bare values 1, 2 and 3, so the reader has to infer the meaning from
the surrounding conditionals.
Add enum btmtk_wmt_pkt_flag and use it in btmtk_setup_firmware_79xx()
and btmtk_setup_firmware(). No functional change.
The other bare flag values in this driver belong to different WMT
opcodes (BTMTK_WMT_FUNC_CTRL, BTMTK_WMT_RST, BTMTK_WMT_SEMAPHORE and so
on), where the field means something else entirely, so they are left
alone.
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
The firmware log line in btmtk_setup_firmware_79xx() never says which
file was requested, which matters because btmtk_fw_get_filename() derives
the name from the device id and firmware version at runtime. It reports
the firmware's own hwver field as the HW version, when the device id the
driver read from the chip is the more useful value and is already
available as dev_id. And it prints datetime, a u8[16] with no guaranteed
NUL terminator, with %s.
Log the filename before the image is parsed, so a file that fails
validation still says which file it was, report dev_id as the HW version,
and bound datetime with %.16s.
The datetime change is hardening rather than a fix, hence no Fixes: tag:
every file in linux-firmware terminates the field, and provoking the
over-read needs a malformed file in /lib/firmware.
Log output on MT7922 after the change:
[ 365.245951] Bluetooth: hci0: Loading BT firmware: mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin
[ 365.245956] Bluetooth: hci0: BT HW ver: 0x7922, SW ver: 0x008a, Build Time: 20260605203811
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
btmtk_setup_firmware_79xx() reads the section count out of the firmware's
global descriptor, then walks a 64-byte section map per section and hands
each section's file-supplied offset and length to the WMT download path.
None of that is checked against fw->size, so a truncated or corrupted
file makes the driver read past the end of request_firmware()'s buffer.
On 32-bit the section count can also wrap the section map size
calculation.
Add btmtk_fw_validate_layout() to check that the header, global
descriptor and section map array all fit, and btmtk_fw_validate_section()
to check one section's offset and length, both written so the size
arithmetic cannot wrap. A section count of zero is rejected as well: it
passes every size check but leaves the download loop with nothing to do,
so the function would report success on hardware it never programmed.
They are helpers rather than open-coded because the MT7928 CBMCU download
path added later needs the same arithmetic.
This is hardening against a corrupted /lib/firmware rather than a bug an
unprivileged user can trigger, hence bluetooth-next and no Fixes: tag.
Well-formed firmware files are unaffected.
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Add the USB ID 13d3:3631 for the MediaTek MT7925 Bluetooth module
found on AzureWave / Mercusys MA37BE PCIe Wi-Fi 7 cards.
T: Bus=01 Lev=02 Prnt=04 Port=03 Cnt=03 Dev#= 7 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3631 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Samuel Alhovuori <samuel.alhovuori@pm.me>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Validate device-supplied debug-region boundaries during mailbox TLV
parsing and convert start/end values to a validated region size. Cap
debug-region sizes to 1 MB to prevent out-of-bounds reads if firmware
reports oversized memory ranges. Skip invalid or oversized regions
prior to coredump capture.
This issue was reported by Claude Mythos.
Fixes: 87e8561bf73a ("Bluetooth: btintel_pcie: unified decoder coredump format")
Assisted-by: Copilot:claude-opus-4.7
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
ll_setup() busy-waits for 100 ms after asserting the controller enable
GPIO on each firmware download attempt. With retries this can occupy
the CPU for up to 400 ms.
The setup callback runs in sleepable context and already uses msleep(),
gpiod_set_value_cansleep() and synchronous firmware commands. Replace
mdelay(100) with msleep(100) so the CPU can run other work during the
power-up delay. Keep the requested delay and subsequent CTS wait.
Signed-off-by: Xuhua Zhang <zhangxuhua@kylinsec.com.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
h5_unslip_one_byte() calls test_and_clear_bit() for every byte other than
an initial SLIP escape byte, even when H5_RX_ESC is already clear. This
performs an unnecessary atomic read-modify-write on the ordinary-byte
receive path. On x86, it emits a locked btr instruction for each such
byte.
Test H5_RX_ESC first and clear it only when consuming an escaped byte.
Handle an initial SLIP escape byte in the alternative branch. The HCI
UART receive callbacks are serialized by the TTY layer, and H5_RX_ESC
is only changed by receive processing and initialization, so there is
no need to atomically test and clear it in one operation.
Keep set_bit() and clear_bit() atomic because other bits in h5->flags
can be updated by the transmit path concurrently. Escape decoding and
invalid-escape recovery remain unchanged.
Signed-off-by: Xuhua Zhang <zhangxuhua@kylinsec.com.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
bcsp_crc_update() processes each byte as two nibbles, requiring two
dependent table lookups for every header and payload byte when CRC is
enabled.
The existing crc_ccitt_byte() helper implements the same reflected
polynomial with one lookup per byte. Use it instead of the private
nibble-based implementation and select CRC_CCITT for BCSP-only UART
configurations as well. The initial CRC value and final bit reversal
remain unchanged.
This replaces the private 16-entry table with the shared 256-entry table,
trading table size for fewer dependent lookups. An exhaustive comparison
of all 65536 CRC states and 256 input bytes matches both the old code and
a bitwise reference implementation.
Signed-off-by: Xuhua Zhang <zhangxuhua@kylinsec.com.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Add the USB ID 0x14b0:0x047a for the StarTech AV53C1-USB-BLUETOOTH
adapter, a Realtek RTL8761BUE based Bluetooth 5.3 dongle.
Without this entry btusb treats the device as a generic Bluetooth
adapter and never loads the Realtek firmware, leaving the controller on
its ROM firmware. In that state it advertises and scans actively, but
never reports advertisements during passive scanning. LE connections
initiated by the kernel wait for a passive-scan report before issuing
LE Create Connection, so connecting and pairing from BlueZ time out
without any error from the controller.
The same product is also sold with the ID 0x2c0a:0x8761, which is
already supported.
lsusb -v output for the device:
Bus 001 Device 010: ID 14b0:047a StarTech.com Ltd. Bluetooth Radio
Device Descriptor:
bcdUSB 1.10
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
idVendor 0x14b0 StarTech.com Ltd.
idProduct 0x047a
bcdDevice 2.00
iManufacturer 1 Realtek
iProduct 2 Bluetooth Radio
iSerial 3 00E04C239987
bNumInterfaces 2
Interface Descriptor:
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
Cc: stable@vger.kernel.org
Signed-off-by: Nikolaj Klitlund Børty <nbn@sj.dk>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Replace the legacy TLV-based coredump with a unified INI-format dump
compatible with the iwlwifi decoder so a single decoder can parse
coredumps across all Intel BT PCIe controller variants.
The dump is emitted via dev_coredumpsg() as structured regions built
from firmware-advertised addresses: DRAM monitor buffers (single or
MDBGC multi-buffer), SMEM monitor, exception event buffer, DCCM, SDS,
SDS IOSF, ECL and dump info metadata. Regions are collected only when
firmware advertises a valid address and size, and only collected
regions are advertised in regions_mask.
Add INTEL_CNVX_TOP_DASH() and INTEL_CNVX_TOP_FLAVOR() helpers to
btintel.h for RfIdDash/RfIdFlavor extraction.
Assisted-by: Copilot:gemini-3.6-flash
Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Newer Intel BT PCIe variants (Nova Lake SCP2 and PTL FMP2) require
three independent DRAM debug (DBGC) buffer pools instead of the
single pool used by existing controllers.
Factor the per-pool buffer allocation into a common helper and add
a multi-DBGC (MDBGC) setup path that allocates three pools using
the fragment context format. MDBGC is used when the device reports
an MDBGC-capable variant; otherwise the existing single-pool DBGC
path is retained.
Assisted-by: Copilot:claude-opus-4.7 sparse
Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Two identical definitions of BTINTEL_PCIE_MAGIC_NUM were present in
btintel_pcie.c, one indented with spaces and one with a tab. Remove the
space-indented duplicate and the surrounding blank lines. Kernel coding
style requires tabs for indentation, so keep the tab-indented copy.
No functional change.
Assisted-by: Copilot:claude-opus-4.7 sparse
Fixes: 6ed83047389c ("Bluetooth: btintel_pcie: Setup buffers for firmware traces")
Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Add support for the Synaptics 4384 Bluetooth controller
by adding the corresponding chip IDs.
Tested on the VIM3 platform. Verified that the controller initializes
successfully and that firmware loading and basic Bluetooth operation
work as expected.
The VIM3 is a Khadas single-board computer that I used as the host
platform for testing the BCM4384 Bluetooth controller.
Test log:
Bluetooth: hci0: BCM: chip id 206
Bluetooth: hci0: BCM: features 0x0f
Bluetooth: hci0: BCM4384B0
Bluetooth: hci0: BCM4384B0 (002.001.025) build 0000
Bluetooth: hci0: BCM4384B0 'brcm/BCM4384B0.hcd' Patch
Bluetooth: hci0: BCM: features 0x0f
Bluetooth: hci0: BCM4384B0 AP6684P CN iPA [Version: 1030.1021]
Bluetooth: hci0: BCM4384B0 (002.001.025) build 1021
Bluetooth: hci0: BCM: Using default device address (43:84:b0:00:76:93)
Signed-off-by: Andy Chang <Andy.Chang@synaptics.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
$ lsusb
Bus 003 Device 003: ID 8087:0043 Intel Corp.
$ cat /sys/kernel/debug/usb/devices
T: Bus=03 Lev=01 Prnt=01 Port=09 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=8087 ProdID=0043 Rev= 0.00
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
Signed-off-by: Catherine L <catherine.l@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
The onboard Realtek RTL8821CE combo card on the ASUS PRIME B550-PLUS
AC-HES presents its Bluetooth function as USB ID 13d3:3556. This ID is
missing from quirks_table, so btusb matches the device only through the
generic Bluetooth class entry in btusb_table and driver_info stays zero.
BTUSB_REALTEK is therefore never set, btrtl never runs, and the
controller keeps executing its on-chip ROM firmware instead of loading
rtl_bt/rtl8821c_fw.bin and rtl_bt/rtl8821c_config.bin.
In that state BLE HID peripherals are unusable. A HHKB Hybrid keyboard
pairs and enumerates as a HID device, then the link drops within 10-30
seconds, repeatedly. The same keyboard is stable on the same host under
other operating systems.
Adding the ID lets btusb run the Realtek setup path:
Bluetooth: hci0: RTL: examining hci_ver=08 hci_rev=000c lmp_ver=08 lmp_subver=8821
Bluetooth: hci0: RTL: rom_version status=0 version=1
Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_fw.bin
Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_config.bin
Bluetooth: hci0: RTL: cfg_sz 10, total sz 34926
Bluetooth: hci0: RTL: fw version 0x75b8f098
With the firmware loaded the same keyboard has stayed connected for over
11 hours without a single drop.
Device descriptor:
T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3556 Rev=01.10
S: Manufacturer=Realtek
S: Product=Bluetooth Radio
S: SerialNumber=00e04c000001
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
Signed-off-by: Aritra Das <aritra.rohit2003@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
This adds support for Bulk Serialization Mode introduced in 6.2:
https://www.bluetooth.com/bluetooth-core-6-2-feature-overview/#5-bluetooth-hci-usb-le-isochronous-support
https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host-controller-interface/usb-transport-layer.html#UUID-c1a65395-29e9-87d3-2981-8bed625d0459
It works by detecting if alternate setting 1 is supported for the
interface and then switches to use it as it serializes all the frames
in a single Bulk endpoint using H4 headers and it considerable more
robust then legacy one while allowing the transport of ISO packets:
'In addition to enabling Bluetooth® LE Audio, the new mode resolves a
persistent race condition in the legacy USB transport layer. In Legacy
Mode, different endpoint types are serviced in a specific order within
a USB frame, which can result in out-of-order delivery of data and
events. For example, a Host might receive a data packet before the
event signaling its arrival. This behavior can disrupt critical
processes such as connection setup, disconnection, and data encryption,
adversely affecting the user experience.'
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
h4_recv_buf() is currently implemented in hci_h4.c which is only built as
part of the hci_uart module, and only when CONFIG_BT_HCIUART_H4 is
enabled. That makes the H:4 reassembly logic unusable by drivers which do
not depend on hci_uart, e.g. btusb which needs it to implement Bulk
Serialization Mode.
Move the transport agnostic part into the Bluetooth core as
h4_recv_skb(), which takes a struct hci_dev instead of a struct hci_uart,
along with struct h4_recv_pkt and the H4_RECV_* helpers, and keep
h4_recv_buf() as a thin wrapper for the hci_uart protocols.
Since every Bluetooth driver already depends on the bluetooth module this
introduces no new module dependency and no new Kconfig symbol.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
mt79xx_setup() passes a hardcoded 0 to btmtk_setup_firmware_79xx(),
discarding the device id that btmtksdio_setup() has just read from register
0x70010200. That argument only gates the section filtering for MT6639,
which has no SDIO interface, so this is a no-op on supported hardware and
carries no Fixes: tag.
Pass the value that has already been read, matching the USB path. Declare
dev_id as u32 while at it, since that is what btmtksdio_mtk_reg_read()
writes through the pointer.
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
btmtksdio_setup() derives the firmware filename with
btmtk_fw_get_filename() and then overwrites it with an snprintf() that
open-codes that helper's fallback format. Commit 7f935b21bee4 ("Bluetooth:
btmtk: apply the common btmtk_fw_get_filename") added the helper call
without removing the snprintf() it was meant to replace.
None of the device ids the helper special-cases can appear here: 0x6639,
0x7925 and the flavored 0x7961 belong to parts with no SDIO interface, and
btmtksdio_setup() passes a flavor of 0 accordingly. The helper always falls
through to the snprintf()'s own format, so both produce the same string and
removing it is a no-op.
Remove it anyway, since it silently defeats the helper for any device id
the helper special-cases.
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
The MT7925 Bluetooth USB function can enumerate successfully after a warm
reboot while the WMT function-control command remains unresponsive.
When that command times out, btmtk_usb_setup() currently returns
-ETIMEDOUT without entering the existing MediaTek reset path. The existing
USB reset and recovery machinery is therefore never reached.
For MT7925, call btmtk_reset_sync() when the WMT function-control command
times out. This enters the existing reset path in btusb_mtk_reset(), which
performs the MediaTek subsystem reset and queues a USB device reset.
Runtime tracing on the affected hardware showed the resulting path through
usb_queue_reset_device(), usb_reset_device() and
usb_reset_and_verify_device(). When reset and verification could not
restore the device, the USB core escalated to a logical disconnect and
re-enumeration.
Recovery succeeded in three controlled Windows-to-Linux tests. Runtime
tracing showed the existing USB reset path escalating to logical disconnect
and re-enumeration. In two of those tests, tracing continued through the
subsequent enumeration failures and directly captured
usb_acpi_port_prr_reset(), after which the MT7925 re-enumerated and
Bluetooth recovered.
These tests were performed on top of Chia-Lin Kao's ACPI _PRR hub patch,
which remains a prerequisite for this patch.
A fourth Windows-to-Linux test was then performed with the diagnostic btusb
blacklist removed and btusb binding normally during boot. The WMT timeout
reproduced and Bluetooth recovered automatically without manual
intervention.
Signed-off-by: George Maraveyas <george.0xfff@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Set dbg_output_mode to 0x06 (BTINTEL_PCIE_WIFI_DBGC) by default so
firmware debug traces are forwarded to the WiFi DBGC. In this mode:
- Host DBGC fragment/data buffers are NOT allocated.
- Context info publishes dbgc_addr/size as 0.
Add a small helper btintel_pcie_dbg_to_wifi() driven by a cached
dbg_path_cache field in struct btintel_pcie_data, initialized to
BTINTEL_PCIE_WIFI_DBGC in probe.
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Catherine L <catherine.l@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Performing a target access to read the mbox TLV table while the driver
is concurrently posting RX buffers to the firmware causes the hardware
to return 0 for the target address, resulting in an invalid/empty TLV
parse.
Add a synchronization handshake between the mbox TLV read operation
performed by the mbox worker and the GP0 (alive) MSI-X interrupt (which
signals completion of RX buffer posting). The worker now waits for the
alive interrupt before initiating the target access, ensuring the
hardware returns valid data.
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Implement GP1 mailbox interrupt handling to receive memory region
addresses from firmware via a TLV-based protocol. When firmware sends
a BUILD_SPECIFIC_RESOURCES_MAPPING mailbox message, the driver reads
a TLV table from device memory containing addresses and sizes of
debug memory regions (exception dump, DCCM, SDS, ECL, SMEM).
This enables the driver to dynamically discover dump region locations
instead of using hardcoded addresses, supporting current and future
Intel BT PCIe controller variants.
Replace per-device hardcoded exception memory address and size
constants in btintel_pcie_read_hwexp() with the dynamically populated
values from dump_info, making exception dump handling consistent with
other dump regions.
Key changes:
- Rewrite GP1 handler to parse mailbox registers and queue TLV work
- Add btintel_parse_mbox_tlv() for parsing FW-provided TLV data
- Add mbox_work workqueue for deferred TLV processing
- Store parsed region addresses in btintel_pcie_dump_mem_info
- Add cnvi_bt field to btintel_data for HW variant identification
- Rename fw_git_sha1 to fw_sha for consistency
- Remove hardcoded HWEXP address/size macros and use dump_info
Assisted-by: GitHub-Copilot:claude-opus-4.7
Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com>
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
hci_uart_unregister_device() frees the HCI device (hci_free_dev)
before cancelling write_work via cancel_work_sync(). If write_work
is executing concurrently on another CPU, it can access hu->hdev
and write to hdev->stat after the memory has been freed.
Additionally, HCI_UART_PROTO_READY is not cleared until after
cancel_work_sync, so the write_wakeup serdev callback can still
schedule write_work via hci_uart_tx_wakeup() even after
hci_free_dev has freed the device.
Fix this by mirroring the same ordering used in the tty/ldisc path
(hci_uart_tty_close, hci_ldisc.c:565-593):
1. Save the PROTO_READY state and clear it under the write lock so
a concurrent hci_uart_tx_wakeup() cannot re-schedule write_work
2. Cancel write_work (no new work can be scheduled and no work is
in flight)
3. Unregister the HCI device
4. Close the protocol (may access hu->hdev and the serdev device)
5. Close the serdev port (safe now that write_work is quiesced and
protocol is done)
6. Free the HCI device
Also free any partially transmitted frame (hu->tx_skb) left over by
write_work once the transmit path is quiesced, since hci_uart_close()
would skip hci_uart_flush() because HCI_UART_PROTO_READY is cleared.
Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
btmtksdio_close() and btmtksdio_reset() call cancel_work_sync() on
bdev->txrx_work while holding the sdio host lock, which is also acquired
by btmtksdio_txrx_work(). If txrx_work is queued when close/reset runs,
a worker thread may start it after the host lock is taken and block in
sdio_claim_host(), while cancel_work_sync() waits for the work to
finish. The host lock is only released after cancel_work_sync()
returns, so both sides wait forever, deadlocking close/reset.
Fix this by releasing the sdio host lock before calling
cancel_work_sync(), then re-acquiring it afterwards.
In btmtksdio_close() the interrupt is already disabled by
sdio_release_irq(), which also unregisters the IRQ handler, so no new
work can be scheduled and cancel_work_sync() fully quiesces txrx_work.
btmtksdio_reset() must additionally unregister the IRQ handler before
dropping the host lock: btmtksdio_txrx_work() unconditionally re-enables
the device interrupt (C_INT_EN_SET) when the handler is still registered,
so an in-flight worker would re-enable interrupts and be rescheduled
while the device is being reset, defeating the cancellation. The IRQ is
re-claimed by btmtksdio_open() when the HCI device is re-opened after
the reset.
This mirrors the pattern already used by btmtksdio_flush(), which
cancels the work without holding the host lock.
Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
When virtbt_open_vdev() fails in virtbt_probe(), hci_free_dev(hdev) is
called without first calling hci_unregister_dev(hdev). Since
hci_register_dev() already succeeded, the HCI device remains registered
while its memory is freed, leading to a use-after-free when accessed
via sysfs or HCI sockets.
Additionally, the probe function leaks the virtio_bluetooth structure
(vbt) in several error paths:
- When virtio_find_vqs() fails, vbt is not freed.
- When hci_alloc_dev() or hci_register_dev() fails, vbt is not freed.
- When virtbt_open_vdev() fails, vbt is not freed.
Furthermore, when virtbt_open_vdev() fails after virtio_device_ready()
has been called, the device is left live (DRIVER_OK set) while its
virtqueues are torn down, and any scheduled work is not flushed,
potentially allowing a use-after-free from device-initiated callbacks.
Fix all of these by restructuring the error labels to properly unwind
in reverse order of the allocation/registration sequence. The new
labels err_del_vqs and err_free_vbt ensure that del_vqs and kfree(vbt)
are called as appropriate for each failure point. For the
virtbt_open_vdev() failure path, call virtio_reset_device() and
virtbt_close_vdev() before unregistering the HCI device, matching the
cleanup pattern in virtbt_remove().
Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
The IMC Networks Bluetooth controller with USB ID 13d3:3558 uses an
RTL8821CE. Without BTUSB_REALTEK, btusb uses generic initialization and
does not load the controller firmware. BLE connections then fail before
pairing with HCI error 0x3e.
Add the device ID to the RTL8821CE table. This enables loading
rtl_bt/rtl8821c_fw.bin and rtl_bt/rtl8821c_config.bin, after which a
BLE HID keyboard pairs successfully.
Signed-off-by: Richard Nunley <richard.w.nunley@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
In btmrvl_process_event(), all error handling paths except one do a direct
return. Update the only one that makes a goto to be consistent.
This does not change the behavior because ret is known to be != 0 when
'exit' is reached.
This simplifies the code, saves 2 LoC and pleases one of my coccinelle
script that tries to spot erroneously mixed goto and return statements.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
btintel_pcie_submit_rx() used frbd_index > rxq->count to guard the
FRBD array access, allowing frbd_index == rxq->count to pass through
and index one element past the end of the array. Change the check to
>= rxq->count so every out-of-range index is rejected.
This issue was reported by Claude Mythos.
Fixes: c2b636b3f788 (Bluetooth: btintel_pcie: Add support for PCIe transport)
Signed-off-by: Sai Teja Aluvala <aluvala.sai.teja@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
In btmtksdio_shutdown(), pm_runtime_get_sync() is called at the
beginning of the function. However, if sending the WMT function
control command fails later, the driver returns early.
It bypasses the corresponding pm_runtime_put_noidle() and
pm_runtime_disable() calls, leaking the PM usage counter and leaving PM
runtime enabled indefinitely.
Fall through to execute the PM runtime cleanup block even if WMT errors.
Fixes: 7f3c563c575e ("Bluetooth: btmtksdio: Add runtime PM support to SDIO based Bluetooth")
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
btmtksdio.c and btmtkuart.c cast a received WMT event straight to
struct btmtk_hci_wmt_evt and read its op/flag fields without checking
the event is long enough to contain them, unlike btmtk.c. The
FUNC_CTRL case then further casts to struct btmtk_hci_wmt_evt_funcc
and reads its 2-byte status field, again without a length check.
Firmware that sends a short or malformed WMT event makes both drivers
read past the end of the received SKB.
Mirror btmtk.c: validate the base WMT header with skb_pull_data()
before touching any of its fields, and when a FUNC_CTRL event turns
out to be the short, header-only form (a plain enable/disable ack
with no status word), decode the result from the header's own flag
byte instead (0 = success, otherwise failure).
Verified setup on MT7920, MT7921, MT7922 and MT7925: no regression.
Fixes: 9aebfd4a2200 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices")
Fixes: e0b67035a90b ("Bluetooth: mediatek: update the common setup between MT7622 and other devices")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
A too-short BTMTK_WMT_FUNC_CTRL event (WMT header only, no trailing
2-byte status word) is always treated as BTMTK_WMT_ON_UNDONE. This
short form is how firmware acks a plain enable/disable request, and
the actual result is carried in the header's own flag byte (0 =
success), not a separate status word. Decode it from there instead of
assuming failure.
Verified setup on MT7920, MT7921, MT7922 and MT7925: no regression.
Fixes: e3ac0d9f1a20 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
hci_uart_close() closes the serdev port if HCI_QUIRK_NON_PERSISTENT_SETUP
is set (for example, for the WCN399x family). A failed hci_dev_open_sync()
following a successful qca_setup() calls hdev->close() but not
hdev->shutdown(), so the port is closed while power->vregs_on is left true.
qca_serdev_remove() then passes its power->vregs_on test and calls
qca_power_off(), which writes to the closed port unconditionally.
Seen on a WCN3988 by unbinding the driver after a controller failure. The
trace below is from a 7.0.0 based kernel, where qca_power_off() was still
named qca_power_shutdown():
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000038
Call trace:
tty_set_termios+0x50/0x238 (P)
ttyport_set_baudrate+0x84/0xc0
serdev_device_set_baudrate+0x24/0x40
qca_power_shutdown+0x158/0x1fc [hci_uart]
qca_serdev_remove+0x54/0x68 [hci_uart]
serdev_drv_remove+0x1c/0x2c
device_remove+0x4c/0x80
device_release_driver_internal+0x1cc/0x224
device_driver_detach+0x18/0x24
unbind_store+0xb4/0xc0
Check HCI_UART_PROTO_READY, which hci_uart_close() clears in the same place
it closes the port, before writing to it. The regulator disable is left
unconditional so the controller is still powered down.
The dangling serport->tty that turns this into a use-after-free is
addressed in a separate patch.
Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990")
Signed-off-by: Ibrahim Abdelkader <iabdelka@qti.qualcomm.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
btintel_pcie_prepare_tx() copies skb->len bytes into a fixed
BTINTEL_PCIE_BUFFER_SIZE (4096) DMA slot via an unchecked memcpy.
Oversized packets are currently rejected only in
btintel_pcie_send_frame(); any future caller of
btintel_pcie_send_sync() would silently overflow the DMA buffer.
Add the bounds check in btintel_pcie_send_sync() itself, right
before skb_push() and the DMA copy.
Assisted-by: Copilot:claude-sonnet-5 code-review code-generation
Fixes: 6e65a09f9275 ("Bluetooth: btintel_pcie: Add *setup* function to download firmware")
Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
The NXP IW610 module exposes itself as a composite USB device
(0471:0215) with three interfaces: two real Bluetooth HCI interfaces
(class 0xe0) and one vendor-specific WiFi interface (class 0xff) used
by mwifiex-nxp.
The composite device's whole USB descriptor reports class 0xe0/01/01
(Bluetooth), so btusb_table's generic USB_DEVICE_INFO(0xe0, 0x01, 0x01)
entry matches every interface, not just the two real HCI ones -- btusb
ends up binding the WiFi interface too, and mwifiex-nxp never gets it.
Fix:
1. In btusb_table (the table the USB core actually matches against),
explicitly ignore the WiFi interface via BTUSB_IGNORE, ahead of the
generic entry.
2. In quirks_table, scope the existing BTUSB_MARVELL entry to the BT
interface class instead of matching the whole device by VID/PID
(harmless either way since quirks_table isn't consulted for initial
binding, but keep it correct).
Not upstream anywhere: checked NXP's own i.MX kernel fork
(nxp-imx/linux-imx), no IW610 references in btusb.c on any branch --
their reference designs wire this chip differently (WiFi over SDIO
per their release notes), so they never hit this.
Signed-off-by: Nicolas Thibert <nithibert@gmail.com>
Cc: stable@vger.kernel.org
Assisted-by: LLM (Claude Sonnet 5, Anthropic)
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
simplify code
Replace the open-coded resource lookup, request_mem_region, ioremap and
the manual iounmap/release_mem_region cleanup in probe/remove with the
managed devm_platform_get_and_ioremap_resource() helper. This removes the
now-unused error-unmap/release paths and simplifies probing.
Fix a resource size mismatch between allocating and freeing where
request_mem_region() and release_mem_region() hopefully use the same size
but is not guarenteed.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260915072853.58587-1-rosenp@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The bcom_psc_params[] array has 6 entries (indices 0-5), but
bcom_psc_gen_bd_rx_init() checked against MPC52xx_PSC_MAXNUM which can
be 12 when CONFIG_PPC_MPC512x is set, allowing indices 6-11 to pass
and read past the array. The tx init function had no bounds check at
all.
A malformed device tree with a large cell-index could therefore trigger
an out-of-bounds read. The garbage initiator and ipr values would then
be used for MMIO writes via out_8(&bcom_eng->regs->ipr[...], ...),
potentially causing out-of-bounds MMIO accesses.
Assisted-by: LLM
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260915072608.57887-1-rosenp@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
bcom_gen_bd_rx_init() and bcom_gen_bd_tx_init() are only called from
the PSC wrapper functions in gen_bd.c, so make them static, drop
their now-unneeded exports, and remove the corresponding header
declarations.
These had use before commit 7d3ee229ea51
("powerpc: Drop MPC5200 LocalPlus bus FIFO driver")
Assisted-by: LLM
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Link: https://patch.msgid.link/20260913194804.39939-1-rosenp@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
