Pull the vblank delay computation into a separate function.
We'll need more logic here soon and we don't want to pollute
intel_crtc_compute_config() with low level details.
We'll use HAS_DSB() to determine if any delay might be required
or not because delayed vblank only really exists for the
purposes of the DSB. It also doesn't event exists on any pre-tgl
platforms, which also don't have DSB. I was midly tempted
to check for the enable_dsb modparam here actually, but as
that can be changed dynamically via debugfs we'd need to either
reconfigure it on the fly or force a modeset. Neither will happen
currently, so we'll just assume DSB may be used of the platform
supports it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-2-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
syzbot triggered the warning in posixtimer_send_sigqueue(), which warns
about a non-ignored signal being already queued on the ignored list.
The warning is actually bogus, as the following sequence causes this:
signal($SIG, SIGIGN);
timer_settime(...); // arm periodic timer
timer fires, signal is ignored and queued on ignored list
sigprocmask(SIG_BLOCK, ...); // block the signal
timer_settime(...); // re-arm periodic timer
timer fires, signal is not ignored because it is blocked
---> Warning triggers as signal is on the ignored list
Ideally timer_settime() could remove the signal, but that's racy and
incomplete vs. other scenarios and requires a full reevaluation of the
pending signal list.
Instead of adding more complexity, handle it gracefully by removing the
warning and requeueing the signal to the pending list. That's correct
versus:
1) sig[timed]wait() as that does not check for SIGIGN and only relies on
dequeue_signal() -> posixtimers_deliver_signal() to check whether the
pending signal is still valid.
2) Unblocking of the signal.
- If the unblocking happens before SIGIGN is replaced by a signal
handler, then the timer is rearmed in dequeue_signal(), but
get_signal() will ignore it. The next timer expiry will move it back
to the ignored list.
- If SIGIGN was replaced before unblocking, then the signal will be
delivered and a subsequent expiry will queue a signal on the pending
list again.
There is a related scenario to trigger the complementary warning in the
signal ignored path, which does not expect the signal to be on the pending
list when it is ignored. That can be triggered even before the above change
via:
task1 task2
signal($SIG, SIGIGN);
sigprocmask(SIG_BLOCK, ...);
timer_create(); // Signal target is task2
timer_settime(...); // arm periodic timer
timer fires, signal is not ignored because it is blocked
and queued on the pending list of task2
syscall()
// Sets the pending flag
sigprocmask(SIG_UNBLOCK, ...);
-> preemption, task2 cannot dequeue the signal
timer_settime(...); // re-arm periodic timer
timer fires, signal is ignored
---> Warning triggers as signal is on task2's pending list
and the thread group is not exiting
Consequently, remove that warning too and just keep the signal on the
pending list.
The following attempt to deliver the signal on return to user space of
task2 will ignore the signal and a subsequent expiry will bring it back to
the ignored list, if it did not get blocked or un-ignored before that.
Fixes: df7a996b4d ("signal: Queue ignored posixtimers on ignore list")
Reported-by: syzbot+3c2e3cc60665d71de2f7@syzkaller.appspotmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Link: https://lore.kernel.org/all/87ikqhcnjn.ffs@tglx
Use syscon_regmap_lookup_by_phandle_args() which is a wrapper over
syscon_regmap_lookup_by_phandle() and getting the argument. Except
simpler code this annotates within one line that given phandle has
arguments, so grepping for code would be easier.
There is also no real benefit in printing errors on missing syscon
argument, because this is done just too late: runtime check on
static/build-time data. Dtschema and Devicetree bindings offer the
static/build-time check for this already.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Link: https://lore.kernel.org/r/20250111-b4-syscon-phandle-args-remoteproc-v1-5-73ed6fafa1e3@linaro.org
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Use syscon_regmap_lookup_by_phandle_args() which is a wrapper over
syscon_regmap_lookup_by_phandle() and getting the argument. Except
simpler code this annotates within one line that given phandle has
arguments, so grepping for code would be easier.
There is also no real benefit in printing errors on missing syscon
argument, because this is done just too late: runtime check on
static/build-time data. Dtschema and Devicetree bindings offer the
static/build-time check for this already.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250111-b4-syscon-phandle-args-remoteproc-v1-4-73ed6fafa1e3@linaro.org
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Having the aux registration helper along with the registered driver is not
great dependency wise. It does not allow the registering driver to be
properly decoupled from the registered auxiliary driver.
Drop the registration helper from the amlogic auxiliary reset driver.
This will be handled in the registering clock driver to start with while
a more generic solution is worked on.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20241209-meson-rst-aux-rework-v1-2-d2afb69cc72e@baylibre.com
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Get regmap directly from the parent device registering the
auxiliary reset driver, instead of using device data attached
to the auxiliary device.
This simplifies the registration a bit.
Suggested-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20241209-meson-rst-aux-rework-v1-1-d2afb69cc72e@baylibre.com
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
This reset controller is part of audio clock controller and handled by
auxiliary reset driver. Introduced defines supposed to be used together
with upcoming device tree nodes for audio clock controller fo A1 SoC.
Signed-off-by: Jan Dakinevich <jan.dakinevich@salutedevices.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20241112230056.1406222-2-jan.dakinevich@salutedevices.com
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
New ideapad helper file with support for handling FN key mute LEDs.
Update conexant and realtec codec to add LED support.
Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Jackie Dong <xy-jackie@139.com>
Link: https://patch.msgid.link/20250115162515.15026-1-xy-jackie@139.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
1. Clear LLBCTL if secondary mmu mapping changed.
2. Add hypercall service support for usermode VMM.
This is a really small changeset, because the Chinese New Year
(Spring Festival) is coming. Happy New Year!
-----BEGIN PGP SIGNATURE-----
iQJKBAABCAA0FiEEzOlt8mkP+tbeiYy5AoYrw/LiJnoFAmeFGcIWHGNoZW5odWFj
YWlAa2VybmVsLm9yZwAKCRAChivD8uImern1D/9AZ8M+0nBAaONZaq2qKLC+RaW6
KqvFsR1PUUFzVcQZaHh9OZcx5s4EAH12EaxBH68W0o0ejbTUJp8QXT6cmO9bNFj1
tVaczGACss34kDerrddHisOpimFdaP+ECX4Q43oTc5N7vG6zUu3ijOISnIIxkhHP
RlX/+5Djw0NoaVAkhEj4v+LkY33z5QnDFNI0OjJiHpDepP2vLQ1FD573pLMeqcGs
BVYwZv7DP3SnVajSjRhT/r5qjy9EMjrXRLkIIwyjOUArRaPq/Lfg4CTK85e5MZsR
2GTkdjvh/YArpluRki4FX1cVOwpBbEtC+24/NWB+MPijtnYqMyAoIraZGqJMAzhw
P6W70A15GvBhlhQmvKNai1oXkdZaaT7XDcbFT706Cwhu7LvcNM8kK7VrPc59WLTR
uHO+ehJh0DCpBMC2BKH/8sztGx80u7SB4Ph0ytZCK+uYznTMEiBqRup7E/QLLG+1
EotXv8U4+Bwx/inzMxwi6vR1ZXo0dIDsnvFdSZeA6PC/cSoPzdqCdrXjQT/7HUIu
DNgcsRVL3LFE+A/sDVGb5/w9UPdQfCdO10bu97FkY37ftqp7LvPTlWJvDZJx+Wle
KfErCOM1/ZRQ2knzE7fst58auA3ZFNn3jWRkD/0gJ4X1Fgu63VrYeuc4FL7r8ken
HxKLYOLtD6dOzR5DeA==
=z2VU
-----END PGP SIGNATURE-----
Merge tag 'loongarch-kvm-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson into HEAD
LoongArch KVM changes for v6.14
1. Clear LLBCTL if secondary mmu mapping changed.
2. Add hypercall service support for usermode VMM.
This is a really small changeset, because the Chinese New Year
(Spring Festival) is coming. Happy New Year!
This development cycle again featured multiple patchsets to ath12k to
support the new 802.11be MLO feature, this time including the device
grouping infrastructure, and the advertisement of MLO support to the
wireless core. However the MLO feature is still considered to be
incomplete.
In addition, there was the usual set of bug fixes and cleanups, mostly
in ath12k, but also in ath9k.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ/mtSHzPUi16IfDEksFbugiYzLewUCZ4bgBAAKCRAsFbugiYzL
eyZoAQDoItj55hlA93r/BuzUc7/lCUztH/IOQBWitMrA9ZQ+8AEAxVVUctcRk0kC
VxVtQIg1OQONeftlfXAt6wAsGOtmOA8=
=Ve3o
-----END PGP SIGNATURE-----
Merge tag 'ath-next-20250114' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
ath.git patches for v6.14
This development cycle again featured multiple patchsets to ath12k to
support the new 802.11be MLO feature, this time including the device
grouping infrastructure, and the advertisement of MLO support to the
wireless core. However the MLO feature is still considered to be
incomplete.
In addition, there was the usual set of bug fixes and cleanups, mostly
in ath12k, but also in ath9k.
The current check in blk_stack_atomic_writes_limits() for a bottom device
supporting atomic writes is to verify that limit atomic_write_unit_min is
non-zero.
This would cause a problem for device mapper queue limits calculation. This
is because it uses a temporary queue_limits structure to stack the limits,
before finally commiting the limits update.
The value of atomic_write_unit_min for the temporary queue_limits
structure is never evaluated and so cannot be used, so use limit
atomic_write_hw_unit_min.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: John Garry <john.g.garry@oracle.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Link: https://lore.kernel.org/r/20250109114000.2299896-3-john.g.garry@oracle.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
For stacking atomic writes, ensure that the start sector is aligned with
the device atomic write unit min and any boundary. Otherwise, we may
permit misaligned atomic writes.
Rework bdev_can_atomic_write() into a common helper to resuse the
alignment check. There also use atomic_write_hw_unit_min, which is more
proper (than atomic_write_unit_min).
Fixes: d7f36dc446 ("block: Support atomic writes limits for stacked devices")
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: John Garry <john.g.garry@oracle.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Link: https://lore.kernel.org/r/20250109114000.2299896-2-john.g.garry@oracle.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Return RET_PF* (excluding RET_PF_EMULATE/RET_PF_CONTINUE/RET_PF_INVALID)
instead of 1 in kvm_mmu_page_fault().
The callers of kvm_mmu_page_fault() are KVM page fault handlers (i.e.,
npf_interception(), handle_ept_misconfig(), __vmx_handle_ept_violation(),
kvm_handle_page_fault()). They either check if the return value is > 0 (as
in npf_interception()) or pass it further to vcpu_run() to decide whether
to break out of the kernel loop and return to the user when r <= 0.
Therefore, returning any positive value is equivalent to returning 1.
Warn if r == RET_PF_CONTINUE (which should not be a valid value) to ensure
a positive return value.
This is a preparation to allow TDX's EPT violation handler to check the
RET_PF* value and retry internally for RET_PF_RETRY.
No functional changes are intended.
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
Message-ID: <20250113021138.18875-1-yan.y.zhao@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
wiphy_unregister()/wiphy_free() has been recently decoupled from
wilc_netdev_cleanup() to fix a faulty error path in sdio/spi probe
functions. However this change introduced a new failure when simply
loading then unloading the driver:
$ modprobe wilc1000-sdio; modprobe -r wilc1000-sdio
WARNING: CPU: 0 PID: 115 at net/wireless/core.c:1145 wiphy_unregister+0x904/0xc40 [cfg80211]
Modules linked in: wilc1000_sdio(-) wilc1000 cfg80211 bluetooth ecdh_generic ecc
CPU: 0 UID: 0 PID: 115 Comm: modprobe Not tainted 6.13.0-rc6+ #45
Hardware name: Atmel SAMA5
Call trace:
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x44/0x70
dump_stack_lvl from __warn+0x118/0x27c
__warn from warn_slowpath_fmt+0xcc/0x140
warn_slowpath_fmt from wiphy_unregister+0x904/0xc40 [cfg80211]
wiphy_unregister [cfg80211] from wilc_sdio_remove+0xb0/0x15c [wilc1000_sdio]
wilc_sdio_remove [wilc1000_sdio] from sdio_bus_remove+0x104/0x3f0
sdio_bus_remove from device_release_driver_internal+0x424/0x5dc
device_release_driver_internal from driver_detach+0x120/0x224
driver_detach from bus_remove_driver+0x17c/0x314
bus_remove_driver from sys_delete_module+0x310/0x46c
sys_delete_module from ret_fast_syscall+0x0/0x1c
Exception stack(0xd0acbfa8 to 0xd0acbff0)
bfa0: 0044b210 0044b210 0044b24c 00000800 00000000 00000000
bfc0: 0044b210 0044b210 00000000 00000081 00000000 0044b210 00000000 00000000
bfe0: 00448e24 b6af99c4 0043ea0d aea2e12c
irq event stamp: 0
hardirqs last enabled at (0): [<00000000>] 0x0
hardirqs last disabled at (0): [<c01588f0>] copy_process+0x1c4c/0x7bec
softirqs last enabled at (0): [<c0158944>] copy_process+0x1ca0/0x7bec
softirqs last disabled at (0): [<00000000>] 0x0
The warning is triggered by the fact that there is still a
wireless_device linked to the wiphy we are unregistering, due to
wiphy_unregister() now being called after net device unregister (performed
in wilc_netdev_cleanup()). Fix this warning by moving wiphy_unregister()
after wilc_netdev_cleanup() is nominal paths (ie: driver removal).
wilc_netdev_cleanup() ordering is left untouched in error paths in probe
function because net device is not registered in those paths (so the
warning can not trigger), yet the wiphy can still be registered, and we
still some cleanup steps from wilc_netdev_cleanup().
Fixes: 1be94490b6 ("wifi: wilc1000: unregister wiphy only if it has been registered")
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20250114-wilc1000_modprobe-v1-1-ad19d46f0c07@bootlin.com
The futex operation FUTEX_OP_ANDN is supposed to implement
*(int *)UADDR2 &= ~OPARG;
The s390 implementation just implements an AND instead of ANDN.
Add the missing bitwise not operation to oparg to fix this.
This is broken since nearly 19 years, so it looks like user space is
not making use of this operation.
Fixes: 3363fbdd6f ("[PATCH] s390: futex atomic operations")
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
The new option controls tests run on boot or module load. With the new
debugfs "run" dentry allowing to run tests on demand, an ability to disable
automatic tests run becomes a useful option in case of intrusive tests.
The option is set to true by default to preserve the existent behavior. It
can be overridden by either the corresponding module option or by the
corresponding config build option.
Link: https://lore.kernel.org/r/173015245931.4747.16419517391658830640.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Reviewed-by: Rae Moar <rmoar@google.com>
Acked-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The SQ and CQ ring heads are read twice - once for verifying that it's
within bounds, and once inside the loops copying SQE and CQE entries.
This is technically incorrect, in case the values could get modified
in between verifying them and using them in the copy loop. While this
won't lead to anything truly nefarious, it may cause longer loop times
for the copies than expected.
Read the ring head values once, and use the verified value in the copy
loops.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
For WCN6855, board ID specific NVM needs to be downloaded once board ID
is available, but the default NVM is always downloaded currently.
The wrong NVM causes poor RF performance, and effects user experience
for several types of laptop with WCN6855 on the market.
Fix by downloading board ID specific NVM if board ID is available.
Fixes: 095327fede ("Bluetooth: hci_qca: Add support for QTI Bluetooth chip wcn6855")
Cc: stable@vger.kernel.org # 6.4
Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Tested-by: Steev Klimaszewski <steev@kali.org> #Thinkpad X13s
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Allow sysfs to trigger hdev reset. This is required to recover devices
that are not responsive from userspace.
Signed-off-by: Hsin-chen Chuang <chharry@chromium.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The hdev->reset is never used now and the hdev->cmd_timeout actually
does reset. This patch changes the call path from
hdev->cmd_timeout -> vendor_cmd_timeout -> btusb_reset -> hdev->reset
, to
hdev->reset -> vendor_reset -> btusb_reset
Which makes it clear when we export the hdev->reset to a wider usage
e.g. allowing reset from sysfs.
This patch doesn't introduce any behavior change.
Signed-off-by: Hsin-chen Chuang <chharry@chromium.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Remove the cmd timeout count in btusb since we only ever allow one
command in flight at a time. We should always reset after a single
command times out.
Signed-off-by: Hsin-chen Chuang <chharry@chromium.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Replace ternary (condition ? "enable" : "disable") syntax with helpers
from string_choices.h because:
1. Simple function call with one argument is easier to read. Ternary
operator has three arguments and with wrapping might lead to quite
long code.
2. Is slightly shorter thus also easier to read.
3. It brings uniformity in the text - same string.
4. Allows deduping by the linker, which results in a smaller binary
file.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Remove resetting mt7921 before downloading the fw, as it may cause
command timeout when performing the reset.
Signed-off-by: Hao Qin <hao.qin@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
A NULL sock pointer is passed into l2cap_sock_alloc() when it is called
from l2cap_sock_new_connection_cb() and the error handling paths should
also be aware of it.
Seemingly a more elegant solution would be to swap bt_sock_alloc() and
l2cap_chan_create() calls since they are not interdependent to that moment
but then l2cap_chan_create() adds the soon to be deallocated and still
dummy-initialized channel to the global list accessible by many L2CAP
paths. The channel would be removed from the list in short period of time
but be a bit more straight-forward here and just check for NULL instead of
changing the order of function calls.
Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.
Fixes: 7c4f78cdb8 ("Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()")
Cc: stable@vger.kernel.org
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
We are now using the on-chip PMU node for power sequencing to manage the
enable/disable functionality of Bluetooth. Consequently, the inputs
previously marked as required under the Bluetooth node can be removed.
For instance, the enable GPIO is now managed by the PMU node with the
property bt-enable-gpios.
Signed-off-by: Janaki Ramaiah Thota <quic_janathot@quicinc.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
If insert an USB dongle which chip is not maintained in ic_id_table, it
will hit the NULL point accessed. Add a null point check to avoid the
Kernel Oops.
Fixes: b39910bb54 ("Bluetooth: Populate hci_set_hw_info for Intel and Realtek")
Reviewed-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Max Chou <max.chou@realtek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
devm_kstrdup() can return a NULL pointer on failure,but this
returned value in btbcm_get_board_name() is not checked.
Add NULL check in btbcm_get_board_name(), to handle kernel NULL
pointer dereference error.
Fixes: f9183eaad9 ("Bluetooth: btbcm: Use devm_kstrdup()")
Signed-off-by: Charles Han <hanchunchao@inspur.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The firmware-name property has been expanded to specify the names of NVM
and rampatch firmware for certain chips, such as the QCA6698 Bluetooth
chip. Although it shares the same IP core as the WCN6855, the QCA6698
has different RF components and RAM sizes, necessitating new firmware
files. This change allows for the configuration of NVM and rampatch in
DT.
Possible configurations:
firmware-name = QCA6698/hpnv21.bin, QCA6698/hpbtfw21.tlv;
firmware-name = QCA6698/hpnv21, QCA6698/hpbtfw21.tlv;
Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
It can be a bit hard to tell which parts of io_register_resize_rings()
are operating on shared memory, and which ones are not. And anything
reading or writing to those regions should really use the read/write
once primitives.
Hence add those, ensuring sanity in how this memory is accessed, and
helping document the shared nature of it.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Different connectivity boards may be attached to the same platform. For
example, QCA6698-based boards can support either a two-antenna or
three-antenna solution, both of which work on the sa8775p-ride platform.
Due to differences in connectivity boards and variations in RF
performance from different foundries, different NVM configurations are
used based on the board ID.
Therefore, in the firmware-name property, if the NVM file has an
extension, the NVM file will be used. Otherwise, the system will first
try the .bNN (board ID) file, and if that fails, it will fall back to
the .bin file.
Possible configurations:
firmware-name = "QCA6698/hpnv21";
firmware-name = "QCA6698/hpnv21.bin";
Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Expand the firmware-name property to specify the names of NVM and
rampatch firmware to load. This update will support loading specific
firmware (nvm and rampatch) for certain chips, like the QCA6698
Bluetooth chip, which shares the same IP core as the WCN6855 but has
different RF components and RAM sizes, requiring new firmware files.
We might use different connectivity boards on the same platform. For
example, QCA6698-based boards can support either a two-antenna or
three-antenna solution, both of which work on the sa8775p-ride platform.
Due to differences in connectivity boards and variations in RF
performance from different foundries, different NVM configurations are
used based on the board ID.
So In firmware-name, if the NVM file has an extension, the NVM file will
be used. Otherwise, the system will first try the .bNN (board ID) file,
and if that fails, it will fall back to the .bin file.
Possible configurations:
firmware-name = "QCA6698/hpnv21.bin", "QCA6698/hpbtfw21.tlv";
firmware-name = "QCA6698/hpnv21", "QCA6698/hpbtfw21.tlv";
firmware-name = "QCA6698/hpnv21.bin";
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
When a Bluetooth raw socket is open, the HCI event related to SCO
connection changes are not dispatched to the hci_event module, and
the underlying Bluetooth controller's USB Interface 1 will not be
updated accordingly.
This patch adds `isoc_alt` sysfs attribute, allowing user space
to update the alternate setting of the USB interface alternate
setting as needed.
Signed-off-by: Ying Hsu <yinghsu@chromium.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
hci_bdaddr_list_del_with_flags() was added in 2020's
commit 8baaa4038e ("Bluetooth: Add bdaddr_list_with_flags for classic
whitelist")
but has remained unused.
hci_remove_ext_adv_instance() was added in 2020's
commit eca0ae4aea ("Bluetooth: Add initial implementation of BIS
connections")
but has remained unused.
Remove them.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This marks LL Privacy as stable by removing its experimental UUID and
move its functionality to Device Flag (HCI_CONN_FLAG_ADDRESS_RESOLUTION)
which can be set by MGMT Device Set Flags so userspace retain control of
the feature.
Link: https://github.com/bluez/bluez/issues/1028
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
- mlo fixes for mt792x
- single wiphy multiband support for mt7996
- mt7915 stability fixes
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iF0EABECAB0WIQR10Rp9kadxD0kAQu/XfRQdAqdu9QUCZ4ZcCgAKCRDXfRQdAqdu
9YpCAJ9xr+zXiop4TVkNIPh/8ihD01vx0gCfbvEw5Ue70XxJgRtlgkHGfBFUxYs=
=qy7n
-----END PGP SIGNATURE-----
Merge tag 'mt76-for-kvalo-2025-01-14' of https://github.com/nbd168/wireless
mt76 patches for 6.14
- mlo fixes for mt792x
- single wiphy multiband support for mt7996
- mt7915 stability fixes
rtl8xxxu, rtlwifi and rtw88 fix field issues reported by users.
rtw89 is ongoing to implement MLO and fix issues during the development.
Major changes:
rtw88:
- support LED blinking
rtw89:
- support RTL8922AE-VS chip
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuyEnvMdOsBl1WjpdjlvZYmhshd8FAmeDKBgACgkQjlvZYmhs
hd9kLRAA2xzwzbtYWYXzJQH36rMg1rc6R8c1XkGKCydkwyjjnIltT2p/VIIBoNVF
mPgWVrU7PjNsmwLKPOyEHdewTRELEkfDmvvxZ2WXV7PAC3LP0myv8WMPeYHuAiti
oQ4Rtj5i6AVM9tOzYhPNz1SzQ6DjgRS0jhq2NkfxSnh2BrsGwrjJOnWzy1mh5oDw
9VeElJ0nyGAkeGAK9bMDMLCk6d0bvTaB/iVU+coK57Vc6Wtaf0ZhOnNQVQWVv1nj
cXOXQWm89lZNc/0eTbCvA73oNYYtJc4B8uucDgpNKbs/3O76sfVZag9MmKyHkeVs
OpoVYCp9TwYFidtA8G4fYQl1U59QhLYEtdu3tnF7o4CiL1QYOO/eWCTd23RmnkOq
E/iljSSOLOF22j+oLIMuE4CcVg5+Y6xIW8Pe5p6i8SJNq8dsnCJua2VL5nyTyJal
MJ5absGahDrAxUucZZzNNT8NBVc0iPIA3Z7DwtphGK+xBVtwGJ4nFJ24OzDEvdAP
X1xCVbSVUlBl9IWI5mg9cnR6IjQ9lkmco6Oi3ShzTPgBND7NNVrlKeeiL+KlwWOP
UEuzsVZ06L9OTw2PfyrXbllsmWfLSYR5BSrzpYOkdsAcQC2z+W81I4HPESrMYued
VT7OTQDQZ+K5R5kbj9c/Kqg1DucaVIfXsjFaW0r+Aw9G6M/j70I=
=Vs7w
-----END PGP SIGNATURE-----
Merge tag 'rtw-next-2025-01-12' of https://github.com/pkshih/rtw
rtw-next patches for v6.14
rtl8xxxu, rtlwifi and rtw88 fix field issues reported by users.
rtw89 is ongoing to implement MLO and fix issues during the development.
Major changes:
rtw88:
- support LED blinking
rtw89:
- support RTL8922AE-VS chip
