| Age | Commit message (Collapse) | Author |
|---|
|
On at least an ASRock 990FX Extreme 4 with a VIA VT6330, the devices
have not yet been enabled by the first time ata_acpi_cbl_80wire() is
called. This means that the ata_for_each_dev loop is never entered,
and a 40 wire cable is assumed.
The VIA controller on this board does not report the cable in the PCI
config space, thus having to fall back to ACPI even though no SATA
bridge is present.
The _GTM values are correctly reported by the firmware through ACPI,
which has already set up faster transfer modes, but due to the above
the controller is forced down to a maximum of UDMA/33.
Resolve this by modifying ata_acpi_cbl_80wire() to directly return the
cable type. First, an unknown cable is assumed which preserves the mode
set by the firmware, and then on subsequent calls when the devices have
been enabled, an 80 wire cable is correctly detected.
Since the function now directly returns the cable type, it is renamed
to ata_acpi_cbl_pata_type().
Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
Link: https://lore.kernel.org/r/20250519085945.1399466-1-tasos@tasossah.com
Signed-off-by: Niklas Cassel <cassel@kernel.org>
|
|
The controller has a hardware bug that can hard hang the system when
doing ATAPI DMAs without any trace of what happened. Depending on the
device attached, it can also prevent the system from booting.
In this case, the system hangs when reading the ATIP from optical media
with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an
Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4,
running at UDMA/33.
The issue can be reproduced by running the same command with a cygwin
build of cdrecord on WinXP, although it requires more attempts to cause
it. The hang in that case is also resolved by forcing PIO. It doesn't
appear that VIA has produced any drivers for that OS, thus no known
workaround exists.
HDDs attached to the controller do not suffer from any DMA issues.
Cc: stable@vger.kernel.org
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/916677
Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
Link: https://lore.kernel.org/r/20250519085508.1398701-1-tasos@tasossah.com
Signed-off-by: Niklas Cassel <cassel@kernel.org>
|
|
Check the return value of kzalloc() and exit early to avoid a potential
NULL pointer dereference.
Cc: stable@vger.kernel.org
Fixes: 4f8ef33dd44a ("ASoC: soc_sdw_utils: skip the endpoint that doesn't present")
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20250610103225.1475-2-thorsten.blum@linux.dev
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Replace `/// SAFETY` comments in doc comments with proper `# Safety`
sections, as per rustdoc conventions.
Also mark the C FFI callbacks as `unsafe` to correctly reflect their
safety requirements.
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Closes: https://github.com/Rust-for-Linux/linux/issues/1169
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
Davide Caratti <dcaratti@redhat.com> says:
drop reasons have been recently introduced to improve debuggability of
networking stack. This series introduces drop reasons in the RX path
of the CAN protocol stack.
Link: https://patch.msgid.link/20250604160605.1005704-1-dcaratti@redhat.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
`vc4_hdmi_audio_init` calls `devm_snd_dmaengine_pcm_register` which may
return EPROBE_DEFER. Calling `drm_connector_hdmi_audio_init` adds a
child device. The driver model docs[1] state that adding a child device
prior to returning EPROBE_DEFER may result in an infinite loop.
[1] https://www.kernel.org/doc/html/v6.14/driver-api/driver-model/driver.html
Fixes: 9640f1437a88 ("drm/vc4: hdmi: switch to using generic HDMI Codec infrastructure")
Signed-off-by: Gabriel Dalimonte <gabriel.dalimonte@gmail.com>
Link: https://lore.kernel.org/r/20250601-vc4-audio-inf-probe-v2-1-9ad43c7b6147@gmail.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
sock_queue_rcv_skb() can fail because of lack of memory resources: use
drop reasons and pass the receiving socket to the tracepoint, so that
it's possible to better locate/debug such events.
Tested with:
| # modprobe vcan echo=1
| # ip link add name vcan2 type vcan
| # ip link set dev vcan2 up
| # ./netlayer/tst-proc 1 &
| # bg
| # while true ; do perf record -e skb:kfree_skb -aR -- \
| > ./raw/tst-raw-sendto vcan2 ; perf script ; done
| [...]
| tst-raw-sendto 10942 [000] 506428.431856: skb:kfree_skb: skbaddr=0xffff97cec38b4200 rx_sk=0xffff97cf0f75a800 protocol=12 location=raw_rcv+0x20e reason: SOCKET_RCVBUF
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Link: https://patch.msgid.link/20250604160605.1005704-3-dcaratti@redhat.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
Besides the existing pr_warn_once(), use skb drop reasons in case AF_CAN
layer drops non-conformant CAN{,FD,XL} frames, or conformant frames
received by "wrong" devices, so that it's possible to debug (and count)
such events using existing tracepoints:
| # perf record -e skb:kfree_skb -aR -- ./drv/canfdtest -v -g -l 1 vcan0
| # perf script
| [...]
| canfdtest 1123 [000] 3893.271264: skb:kfree_skb: skbaddr=0xffff975703c9f700 rx_sk=(nil) protocol=12 location=can_rcv+0x4b reason: CAN_RX_INVALID_FRAME
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Link: https://patch.msgid.link/20250604160605.1005704-2-dcaratti@redhat.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
The mailbox framework has a single inflight request at a time. If
a request is sent while another is still active, it will be queued
to the mailbox core ring buffer.
ACPM protocol did not serialize the calls to the mailbox subsystem so we
could start the timeout ticks in parallel for multiple requests, while
just one was being inflight.
Consider a hypothetical case where the xfer timeout is 100ms and an ACPM
transaction takes 90ms:
| 0ms: Message #0 is queued in mailbox layer and sent out, then sits
| at acpm_dequeue_by_polling() with a timeout of 100ms
| 1ms: Message #1 is queued in mailbox layer but not sent out yet.
| Since send_message() doesn't block, it also sits at
| acpm_dequeue_by_polling() with a timeout of 100ms
| ...
| 90ms: Message #0 is completed, txdone is called and message #1 is sent
| 101ms: Message #1 times out since the count started at 1ms. Even though
| it has only been inflight for 11ms.
Fix the problem by moving mbox_send_message() and mbox_client_txdone()
immediately after the message has been written to the TX queue and while
still keeping the ACPM TX queue lock. We thus tie together the TX write
with the doorbell ring and mark the TX as done after the doorbell has
been rung. This guarantees that the doorbell has been rang before
starting the timeout ticks. We should also see some performance
improvement as we no longer wait to receive a response before ringing
the doorbell for the next request, so the ACPM firmware shall be able to
drain faster the TX queue. Another benefit is that requests are no
longer able to ring the doorbell one for the other, so it eases
debugging. Finally, the mailbox software queue will always contain a
single doorbell request due to the serialization done at the ACPM TX
queue level. Protocols like ACPM, that handle their own hardware queues
need a passthrough mailbox API, where they are able to just ring the
doorbell or flip a bit directly into the mailbox controller. The mailbox
software queue mechanism, the locking done into the mailbox core is not
really needed, so hopefully this lays the foundation for a passthrough
mailbox API.
Reported-by: André Draszik <andre.draszik@linaro.org>
Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver")
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/r/20250606-acpm-timeout-v2-1-306b1aa07a6c@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
|
|
Since the introduction of alloc_candev_mqs() and friends, there is no
longer a need to allocate a generic network device and perform explicit
CAN-specific setup. Remove the code showing this setup, and document
alloc_candev_mqs() instead.
Fixes: 39549eef3587f1c1 ("can: CAN Network device driver and Netlink interface")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/c0f9a706ba31f1a49eb72e58526cd294d97a1ce9.1748865431.git.geert+renesas@glider.be
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
This config option was renamed, update the defconfig to match.
Fixes: 8d3b5f637546 ("phy: move phy-qcom-snps-eusb2 out of its vendor sub-directory")
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250523115630.459249-3-casey.connolly@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
|
|
Vincent Mailhol <mailhol.vincent@wanadoo.fr> says:
An RFC was sent last weekend to kick-off the discussion of the
introduction of CAN XL [1]. While the series received some positive
feedback, it is far from completion. Some work is still needed to:
- adjust the nesting of the IFLA_CAN_XL_DATA_BITTIMING_CONST in the
netlink interface
- add the CAN XL PWM configuration
and this TODO list may grow if more feedback is received.
Regardless of this, the RFC started with a tree wide refactor followed
by a set of trivial patches to do some clean-up and some renaming in
preparation of the introduction of CAN XL.
This series just contains those preparation patch which were cherry
picked from the RFC and rebased on of top of linux-can-next/main:
- the first patch is purely cosmetic and fixes a trivial tabulation
mistake.
- the last three patches do some renaming: both the CAN FD and the
CAN XL have databittiming parameters. In order not to get confused
once CAN XL will be introduced, many symbols are modified to
explicitly add CAN FD in their names.
The goal is to have those merged first to remove some overhead from
the netlink CAN XL main series before tacking care of the other
comments.
[1] [RFC] can: netlink: add CAN XL
Link: https://lore.kernel.org/linux-can/20241110155902.72807-16-mailhol.vincent@wanadoo.fr
Link: https://patch.msgid.link/20241112165118.586613-7-mailhol.vincent@wanadoo.fr
[mkl: adjusted commit message, as patch 1 of the original series is already mainline]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
Add Yang Shen as the maintainer of the HiSilicon GPIO driver,
replacing Jay Fang.
Signed-off-by: Yang Shen <shenyang39@huawei.com>
Reviewed-by: Jay Fang <f.fangjian@huawei.com>
Link: https://lore.kernel.org/r/20250529034023.3780376-1-shenyang39@huawei.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
I'm moving all my kernel work over to using my kernel.org email address.
Update .mailmap and MAINTAINER entries still using hdegoede@redhat.com.
Signed-off-by: Hans de Goede <hansg@kernel.org>
Link: https://lore.kernel.org/r/20250609143558.42941-2-hansg@kernel.org
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Bump the module version.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Link: https://lore.kernel.org/r/20250609184659.7210-6-stuart.w.hayes@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The dell_rbu driver will use memset() to clear the data held by each
packet when it is no longer needed (when the driver is unloaded, the
packet size is changed, etc).
The amount of memory that is cleared (before this patch) is the normal
packet size. However, the last packet in the list may be smaller.
Fix this to only clear the memory actually used by each packet, to prevent
it from writing past the end of data buffer.
Because the packet data buffers are allocated with __get_free_pages() (in
page-sized increments), this bug could only result in a buffer being
overwritten when a packet size larger than one page is used. The only user
of the dell_rbu module should be the Dell BIOS update program, which uses
a packet size of 4096, so no issues should be seen without the patch, it
just blocks the possiblity.
Fixes: 6c54c28e69f2 ("[PATCH] dell_rbu: new Dell BIOS update driver")
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Link: https://lore.kernel.org/r/20250609184659.7210-5-stuart.w.hayes@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Pass the correct list head to list_for_each_entry*() when looping through
the packet list.
Without this patch, reading the packet data via sysfs will show the data
incorrectly (because it starts at the wrong packet), and clearing the
packet list will result in a NULL pointer dereference.
Fixes: d19f359fbdc6 ("platform/x86: dell_rbu: don't open code list_for_each_entry*()")
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Link: https://lore.kernel.org/r/20250609184659.7210-3-stuart.w.hayes@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Fix a sparse lock context warning.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Link: https://lore.kernel.org/r/20250609184659.7210-2-stuart.w.hayes@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
commit 5b1122fc4995f ("platform/x86/amd/pmf: fix cleanup in
amd_pmf_init_smart_pc()") adjusted the error handling flow to use a ladder
but this isn't actually needed because work is only scheduled in
amd_pmf_start_policy_engine() and with device managed cleanups pointers
for allocations don't need to be freed.
Adjust the error flow to a single call to amd_pmf_deinit_smart_pc() for
the cases that need to clean up.
Cc: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/20250512211154.2510397-4-superm1@kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20250522003457.1516679-4-superm1@kernel.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
If any of the tee init fails, pass up the errors and clear the tee_ctx
pointer. This will prevent cleaning up multiple times.
Fixes: ac052d8c08f9d ("platform/x86/amd/pmf: Add PMF TEE interface")
Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/20250512211154.2510397-3-superm1@kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20250522003457.1516679-3-superm1@kernel.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
If setting up smart PC fails for any reason then this can lead to
a double free when unloading amd-pmf. This is because dev->buf was
freed but never set to NULL and is again freed in amd_pmf_remove().
To avoid subtle allocation bugs in failures leading to a double free
change all allocations into device managed allocations.
Fixes: 5b1122fc4995f ("platform/x86/amd/pmf: fix cleanup in amd_pmf_init_smart_pc()")
Link: https://lore.kernel.org/r/20250512211154.2510397-2-superm1@kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20250522003457.1516679-2-superm1@kernel.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The only purpose of the tdc_mask variable is to check whether or not
any tdc flags (CAN_CTRLMODE_TDC_{AUTO,MANUAL}) were provided. At this
point, the actual value of the flags do no matter any more because
these can be deduced from some other information.
Rename the tdc_mask variable into fd_tdc_flag_provided to make this
more explicit. Note that the fd_ prefix is added in preparation of the
introduction of CAN XL.
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Link: https://patch.msgid.link/20241112165118.586613-12-mailhol.vincent@wanadoo.fr
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
With the introduction of CAN XL, a new can_xl_tdc_is_enabled() helper
function will be introduced later on. Rename can_tdc_is_enabled() into
can_fd_tdc_is_enabled() to make it more explicit that this helper is
meant for CAN FD.
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Link: https://patch.msgid.link/20241112165118.586613-11-mailhol.vincent@wanadoo.fr
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
With the introduction of CAN XL, a new CAN_CTRLMODE_XL_TDC_MASK will
be introduced later on. Because CAN_CTRLMODE_TDC_MASK is not part of
the uapi, rename it to CAN_CTRLMODE_FD_TDC_MASK to make it more
explicit that this mask is meant for CAN FD.
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Link: https://patch.msgid.link/20241112165118.586613-10-mailhol.vincent@wanadoo.fr
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
commit cfd98c838cbe ("can: netlink: move '=' operators back to
previous line (checkpatch fix)") inadvertently introduced a tabulation
between the IFLA_CAN_DATA_BITTIMING_CONST array index and the equal
sign.
Remove it.
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Link: https://patch.msgid.link/20241112165118.586613-9-mailhol.vincent@wanadoo.fr
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
When the DMA mode is changed on the (still real!) SB AWE32 after
playing a stream and closing, the previous DMA setup was still
silently kept, and it can confuse the hardware, resulting in the
unexpected noises. As a workaround, enforce the disablement of DMA
setups when the DMA setup is changed by the kcontrol.
https://bugzilla.kernel.org/show_bug.cgi?id=218185
Link: https://patch.msgid.link/20250610064322.26787-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
When a PCM stream is already running, one shouldn't change the DMA
mode via kcontrol, which may screw up the hardware. Return -EBUSY
instead.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218185
Link: https://patch.msgid.link/20250610064322.26787-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The GU605C has similar audio hardware to the GU605M so apply the
same quirk.
Note that in the linked bugzilla there are two separate problems
with the GU605C. This patch fixes one of the problems, so I haven't
added a Closes: tag.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reported-by: Nick Karaolidis <nick@karaolidis.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=220152
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20250609102125.63196-1-rf@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The built-in mic of ASUS VivoBook X513EA is broken recently by the
fix of the pin sort. The fixup ALC256_FIXUP_ASUS_MIC_NO_PRESENCE
is working for addressing the regression, too.
Fixes: 3b4309546b48 ("ALSA: hda: Fix headset detection failure due to unstable sort")
Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20250610035607.690771-1-chris.chiu@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Madhavan Srinivasan:
- a couple of fixes for out of bounds issues in memtrace and vas
Thanks to Ritesh Harjani (IBM), Haren Myneni, and Jonathan Greental
* tag 'powerpc-6.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/vas: Return -EINVAL if the offset is non-zero in mmap()
powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmap
|
|
The user space calls mmap() to map VAS window paste address
and the kernel returns the complete mapped page for each
window. So return -EINVAL if non-zero is passed for offset
parameter to mmap().
See Documentation/arch/powerpc/vas-api.rst for mmap()
restrictions.
Co-developed-by: Jonathan Greental <yonatan02greental@gmail.com>
Signed-off-by: Jonathan Greental <yonatan02greental@gmail.com>
Reported-by: Jonathan Greental <yonatan02greental@gmail.com>
Fixes: dda44eb29c23 ("powerpc/vas: Add VAS user space API")
Signed-off-by: Haren Myneni <haren@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20250610021227.361980-2-maddy@linux.ibm.com
|
|
AP mode can be enabled again for SDIO now that the problem was fixed
in commit b2effcdc2379 ("wifi: rtw88: sdio: map mgmt frames to queue
TX_DESC_QSEL_MGMT") and commit fc5f5a0ec463 ("wifi: rtw88: sdio: call
rtw_sdio_indicate_tx_status unconditionally").
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/5ac60c1c-9cc8-41b8-871c-a067e74f70ea@gmail.com
|
|
The RTW_WCPU_11AC and RTW_WCPU_11N enums are used to identify two
types of microcontrollers used in Realtek chips, but these names are
misleading. The "11AC" type was also used in 11n devices (e.g.
RTL8733BU, not supported by rtw88), and the "11N" type was also used
in 11ac devices (RTL8821AU, RTL8812AU).
Rename RTW_WCPU_11AC to RTW_WCPU_3081 and RTW_WCPU_11N to RTW_WCPU_8051.
(8051 is well known. It's less clear what 3081 is, but the out of tree
drivers use this name.)
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/bfb1099c-db52-4b25-b111-17ab712e9404@gmail.com
|
|
memtrace mmap issue has an out of bounds issue. This patch fixes the by
checking that the requested mapping region size should stay within the
allocated region size.
Reported-by: Jonathan Greental <yonatan02greental@gmail.com>
Fixes: 08a022ad3dfa ("powerpc/powernv/memtrace: Allow mmaping trace buffers")
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20250610021227.361980-1-maddy@linux.ibm.com
|
|
Newer firmware requires the driver to pass channel information
when switching from normal mode to low power mode; otherwise it
will result in poor RX beacon performance.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250606020437.17160-1-pkshih@realtek.com
|
|
The RF 0x18 register stores radio frequency domain parameters, including
band, center channel and bandwidth. This information is used in RF
domain. Add a chip_ops to retrieve the RF 0x18 value, which allows
driver to query for a specific channel.
No logic is changed.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250606020408.17035-1-pkshih@realtek.com
|
|
The newer firmware add new C2H event class 27, which is to report WiFi
role status. Since rtw89 doesn't use the status yet, add a dummy handler
to avoid warning:
rtw89_8922ae 0000:03:00.0: MAC c2h class 27 func 0 not support
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250606020302.16873-5-pkshih@realtek.com
|
|
Add new IQK firmware command format v1 (with suffix), and rename original
command format to v0 for older firmware.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250606020302.16873-4-pkshih@realtek.com
|
|
Append a new field for RFE (RF Front End) type to RF TSSI H2C command.
FW has forward compatibility when handling this H2C command, so just
need to consider backward cases in FW point of view.
| old FW | new FW
------------------------------
old driver | O | X
------------------------------
new driver | O | O
Currently only RTL8922A uses this RF TSSI H2C command. Increase its FW
format max and will let new FW binary align with it. Then, old driver
won't load new FW.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250606020302.16873-3-pkshih@realtek.com
|
|
Intermittent beacon loss from a specific AP causes the connection
to be lost. Increasing the beacon loss count can make the
connection more stable.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250606020302.16873-2-pkshih@realtek.com
|
|
When a host is configured with a few LUNs and I/O is running, injecting
FC faults repeatedly leads to path recovery problems. The LUNs have 4
paths each and 3 of them come back active after say an FC fault which
makes 2 of the paths go down, instead of all 4. This happens after
several iterations of continuous FC faults.
Reason here is that we're returning an I/O error whenever we're
encountering sense code 06/04/0a (LOGICAL UNIT NOT ACCESSIBLE, ASYMMETRIC
ACCESS STATE TRANSITION) instead of retrying.
Signed-off-by: Rajashekhar M A <rajs@netapp.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Link: https://lore.kernel.org/r/20250606135924.27397-1-hare@kernel.org
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Currently storvsc_timeout is only used in storvsc_sdev_configure(), and
5s and 10s are used elsewhere. It turns out that rarely the 5s is not
enough on Azure, so let's use storvsc_timeout everywhere.
In case a timeout happens and storvsc_channel_init() returns an error,
close the VMBus channel so that any host-to-guest messages in the
channel's ringbuffer, which might come late, can be safely ignored.
Add a "const" to storvsc_timeout.
Cc: stable@kernel.org
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Link: https://lore.kernel.org/r/1749243459-10419-1-git-send-email-decui@microsoft.com
Reviewed-by: Long Li <longli@microsoft.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
The 4-octet EHT MCS/NSS subfield is only used for 20 MHz-only
non-AP STA. Correct the interpretation of this subfield to
prevent improper rate limitations.
Fixes: f1dfcee2eae9 ("wifi: rtw89: Correct EHT TX rate on 20MHz connection")
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250605114207.12381-6-pkshih@realtek.com
|
|
Adding EHT physts and adjust IE bitmap initialization. This setting
is for PHY statistic gathering, won't effect functionality.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250605114207.12381-5-pkshih@realtek.com
|
|
To support channel switch on STA mode, declare IEEE80211_HW_CHANCTX_STA_CSA
and implement ieee80211_ops::switch_vif_chanctx. Handling of CSA procedure
still relies on mac80211 SW flow, since FW doesn't support chanctx offload.
To support channel switch on AP mode, declare WIPHY_FLAG_HAS_CHANNEL_SWITCH
and implement ieee80211_ops::channel_switch_beacon additionally.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250605114207.12381-4-pkshih@realtek.com
|
|
Previously, default chandef is configured if no chanctx is active, i.e. no
chanctx is assigned to some vif. For normal cases, it's fine. However, for
impending CSA support, need to consider that one chanctx may be added, or
called registered, ahead without being assigned immediately. Then, it will
keep inactive, and might be covered by the default one when re-calculating
chanctxs happens in certain sequences. So now, don't re-config the default
chandef unless no chanctx is registered.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250605114207.12381-3-pkshih@realtek.com
|
|
Originally, the logic for setting bits was wrapped inside the configuring
function. However, raw clearing bits, clear_bit, was called directly. To be
more paired and more understandable. Concentrate the logic of them into the
same function.
(don't change logic at all)
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250605114207.12381-2-pkshih@realtek.com
|
|
rtw89_sar_set_src() may be called at driver early init phase when
applying SAR configuration via ACPI. wiphy lock is not held there.
Since the assertion was initially added for rtw89_apply_sar_common() call
path and may be helpful for other places in future changes, keep it but
move it under RTW89_FLAG_PROBE_DONE test.
Found by Linux Verification Center (linuxtesting.org).
Fixes: 88ca3107d2ce ("wifi: rtw89: sar: add skeleton for SAR configuration via ACPI")
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250604161339.119954-2-pchelkin@ispras.ru
|
|
The following assertion is triggered on the rtw89 driver startup. It
looks meaningless to hold wiphy lock on the early init stage so drop the
assertion.
WARNING: CPU: 7 PID: 629 at drivers/net/wireless/realtek/rtw89/sar.c:502 rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core]
CPU: 7 UID: 0 PID: 629 Comm: (udev-worker) Not tainted 6.15.0+ #29 PREEMPT(lazy)
Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN50WW 09/27/2024
RIP: 0010:rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core]
Call Trace:
<TASK>
rtw89_sar_init+0x68/0x2c0 [rtw89_core]
rtw89_core_init+0x188e/0x1e50 [rtw89_core]
rtw89_pci_probe+0x530/0xb50 [rtw89_pci]
local_pci_probe+0xd9/0x190
pci_call_probe+0x183/0x540
pci_device_probe+0x171/0x2c0
really_probe+0x1e1/0x890
__driver_probe_device+0x18c/0x390
driver_probe_device+0x4a/0x120
__driver_attach+0x1a0/0x530
bus_for_each_dev+0x10b/0x190
bus_add_driver+0x2eb/0x540
driver_register+0x1a3/0x3a0
do_one_initcall+0xd5/0x450
do_init_module+0x2cc/0x8f0
init_module_from_file+0xe1/0x150
idempotent_init_module+0x226/0x760
__x64_sys_finit_module+0xcd/0x150
do_syscall_64+0x94/0x380
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Found by Linux Verification Center (linuxtesting.org).
Fixes: 88ca3107d2ce ("wifi: rtw89: sar: add skeleton for SAR configuration via ACPI")
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250604161339.119954-1-pchelkin@ispras.ru
|
|
Rename RTW89_FLAG_FORBIDDEN_TRACK_WROK -> RTW89_FLAG_FORBIDDEN_TRACK_WORK.
Found by Linux Verification Center (linuxtesting.org).
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250603153124.188755-1-pchelkin@ispras.ru
|
